TAHA
10-29-2009, 10:34 AM
جوئل اسپولسکی بنیانگذار Fog Creek Software است که یک شرکت کوچک نرم افزاری در شهر نیویورک است.او فارغ التحصیل دانشگاه یل(Yale University) است وبه عنوان برنامه نویس و مدیر در مایکروسافت ،Viacom و Juno کارکرده است.
جوئل مقاله جالبی در باب کد نویسی دارد ه با عنوان ۱۲ راه برای کد بهتر :
تست جوئل -- The Joel Test : 12 راه برای کد بهتر
توسط جوئل اسپولسکی
آیا تا بحال نام SEMA (Software Engineering Measurement and Analysis) را شنیده اید؟ SEMA ، سیستم نسبتاً مبهمی است برای اندازه گیری شايستگی یک تیم نرم‌افزاری. نه! صبر كنيد، به سایت آن نروید، زیرا فقط شش سال طول می‌کشد تا مطالب آن را بفهمید. به همین علت من تست کاملاً نامرتب و نامعتبر (!) خودم را برای ارزیابی كيفيت یک تیم نرم‌افزاری درست كردم. بهترین قسمت ماجرا اینجاست كه فقط سه دقیقه از وقتتان را می‌گيرد. با وقتی كه صرفه جویی می‌كنید، می‌توانید به سراغ حرفه پزشكي بروید[1]!
۱. آیا از سیستم كنترل سورس بهره می‌برید؟
۲. آیا می‌توانید در یك مرحله، برنامه‌تان را build كنید؟
۳. آیا دارای build روزانه هستید؟
۴. آیا بانك اطلاعاتی از اشكالات ((bugs دارید؟
۵. آیا قبل از نوشتن كد جدید، به رفع اشكالات کنونی می‌پردازید؟
۶. آیا برنامه زمان‌بندیتان به روز است؟
۷. آیا دارای لیست مشخصات هستید؟
۸. آیا برنامه‌نویسان شما محیط آرامی برای كار كردن دارند؟
۹. آیا بهترین ابزارهایی را که وجود دارد می‌خرید؟
۱۰. آیا بخش تست شما جداست؟
۱۱. آیا داوطلبان جدید در موقع مصاحبه، کد هم می‌نویسند؟
۱۲. آیا از آزمایش « قابلیت استفاده راهرویی » سود می‌جویید؟
ویژگی شسته و رفته تست جوئل در این است كه به راحتی می‌توان به هر سؤال جواب بله یا نه داد. شما مجبور نیستید كه تعداد خطهای كد در روز یا تعداد متوسط اشكال در هر قسمت را بشمارید. نقطه ضعف تست جوئل در این است كه نباید از آن برای اطمینان از صحت نرم‌افزار نیروگاه اتمی خود استفاده كنید!
امتیاز 12 عالی، 11 قابل قبول و 10 یا پایینتر نشان دهنده مشكلات جدی است. واقعیت در این است كه بیشتر موسسات نرم‌افزاری با امتیاز 2 یا 3 در حال فعالیت هستند و به كمك جدی نیاز دارند، چرا كه شركتهایی مانند Microsoft تمام مدت با امتیاز 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 ، این موارد را بر می‌شمرد.
مشكل اینجاست: همه ما می‌دانیم كه نیروی كار فنی با قرار گرفتن در جریانی كه از آن به « در بحر موضوع رفتن » تعبیر می‌شود - بهتر كار می‌كنند ؛ این زمانی است كه تمركزشان كاملاً بر روی كارشان است و حواسشان کاملاً از محیط اطرافشان پرت شده است. احساس زمان را از دست می‌دهند و از طریق تمرکز مطلق، چیزهای عالی‌ای خلق می‌کنند. نویسندگان، برنامه‌نویسان، دانشمندان، و حتی بازیکنان بسکتبال در مورد حالت « در بحر موضوع فرو رفتن » می‌توانند برای شما توضیح دهند.
وارد شدن به این حالت کار ساده‌ای نیست. اگر اندازه‌گیری کنید، می‌بینید که حدوداً ۱۵ دقیقه طول می‌کشد تا به حداکثر کارایی خود برسید. بعضی مواقع، زمانهایی که خسته هستید و یا به اندازه کافی برای آن روزتان خلاقیت به خرج داده‌اید، دیگر نمی‌توانید در بحر موضوع بروید و بقیه روز را به کارهای بیهوده، خواندن وب و Tetris بازی کردن می‌گذرانید.
مشکل دیگر در اینجاست که از دست دادن تمرکز کار ساده ایست :سر و صدا، تماسهای تلفنی، ناهار را بیرون خوردن، آن پنج دقیقه‌ای که برای نوشیدن قهوه تا کافی‌شاپ صرف رانندگی می‌کنید، و علی‌الخصوص مزاحمتها و سؤالهای همکاران، همگی تمرکز را از بین می‌برند. اگر همکار شما ازتان سؤالی بپرسد که یک دقیقه کارتان را متوقف کند، ولی آنقدر حواستان را پرت کند که نیم ساعتی طول بکشد تا به حالت سابق برگردید، بهره‌وری کلی تیمتان در خطر جدی قرار دارد. اگر در محیط شلوغی کار می‌کنید – از همان نوعی که dotcom های کافئین‌زده سخت عاشق آن هستند و در آنها بخش فروش زیر گوش برنامه‌نویسان مشغول داد و بیداد هستند - بهره‌وری شما سقوط بدی خواهد کرد.
در مورد برنامه‌نویسان (به نسبت بقیه knowledge workers و طیفهای دیگری که نیازمند تمرکز زیاد هستند)، قضیه سختتر است. بهره‌وری، به توانایی شعبده بازی با جزئیات زیادی در حافظه موقت بستگی دارد. هر نوع وقفه‌ای باعث بهم ریختن این جزئیات می‌شود. وقتی کارتان را از سر می‌گیرید، هیچ کدام از جزئیات (نظیر نام متغیرهای محلی یا اين که تا کجای پیاده‌سازی الگوریتم جستجویتان را انجام داده بودید) یادتان نخواهد آمد و مجبور به مراجعه به کار قبلتان هستید که سرعتتان را می‌گیرد.
ریاضیات این مسأله زیاد سخت نیست: فرض کنید (که شواهد هم این فرض را تأیید می‌کنند) که اگر برای یک دقیقه هم یک برنامه‌نویس را متوقف کنید، پانزده دقیقه از بهره‌وریش کم می‌کنید. برای مثال، Jeff و Mutt (که هر دو برنامه‌نویس هستند) را در دو پارتیشن کنار هم قرار می‌دهیم (در یک فضای کاملاً Dilbert ای). مات، نام تابع کپی رشته در یونیکد را به خاطر نمی‌آورد. می‌تواند جواب آن را جستجو کند - که ۳۰ ثانیه طول می‌کشد، و یا این که از جف بپرسد - که ۱۵ ثانیه طول خواهد کشید. خوب، چون جف در کنارش نشسته است ترجیح می‌دهد که از او بپرسد. حواس جف پرت می‌شود و ۱۵ دقیقه را از دست می‌دهد (برای این که مات ۱۵ ثانیه صرفه‌جویی کرده باشد.)
حالا اجازه دهید که جف و مات را در دو اتاق (با در و دیوار) جدا بگذاریم. اکنون وقتی که مات اسم تابع را به خاطر نمی‌آورد، می‌تواند جواب آن را جستجو کند (که همان ۳۰ ثانیه طول می‌کشد) و یا این که از جف بپرسد که ۴۵ ثانیه طول می‌کشد و شامل از جای خود بلند شدن هم می‌شود (که با توجه به وضعیت جسمی معمول برنامه‌نویسان و مسایل ديگر ، کار ساده‌ای نیست!). بنابر این ترجیح می‌دهد که جوابش را جستجو کند. ۳۰ ثانیه وقتش تلف می‌شود اما ۱۵ دقیقه به نفع جف است! وای!
۹. آیا بهترین ابزارهایی را که وجود دارد می‌خرید؟
نوشتن کد در یک زبان کامپایل شده از کارهایی است که هنوز بر روی کامپیوترهای خروس‌نشان، نمی‌توان با سرعت انجام داد. اگر فرآیند کامپایل، بیشتر از چند ثانیه طول می‌کشد، خرید جدیدترین و بهترین کامپیوتر در وقتتان صرفه‌جویی خواهد کرد. اگر کامپایل کردن حتی ۱۵ ثانیه طول بکشد، برنامه‌نویسها حوصله‌شان سر می‌رود و می‌روند به سراغ خواندن سایت The Onion ، که آن هم تمام هوش و حواسشان را به خود خواهد برد و ساعتها بهره‌وری از بین می‌رود.
debug کردن کد GUI با یک مانیتور اگر غیر ممکن نباشد، بسیار سخت و دردناک است. اگر در حال نوشتن کد GUI هستید، داشتن دو مانیتور همه چیز را بسیار ساده خواهد کرد.
بیشتر برنامه‌نویسان باید یک زمانی فایلهای bitmap را (برای iconها و toolbarها) دستکاری کنند و اکثراً ویرایشگر مناسب برای این کار ندارند. استفاده از MS Paint برای این کار بیشتر شبیه یک شوخی است، که البته غالب برنامه‌نویسها از همین روش استفاده می‌کنند.
در محل کار قبلی‌ام، admin شبکه دایماً برای من spamمی‌فرستاد و غر می‌زد که من بیشتر از ۲۲۰ مگابایت فضای مجازم، روی سرور جا اشغال کرده‌ام. من روزی جواب دادم که با توجه به قیمت هارد دیسک، هزینه فضای مورد استفاده کمتر از هزینه دستمال کاغذی من است و صرف کردن حتی ده دقیقه از وقتم برای کوچک کردن دایرکتوری‌ام یک هدر دادن اشرافی بهره‌وری است.
تیمهای تولید نرم‌افزار درجه یک، برنامه‌نویسان خود را ***جه نمی‌کنند. حتی موضوعات جزیی اعصاب‌خردکن ناشی از داشتن ابزار نامناسب، جمع می‌شود و برنامه‌نویسها را بد اخلاق و ناراحت می‌کند. یک برنامه‌نویس بد خلق، یک برنامه‌نویس با کارایی پایین است.
یک نکته دیگر هم اضافه کنم... برنامه‌نویسها را به راحتی می‌توان با رشوه دادن - بوسیله جدیدترین و باحالترین وسایل - تطمیع کرد. این برایتان خیلی ارزانتر از دادن حقوق مکفی تمام می‌شود!
۱۰. آیا بخش تست شما جداست؟
اگر در تیم شما افرادی که وقتشان اختصاصاً برای تست کردن باشد – حداقل یک نفر برای هر دو یا سه برنامه‌نویس – وجود نداشته باشد، شما یا محصولات باگ‌دار تحویل خواهید داد؛ و یا این که با پرداخت ۱۰۰ دلار در ساعت به جای ۳۰ دلار در ساعت، پولتان را هدر می‌دهید. خساست در زمینه افراد جهت بخش تست، آن قدر صرفه‌جویی احمقانه‌ایست که من واقعاً تعجب می‌کنم چرا اکثر مردم نمی‌فهمند.
مقاله Top Five (Wrong) Reasons You Don’t Have Testers را که در مورد همین موضوع نوشتم، بخوانید.
۱۱. آیا داوطلبان جدید در موقع مصاحبه، کد هم می‌نویسند؟
آیا شما حاضرید یک شعبده‌بازی را بدون این که چند حقه برایتان اجرا کند، استخدام کنید؟ معلوم است که نه. آیا برای عروسیتان، آشپزی که غذایش را نچشیده باشید، استخدام می‌کنید؟ بعید می‌دانم. (مگر این که خاله بزرگتان باشد و بترسید که تا آخر عمر از شما به دل بگیرد و برنجد.)
با این وجود، هر روز، برنامه‌نویسهایی بخاطر داشتن resume جالب یا به این خاطر که مصاحبه‌گر از گپ زدن با او لذت برده، استخدام می‌شوند. یا باید به سوالات ساده‌ای مانند « فرق CreateDialog() و DialogBox() چیه؟ » که با خواندن مستندات قابل پاسخ‌گویی است، جواب دهند. واقعاً نباید برایتان اهمیتی داشته باشد که داوطلب، هزاران نکته پیش پا افتاده را حفظ کرده‌است یا نه، بلكه باید توانایی او در تولید کد برایتان مهم باشد. از همه چیز بدتر، سؤالات « معما گونه » است : آن دسته از سؤالاتی که پاسخ دادن به آنها غیر ممکن است ولی وقتی جواب را می‌دانید بدیهی به نظر می‌رسند.
لطفاً از این کارها نکنید! و هر کاری که می‌کنید، حتماً از مصاحبه شونده بخواهید که برایتان کد بنویسد. (برای راهنمایی بیشتر، به مقاله Guerrilla Guide to Interviewing مراجعه کنید.)
۱۲. آیا از آزمایش « قابلیت استفاده راهرویی » سود می‌جویید؟
در تست hallway usability، شما خِر اولین فردی را که از راهرو رد می‌شود، می‌گیرید؛ و مجبورشان می‌کنید که بنشینند پای برنامه‌ای که همین الان نوشته‌اید. اگر با پنج نفر این کار را تکرار کنید، ۹۵٪ مشکلات کار با برنامه‌تان (usability problems) را کشف خواهید کرد.
طراحی « واسط کاربر » خوب آنقدرها هم که فکر می‌کنید سخت نیست، حتی برای این که مشتریها عاشق برنامه‌تان بشوند و آن را بخرند، واجب هم هست. کتاب مجانی و online من در مورد طراحی واسط کاربر که الفبای آن را برای برنامه‌نویسان شرح می‌دهد بخوانید.
اما مهمترین نکته در مورد واسطهای کاربر (user interfaces) این است که اگر برنامه‌تان را به پنج یا شش نفر نشان دهید، به سرعت بزرگترین مشکلات کاربران را خواهید دانست. Jakob Nielsen مقاله‌ای دارد که در آن توضیح می‌دهد چرا این چنین است. خلاصه این که حتی اگر در زمینه UI واقعاً ضعیف باشید، با آزمایشهای قابلیت استفاده راهرویی که شرح آن رفت و خرجی هم ندارد، UI تان واقعاً بهبود پیدا می‌کند.
چهار استفاده برای تست جوئل
1.موسسه نرم‌افزاری خود را بسنجید و امتیازتان را به من اطلاع دهید تا بتوانم حرفهای خاله‌زنکی پشت سرتان بزنم!
2.اگر مدیر یک تیم نرم‌افزاری هستید، با استفاده از این تست چک کنید که آیا تیمتان با تمام توانش کار می‌کند یا نه؟ اگر امتیازتان ۱۲ است، بهتر است که برنامه‌نویسانتان را به حال خودشان رها کنید و انرژیتان را روی عدم مداخله بخش مالی و فروش شرکت در کار برنامه‌نویسها متمرکز کنید.
3.اگر می‌خواهید جایی استخدام شوید، از کارفرمای جدیدتان بپرسید که چه امتیازی در این تست به دست می‌آورند. اگر خیلی پایین بود، مطمئن شوید که اختیارات درست کردن اوضاع را دارید و الا وجودتان بی‌حاصل خواهد بود.
4.اگر سرمایه‌گذاری هستید که در حال برنامه‌ریزی و سنجش تیمتان می‌باشید و یا شرکتی نرم‌افزاری هستید که قصد ترکیب با مجموعه نرم‌افزاری دیگری را دارید، این تست وضعیت را به صورت سرانگشتی به شما خواهد گفت
جوئل مقاله جالبی در باب کد نویسی دارد ه با عنوان ۱۲ راه برای کد بهتر :
تست جوئل -- The Joel Test : 12 راه برای کد بهتر
توسط جوئل اسپولسکی
آیا تا بحال نام SEMA (Software Engineering Measurement and Analysis) را شنیده اید؟ SEMA ، سیستم نسبتاً مبهمی است برای اندازه گیری شايستگی یک تیم نرم‌افزاری. نه! صبر كنيد، به سایت آن نروید، زیرا فقط شش سال طول می‌کشد تا مطالب آن را بفهمید. به همین علت من تست کاملاً نامرتب و نامعتبر (!) خودم را برای ارزیابی كيفيت یک تیم نرم‌افزاری درست كردم. بهترین قسمت ماجرا اینجاست كه فقط سه دقیقه از وقتتان را می‌گيرد. با وقتی كه صرفه جویی می‌كنید، می‌توانید به سراغ حرفه پزشكي بروید[1]!
۱. آیا از سیستم كنترل سورس بهره می‌برید؟
۲. آیا می‌توانید در یك مرحله، برنامه‌تان را build كنید؟
۳. آیا دارای build روزانه هستید؟
۴. آیا بانك اطلاعاتی از اشكالات ((bugs دارید؟
۵. آیا قبل از نوشتن كد جدید، به رفع اشكالات کنونی می‌پردازید؟
۶. آیا برنامه زمان‌بندیتان به روز است؟
۷. آیا دارای لیست مشخصات هستید؟
۸. آیا برنامه‌نویسان شما محیط آرامی برای كار كردن دارند؟
۹. آیا بهترین ابزارهایی را که وجود دارد می‌خرید؟
۱۰. آیا بخش تست شما جداست؟
۱۱. آیا داوطلبان جدید در موقع مصاحبه، کد هم می‌نویسند؟
۱۲. آیا از آزمایش « قابلیت استفاده راهرویی » سود می‌جویید؟
ویژگی شسته و رفته تست جوئل در این است كه به راحتی می‌توان به هر سؤال جواب بله یا نه داد. شما مجبور نیستید كه تعداد خطهای كد در روز یا تعداد متوسط اشكال در هر قسمت را بشمارید. نقطه ضعف تست جوئل در این است كه نباید از آن برای اطمینان از صحت نرم‌افزار نیروگاه اتمی خود استفاده كنید!
امتیاز 12 عالی، 11 قابل قبول و 10 یا پایینتر نشان دهنده مشكلات جدی است. واقعیت در این است كه بیشتر موسسات نرم‌افزاری با امتیاز 2 یا 3 در حال فعالیت هستند و به كمك جدی نیاز دارند، چرا كه شركتهایی مانند Microsoft تمام مدت با امتیاز 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 ، این موارد را بر می‌شمرد.
مشكل اینجاست: همه ما می‌دانیم كه نیروی كار فنی با قرار گرفتن در جریانی كه از آن به « در بحر موضوع رفتن » تعبیر می‌شود - بهتر كار می‌كنند ؛ این زمانی است كه تمركزشان كاملاً بر روی كارشان است و حواسشان کاملاً از محیط اطرافشان پرت شده است. احساس زمان را از دست می‌دهند و از طریق تمرکز مطلق، چیزهای عالی‌ای خلق می‌کنند. نویسندگان، برنامه‌نویسان، دانشمندان، و حتی بازیکنان بسکتبال در مورد حالت « در بحر موضوع فرو رفتن » می‌توانند برای شما توضیح دهند.
وارد شدن به این حالت کار ساده‌ای نیست. اگر اندازه‌گیری کنید، می‌بینید که حدوداً ۱۵ دقیقه طول می‌کشد تا به حداکثر کارایی خود برسید. بعضی مواقع، زمانهایی که خسته هستید و یا به اندازه کافی برای آن روزتان خلاقیت به خرج داده‌اید، دیگر نمی‌توانید در بحر موضوع بروید و بقیه روز را به کارهای بیهوده، خواندن وب و Tetris بازی کردن می‌گذرانید.
مشکل دیگر در اینجاست که از دست دادن تمرکز کار ساده ایست :سر و صدا، تماسهای تلفنی، ناهار را بیرون خوردن، آن پنج دقیقه‌ای که برای نوشیدن قهوه تا کافی‌شاپ صرف رانندگی می‌کنید، و علی‌الخصوص مزاحمتها و سؤالهای همکاران، همگی تمرکز را از بین می‌برند. اگر همکار شما ازتان سؤالی بپرسد که یک دقیقه کارتان را متوقف کند، ولی آنقدر حواستان را پرت کند که نیم ساعتی طول بکشد تا به حالت سابق برگردید، بهره‌وری کلی تیمتان در خطر جدی قرار دارد. اگر در محیط شلوغی کار می‌کنید – از همان نوعی که dotcom های کافئین‌زده سخت عاشق آن هستند و در آنها بخش فروش زیر گوش برنامه‌نویسان مشغول داد و بیداد هستند - بهره‌وری شما سقوط بدی خواهد کرد.
در مورد برنامه‌نویسان (به نسبت بقیه knowledge workers و طیفهای دیگری که نیازمند تمرکز زیاد هستند)، قضیه سختتر است. بهره‌وری، به توانایی شعبده بازی با جزئیات زیادی در حافظه موقت بستگی دارد. هر نوع وقفه‌ای باعث بهم ریختن این جزئیات می‌شود. وقتی کارتان را از سر می‌گیرید، هیچ کدام از جزئیات (نظیر نام متغیرهای محلی یا اين که تا کجای پیاده‌سازی الگوریتم جستجویتان را انجام داده بودید) یادتان نخواهد آمد و مجبور به مراجعه به کار قبلتان هستید که سرعتتان را می‌گیرد.
ریاضیات این مسأله زیاد سخت نیست: فرض کنید (که شواهد هم این فرض را تأیید می‌کنند) که اگر برای یک دقیقه هم یک برنامه‌نویس را متوقف کنید، پانزده دقیقه از بهره‌وریش کم می‌کنید. برای مثال، Jeff و Mutt (که هر دو برنامه‌نویس هستند) را در دو پارتیشن کنار هم قرار می‌دهیم (در یک فضای کاملاً Dilbert ای). مات، نام تابع کپی رشته در یونیکد را به خاطر نمی‌آورد. می‌تواند جواب آن را جستجو کند - که ۳۰ ثانیه طول می‌کشد، و یا این که از جف بپرسد - که ۱۵ ثانیه طول خواهد کشید. خوب، چون جف در کنارش نشسته است ترجیح می‌دهد که از او بپرسد. حواس جف پرت می‌شود و ۱۵ دقیقه را از دست می‌دهد (برای این که مات ۱۵ ثانیه صرفه‌جویی کرده باشد.)
حالا اجازه دهید که جف و مات را در دو اتاق (با در و دیوار) جدا بگذاریم. اکنون وقتی که مات اسم تابع را به خاطر نمی‌آورد، می‌تواند جواب آن را جستجو کند (که همان ۳۰ ثانیه طول می‌کشد) و یا این که از جف بپرسد که ۴۵ ثانیه طول می‌کشد و شامل از جای خود بلند شدن هم می‌شود (که با توجه به وضعیت جسمی معمول برنامه‌نویسان و مسایل ديگر ، کار ساده‌ای نیست!). بنابر این ترجیح می‌دهد که جوابش را جستجو کند. ۳۰ ثانیه وقتش تلف می‌شود اما ۱۵ دقیقه به نفع جف است! وای!
۹. آیا بهترین ابزارهایی را که وجود دارد می‌خرید؟
نوشتن کد در یک زبان کامپایل شده از کارهایی است که هنوز بر روی کامپیوترهای خروس‌نشان، نمی‌توان با سرعت انجام داد. اگر فرآیند کامپایل، بیشتر از چند ثانیه طول می‌کشد، خرید جدیدترین و بهترین کامپیوتر در وقتتان صرفه‌جویی خواهد کرد. اگر کامپایل کردن حتی ۱۵ ثانیه طول بکشد، برنامه‌نویسها حوصله‌شان سر می‌رود و می‌روند به سراغ خواندن سایت The Onion ، که آن هم تمام هوش و حواسشان را به خود خواهد برد و ساعتها بهره‌وری از بین می‌رود.
debug کردن کد GUI با یک مانیتور اگر غیر ممکن نباشد، بسیار سخت و دردناک است. اگر در حال نوشتن کد GUI هستید، داشتن دو مانیتور همه چیز را بسیار ساده خواهد کرد.
بیشتر برنامه‌نویسان باید یک زمانی فایلهای bitmap را (برای iconها و toolbarها) دستکاری کنند و اکثراً ویرایشگر مناسب برای این کار ندارند. استفاده از MS Paint برای این کار بیشتر شبیه یک شوخی است، که البته غالب برنامه‌نویسها از همین روش استفاده می‌کنند.
در محل کار قبلی‌ام، admin شبکه دایماً برای من spamمی‌فرستاد و غر می‌زد که من بیشتر از ۲۲۰ مگابایت فضای مجازم، روی سرور جا اشغال کرده‌ام. من روزی جواب دادم که با توجه به قیمت هارد دیسک، هزینه فضای مورد استفاده کمتر از هزینه دستمال کاغذی من است و صرف کردن حتی ده دقیقه از وقتم برای کوچک کردن دایرکتوری‌ام یک هدر دادن اشرافی بهره‌وری است.
تیمهای تولید نرم‌افزار درجه یک، برنامه‌نویسان خود را ***جه نمی‌کنند. حتی موضوعات جزیی اعصاب‌خردکن ناشی از داشتن ابزار نامناسب، جمع می‌شود و برنامه‌نویسها را بد اخلاق و ناراحت می‌کند. یک برنامه‌نویس بد خلق، یک برنامه‌نویس با کارایی پایین است.
یک نکته دیگر هم اضافه کنم... برنامه‌نویسها را به راحتی می‌توان با رشوه دادن - بوسیله جدیدترین و باحالترین وسایل - تطمیع کرد. این برایتان خیلی ارزانتر از دادن حقوق مکفی تمام می‌شود!
۱۰. آیا بخش تست شما جداست؟
اگر در تیم شما افرادی که وقتشان اختصاصاً برای تست کردن باشد – حداقل یک نفر برای هر دو یا سه برنامه‌نویس – وجود نداشته باشد، شما یا محصولات باگ‌دار تحویل خواهید داد؛ و یا این که با پرداخت ۱۰۰ دلار در ساعت به جای ۳۰ دلار در ساعت، پولتان را هدر می‌دهید. خساست در زمینه افراد جهت بخش تست، آن قدر صرفه‌جویی احمقانه‌ایست که من واقعاً تعجب می‌کنم چرا اکثر مردم نمی‌فهمند.
مقاله Top Five (Wrong) Reasons You Don’t Have Testers را که در مورد همین موضوع نوشتم، بخوانید.
۱۱. آیا داوطلبان جدید در موقع مصاحبه، کد هم می‌نویسند؟
آیا شما حاضرید یک شعبده‌بازی را بدون این که چند حقه برایتان اجرا کند، استخدام کنید؟ معلوم است که نه. آیا برای عروسیتان، آشپزی که غذایش را نچشیده باشید، استخدام می‌کنید؟ بعید می‌دانم. (مگر این که خاله بزرگتان باشد و بترسید که تا آخر عمر از شما به دل بگیرد و برنجد.)
با این وجود، هر روز، برنامه‌نویسهایی بخاطر داشتن resume جالب یا به این خاطر که مصاحبه‌گر از گپ زدن با او لذت برده، استخدام می‌شوند. یا باید به سوالات ساده‌ای مانند « فرق CreateDialog() و DialogBox() چیه؟ » که با خواندن مستندات قابل پاسخ‌گویی است، جواب دهند. واقعاً نباید برایتان اهمیتی داشته باشد که داوطلب، هزاران نکته پیش پا افتاده را حفظ کرده‌است یا نه، بلكه باید توانایی او در تولید کد برایتان مهم باشد. از همه چیز بدتر، سؤالات « معما گونه » است : آن دسته از سؤالاتی که پاسخ دادن به آنها غیر ممکن است ولی وقتی جواب را می‌دانید بدیهی به نظر می‌رسند.
لطفاً از این کارها نکنید! و هر کاری که می‌کنید، حتماً از مصاحبه شونده بخواهید که برایتان کد بنویسد. (برای راهنمایی بیشتر، به مقاله Guerrilla Guide to Interviewing مراجعه کنید.)
۱۲. آیا از آزمایش « قابلیت استفاده راهرویی » سود می‌جویید؟
در تست hallway usability، شما خِر اولین فردی را که از راهرو رد می‌شود، می‌گیرید؛ و مجبورشان می‌کنید که بنشینند پای برنامه‌ای که همین الان نوشته‌اید. اگر با پنج نفر این کار را تکرار کنید، ۹۵٪ مشکلات کار با برنامه‌تان (usability problems) را کشف خواهید کرد.
طراحی « واسط کاربر » خوب آنقدرها هم که فکر می‌کنید سخت نیست، حتی برای این که مشتریها عاشق برنامه‌تان بشوند و آن را بخرند، واجب هم هست. کتاب مجانی و online من در مورد طراحی واسط کاربر که الفبای آن را برای برنامه‌نویسان شرح می‌دهد بخوانید.
اما مهمترین نکته در مورد واسطهای کاربر (user interfaces) این است که اگر برنامه‌تان را به پنج یا شش نفر نشان دهید، به سرعت بزرگترین مشکلات کاربران را خواهید دانست. Jakob Nielsen مقاله‌ای دارد که در آن توضیح می‌دهد چرا این چنین است. خلاصه این که حتی اگر در زمینه UI واقعاً ضعیف باشید، با آزمایشهای قابلیت استفاده راهرویی که شرح آن رفت و خرجی هم ندارد، UI تان واقعاً بهبود پیدا می‌کند.
چهار استفاده برای تست جوئل
1.موسسه نرم‌افزاری خود را بسنجید و امتیازتان را به من اطلاع دهید تا بتوانم حرفهای خاله‌زنکی پشت سرتان بزنم!
2.اگر مدیر یک تیم نرم‌افزاری هستید، با استفاده از این تست چک کنید که آیا تیمتان با تمام توانش کار می‌کند یا نه؟ اگر امتیازتان ۱۲ است، بهتر است که برنامه‌نویسانتان را به حال خودشان رها کنید و انرژیتان را روی عدم مداخله بخش مالی و فروش شرکت در کار برنامه‌نویسها متمرکز کنید.
3.اگر می‌خواهید جایی استخدام شوید، از کارفرمای جدیدتان بپرسید که چه امتیازی در این تست به دست می‌آورند. اگر خیلی پایین بود، مطمئن شوید که اختیارات درست کردن اوضاع را دارید و الا وجودتان بی‌حاصل خواهد بود.
4.اگر سرمایه‌گذاری هستید که در حال برنامه‌ریزی و سنجش تیمتان می‌باشید و یا شرکتی نرم‌افزاری هستید که قصد ترکیب با مجموعه نرم‌افزاری دیگری را دارید، این تست وضعیت را به صورت سرانگشتی به شما خواهد گفت