تست جوئل, 12 راه براي كد بهتر

مقدمه

جوئل اسپولسكي، يهودي ساكن آمريكا است كه از جمله سوابقش مديريت پروژه MS Excel v5 است. او نظريات منحصر به فرد و جالبي در زمينه توليد نرم افزار دارد و امروزه در شركت خودش، Fog Creek Software مشغول به كار است. متن زير كه توسط وي در اوت 2000 منتشر شده است مشخصه هاي ارزيابي يك تيم نرم افزاري را به زبان ساده و تا حدي طنز گونه بيان ميكند. در ترجمه اين متن سعي شده است اصطلاحات فني به صورتي كه بين برنامه نويسان حرفهاي در ايران مصطلح است به كار رود.

آيا تا بحال نام SEMA (Software Engineering Measurement and Analysis) را شنيده ايد؟ SEMA ، سيستم نسبتاً مبهمي است براي اندازه گيري شايستگي يك تيم نرم افزاري. نه! صبر كنيد، به سايت آن نرويد، زيرا فقط شش سال طول ميكشد تا مطالب آن را بفهميد. به همين علت من تست كاملاً نامرتب و نامعتبر (!) خودم را براي ارزيابي كيفيت يك تيم نرم افزاري درست كردم. بهترين قسمت ماجرا اينجاست كه فقط سه دقيقه از وقتتان را ميگيرد. با وقتي كه صرفه جويي ميكنيد، ميتوانيد به سراغ حرفه پزشكي برويد[1]!

• ایا از سيستم كنترل سورس بهره ميبريد؟
• آيا ميتوانيد در يك مرحله، برنامه نان را build كنيد؟
• آيا داراي build روزانه هستيد؟
• آيا بانك اطلاعاتي از اشكالات (bugs) داريد؟
• آيا قبل از نوشتن كد جديد، به رفع اشكالات كنوني ميپردازيد؟
• آيا برنامه زمانبنديتان به روز است؟
• آيا داراي ليست مشخصات هستيد؟
• آيا برنامه نويسان شما محيط آرامي براي كار كردن دارند؟
• آيا بهترين ابزارهايي را كه وجود دارد ميخريد؟
• آيا بخش تست شما جداست؟
• آيا داوطلبان جديد در موقع مصاحبه، كد هم مينويسند؟
• آيا از آزمايش " قابليت استفاده راهرويي " سود ميجوييد؟

ويژگي شسته و رفته تست جوئل در اين است كه به راحتي ميتوان به هر سؤال جواب بله يا نه داد. شما مجبور نيستيد كه تعداد خطهاي كد در روز يا تعداد متوسط اشكال در هر قسمت را بشماريد. نقطه ضعف تست جوئل در اين است كه نبايد از آن براي اطمينان از صحت نرم افزار نيروگاه اتمي خود استفاده كنيد!

امتياز 12 عالي، 11 قابل قبول و 10 يا پايينتر نشان دهنده مشكلات جدي است. واقعيت در اين است كه بيشتر موسسات نرم افزاري با امتياز 2 يا 3 در حال فعاليت هستند و به كمك جدي نياز دارند، چرا كه شركتهايي مانند Microsoft تمام مدت با امتياز 12 اداره مي شوند.

البته، اينها تنها موارد مشخص كننده موفقيت يا شكست نيستند: مثلاً ، اگر شما تيم ماهري داريد كه بر روي محصولي كه هيچ كس آن را نمي خواهد كار ميكند، خوب، مردم باز هم آن محصول را نخواهند خواست. از طرفي، تيم غير عادي را ميتوان تصور كرد كه بدون انجام هيچ كدام از اين كارها، نرم افزار فوق العاده اي توليد كند و دنيا را تغيير دهد. اما اگر همه شرايط برابر باشند، با رعايت اين 12 نكته، تيم منضبطي خواهيد داشت كه هميشه موفق به تحويل پروژه هايش ميشود.

 آيا از سيستم كنترل سورس بهره ميبريد؟

من هم از پكيجهاي تجاري كنترل سورس استفاده كردم، و هم از CVS كه مجاني است ؛ و بگذاريد به شما بگويم كه CVS مناسب است. اما اگر سورس كنترل نداريد، فشار زيادي را براي اينكه برنامه نويسانتان بتوانند با هم كار كنند متحمل ميشويد: برنامه نويسها راهي براي اينكه بدانند بقيه چه كرده اند، ندارند. و اشتباهات، به راحتي قابل بازگشت نيستند. و در آخر اينكه چون كد برنامه بر روي دستگاه تمام برنامه نويسان check out ميشود، تا بحال نشنيده ام كه پروژه هاي داراي سورس كنترل ، كد زيادي را به اشتباه از دست دهند.

آيا ميتوانيد در يك مرحله، برنامه تان را build كنيد؟

منظورم اين است: براي ايجاد نسخه قابل تحويل به مشتري از آخرين سورس، چند مرحله وجود دارد؟ در تيمهاي خوب، يك اسكريپت وجود دارد كه با اجراي آن، يك check out كامل صورت ميگيرد، تمام كد كامپايل ميشود، EXE ها ساخته ميشوند (در تمامي نسخه ها، زبانها و #ifdef ها) ، پكيج قابل نصب توليد ميشود و بالاخره در فرم رسانه نهايي (CD يا وبسايت يا ...) ايجاد ميشود.

اگر اين رويه بيشتر از يك مرحله داشته باشد، مستعد اشتباه است. و هر چقدر به زمان تحويل نزديكتر ميشويد، احتياج به چرخه سريعتري براي تصحيح "آخرين" bug، و ساختن EXE نهايي داريد. اگر كامپايل كردن كد، اجراي سازنده installer و بقيه كارها بيست مرحله به طول انجامد، دست به اشتباهات احمقانه خواهيد زد.

فقط به همين علت، آخرين شركتي كه در آن كار ميكردم، از WISE به InstallShield تغيير كرد: لازم بود كه رويه ايجاد installer از روي يك script به صورت خودكار نيمه شبها توسط NT Scheduler اجرا شود و WISE چنين قابليتي نداشت. (دوستان خوب ما در WISE به من اطمينان داده اند كه آخرين نسخه شان توانايي build هاي شبانه را دارد.)

آيا داراي build روزانه هستيد؟

وقتي كه از كنترل سورس استفاده ميكنيد، گاهي پيش ميآيد كه يك برنامه نويس چيزي را check in ميكند كه باعث شكستن build ميشود. به عنوان مثال، يك برنامه نويس يك فايل سورس جديد اضافه كرده است و همه چيز روي دستگاه خودش درست كامپايل ميشود، ولي يادشان ميرود كه فايل را به مخزن كد (repository) اضافه كند. دستگاه خودش را هم قفل كرده و بي توجه و خوشحال به خانه ميرود. حالا كسان ديگري نيز نمي تواند كار كنند. آنها هم به خانه ميروند، البته غمگين.

شكستن بيلد آنقدر بد (و رايج) است كه درست كردن بيلد روزانه كمك ميكند كه چنين موضوعي ناشناخته نماند. در تيمهاي بزرگ، يك راه اين كه مطمئن شويد كه چنين مشكلاتي در اولين فرصت برطرف شوند، اين است كه بيلد روزانه را هر روز، هنگام ناهار انجام دهيد. همه تمامي check in هايي را كه ميتوانند قبل از رفتن به ناهار انجام ميدهند. بيلد، زماني كه همه برگشتند تمام شده است. اگر كه همه چيز درست است، كه فبحال! آخرين نسخه سورس توسط همه check out شده و كار ادامه پيدا ميكند. اما اگر كه عمل بيلد با موفقيت روبرو نشده باشد، افراد با نسخه سالم قبلي به كار خود ادامه ميدهند.

در تيم Excel، با قانوني داشتيم: هر كسي كه build را ميشكست، به عنوان تنبيه، مسئولیت نگهداري از بيلدها را عهده دار ميشد. اين انگيزه خوبي بود هم براي جلوگيري از شكستن بيلد، و هم راه خوبي بود براي اين كه همه (به صورت چرخشي) ياد بگيرند كه رويه چطور است.

ميتوانيد در مقاله ديگرم - Daily Builds are Your Friend - در مورد build هاي روزانه بيشتر بخوانيد.

آيا بانك اطلاعاتي از اشكالات (bugs) داريد؟

برايم مهم نيست كه در اين مورد چه فكر ميكنيد. اما اگر حتي در يك تيم يك نفره مشغول توليد كد هستيد و از بانك منظمي كه تمامي ايرادات برنامه را ليست كند استفاده نميكنيد، حتماً كد با كيفيت پايين تحويل خواهيد داد. برنامه نويسان زيادي فكر ميكنند كه ميتوانند ليست اشكالات و باگها را در كله خود نگهدارند. چه مزخرفاتي! من در آن واحد بيشتر از دو يا سه باگ را نميتوانم بخاطر بسپارم، و صبح روز بعد، يا با عجله اي كه زمان تحويل داريد، همه به فراموشي سپرده ميشوند. قطعاً بايد به صورت رسمي و مكتوب ليست اشكالات را نگهداري كنيد.

بانك باگ ميتواند پيچيده و يا ساده باشد. يك بانك باگ سودمند بايد حداقل اطلاعات زير را در مورد هر باگ نگه دارد :

• مراحل كامل براي باز توليد اشكال
• رفتاري كه انتظار آن ميرود
• رفتار (ايراد داري) كه واقعاً رخ ميدهد
• فردي كه رفع اشكال به او واگذار شده است
• آيا اشكال رفع شده است يا خير

اگر پيچيدگي نرم افزار پيگيري باگها مانع از آن ميشود كه چنين كاري را انجام دهيد، يك جدول پنج ستونه (با فيلدهاي ضروري فوق) بسازيد و شروع به انجام اين كار كنيد.

براي اطلاعات بيشتر در مورد رديابي باگها، مقاله Painless Bug Tracking را بخوانيد.

آيا قبل از نوشتن كد جديد، به رفع اشكالات كنوني ميپردازيد؟

اولين نسخه Word تحت ويندوز، پروژه " نوحه مرگ " محسوب ميشد كه نوشتن آن به درازا كشيد، فرجه ها دايماً به سر ميرسيدند؛ افراد تيم، ساعتهاي مسخره آميزي كار ميكردند، و پروژه باز ... و باز ... و باز به تاخير ميافتاد. استرس باور نكردني بود. وقتي بعد از چندين سال، بالاخره محصول لعنتي اش بيرون آمد، مايكروسافت كل تيم Word را براي استراحت به جنوب مكزيك فرستاد ؛ و خودش به كنكاش روحاني جدي دست زد.

مايكروسافت متوجه شد كه مديران پروژه آنقدر بر حفظ " زمان بندي " (schedule) اصرار داشتند كه برنامه نويسان مجبور به كد نويسي با عجله شده بودند، و بسيار بد كد مي نوشتند - به اين علت كه فاز bug fix جز زمانبندي رسمي نبود. تلاشي براي پايين نگهداشتن تعداد خطاها وجود نداشت. حتي برعكس، روايت شده كه يكي از برنامه نويسان كه مسؤول نوشتن كد محاسبه ارتفاع خطوط متن بود، فقط نوشت: return 12; و بعد هم منتظر نشست تا در گزارش باگها بيايد كه تابعاش ، هميشه درست كار نميكند. زمانبندي پروژه صرفاً تبديل شده بود به ليستي از باگهايي كه بايد توليد ميشد! بعدها، از اين اتفاق با عنوان " متدولوژي عيوب نامحدود " (infinite defects methodology) ياد شد.

براي حل اين معضل، مايكروسافت " متودولوژي كمترين عيوب" (zero defects methodology) را به صورت فراگيري اتخاذ كرد. بسياري از برنامه نويسان داخل شركت خنديدند - چون به نظر ميرسيد مديريت به اين نتيجه رسيده بود كه با يك حكم سازماني تعداد باگها را كم كند. اما در واقع، معني " كمترين عيوب" در اين است كه در هر لحظه، بالاترين اولويت در رفع باگهاست، نه نوشتن كد جديد. اما چرا؟

به صورت كلي، هر چه براي تصحيح يك اشكال بيشتر معطل كنيد، هزينه تصحيح آن (از لحاظ وقت و پول) بيشتر خواهد بود.

به عنوان مثال، وقتي كه اشتباه تايپي انجام ميدهيد و كامپايلر آن را catch ميكند، تصحيح آن كار اساساً سادهايست. به همين ترتيب، بار اولي كه كدتان را اجرا ميكنيد و در آن اشكالي ميبينيد، ميتوانيد بلافاصله آن را تصحيح كنيد، چون همه كد در ذهنتان وجود دارد.

اما اگر در كدي كه چند روز پيشتر آن را نوشته ايد، ايرادي بيابيد، يافتن محل دقيق آن مدتي طول خواهد كشيد، البته وقتي كه كدتان را باز خواني كنيد همه چيز بالاخره يادتان ميآيد و در يك زمان قابل قبول مشكل رفع ميشود.

اما بالاخره اگر در كدي كه چند ماه پيش آن را نوشته ايد باگي پيدا شود، به احتمال زياد چيزهاي زيادي را در مورد آن كد به فراموشي سپرده ايد و تصحيح آن بسيار سختتر است. ممكن است مشغول تصحيح باگ كد كسي شده باشيد كه در آن لحظه براي مرخصي به جزاير درياي كارايب رفته باشد. در اين صورت، تصحيح باگ به صورت يك علم در ميآيد : بايد با درايت، وسواس، نظم و بدون هيچ تصوري از مدت زماني كه يافتن راه حل طول ميكشد، عمل كنيد.

اگر در كدي كه تحويل دادهايد ايرادي بيابيد، متحمل هزينه باز هم زيادتر براي اصلاح آن خواهيد شد.

پس اولين دليلي كه بايد باگها را بلافاصله رفع كرد، كم كردن زمان لازم براي اين كار است. دليل ديگري هم وجود دارد: پيشبيني مدت زمان لازم براي نوشتن كد جديد، راحتتر از پيشبيني زمان لازم براي رفع يك باگ است. مثلاً اگر از شما بپرسم كه چقدر زمان براي نوشتن كدي براي مرتب سازي يك فهرست لازم داريد، جواب نسبتاً دقيق ميتوانيد به من بدهيد. اما اگر از شما بپرسم در جايي كه IE 5.5 نصب شده باشد و كدتان ديگر كار نميكند چقدر زمان لازم داريد تا باگ مربوطه را رفع كنيد، بعيد ميدانم كه حتي بتوانيد حدسي بزنيد! چرا كه (بنابر تعريف صورت مساله) نميدانيد كه منشأ مشكل كجاست. ممكن است سه روز وقتتان را بگيرد، ممكن هم هست كه فقط دو دقيقه.

به بيان ديگر، اگر در برنامه زمانبنديتان تعداد زيادي باگي كه بايد رفع شوند، وجود داشته باشد، زمانبنديتان غير قابل اعتماد است. اما اگر تمامي ايرادهاي شناخته شده را تصحيح كردهايد و فقط كد جديد مانده، زمانبنديتان به طرز حيرت آوري دقيقتر خواهد بود.

نكته خوب ديگري هم كه صفر نگهداشتن تعداد باگها در هر زمان دارد، عكس العمل سريعتر در برابر رقباست. بعضي برنامه نويسان اين قضيه را به " آماده تحويل بودن" محصول در تمام لحظات، تعبير ميكنند. اگر رقيب شما امكان مشتريكُشي[2] عرضه كرد، شما هم ميتوانيد آن امكان را فوراً به برنامه تان اضافه كنيد و آن را تحويل دهيد، بدون اين كه مجبور به تصحيح تعداد زيادي ايراد انباشته شده باشيد.

آيا برنامه زمانبنديتان به روز است؟

ميرسيم به بحث شيرين زمانبندي. اگر كدتان براي شركتتان اهميتي داشته باشد، پس حتماً به دلايل زيادي براي شركتتان زمان اتمامش هم مهم هست. برنامه نويسان به صورت خيلي مفتضحي در زمينه زمانبندي، ترشرو هستند : سر قسمت بيزنس فرياد ميكشند " كار وقتي تمام ميشود كه تمام شده باشد ! "

متاسفانه، اين اصلاً به درد نميخورد. برنامه ريزي هاي زيادي بايد قبل از تحويل نهايي كد انجام گيرد : دمونستراسيون، نمايشگاهها، تبليغات و غيره. و تنها راه انجام اين كارها، داشتن برنامه زمان بندي و به روز نگهداشتن آن است.

فايده حياتي ديگر داشتن برنامه زمانبندي در اين است كه مجبورتان ميكند تصميم بگيريد چه امكاناتي[3] را ميخواهيد در برنامه بگنجانيد و اين كه امكانات با اوليت پايينتر را حذف كنيد، و گرفتار بيماري featuritis نشويد. (featuritis / scope creep / creeping featurism، و يا گرايش به ويژگيهاي نو، بيماري طراحان است ؛ طراحان مبتلا به اين بيماري دوست دارند كه به سيستم پيچيدهاي بدون برنامه ريزي كافي امكانات و ويژگيهاي نو اضافه كنند؛ و در واقع آن را - به صورت غير اصولي - فقط پيچيدهتر كنند!)

نگهداشتن schedule (برنامه زمانبندي)، الزاماً سخت نيست. مقاله ديگرم، Painless Software Schedules - كه راه ساده اي براي اين كار ياد ميدهد - را بخوانيد.

آيا داراي ليست مشخصات هستيد؟

نوشتن ليست مشخصات (specifications) درست مثل استفاده از نخ دندان است: همه قبول دارند كه كار خوبي است ولي هيچ كس حوصله اش را ندارد.

دقيقاً مطمئن نيستم كه چرا ؛ احتمالاً به اين علت است كه برنامه نويسان از نوشتن مستندات متنفرند. در نتيجه، تيمهايي كه همه اعضايش برنامه نويس هستند وقتي سراغ مسألهاي ميروند، ترجيح ميدهند كه راه حلشان به زبان كد باشد تا به صورت سند. ترجيح ميدهند كه از اول شيرجه بزنند و كد بنويسند تا اين كه ابتدا يك ليست مشخصات درست كنند.

در مرحله طراحي، اگر به معضلي بر بخوريد، به سادگي با تغيير چند خط ميتوانيد آن را حل كنيد. اما زماني كه كد نوشته شده است، هزينه درست كردن معضلات بسيار گزاف است : هم از لحاظ عاطفي (چون مردم از دور انداختن كد خود متنفرند)، و هم از لحاظ زماني، و به همين علت نوعي مقاومت در مقابل درست كردن معضل بوجود ميآيد. نرم افزاري كه از روي ليست مشخصات (specifications) توليد نشود معمولاً نتيجه اش طراحي بد و زمانبندي خارج از كنترل است. به نظر ميرسد كه مشكل Netscape نيز همين بوده - چهار نسخه اول آن قدر شلم شوربا شد كه مديريت به طرز احمقانه اي تصميم گرفت همه كد آن را دور بياندازد و از صفر شروع كند. سر Mozilla هم دوباره همين اشتباه را مرتكب شدند، كه محصول آن هيولايي خارج از كنترل است كه چند سال طول كشيده تا فقط به مرحله آلفا برسد.

تئوري مورد علاقه من اين است كه اگر برنامه نويسان را به يك دوره متمركز نويسندگي بفرستيد، ياد خواهند گرفت كه نويسندگان با ذوقي شوند. راه حل ديگر، استخدام مدير برنامه (program manager) زبردستي است كه خود نوشته ها را تهيه كند. در هر دو حالت، بايد قانون " هيچ كدي بدون مشخصات پذيرفته نيست " را به اجرا بگذاريد.

در نوشته چهار قسمتي من، هر چه كه در مورد نوشتن مشخصات لازم داريد را ميتوانيد بخوانيد.

آيا برنامه نويسان شما محيط آرامي براي كار كردن دارند؟

اين موضوع - كه با دادن فضاي مناسب، ايجاد آرامش و محيط دنج (privacy) به كارمندان IT (يا اصطلاحاً knowledge workers) - بهروري افزايش مييابد ، به صورت گسترده اي مستند شده است. كتاب كلاسيك مديريت نرم افزار، PeopleWare ، اين موارد را بر ميشمرد.

مشكل اينجاست: همه ما ميدانيم كه نيروي كار فني با قرار گرفتن در جرياني كه از آن به " در بحر موضوع رفتن " تعبير ميشود - بهتر كار ميكنند ؛ اين زماني است كه تمركزشان كاملاً بر روي كارشان است و حواسشان كاملاً از محيط اطرافشان پرت شده است. احساس زمان را از دست ميدهند و از طريق تمركز مطلق، چيزهاي عالي اي خلق ميكنند. نويسندگان، برنامه نويسان، دانشمندان، و حتي بازيكنان بسكتبال در مورد حالت " در بحر موضوع فرو رفتن " ميتوانند براي شما توضيح دهند.

وارد شدن به اين حالت كار ساده اي نيست. اگر اندازه گيري كنيد، ميبينيد كه حدوداً 15 دقيقه طول ميكشد تا به حداكثر كارايي خود برسيد. بعضي مواقع، زمانهايي كه خسته هستيد و يا به اندازه كافي براي آن روزتان خلاقيت به خرج دادهايد، ديگر نميتوانيد در بحر موضوع برويد و بقيه روز را به كارهاي بيهوده، خواندن وب و Tetris بازي كردن ميگذرانيد.

مشكل ديگر در اينجاست كه از دست دادن تمركز كار ساده ايست :سر و صدا، تماسهاي تلفني، ناهار را بيرون خوردن، آن پنج دقيقهاي كه براي نوشيدن قهوه تا كافي شاپ صرف رانندگي ميكنيد، و علل الخصوص مزاحمت ها و سؤالهاي همكاران، همگي تمركز را از بين ميبرند. اگر همكار شما ازتان سؤالي بپرسد كه يك دقيقه كارتان را متوقف كند، ولي آنقدر حواستان را پرت كند كه نيم ساعتي طول بكشد تا به حالت سابق برگرديد، بهروري كلي تيمتان در خطر جدي قرار دارد. اگر در محيط شلوغي كار ميكنيد - از همان نوعي كه dotcom هاي كافئينزده سخت عاشق آن هستند و در آنها بخش فروش زير گوش برنامه نويسان مشغول داد و بيداد هستند - بهروري شما سقوط بدي خواهد كرد.

در مورد برنامه نويسان (به نسبت بقيه knowledge workers و طيفهاي ديگري كه نيازمند تمركز زياد هستند)، قضيه سختتر است. بهروري، به توانايي شعبده بازي با جزئيات زيادي در حافظه موقت بستگي دارد. هر نوع وقفهاي باعث بهم ريختن اين جزئيات ميشود. وقتي كارتان را از سر ميگيريد، هيچ كدام از جزئيات (نظير نام متغيرهاي محلي يا اين كه تا كجاي پياده سازي الگوريتم جستجويتان را انجام داده بوديد) يادتان نخواهد آمد و مجبور به مراجعه به كار قبلتان هستيد كه سرعتتان را ميگيرد.

رياضيات اين مساله زياد سخت نيست: فرض كنيد (كه شواهد هم اين فرض را تاييد ميكنند) كه اگر براي يك دقيقه هم يك برنامه نويس را متوقف كنيد، پانزده دقيقه از بهروريش كم ميكنيد. براي مثال، Jeff و Mutt (كه هر دو برنامه نويس هستند) را در دو پارتيشن كنار هم قرار ميدهيم (در يك فضاي كاملاً Dilbert اي). مات، نام تابع كپي رشته در يونيكد را به خاطر نميآورد. ميتواند جواب آن را جستجو كند - كه 30 ثانيه طول ميكشد، و يا اين كه از جف بپرسد - كه 30 ثانيه طول خواهد كشيد. خوب، چون جف در كنارش نشسته است ترجيح ميدهد كه از او بپرسد. حواس جف پرت ميشود و 15 دقيقه را از دست ميدهد (براي اين كه مات 15 ثانيه صرفه جويي كرده باشد.)

حالا اجازه دهيد كه جف و مات را در دو اتاق (با در و ديوار) جدا بگذاريم. اكنون وقتي كه مات اسم تابع را به خاطر نميآورد، ميتواند جواب آن را جستجو كند (كه همان 30 ثانيه طول ميكشد) و يا اين كه از جف بپرسد كه 30 ثانيه طول ميكشد و شامل از جاي خود بلند شدن هم ميشود (كه با توجه به وضعيت جسمي معمول برنامه نويسان و مسايل ديگر ، كار ساده اي نيست!). بنابر اين ترجيح ميدهد كه جوابش را جستجو كند. 30 ثانيه وقتش تلف ميشود اما 15 دقيقه به نفع جف است! واي!

آيا بهترين ابزارهايي را كه وجود دارد ميخريد؟

نوشتن كد در يك زبان كامپايل شده از كارهايي است كه هنوز بر روي كامپيوترهاي خروس نشان، نميتوان با سرعت انجام داد. اگر فرآيند كامپايل، بيشتر از چند ثانيه طول ميكشد، خريد جديدترين و بهترين كامپيوتر در وقتتان صرفهجويي خواهد كرد. اگر كامپايل كردن حتي 15 ثانيه طول بكشد، برنامه نويسها حوصله شان سر ميرود و ميروند به سراغ خواندن سايت The Onion ، كه آن هم تمام هوش و حواسشان را به خود خواهد برد و ساعتها بهروري از بين ميرود.

debug كردن كد GUI با يك مانيتور اگر غير ممكن نباشد، بسيار سخت و دردناك است. اگر در حال نوشتن كد GUI هستيد، داشتن دو مانيتور همه چيز را بسيار ساده خواهد كرد.
بيشتر برنامه نويسان بايد يك زماني فايلهاي bitmap را (براي iconها و toolbarها) دستكاري كنند و اكثراً ويرايشگر مناسب براي اين كار ندارند. استفاده از MS Paint براي اين كار بيشتر شبيه يك شوخي است، كه البته غالب برنامه نويسها از همين روش استفاده ميكنند.

در محل كار قبلي ام، admin شبكه دايماً براي من spam ميفرستاد و غر ميزد كه من بيشتر از 220 مگابايت فضاي مجازم، روي سرور جا اشغال كرده ام. من روزي جواب دادم كه با توجه به قيمت هارد ديسك، هزينه فضاي مورد استفاده كمتر از هزينه دستمال كاغذي من است و صرف كردن حتي ده دقيقه از وقتم براي كوچك كردن دايركتوريام يك هدر دادن اشرافي بهرهوري است.

تيمهاي توليد نرمافزار درجه يك، برنامه نويسان خود را شكنجه نميكنند. حتي موضوعات جزيي اعصاب خرد كن ناشي از داشتن ابزار نامناسب، جمع ميشود و برنامه نويسها را بد اخلاق و ناراحت ميكند. يك برنامه نويس بد خلق، يك برنامه نويس با كارايي پايين است.

يك نكته ديگر هم اضافه كنم... برنامه نويسها را به راحتي ميتوان با رشوه دادن - بوسيله جديدترين و با حال ترين وسايل - تطميع كرد. اين برايتان خيلي ارزانتر از دادن حقوق مكفي تمام ميشود!

آيا بخش تست شما جداست؟

اگر در تيم شما افرادي كه وقتشان اختصاصاً براي تست كردن باشد - حداقل يك نفر براي هر دو يا سه برنامه نويس - وجود نداشته باشد، شما يا محصولات باگدار تحويل خواهيد داد؛ و يا اين كه با پرداخت 100 دلار در ساعت به جاي 30 دلار در ساعت، پولتان را هدر ميدهيد. خساست در زمينه افراد جهت بخش تست، آن قدر صرفه جويي احمقانه ايست كه من واقعاً تعجب ميكنم چرا اكثر مردم نميفهمند.

مقاله Top Five (Wrong) Reasons You Don't Have Testers را كه در مورد همين موضوع نوشتم، بخوانيد.

آيا داوطلبان جديد در موقع مصاحبه، كد هم مينويسند؟

آيا شما حاضريد يك شعبده بازي را بدون اين كه چند حقه برايتان اجرا كند، استخدام كنيد؟ معلوم است كه نه. آيا براي عروسيتان، آشپزي كه غذايش را نچشيده باشيد، استخدام ميكنيد؟ بعيد ميدانم. (مگر اين كه خاله بزرگتان باشد و بترسيد كه تا آخر عمر از شما به دل بگيرد و برنجد.)

با اين وجود، هر روز، برنامه نويسهايي بخاطر داشتن resume جالب يا به اين خاطر كه مصاحبه گر از گپ زدن با او لذت برده، استخدام ميشوند. يا بايد به سوالات ساده اي مانند " فرق CreateDialog() و DialogBox() چيه؟ " كه با خواندن مستندات قابل پاسخگويي است، جواب دهند. واقعاً نبايد برايتان اهميتي داشته باشد كه داوطلب، هزاران نكته پيش پا افتاده را حفظ كردهاست يا نه، بلكه بايد توانايي او در توليد كد برايتان مهم باشد. از همه چيز بدتر، سؤالات " معما گونه " است : آن دسته از سؤالاتي كه پاسخ دادن به آنها غير ممكن است ولي وقتي جواب را ميدانيد بديهي به نظر ميرسند.

لطفاً از اين كارها نكنيد! و هر كاري كه ميكنيد، حتماً از مصاحبه شونده بخواهيد كه برايتان كد بنويسد. (براي راهنمايي بيشتر، به مقاله Guerrilla Guide to Interviewing مراجعه كنيد.)

آيا از آزمايش " قابليت استفاده راهرويي " سود ميجوييد؟

در تست hallway usability، شما خِر اولين فردي را كه از راهرو رد ميشود، ميگيريد؛ و مجبورشان ميكنيد كه بنشينند پاي برنامه اي كه همين الان نوشته ايد. اگر با پنج نفر اين كار را تكرار كنيد، 95% مشكلات كار با برنامه تان (usability problems) را كشف خواهيد كرد.

طراحي " واسط كاربر " خوب آنقدرها هم كه فكر ميكنيد سخت نيست، حتي براي اين كه مشتريها عاشق برنامه تان بشوند و آن را بخرند، واجب هم هست. كتاب مجاني و online من در مورد طراحي واسط كاربر كه الفباي آن را براي برنامه نويسان شرح ميدهد بخوانيد.

اما مهمترين نكته در مورد واسطهاي كاربر (user interfaces) اين است كه اگر برنامهتان را به پنج يا شش نفر نشان دهيد، به سرعت بزرگترين مشكلات كاربران را خواهيد دانست. Jakob Nielsen مقالهاي دارد كه در آن توضيح ميدهد چرا اين چنين است. خلاصه اين كه حتي اگر در زمينه UI واقعاً ضعيف باشيد، با آزمايشهاي قابليت استفاده راهرويي كه شرح آن رفت و خرجي هم ندارد، UI تان واقعاً بهبود پيدا ميكند. 

چهار استاده براي تست جوئل :

1. موسسه نرم افزاري خود را بسنجيد و امتيازتان را به من اطلاع دهيد تا بتوانم حرفهاي خاله زنكي پشت سرتان بزنم!
2. اگر مدير يك تيم نرم افزاري هستيد، با استفاده از اين تست چك كنيد كه آيا تيمتان با تمام توانش كار ميكند يا نه؟ اگر امتيازتان 12 است، بهتر است كه برنامه نويسانتان را به حال خودشان رها كنيد و انرژيتان را روي عدم مداخله بخش مالي و فروش شركت در كار برنامه نويسها متمركز كنيد.
3. اگر ميخواهيد جايي استخدام شويد، از كارفرماي جديدتان بپرسيد كه چه امتيازي در اين تست به دست ميآورند. اگر خيلي پايين بود، مطمئن شويد كه اختيارات درست كردن اوضاع را داريد و الا وجودتان بي حاصل خواهد بود.
4. اگر سرمايه گذاري هستيد كه در حال برنامه ريزي و سنجش تيمتان ميباشيد و يا شركتي نرم افزاري هستيد كه قصد تركيب با مجموعه نرم افزاري ديگري را داريد، اين تست وضعيت را به صورت سر انگشتي به شما خواهد گفت.