برنامه نویس هنرمندش خوبه!

در تلاش برای بهتر شدن، اغلب ما آنچه را که خوب است خراب می کنیم.

در این پست قصد داریم درباره ی مفهوم "به اندازه ی کافی خوب" صحبت کنیم. این پست برگردانی آزاد از بخش پنجم کتاب ارزشمند The Pragmatic Programmer است. که خواندن مداوم و مکرر این کتاب را به همه ی برنامه نویس های تازه کار و حرفه ای پیشنهاد می کنم.

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

آیا واقعاً ما چنین کنترلی روی کیفیت داریم؟

دنیای واقعی به ما اجازه نمی دهد چیزهای کاملا بی نقصی تولید کنیم، و این موضوع درباره ی نرم افزارهای بدون اشکال، بیشتر به چشم می آید و می توان با قاطعیت تمام گفت که تولید نرم افزار بدون اشکال یا به اصطلاح فنی Bug-Free ممکن نیست. زمان، پیشرفت ها و تغییرهای تکنولوژی و دانش و مهارت ها و حال و روزمان، همه علیه ما توطئه می کنند تا نتوانیم یک نرم افزار بدون عیب و کامل تولید کنیم.

با این حال، این موضوع نباید مارا ناامید کند. همانطور که Ed Yourdon در مقاله‌ای در IEEE Software با نام "وقتی نرم‌افزار به اندازه کافی خوب، بهترین است" توضیح داد؛ می‌توانید خود را به گونه ای عادت دهید تا نرم‌افزاری بنویسید که به اندازه کافی خوب باشد. به اندازه کافی خوب بودن یعنی برای کاربران شما، برای کسانی که قرار است در آینده از آن نگهداری کنند یا به آن امکانی را اضافه کنند و از همه مهمتر برای آرامش خاطر و وجدان خود شما خوب باشد. یعنی فکر نکنید که جایی از آن را کم فروشی کرده اید و یا زیادی وقت صرف کرده اید. با رعایت این نکته، متوجه خواهید شد که بهره وری بیشتری دارید و کاربران و مشتری های تان راضی تر هستند. 

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

کاربران خود را در تصمیم گیری مشارکت دهید

به طور معمول شما نرم افزار را برای افراد دیگر می نویسید. همیشه به دنبال برطرف کردن نیازمندی های آنها هستیم. اما آیا تا به حال از آنها پرسیده اید که می‌خواهند نرم‌افزارشان چقدر خوب باشد؟ 

وقتی روی دستگاه‌های ضربان‌ساز، خلبان خودکار یا یک کتابخانه سطح پایین کار می‌کنید که به طور گسترده منتشر می‌شود، قوانین و شرایط سخت‌گیرانه‌تر و گزینه‌های شما محدودتر خواهند بود و به اندازه ی کافی خوب، معنای متفاوتی نسبت به زمانی خواهد داشت که برای مثال نرم افزار یک وبلاگ برای خواننده ای شناخته نشده است😉.

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

دامنه و کیفیتِ سیستمی که تولید می کنید باید به عنوان بخشی از نیازمندی ها و بندهای توافق، مورد بحث و گفتگو با مشتری قرار بگیرد.

نکته: کیفیت را به یک نیازمندی قابل توافق تبدیل کنید.

اغلب در موقعیت هایی قرار می گیرید که توافق ها در آن دخیل هستند. با کمال تعجب، بسیاری از کاربران امروز ترجیح می دهند از نرم افزارهایی استفاده کنند که شاید بعضی از جاهای آن خیلی هم خوب نباشد تا اینکه یک سال برای نسخه فوق العاده و بدون ایراد آن صبر کنند (و در واقع چیزی که یک سال بعد نیاز دارند ممکن است با چیزی که امروز به فکرشان رسیده است کاملاً متفاوت باشد). 

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

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

بدانید چه زمانی باید متوقف شود

از برخی جهات، برنامه نویسی مانند نقاشی است. شما با یک بوم خالی و مواد اولیه شروع می کنید. شما از ترکیبی از علم، هنر و صنعت استفاده می کنید تا با آنها کاری را انجام دهید. شما یک طرح کلی را ترسیم می کنید، محیط اصلی نقاشی را رنگ می کنید و بعد از آن جزئیات را به نقاشی تان اضافه می کنید. شما دائماً با نگاهی انتقادی به عقب برمی‌گردید تا کارهایی را که انجام داده‌اید ببینید. هرازگاهی یک بوم را دور می اندازید و دوباره شروع می کنید.

اما هنرمندان با تجربه برای شما توصیه ی مهمی دارند: اگر ندانید چه زمانی باید دست از کار بکشید، تمام زحمتی که کشیده اید خراب می شود. و اگر لایه به لایه، هی جزئیات روی جزئیات اضافه کنید، نقاشی تان در رنگ گم می شود و دیگر چیزی دیده نمی شود. هنرمندان واقعی، به خوبی می دانند که چه زمانی دیگر لازم نیست به جزئیات نقاشی شان اضافه کنند.

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

تمرین:

یکی از برنامه هایی که با آن، به طور مکرر کار می کنید را در نظر بگیرید (مثلا اینستاگرام):

• آیا از نظر شما این برنامه هیچ جایی برای بهبود ندارد؟
• آیا نیازمندی هایی دارد که یک جایی از برنامه هست و خیلی از آن استفاده نمی شود؟
• از نظر شما برنامه نویس ها و تیم توسعه‌ی این نرم افزار، از شرایط این برنامه رضایت کامل دارند؟

خلاصه که به قول قماربازها:

یک قمارباز حرفه ای، میدونه کی باید از سر میز قمار بلند بشه!