تست جوئل The Joel Test
تست جوئل The Joel Test
begin
12 راه برای کدنویسی بهتر ...
جوئل اسپولسکی، یهودی ساکن آمریکا است که از جمله سوابقش مدیریت پروژه MS Excel v5 است. او نظریات منحصر به فرد و جالبی در زمینه تولید نرم افزار دارد و امروزه در شرکت خودش، Fog Creek Software مشغول به کار است. متن زیر که توسط وی در اوت 2000 منتشر شده است مشخصه های ارزیابی یک تیم نرم افزاری را به زبان ساده و تا حدی طنز گونه بیان میکند. در ترجمه این متن سعی شده است اصطلاحات فنی به صورتی که بین برنامه نویسان حرفه ای در ایران مصطلح است به کار رود.
آیا تا بحال نام SEMA (Software Engineering Measurement and Analysis) را شنیده اید؟ SEMA ، سیستم نسبتاً مبهمی است برای اندازه گیری شایستگی یک تیم نرم افزاری. نه! صبر کنید، به سایت آن نروید، زیرا فقط شش سال طول میکشد تا مطالب آن را بفهمید. به همین علت من تست کاملاً نامرتب و نامعتبر (!) خودم را برای ارزیابی کیفیت یک تیم نرمافزاری درست کردم. بهترین قسمت ماجرا اینجاست که فقط سه دقیقه از وقتتان را میگیرد. با وقتی که صرفه جویی میکنید، میتوانید به سراغ حرفه پزشکی بروید ! ]1[
1- آیا از سیستم کنترل سورس بهره میبرید؟
2- آیا میتوانید در یک مرحله، برنامه تان را build کنید؟
3- آیا دارای build روزانه هستید؟
4- آیا بانک اطلاعاتی از اشکالات (bugs) دارید؟
5- آیا قبل از نوشتن کد جدید، به رفع اشکالات کنونی میپردازید؟
6- آیا برنامه زمانبندی تان به روز است؟
7- آیا دارای لیست مشخصات هستید؟
8- آیا برنامه نویسان شما محیط آرامی برای کار کردن دارند؟
9- آیا بهترین ابزارهایی را که وجود دارد میخرید؟
10- آیا بخش تست شما جداست؟
11- آیا داوطلبان جدید در موقع مصاحبه، کد هم مینویسند؟
12- آیا از آزمایش " قابلیت استفاده راهرویی " سود میجویید؟
ویژگی شسته و رُفته ی تست جوئل در این است که به راحتی میتوان به هر سؤال جواب بله یا نه داد. شما مجبور نیستید که تعداد خط های کد در روز یا تعداد متوسط اشکال در هر قسمت را بشمارید. نقطه ضعف تست جوئل در این است که نباید از آن برای اطمینان از صحت نرم افزار نیروگاه اتمی خود استفاده کنید!
امتیاز 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 (که هر دو برنامه نویس هستند) را در دو پارتیشن کنار هم قرار میدهیم. Mutt ، نام تابع کپی رشته در یونیکد را به خاطر نمی آورد. میتواند جواب آن را جستجو کند - که 30 ثانیه طول میکشد، و یا این که از Jeff بپرسد - که 30 ثانیه طول خواهد کشید. خوب، چون Jeff در کنارش نشسته است ترجیح میدهد که از او بپرسد. حواس جف پرت میشود و 15 دقیقه را از دست میدهد (برای این که Mutt 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. اگر سرمایه گذاری هستید که در حال برنامه ریزی و سنجش تیم تان میباشید و یا شرکتی نرم افزاری هستید که قصد ترکیب با مجموعه نرم افزاری دیگری را دارید، این تست وضعیت را به صورت سرانگشتی به شما خواهد گفت.
--------------پانوشت.
[1] ظاهراً آقای اسپولسکی در دانشگاه درس پزشکی خوانده است.
[2] killer feature
[3] features و یا ویژگیها
------------
حمید