هر نیازمندی در واقع یه تصمیمه، نه یه نیاز
تستخلاصهٔ کاملتر
مقاله با یه سؤال آشنا شروع میشه: چند بار تو کارت یه «نیازمندی» گرفتی که آخرش سخت و پرهزینه از آب دراومد؟ ترفندی که نویسنده میگه چند سال بعد از شروع کارش کشف کرد اینه که «چی»ِ یه نفر تقریباً همیشه «چطور»ِ یه نفر دیگهست. نیازمندیها بهندرت یه نیاز واقعی — مثلاً هدف کاربر — رو توصیف میکنن؛ معمولاً تصمیمیان که یه نفر دربارهٔ نحوهٔ رفع اون نیاز گرفته.
حرف اصلی اینجاست که هر تصمیم، تصمیمهای ممکن بعدی رو محدود میکنه. مثال خودش: «کاربر پلاک خونهش رو از یه لیست کشویی انتخاب میکنه.» این یه نیاز نیست، یه تصمیمه — و همون لحظه گزینههای دیگهای که ممکن بود مسئلهای رو حل کنن که حتی از وجودش خبر نداریم، از دست میره.
نویسنده تصمیمهای طراحی رو مثل یه درخت تصویر میکنه که سه جهت پیمایش داره. پایین رفتن با سؤال «چطور؟» — لیست پلاکها رو چطور پر کنیم؟ — که اسمش رو اجرا میذاره. چپ و راست رفتن با بررسی گزینههای همسطح — حتماً باید لیست کشویی باشه؟ میشه سوزن روی نقشه گذاشت یا تو یه textbox نوشت؟ — که اسمش رو کاوش میذاره. و بالا رفتن با سؤال «چرا؟» که اسمش فهمه: چرا باید از لیست انتخاب بشه؟ چون میخوایم مطمئن باشیم آدرس واقعیه. چرا؟ چون قراره به همون آدرس تحویل بدیم. به گفتهٔ اون همین آخری نیاز واقعیه.
دلیل قدرت «چرا» هم برمیگرده به همون محدودسازی: هر بار که به یه شاخهٔ مشخص متعهد میشی، اختیار از دست میره — گزینههای اجرایی کمتر و فضای راهحل کوچیکتر میشه، و شانس حل مسئله با زمان و منابع محدود پایین میآد. عقبگرد به یه تصمیم ریشهایتر همون اختیار رو برمیگردونه.
نویسنده میگه بیشمار بار پیش اومده که ددلاین نزدیک بوده و مسیر انتخابشده بهموقع نمیرسیده، و اون پرسیده «اصلاً قراره به چی برسیم؟» — و به روایتش ۹۹ درصد مواقع معلوم شده اون نیازمندی، نیازمندی واقعی نبوده بلکه یه تصمیم بوده؛ و ۹۹ درصد اون موارد راههای سریعتر و ارزونتری وجود داشته که خیلی وقتها اصلاً کد زدن لازم نداشته. اونقدر تکرار شده که تو دورهٔ پیمانکاریش قاعدهای برای خودش گذاشته: زیر سؤال بردن هر نیازمندی، و رد کردن هر مستندی که تیم تو توافقش دخیل نبوده. به همین خاطر امروز به مستند نیازمندی میگه «دستبند».
نکتهٔ بعدی اینه که هرچقدر هم دلیل یه تصمیم طراحی روشن باشه، در نهایت یه حدس آگاهانهست از اینکه چی مسئلهٔ ریشهای رو حل میکنه؛ فقط واقعیت میتونه جواب بده که واقعاً حلش کرده یا نه. از اینجا میرسه به تأخیر بازخورد: چقدر تو یه شاخه پایین میری تا بازخورد معناداری دربارهٔ تصمیم ریشه بگیری؟ به گفتهٔ اون ساخت و انتشار نرمافزار تو برشهای نازک و گرفتن بازخورد پیوسته، هم زودتر جواب میده و هم اختیار رو بیشتر حفظ میکنه. در مقابل، طراحی سنگین از پیش تأخیر بازخورد بالایی داره — وقت زیادی صرف بالا رفتن از درخت اشتباه میشه — و شاخههای جایگزین رو خیلی زود، قبل از وجود هر شاهد واقعی، میبنده.
دو راه دیگه هم برای باز نگه داشتن گزینهها معرفی میکنه. اول اینکه تو Extreme Programming تعهد به تصمیمها — مخصوصاً اونهایی که سخت عوض میشن — تا جای معقول عقب میافته، که هم سادگی رو حفظ میکنه (همون YAGNI) و هم اختیار رو. دوم پنهون کردن «چطور» پشت یه انتزاع: یه interface میگه یه ماژول چی باید بکنه، ولی انتخاب نحوهٔ انجامش رو میشه بعداً گرفت یا جاش عوض کرد.
بهعنوان نمونهٔ عملی به کتاب Growing Object-Oriented Software Guided By Tests اشاره میکنه که تو فرایند طراحی آزمونمحور بیرونبهدرون، از mock برای تعریف انتزاعها و قراردادها قبل از تعهد به هر پیادهسازی استفاده میکنه. مثالش: نهایی کردن سبد خرید کارت مشتری رو شارژ میکنه — چطور؟ بعداً میرسیم؛ ولی الان میدونیم سبد چی باید به پردازشگر پرداخت بگه. نویسنده تأکید میکنه هدف اصلی mock همین بوده: یه ابزار طراحی، نه یه ابزار تست. جمعبندیش هم اینه که برنامهنویسها ذهن «چطور»محور دارن، ولی این افسانهست که نمیتونیم درخت رو بالا بریم و نیاز واقعی رو بفهمیم.
نکات کلیدی:
- بیشتر نیازمندیها نیاز نیستن؛ تصمیم یه نفر دربارهٔ نحوهٔ رفع نیازن
- درخت تصمیم سه جهت داره: اجرا (چطور)، کاوش (گزینهٔ همسطح)، فهم (چرا)
- هر تعهد به یه شاخه، اختیار و فضای راهحل رو کوچیک میکنه
- عقبگرد به تصمیم ریشه معمولاً راه ارزونتر — و بعضاً بیکد — رو نشون میده
- برش نازک و بازخورد پیوسته، تأخیر بازخورد رو کم و اختیار رو حفظ میکنه
- interface و mock ابزار به تعویق انداختن «چطور» هستن؛ mock ابزار طراحیـه نه تست
