موازنه‌ها در نرم‌افزار

هر انتخاب طراحی که انجام می‌دهید، دری را به روی گزینه‌ای دیگر می‌بندد. نرم‌افزار بر پایه موازنه‌ها (trade-offs) کار می‌کند. شما باید این انتخاب‌ها را آگاهانه انجام دهید؛ در غیر این صورت، آن‌ها را به صورت تصادفی انجام خواهید داد.

موازنه‌های رایجی که با آن‌ها روبرو می‌شوید:

• قابلیت (Functionality) در مقابل عملکرد (Performance) کد تمیز اغلب کندتر اجرا می‌شود. کد سریع اغلب خواندنش دشوار است. برای فرآیندهای دسته‌ای (batch processes) که روزی یک بار اجرا می‌شوند، از کد خوانا استفاده کنید. برای مسیرهایی که در هر درخواست هزاران بار اجرا می‌شوند، از کد بهینه‌سازی‌شده استفاده کنید.

• انعطاف‌پذیری در مقابل سادگی انتزاع‌های (abstractions) پیچیده، درک کد را دشوار می‌کنند. ساده‌ترین کدی را که کار می‌کند بنویسید. آن را به‌گونه‌ای بسازید که بتوانید بعداً آن را گسترش دهید.

• مقیاس‌پذیری در مقابل هزینه طراحی برای ترافیک بسیار بالا، در حال حاضر هزینه بیشتری دارد. اندازه‌گیری نرخ رشد به شما در تصمیم‌گیری کمک می‌کند. اگر هر ماه ۲۰٪ رشد می‌کنید، برای آینده برنامه‌ریزی کنید. اگر سرمایه کمی دارید، مراقب هزینه‌های خود باشید.

• امنیت در مقابل قابلیت استفاده (Usability) امنیت افراطی می‌تواند تجربه کاربری را مختل کند. ما زمانی برای یک ابزار مدیریت، استفاده از توکن‌های سخت‌افزاری را اجباری کردیم. نرخ موفقیت ورود به سیستم از ۹۸٪ به ۸۴٪ کاهش یافت. مهندسان در مواقع اضطراری از دسترسی خارج شدند. ما به اعلان‌های موبایل (push notifications) تغییر وضعیت دادیم. نرخ موفقیت دوباره به ۹۶٪ بازگشت. هدف شما امنیت معقول باشد، نه امنیت حداکثری.

چگونه تصمیمات بهتری بگیریم:

  • هدف خود را صریح بیان کنید.
  • به جای حدس زدن، داده‌ها را اندازه‌گیری کنید.
  • با یک راهکار ساده شروع کنید.
  • تنها زمانی بهینه‌سازی کنید که مدرک و دلیل داشته باشید.
  • دلیل انتخاب خود را مستند کنید.

من زمانی سعی کردم یک JSON serializer را برای صرفه‌جویی در چند میکروثانیه بهینه کنم. این کار باعث ایجاد یک نشت حافظه (memory leak) شد که ۳۰۰ مگابایت افزایش یافت. یک profiler نشان داد که گلوگاه (bottleneck) واقعی، ورودی/خروجی شبکه (network I/O) بود. همیشه قبل از بازنویسی کد، از یک profiler استفاده کنید.

بدهی فنی (Technical debt) یک واقعیت است. میان‌بر زدن امروز، هزینه زمانی در فردا خواهد داشت. وقتی یک سرویس نامنظم را تحویل گرفتیم، بازنویسی بزرگی انجام ندادیم. ما از تغییرات کوچک و مداوم استفاده کردیم. پوشش تست (test coverage) را از ۳۰٪ به ۷۸٪ رساندیم. این کار زمان رفع باگ را از ۴ روز به ۱.۲ روز کاهش داد.

موازنه‌ها دائمی نیستند. در تصمیمات خود تجدیدنظر کنید. بررسی کنید که آیا بهینه‌سازی‌های شما هنوز اهمیت دارند یا خیر. هدفمند بودن مانع از ایجاد سیستمی می‌شود که در همه چیز متوسط و معمولی است.

Source: https://dev.to/lavkeshdwivedi/software-tradeoffs-44e7

Optional learning community: https://t.me/GyaanSetuAi