بینقص بودن همون over-engineering نیست
خلاصهٔ کاملتر
نویسنده میگه بارها این جمله رو شنیده که «ما نمیخوایم راهحل بینقص بسازیم»، انگار «بینقص» یک فحش باشه. احتیاطش رو درک میکنه، چون over-engineering واقعاً تیمها رو میسوزونه و آدمها یاد گرفتن هر چیزی که بوی کمالگرایی بده رو همون خطر بدونن. ولی به نظرش این دو تا یکی نیستن و صنعت بیصدا قاطیشون کرده.
تعریفی که پیش میذاره کوتاهه: over-engineering یعنی حل کردن مسئلهٔ اشتباه. نه «زیادی اهمیت دادن»، نه «زیادی خوب ساختن». معمولاً هم با نیت خوب اتفاق میافته و تقریباً همیشه با پشتهای از پیچیدگی اضافی که مرتب بزرگتر میشه.
به باور نویسنده راهحل بینقص وجود داره، با یک شرط بزرگ: نیازمندیهای خیلی روشن و همهٔ محدودیتها روی میز. اونقدر که اینها رو تنگ کنی، اتفاق جالبی میافته و در نهایت فقط یک راهحل ممکن باقی میمونه — و همون، طنزآمیز، راهحل بینقصه؛ بینقص به این خاطر که تنها گزینهایه که جا میشه.
مثالش شروع یک پروژهٔ تازهست: با همهٔ زبانها و ابزارها و مدلهای هاستینگ روی میز، سرورلس رو انتخاب میکنی و پایتون گزینهٔ قویایه چون مرحلهٔ کامپایل نداره. برای یک نفر دیگه همین انتخاب غلطه، چون پایتون بلد نیست یا باید برای کارایی بهینه کنه. یا فرض کن پایتون رو انتخاب کردی و وباپ میسازی: جنگو یا فلسک؟ با هر دو به نتیجهٔ مشابه میرسی، ولی فلسفهٔ متفاوتی دارن. محدودیتهای سختتر، جواب رو مشخص میکنن.
نکتهٔ دومش اینه که سیستمها هم محصولن. یک کتابخونه، یک API یا یک ابزار داخلی رو دوست داریم «کاملاً فنی» فرض کنیم و بیرون از مفهوم محصول بذاریم، ولی اینها کاربر دارن و کاربر نیاز داره. شاید چیزی که لازم دارن سرویس باشه، شاید یک پکیج بهتر از یک فراخوانی HTTP جواب بده. شکل راهحل تازه وقتی واضح میشه که سیستم رو محصول ببینی و نیازمندی رو صادقانه تعریف کنی.
نشانهٔ عملیاش برای تشخیص over-engineering اینه که بپرسی «چرا چیزها اینطوری ساخته شدن؟» و جوابها سر پا نمونن. مثال کلاسیکش تیم سهنفرهایه که پنج میکروسرویس نگه میداره و سرویسها دادهشون رو با هم شریکن. برای قضاوت باید دید دنبال حل چه مسئلهای بودن — و به احتمال زیاد مسئلههای اشتباه، یا چندتا با هم.
هزینهٔ همین تفکیک رو هم میشمره: چیزی که قبلاً یک foreign key بود و موتور دیتابیس تضمینش میکرد، حالا یک رشتهٔ آزاد در یک فیلده. جامعیت داده از بین میره؛ یک سرویس رکوردی رو حذف میکنه و سرویس دیگه خبر نداره و فقط یک ارجاع معلق نگه میداره تا بعداً بهسختی خبردار بشه. در عوض چی گرفتی؟ دیپلوی مستقل، البته — ولی این مسئلهای بود که واقعاً داشتی؟ سه نفر و یک دامنه. یعنی برای مسئلهٔ مقیاس و مالکیتی که روی میز نبود جواب دادی و بهاش رو با ناسازگاری توزیعشده و سرباز عملیاتی پرداختی.
جمعبندیاش اینه که تشخیص سادهست حتی اگه کار سخت باشه: over-engineering شکستِ جمعآوری نیازمندیه، یعنی جمع کردن نیازمندیهای اشتباه و بعد مهندسی کردن سختکوشانه علیه همونها. به گفتهٔ نویسنده دشمن هیچوقت کمال نبوده، نیازمندی مبهم بوده؛ اونها رو درست کن و همهٔ محدودیتها رو روی میز بذار، تا راهحل بینقص از خیال دربیاد و تنها چیزی باشه که سر پا مونده.
نکات کلیدی:
- over-engineering یعنی حل کردن مسئلهٔ اشتباه، نه بیش از حد خوب ساختن
- با محدودیتهای بهقدر کافی تنگ، فقط یک راهحل ممکن باقی میمونه و همون بینقصه
- کتابخونه و API و ابزار داخلی هم محصولن و کاربر و نیاز دارن
- نشانهٔ over-engineering: پرسیدن «چرا اینطوری ساخته شده؟» و سر پا نموندن جوابها
- مثال میکروسرویسها: از دست دادن جامعیت داده در ازای دیپلوی مستقلی که مسئله نبود
