10 جنبه چالش برانگیز مهندسی نرم افزار

بررسی کامل مهندسی نرم افزار

دسته بندی

آخرین آپدیت

1400/06/10

زمان خواندن

6 دقیقه

پیمان احمدی هستم موسس سایت تیک پارس،در زمینه طراحی و برنامه نویسی سایت و اپلیکیشن فعالیت دارم

جدیدترین مقاله سایت

دسته بندی

آخرین آپدیت

1400/06/10

زمان خواندن

6 دقیقه

10 جنبه چالش برانگیز مهندسی نرم افزار

 بررسی کامل مهندسی نرم افزار و نحوه ی استفاده ی آن در حوزه های گوناگون و 10 نوع آن را مورد بررسی قرار خوایم داد.

  •  
  •  
  • 1. پشتیبان گیری و جلوگیری از حذف تصادفی
  •  

آیا تا به حال چیزی را پیش از موعد حذف کرده اید تا بدانید پشتیبان وجود ندارد؟ یک قانون خوب این است که قبل از حذف هر چیزی سه بار بررسی کنید. اگر ما در محیط ، منطقه ، طرحواره پایگاه داده یا سطل S3 مناسب هستیم ، ممکن است شامل بررسی متقابل باشد.
علاوه بر این ، روشهای زیادی برای کاهش تأثیر حذف ناخواسته وجود دارد:
می توانید نسخه بندی را در سطل های ذخیره سازی ابر (به عنوان مثال AWS S3) فعال کنید
می توانید پشتیبان گیری خودکار را پیکربندی کنید
می توانید دسترسی را محدود کنید تا فقط چند نفر بتوانند چیزها را حذف کنند
بسیاری از پایگاه های داده دارای ویژگی های بازیابی اطلاعات اضافی مانند سفر در زمان هستند ، به شما این امکان را می دهند که به زمان گذشته برگردید و درخواست هایی را تا قبل از حذف داده ها انجام دهید (به عنوان مثال ، Snowflake ، Databricks ، BigQuery).

 

  • 2. نامگذاری اشیاء


همه ارائه دهندگان عمده ابر خدمات ذخیره سازی اشیا را ارائه می دهند. اکثر آنها (AWS S3 یا GCP GCS) داده ها را در سطل ذخیره می کنند. مایکروسافت نام "ظروف" را به جای "سطل" برای Azure Blob Storage انتخاب کرد.
چرا این نامگذاری گیج کننده است؟
دلیل آن این است که ظروف معمولاً با نمونه های در حال اجرا تصاویر Docker مرتبط هستند ، نه با ذخیره اشیاء BLOB. این مثال نشان می دهد که حتی بزرگترین شرکت های فناوری در جهان نیز گاهی تصمیمات نامگذاری را اشتباه می گیرند.
یکی از همکاران من اغلب این نقل قول را که به زیبایی خلاصه می کند ، تکرار می کند:
"فقط دو مورد سخت در علوم کامپیوتر وجود دارد: نامعتبر بودن حافظه پنهان و نامگذاری موارد." - فیل کارلتون

 

  • 3. بررسی کد


محصولات فناوری عالی به ندرت در خلا ایجاد می شوند - زمانی پدیدار می شوند که چندین فرد باهوش در حل مشکلات چالش برانگیز یکدیگر را پشتیبانی می کنند. به همین دلیل بازخورد و بررسی کد بسیار مهم است. آنها به عنوان پایه ای برای بحث های سازنده ای هستند که منجر به فرآیندهای مهندسی بهتر و کد بهتر می شود.
نه: "LGTM!" بنویسید و درخواست کشش را یک دقیقه پس از دریافت آن تأیید کنید.
انجام دهید: برای درک کد و مقاصد پشت آن زمان لازم را صرف کنید و سوال کنید که آیا همه چیز مطابق انتظار کار می کند یا خیر.
اکثر مهندسانی که درخواست های کشش ایجاد می کنند واقعاً می خواهند بازخورد کامل شما را بشنوند و از تجربه شما درس بگیرند. آنها برای تشخیص اشتباهات و مسائلی که ممکن است در مورد آنها فکر نمی کردند ، به شما تکیه می کنند.

 

  • 4. تعریف مسئله


احتمالاً در حرفه خود بارها با آن روبرو شده اید. شخصی به شما بلیط اختصاص داد که می گوید: "XYZ انجام دهید" بدون اینکه دلیل آن را مشخص کنید. از قبل تصور می شود که XYZ راه حل مناسب برای این مشکل است و شما باید به سادگی آن را انجام دهید. اما هنگامی که شروع به غواصی عمیق تر در موضوع واقعی می کنید ، متوجه می شوید که XYZ ممکن است روش بهینه نباشد.
Don't: یک بلیط ایجاد کنید که رویکرد خاصی مانند "ایجاد یک اسکریپت که اطلاعات X را جمع آوری می کند و این داده ها را به عنوان پیوست ایمیل فایل Excel با سرویس گیرنده ABC به اشتراک می گذارد."
انجام دهید: یک بلیط ایجاد کنید که مشکل را مشخص کند: "مشتری ABC باید روزانه اطلاعات مربوط به X را دریافت کند. با مشتری صحبت کنید و بهترین رابط را برای اشتراک گذاری این داده ها به روشی مطمئن و مطمئن پیدا کنید. "
همیشه مفید است که یک بلیط یا داستان کاربر مشکل و ذینفعان دخیل را مشخص کند. ممکن است راه حل های بالقوه را پیشنهاد دهد ، اما دقیقاً آنچه باید انجام شود را تجویز نمی کند مگر اینکه در این مورد واقعاً مطمئن باشید. پس از مشخص شدن مشکل ، مهندسان آنقدر باهوش هستند که بهترین راه ها را برای مقابله با آن پیدا کنند.

 

  • 5. تصمیمات معماری و طراحی


تصمیمات معماری به طور معمول عواقب گسترده ای دارد. پس از اجرایی شدن موارد ، "واگرد" آنها (به عنوان مثال پروژه های مهاجرت وقت گیر) گران است.
با این وجود ، اغلب ما برای ارزیابی گزینه های کافی وقت نمی گذاریم و درخواست بازخورد نمی کنیم. محبوب ترین ابزار ممکن است لزوماً بهترین ابزار برای مشکل موجود نباشد.
انجام ندهید: برای پیاده سازی اولین پیش نویس طرح یا محبوب ترین ابزار عجله کنید.
انجام دهید: برای ارزیابی اینکه کدام معماری یا طرح ها نامزدهای مناسبی برای مشکل موجود هستند وقت بگذارید. اثبات مفاهیم را اجرا کنید از سایر مهندسان ، ذینفعان و مشاوران خارجی برای بازخورد بخواهید. گزینه های مختلف را در عمل آزمایش کنید و سپس تصمیم بگیرید که چه چیزی بهتر عمل می کند.

 

  • 6. همسویی با سایر تیم ها


گاهی اوقات رسیدن به توافق در مورد استانداردهای مشترک نیمی از راه است. عدم برقراری ارتباط با تیم های دیگر ممکن است منجر به اصطکاک و درگیری شود.
به عنوان مثال ، بسیاری از تیم های داده در سال های اخیر سرمایه گذاری زیادی بر روی انبارهای داده ابری ، سیستم عامل های جذب داده و ابزارهای تحول مبتنی بر SQL کرده اند. سپس ، آنها شروع به حمایت کردند که همه باید از این پس از SQL برای حل تمام مشکلات تحلیلی خود استفاده کنند.
با پیروی از این توصیه ، ممکن است تصور شود که ما دیگر نیازی به خوشه های توزیع شده مانند Dask یا Spark نداریم. اما در تلاش برای استانداردسازی (فقط) SQL ، تیم های دیگر را فراموش می کنیم. در مورد دانشمندان داده و محققان کمی چطور؟
SQL برای حل مشکلات آنها کافی نیست. همین امر در مورد نیاز به ارائه داده ها برای مصرف توسط API ها ، اتوماسیون فرآیندها و بسیاری موارد کاربرد جالب دیگر که از داده ها بیشتر از گزارش استفاده می کند ، صادق است. پایتون برای موارد استفاده بسیار بهتر خواهد بود.
به طور مشابه ،
پل سینگمن
 در این مقاله پیشنهاد شده است که توافق بر سر تعریف مشترک داده و رابط بین مهندسین نرم افزار و تیم های داده گاهی اوقات نیاز به مشاغل ETL را برطرف می کند. توجه داشته باشید که این امر تنها در موارد کمی هنگام ساخت ابزارهایی بر اساس معماری pub-sub امکان پذیر است.

 

  • 7. ستایش در جایی که شایسته است


ستایش یا تعریف و تمجید گاهی ممکن است ناخوشایند به نظر برسد ، اما همه ما تا حدی به دنبال تأیید هستیم. دیدن تأثیر مثبت یک "شغل عالی!" بسیار جذاب است. مراقب ستایش های دروغین باشید ؛ مردم می توانند تشخیص دهند که تعارف غیر صادقانه است.

 

  • 8. استخدام


پیدا کردن و مدیریت استعدادهای مهندسی این روزها چالش برانگیز است. اما استخدام زودهنگام و سپس اخراج افراد می تواند به فرهنگ شرکت و روحیه تیم آسیب برساند. بسیاری رویکرد "جهنم بله یا خیر" را اتخاذ می کنند. هر استراتژی را که انتخاب می کنید ، بهتر است وقت بگذارید و در مورد تیمی که می خواهید بسازید عمدی عمل کنید.

 

  • 9. خواندن سیاهه های مربوط


برخی از مسائل مهندسی ناشی از نخواندن صحیح گزارش ها است.
یک داستان واقعی: در اولین پروژه مشاوره ام ، ما روی یک خوشه Hadoop کار می کردیم ، و من برای فهمیدن اینکه چرا کار Spark من شکست خورده است ، مشکل داشتم. من از یکی از همکارانم پرسیدم ، او من را با یک خطای خط پشته جاوا ، که به نظر می رسید در فایل های log نادیده گرفته ام ، نشان داد.
باید اعتراف کنم که او درست می گفت - پاسخ در سیاهههای مربوط بود. من وقت کافی برای خواندن کامل آن نداشتم.
اگر می خواهید از موقعیت های شرم آور مشابه جلوگیری کنید و به طور اتفاقی از سرور استفاده می کنید ، نگاهی به Dashbird بیندازید. این پلتفرم به شما امکان می دهد تا سیاهههای مربوط به تمام منابع AWS بدون سرور خود را فیلتر کنید.
نیازی به تنظیم هرگونه کنترل کننده سفارشی ورود به سیستم در کد خود ندارید. Dashbird به طور خودکار سیاهههای مربوط را مستقیماً از API های CloudWatch می کشد تا نیازی به تنظیم هیچ چیزی نداشته باشید.
سپس می توانید تمام گزارش های خود را در زمان واقعی از طریق UI ، از جمله آثار X-Ray جستجو کنید.

جستجوی ثبت جهانی در Dashbird.io - تصویر توسط نویسنده

 

  • 10. برقراری ارتباط


آیا می دانستید که اکثر پروژه های فناوری اطلاعات به دلیل مشکلات ارتباطی شکست می خورند؟ ما ابزارهای ارتباطی بیشتری نسبت به گذشته در اختیار داریم ، اما یافتن تعادل بین ارتباط بیش از حد و بیش از حد هنوز چالش برانگیز است.
نه: هر بیست دقیقه پنجاه پیام کوتاه ارسال کنید.
انجام دهید: به مواردی که باید به آنها اطلاع دهید فکر کنید ، آن را بنویسید و دریابید که بهترین کانال برای برقراری ارتباط چیست: یک ایمیل (اگر زمان پاسخگویی 1 تا 2 روز خوب باشد) ، یک تماس (اگر به بحث یا اشتراک صفحه نیاز دارد) ) ، یا یک پیام فوری (اگر مهم است ، یا چیزی که شما را مسدود می کند).
نتیجه
این مقاله ده جنبه چالش برانگیز در مهندسی را مورد بحث قرار می دهد که ما گاهی وقت کافی را به آنها اختصاص نمی دهیم. این موارد شامل حذف و نامگذاری موارد ، خواندن گزارش ها ، بازخورد و ستایش ، تعریف مشکلات ، طراحی معماری ، استخدام و در نهایت ارتباط درون تیم و سایر تیم ها است.

 

اگر به هوش مصنوعی علاقه مند هستین مقاله ی  هوش مصنوعی چیست را دنبال کنید

نظرات کاربران


برای ارسال نظر ابتدا وارد حساب کاربری خود شوید