توضیح دوات: این مطلب در سال ۲۰۰۰ توسط جوئل اسپالسکی، هم‌بنیان‌گذار Stackoverflow نوشته شده است. بعضی از مثال‌ها به مرور زمان معنای خود را از دست داده‌اند (به عنوان مثال شاید دیگر کسی CVS را نشناسد و در مقابل معادل بروز آن Git کاملا بنام باشد)، با این همه بسیاری از شرکت‌های کوچک در داخل کشور در حال حاضر ۱۲ امتیاز را نمیگیرند.
آیا تا به حال درباره‌ی SEMA شنیده‌اید؟ این یک سیستم نسبتاً خاص برای ارزیابی کیفیت یک تیم نرم‌افزاری است. نه، صبر کنید! روی آن لینک کلیک نکنید! حدود شش سال طول می‌کشد تا بتوانید آن مطالب را درک کنید. بنابراین من خودم یک تست کاملاً غیرمسئولانه و شلخته برای سنجش کیفیت تیم‌های نرم‌افزاری طراحی کرده‌ام. بهترین بخش آن این است که حدود ۳ دقیقه طول می‌کشد. با زمانی که صرفه‌جویی می‌کنید، می‌توانید به دانشکده‌ی پزشکی بروید.
تست جوئل (The Joel Test)
- آیا از کنترل نسخه استفاده می‌کنید؟
- آیا می‌توانید با یک مرحله یک بیلد (build) بسازید؟
- آیا روزانه بیلد می‌گیرید؟
- آیا یک پایگاه داده برای باگ‌ها دارید؟
- آیا قبل از نوشتن کد جدید، باگ‌ها را برطرف می‌کنید؟
- آیا یک برنامه زمان‌بندی به‌روز دارید؟
- آیا مستندات (spec) دارید؟
- آیا برنامه‌نویسان شرایط کاری آرامی دارند؟
- آیا از بهترین ابزارهای موجود استفاده می‌کنید؟
- آیا تستر دارید؟
- آیا در مصاحبه‌ها از کاندیداها خواسته می‌شود کد بنویسند؟
- آیا تست کاربری در محل انجام می‌دهید؟
ویژگی جالب تست جوئل این است که پاسخ هر سوال به سادگی یک “بله” یا “نه” است. نیازی نیست که خطوط کد در روز یا متوسط تعداد باگ‌ها را محاسبه کنید. برای هر پاسخ “بله” به تیم خود یک امتیاز بدهید. اما نکته منفی این تست این است که واقعاً نباید از آن برای اطمینان از امنیت نرم‌افزار یک نیروگاه هسته‌ای استفاده کنید.
امتیاز ۱۲ عالی است، ۱۱ قابل قبول است، اما اگر امتیاز شما ۱۰ یا کمتر باشد، مشکلات جدی دارید. واقعیت این است که بیشتر سازمان‌های نرم‌افزاری با امتیاز ۲ یا ۳ کار می‌کنند و نیاز جدی به کمک دارند، چون شرکت‌هایی مثل مایکروسافت با امتیاز کامل ۱۲ کار می‌کنند.
البته، این‌ها تنها عوامل تعیین‌کننده‌ی موفقیت یا شکست نیستند: به خصوص اگر یک تیم نرم‌افزاری عالی داشته باشید که روی محصولی کار میکند که کسی آن را نمی‌خواهد، خوب، کسی آن را نخواهد خواست. همچنین ممکن است تیمی از “مسلحان” را تصور کنید که هیچ‌کدام از این موارد را انجام نمی‌دهند اما همچنان نرم‌افزار شگفت‌انگیزی تولید می‌کنند که دنیا را تغییر می‌دهد. اما اگر بقیه شرایط برابر باشند، اگر این ۱۲ مورد را درست انجام دهید، تیم منظمی خواهید داشت که می‌تواند به‌طور مستمر عملکرد خوبی ارائه دهد.
1. آیا از کنترل نسخه استفاده می‌کنید؟
من از بسته‌های تجاری کنترل نسخه استفاده کرده‌ام و از CVS هم که رایگان است استفاده کرده‌ام و به شما بگویم، CVS خوب است. اما اگر کنترل نسخه ندارید، برای همکاری برنامه‌نویسان دچار استرس خواهید شد. برنامه‌نویسان هیچ راهی ندارند که بدانند بقیه چه کرده‌اند. اشتباهات به راحتی قابل بازگشت نیستند. نکته دیگر در مورد سیستم‌های کنترل نسخه این است که کد منبع خودش روی هارد درایو هر برنامه‌نویس قرار می‌گیرد — من هرگز پروژه‌ای با کنترل نسخه ندیده‌ام که مقدار زیادی کد از دست داده باشد.
2. آیا می‌توانید با یک مرحله یک بیلد بسازید؟
منظورم این است که چند مرحله برای ساخت یک بیلد نهایی از آخرین نسخه‌ی سورس لازم است؟ در تیم‌های خوب، یک اسکریپت واحد وجود دارد که می‌توانید اجرا کنید و یک چک‌آوت کامل از ابتدا بگیرد، تمام کدها را از نو بسازد، EXEها را در همه نسخه‌ها، زبان‌ها و ترکیب‌های #ifdef مختلف بسازد، بسته نصب را ایجاد کند، و رسانه نهایی را بسازد — از جمله چیدمان CDROM، سایت دانلود و هر چیز دیگر.
اگر فرآیند بیش از یک مرحله طول بکشد، مستعد خطا است. و زمانی که به زمان عرضه نزدیک می‌شوید، می‌خواهید چرخه‌ای سریع برای رفع باگ آخر و ساخت EXE نهایی داشته باشید. اگر ۲۰ مرحله طول بکشد تا کد را کامپایل کنید و نصب‌ساز را اجرا کنید، دیوانه می‌شوید و اشتباهات احمقانه می‌کنید.
به همین دلیل بود که آخرین شرکتی که در آن کار می‌کردم از WISE به InstallShield تغییر داد: ما نیاز داشتیم که فرآیند نصب از طریق یک اسکریپت به‌طور خودکار، شبانه، با استفاده از NT scheduler اجرا شود، و WISE نمی‌توانست از scheduler در شب اجرا شود، بنابراین آن را کنار گذاشتیم. (دوستان خوبمان در WISE به من اطمینان دادند که نسخه آخرشان از بیلدهای شبانه پشتیبانی میکند.)
3. آیا روزانه بیلد می‌گیرید؟
وقتی از کنترل نسخه استفاده می‌کنید، گاهی یک برنامه‌نویس به‌طور تصادفی چیزی را که بیلد را خراب میکند، چک‌این میکند. مثلاً فایلی جدید اضافه کرده و همه چیز روی دستگاه خودش به‌خوبی کامپایل شده، اما فراموش کرده آن فایل را به مخزن کد اضافه کند. او دستگاهش را قفل میکند و خوشحال و بی‌خبر به خانه می‌رود. اما بقیه نمی‌توانند کار کنند و مجبورند به خانه بروند، ناراحت.
خراب کردن بیلد بسیار بد (و بسیار رایج) است و کمک میکند که بیلدهای روزانه انجام دهید تا هیچ خرابی نادیده نماند. در تیم‌های بزرگ، یکی از راه‌های خوب برای اطمینان از اینکه خرابی‌ها سریعاً رفع شوند این است که بیلد روزانه هر بعد از ظهر، مثلاً موقع ناهار انجام شود. همه تا جای ممکن چک‌این‌های خود را قبل از ناهار انجام می‌دهند. وقتی برمی‌گردند، بیلد تمام شده است. اگر درست عمل کرد، عالی! همه آخرین نسخه کد را چک‌آوت کرده و به کار ادامه می‌دهند. اگر بیلد ناموفق بود، آن را رفع می‌کنید، اما همه می‌توانند با نسخه‌ی پیش از بیلد، که خراب نیست، به کار ادامه دهند.
در تیم Excel ما قانونی داشتیم که هرکسی که بیلد را خراب کرد، به عنوان “مجازات” مسئول نگهداری بیلدها می‌شد تا کسی دیگر آن را خراب کند. این انگیزه خوبی برای خراب نکردن بیلد بود و راهی خوب برای چرخاندن همه در فرآیند بیلد بود تا همه یاد بگیرند که چگونه کار میکند.
بیشتر درباره بیلدهای روزانه را در مقاله‌ی Daily Builds are Your Friend بخوانید.
4. آیا پایگاه داده‌ای برای باگ‌ها دارید؟
اهمیتی ندارد چه می‌گویید. اگر بدون داشتن پایگاهی سازماندهی شده که همه‌ی باگ‌های شناخته شده‌ی کد را لیست کند، حتی در تیمی یک‌نفره، کد توسعه می‌دهید، کد بی‌کیفیتی تحویل خواهید داد. بسیاری از برنامه‌نویسان فکر می‌کنند که می‌توانند فهرست باگ‌ها را در ذهن خود نگه دارند. حرف بیهوده‌ای است. من نمی‌توانم بیشتر از دو یا سه باگ را همزمان به خاطر بسپارم، و صبح روز بعد یا در حین فشار عرضه، فراموش می‌شوند. شما حتماً باید باگ‌ها را به صورت رسمی پیگیری کنید.
پایگاه داده‌های باگ می‌توانند پیچیده یا ساده باشند. یک پایگاه داده باگ ساده و کارآمد باید شامل اطلاعات زیر برای هر باگ باشد:
- مراحل کامل برای بازتولید باگ
- رفتار مورد انتظار
- رفتار مشاهده شده (مشکل‌دار)- فرد مسئول آن
- اینکه رفع شده یا نه
اگر پیچیدگی نرم‌افزار پیگیری باگ تنها چیزی است که شما را از پیگیری باگ‌ها باز می‌دارد، فقط یک جدول ساده پنج ستونه با این فیلدهای حیاتی بسازید و از آن استفاده کنید.
برای اطلاعات بیشتر در مورد پیگیری باگ، مقاله‌ی Painless Bug Tracking را بخوانید.
5. آیا شما پیش از نوشتن کد جدید، خطاها را رفع می‌کنید؟
اولین نسخه Microsoft Word برای Windows به‌عنوان یک پروژه با عنوان “مارش مرگ” شناخته می‌شد. این پروژه بسیار طولانی و زمان‌بر بود و به تأخیرهای پی‌درپی دچار می‌شد. تیم توسعه‌دهنده ساعت‌های طولانی و طاقت‌فرسایی کار می‌کردند و پروژه بارها و بارها به تعویق می‌افتاد. پس از اتمام پروژه، با سال‌ها تأخیر، مایکروسافت تمام تیم را برای تعطیلات به Cancun فرستاد و سپس جلسه‌ای برای بررسی مشکلات پروژه برگزار کرد.
آن‌ها دریافتند که مدیران پروژه به‌قدری بر “برنامه زمان‌بندی” تأکید داشتند که برنامه‌نویسان به‌صورت شتاب‌زده کدهای بی‌کیفیت می‌نوشتند، زیرا فرآیند رفع خطا در برنامه رسمی زمان‌بندی قرار نداشت. حتی سعی نمی‌شد که تعداد خطاها کاهش یابد، بلکه برعکس بود. روایت شده که یکی از برنامه‌نویسان برای نوشتن تابعی که ارتفاع یک خط متن را محاسبه می‌کرد، تنها نوشت “return 12;” و منتظر گزارش خطا ماند تا مشخص شود تابع او همیشه درست کار نمی‌کند. برنامه زمان‌بندی تنها یک فهرست ویژگی بود که منتظر تبدیل به خطاها بود. در بررسی پروژه، این رویکرد به‌عنوان “روش خطاهای بی‌پایان” شناخته شد.
برای اصلاح این مشکل، مایکروسافت روشی به نام “روش صفر خطا” را به‌طور کلی پذیرفت. بسیاری از برنامه‌نویسان شرکت به آن خندیدند، چون به نظر می‌رسید که مدیریت می‌خواست با فرمان اجرایی تعداد خطاها را کاهش دهد. اما در واقع، “صفر خطا” به این معنا بود که در هر زمان اولویت اصلی حذف خطاها قبل از نوشتن کد جدید باشد. دلیل آن روشن است.
به‌طور کلی، هرچه بیشتر برای رفع یک خطا صبر کنید، هزینه بیشتری از لحاظ زمان و پول برای رفع آن می‌پردازید.
مثلاً وقتی خطای تایپی یا دستوری در کد خود دارید که کامپایلر آن را می‌گیرد، رفع آن بسیار ساده است.
اگر خطایی در کد خود داشته باشید که هنگام اجرای اولیه مشاهده کنید، می‌توانید فوراً آن را رفع کنید، زیرا تمام کد هنوز در ذهن شما تازه است.
اگر چند روز بعد خطایی در کدی پیدا کنید که نوشته‌اید، کمی وقت می‌برد تا آن را پیدا کنید، اما با مرور کد نوشته شده، همه چیز را به یاد می‌آورید و می‌توانید خطا را در زمانی معقول رفع کنید.
اما اگر خطایی در کدی پیدا کنید که چند ماه پیش نوشته‌اید، احتمالاً خیلی چیزها را درباره آن کد فراموش کرده‌اید و رفع آن بسیار دشوارتر است. در این حالت، ممکن است شما مجبور شوید کد شخص دیگری را تعمیر کنید و آن شخص ممکن است در تعطیلات باشد؛ در این صورت، رفع خطا مثل حل مسئله‌ای علمی خواهد بود: باید با دقت و روش‌مندانه عمل کنید و نمی‌توانید پیش‌بینی کنید که چه مدت طول می‌کشد تا راه‌حل را بیابید.
و اگر خطایی در کدی پیدا کنید که قبلاً منتشر شده است، هزینه فوق‌العاده‌ای برای رفع آن متحمل خواهید شد.
این یکی از دلایلی است که باید خطاها را بلافاصله رفع کرد: چون زمان کمتری می‌برد. دلیل دیگر به این واقعیت مربوط می‌شود که پیش‌بینی زمان نوشتن کد جدید بسیار ساده‌تر از پیش‌بینی زمان رفع یک خطای موجود است. مثلاً اگر از شما بپرسم که چقدر طول می‌کشد کدی برای مرتب کردن یک فهرست بنویسید، می‌توانید تخمین خوبی بدهید. اما اگر از شما بخواهم پیش‌بینی کنید چقدر طول می‌کشد تا آن خطایی که باعث می‌شود کد شما با نصب Internet Explorer 5.5 کار نکند را رفع کنید، حتی نمی‌توانید حدس بزنید، چون نمی‌دانید (طبق تعریف) چه چیزی باعث خطا شده است. ممکن است ۳ روز طول بکشد تا آن را پیدا کنید، یا ممکن است ۲ دقیقه طول بکشد.
این به این معناست که اگر برنامه زمانی با خطاهای زیادی برای رفع باقی مانده باشد، برنامه غیرقابل اعتماد است. اما اگر تمام خطاهای شناخته شده را رفع کرده‌اید و تنها کد جدید مانده است، آنگاه برنامه زمانی شما به طرز شگفت‌انگیزی دقیق‌تر خواهد بود.
یکی دیگر از مزایای حفظ تعداد خطاها در صفر این است که می‌توانید به رقبا سریع‌تر پاسخ دهید. برخی برنامه‌نویسان این را به عنوان آماده بودن دائمی محصول برای انتشار در نظر می‌گیرند. در این صورت، اگر رقیب شما ویژگی برجسته‌ای را ارائه دهد که مشتریان شما را جذب کند، می‌توانید تنها همان ویژگی را پیاده‌سازی کنید و بلافاصله منتشر کنید، بدون اینکه نیاز به رفع تعداد زیادی خطای انباشته داشته باشید.
6. آیا برنامه زمانی به‌روز دارید؟
این ما را به برنامه زمانی می‌رساند. اگر کد شما به هر شکلی برای کسب و کار اهمیت داشته باشد، دلایل زیادی وجود دارد که دانستن زمان تکمیل کد برای کسب و کار مهم است. برنامه‌نویسان به طور مشهور نسبت به تهیه برنامه‌های زمانی بدخلق هستند. آن‌ها فریاد می‌زنند: “وقتی آماده شد، آماده است!”
متأسفانه، این پاسخ کافی نیست. تصمیمات برنامه‌ریزی بسیاری وجود دارند که کسب و کار باید مدت‌ها قبل از انتشار کد بگیرد: دموها، نمایشگاه‌ها، تبلیغات و غیره. و تنها راه انجام این کار داشتن یک برنامه زمانی است و به‌روز نگه داشتن آن.
موضوع مهم دیگر در مورد داشتن یک برنامه زمانی این است که شما را مجبور میکند تصمیم بگیرید چه ویژگی‌هایی را قرار است پیاده‌سازی کنید و سپس مجبور می‌شوید ویژگی‌های کم‌اهمیت‌تر را انتخاب کرده و آن‌ها را حذف کنید، به جای اینکه به بیماری ویژگی‌ها (scope creep) دچار شوید.
نگه داشتن برنامه‌های زمانی نباید سخت باشد. مقاله من با عنوان Painless Software Schedules را بخوانید که روشی ساده برای تهیه برنامه‌های زمانی عالی را توضیح می‌دهد.
7. آیا شما مشخصات (spec) دارید؟
نوشتن مشخصات مانند نخ دندان کشیدن است: همه موافقند که این کار خوبی است، اما هیچ‌کس انجامش نمی‌دهد.
نمی‌دانم چرا این‌طور است، اما احتمالاً به این دلیل است که بیشتر برنامه‌نویسان از نوشتن مستندات متنفرند. در نتیجه، وقتی تیمی فقط از برنامه‌نویسان تشکیل شده باشد، ترجیح می‌دهند راه‌حل خود را در کد بیان کنند تا در مستندات. آن‌ها خیلی بیشتر ترجیح می‌دهند وارد کدنویسی شوند تا اینکه ابتدا یک مشخصات بنویسند.
در مرحله طراحی، وقتی مشکلی کشف می‌شود، می‌توانید به‌راحتی آن را با ویرایش چند خط متن رفع کنید. اما وقتی کد نوشته می‌شود، هزینه رفع مشکلات به طرز چشم‌گیری بیشتر است، هم از نظر عاطفی (مردم از دور ریختن کد متنفرند) و هم از نظر زمان، و در نتیجه تمایل به رفع مشکلات وجود ندارد. نرم‌افزاری که بدون مشخصات ساخته شده باشد، معمولاً به طرز بدی طراحی شده و برنامه زمانی از کنترل خارج می‌شود. به نظر می‌رسد این مشکل در Netscape وجود داشت، جایی که چهار نسخه اول به یک آشفتگی تبدیل شدند و مدیریت با تصمیمی احمقانه، کد را دور ریخت و از نو شروع کرد. سپس این اشتباه را دوباره با Mozilla تکرار کردند و یک هیولا خلق کردند که از کنترل خارج شد و چندین سال طول کشید تا به مرحله آلفا برسد.
تئوری شخصی من این است که این مشکل را می‌توان با آموزش نوشتن به برنامه‌نویسان برای کاهش بی‌میلی‌شان حل کرد. راه‌حل دیگر استخدام مدیران برنامه باهوش است که مشخصات نوشته شده را تولید کنند. در هر صورت، باید این قانون ساده را اجرا کنید: “بدون مشخصات کد ننویسید”.
همه چیز را درباره نوشتن مشخصات با خواندن سری ۴ قسمتی من بیاموزید.
8. آیا برنامه‌نویسان شرایط کاری آرام دارند؟
ارائه فضای خصوصی و آرام به کارکنان دانشی، مزایای بهره‌وری مستند و گسترده‌ای دارد. کتاب کلاسیک مدیریت نرم‌افزار Peopleware این مزایا را به‌طور گسترده شرح داده است.
مشکل اینجاست که همه می‌دانیم کارکنان دانشی وقتی به “جریان” یا همان “منطقه” تمرکز کامل وارد می‌شوند، بهترین کارایی را دارند؛ در این حالت، تمرکزشان به‌کلی روی کارشان است و از محیط اطراف جدا می‌شوند. آن‌ها گذر زمان را فراموش کرده و با تمرکز مطلق به نتایج عالی می‌رسند. نویسندگان، برنامه‌نویسان، دانشمندان و حتی بازیکنان بسکتبال نیز در مورد این وضعیت تمرکز کامل صحبت می‌کنند.
مشکل این است که ورود به “منطقه” آسان نیست. به‌نظر می‌رسد، اگر بخواهیم آن را اندازه‌گیری کنیم، ورود به اوج بهره‌وری به‌طور متوسط ۱۵ دقیقه طول می‌کشد. گاهی اگر خسته باشید یا در آن روز کار خلاقانه زیادی انجام داده باشید، نمی‌توانید به این منطقه برسید و بقیه روز کاری را به گذراندن وقت، وب‌گردی یا بازی تتریس سپری می‌کنید.
مشکل دیگر این است که خروج از منطقه تمرکز بسیار آسان است. سر و صدا، تماس‌های تلفنی، رفتن به ناهار، رانندگی کوتاه به استارباکس برای خرید قهوه، و مزاحمت‌های همکاران — مخصوصاً مزاحمت‌های همکاران — می‌توانند شما را از منطقه تمرکز بیرون کنند. اگر یک همکار با طرح سوال، باعث وقفه یک‌دقیقه‌ای شود و این وقفه به اندازه‌ای شما را از منطقه تمرکز خارج کند که نیم ساعت طول بکشد تا دوباره به بهره‌وری کامل بازگردید، بهره‌وری کلی شما به خطر می‌افتد. اگر در محیط شلوغ و پر سر و صدایی شبیه به آنچه شرکت‌های فناوری دوست دارند ایجاد کنند کار کنید — جایی که بازاریابان کنار برنامه‌نویسان با صدای بلند صحبت می‌کنند — بهره‌وری شما افت میکند، زیرا کارکنان دانشی مدام از منطقه تمرکز خارج می‌شوند و هرگز وارد آن نمی‌شوند.
برای برنامه‌نویسان، این موضوع به‌ویژه دشوار است. بهره‌وری آن‌ها وابسته به توانایی مدیریت جزئیات کوچک در حافظه کوتاه‌مدت است. هر نوع وقفه‌ای می‌تواند این جزئیات را در هم بشکند. وقتی دوباره به کار برمی‌گردید، نمی‌توانید جزئیات را به یاد بیاورید (مانند نام متغیرهای محلی که استفاده می‌کردید یا قسمتی که در حال اجرای آن بودید) و مجبور می‌شوید آن‌ها را دوباره جستجو کنید، که این کار شما را کند میکند تا به سرعت قبل برگردید.
اینجا یک محاسبه ساده است. فرض کنیم (همان‌طور که شواهد نشان می‌دهند) اگر برنامه‌نویسی را حتی برای یک دقیقه قطع کنیم، در واقع ۱۵ دقیقه از بهره‌وری او را از دست داده‌ایم. برای این مثال، دو برنامه‌نویس، جف (Jeff) و مات (Mutt)، را در اتاق‌های مکعبی باز کنار یکدیگر در یک اداره قرار می‌دهیم. مات نمی‌تواند نام نسخه Unicode تابع strcpy را به یاد بیاورد. او می‌تواند آن را جستجو کند که ۳۰ ثانیه طول می‌کشد یا می‌تواند از جف بپرسد که ۱۵ ثانیه طول می‌کشد. از آنجایی که درست کنار جف نشسته، از او می‌پرسد. جف حواسش پرت می‌شود و ۱۵ دقیقه از بهره‌وری خود را از دست می‌دهد (تا ۱۵ ثانیه برای مات صرفه‌جویی شود).
حالا بیایید آن‌ها را به اتاق‌های جداگانه با دیوار و درب منتقل کنیم. حالا وقتی مات نمی‌تواند نام تابع را به یاد بیاورد، می‌تواند آن را جستجو کند که هنوز ۳۰ ثانیه طول می‌کشد یا می‌تواند از جف بپرسد که حالا ۴۵ ثانیه طول می‌کشد و شامل بلند شدن می‌شود (که با توجه به وضعیت بدنی برنامه‌نویسان کار آسانی نیست!). پس آن را جستجو میکند. حالا مات ۳۰ ثانیه بهره‌وری خود را از دست می‌دهد، اما برای جف ۱۵ دقیقه صرفه‌جویی می‌کنیم. آآآه!
9. آیا از بهترین ابزارهای موجود استفاده می‌کنید؟
نوشتن کد در یک زبان کامپایل‌شونده از آخرین مواردی است که هنوز نمی‌توان آن را به‌صورت فوری روی یک کامپیوتر خانگی انجام داد. اگر فرایند کامپایل بیش از چند ثانیه طول بکشد، تهیه جدیدترین کامپیوتر می‌تواند برای شما زمان ذخیره کند. اگر کامپایل حتی ۱۵ ثانیه طول بکشد، برنامه‌نویسان حوصله‌شان سر می‌رود و به خواندن The Onion روی می‌آورند، که آن‌ها را به خود مشغول کرده و ساعت‌ها از بهره‌وری‌شان می‌کاهد.
اشکال‌زدایی کدهای GUI با سیستم تک‌مانیتوری دشوار است، اگر نگوییم غیرممکن. اگر کد GUI می‌نویسید، دو مانیتور کار را بسیار راحت‌تر میکند.
بیشتر برنامه‌نویسان سرانجام باید بیت‌مپ‌ها را برای آیکون‌ها یا نوار ابزارها دستکاری کنند، و بیشتر آن‌ها دسترسی به یک ویرایشگر بیت‌مپ خوب ندارند. تلاش برای استفاده از *Microsoft Paint* برای دستکاری بیت‌مپ‌ها یک شوخی است، اما این همان کاری است که اکثر برنامه‌نویسان مجبور به انجام آن هستند.
در آخرین شغلم، مدیر سیستم مدام اسپم‌های خودکار می‌فرستاد و از من شکایت می‌کرد که بیش از … باور کنید … ۲۲۰ مگابایت فضای هارد دیسک روی سرور استفاده می‌کنم. به او گفتم با توجه به قیمت هارد دیسک‌های امروزی، هزینه این فضا به‌مراتب کمتر از هزینه دستمال کاغذی است که استفاده می‌کنم. صرف حتی ۱۰ دقیقه برای تمیز کردن دایرکتوری من اتلاف فوق‌العاده‌ای از بهره‌وری بود.
تیم‌های توسعه برتر برنامه‌نویسان خود را شکنجه نمی‌کنند. حتی ناراحتی‌های جزئی ناشی از استفاده از ابزارهای ناکافی جمع شده و باعث نارضایتی و کج‌خلقی برنامه‌نویسان می‌شود. و برنامه‌نویس کج‌خلق، برنامه‌نویس ناکارآمدی است.
علاوه بر همه این‌ها، برنامه‌نویسان به‌راحتی با دادن آخرین و جذاب‌ترین وسایل به آن‌ها راضی می‌شوند. این روش بسیار ارزان‌تری برای جلب همکاری آن‌ها نسبت به پرداخت حقوق‌های رقابتی است!
10. آیا تِستِر دارید؟
اگر تیم شما تسترهای اختصاصی ندارد، حداقل یک تستر به‌ازای هر دو یا سه برنامه‌نویس، یا محصولات پر اشکال عرضه می‌کنید یا پول هدر می‌دهید و به برنامه‌نویسان با حقوق ۱۰۰ دلار در ساعت کارهایی محول می‌کنید که با تسترهای ۳۰ دلار در ساعت قابل انجام است. صرفه‌جویی در تعداد تسترها یک اقتصاد کاذب است که من واقعاً از اینکه افراد بیشتری آن را نمی‌فهمند شگفت‌زده هستم.
Top Five (Wrong) Reasons You Don’t Have Testers را بخوانید که مقاله‌ای است که در اینباره نوشته‌ام.
11. آیا نامزدهای جدید در مصاحبه کد می‌نویسند؟
آیا حاضرید یک شعبده‌باز را بدون اینکه از او بخواهید چند شعبده‌بازی نشان دهد استخدام کنید؟ قطعاً نه.
آیا برای مراسم عروسی خود، پذیرایی‌کننده‌ای را استخدام می‌کنید بدون اینکه غذای او را بچشید؟ بعید می‌دانم. (مگر اینکه عمه مرج باشد، و اگر به او اجازه ندهید کیک معروف جگر خرد شده‌اش را درست کند، برای همیشه از شما متنفر خواهد شد.)
با این حال، هر روز، برنامه‌نویسان بر اساس یک رزومه چشمگیر یا به دلیل لذت بردن از صحبت با آن‌ها استخدام می‌شوند. یا از آن‌ها سوالات جزیی می‌پرسند (“تفاوت CreateDialog() و DialogBox() چیست؟”) که می‌توان با نگاه کردن به مستندات پاسخ داد. شما اهمیتی نمی‌دهید که آن‌ها هزاران اطلاعات جزئی برنامه‌نویسی را حفظ کرده باشند؛ شما اهمیت می‌دهید که بتوانند کد تولید کنند. یا، بدتر از آن، سوالات “آها!” می‌پرسند: سوالاتی که وقتی جواب را می‌دانید آسان به‌نظر می‌رسند، اما اگر جواب را ندانید غیرممکن هستند.
لطفاً، این کار را متوقف کنید. در طول مصاحبه هر کاری دوست دارید انجام دهید، اما از نامزد بخواهید مقداری کد بنویسد. (برای مشاوره بیشتر، Guerrilla Guide to Interviewing را بخوانید.)
12. آیا آزمایش‌های کاربردپذیری در راهرو انجام می‌دهید؟
آزمایش کاربردپذیری راهرو جایی است که شما اولین کسی را که از راهرو عبور میکند گرفته و او را مجبور می‌کنید کدی را که تازه نوشته‌اید امتحان کند. اگر این کار را با پنج نفر انجام دهید، ۹۵٪ از مشکلات کاربردپذیری کد خود را کشف خواهید کرد.
طراحی رابط کاربری خوب آن‌قدر که فکر می‌کنید سخت نیست و اگر می‌خواهید مشتریان محصول شما را دوست داشته باشند و آن را بخرند، حیاتی است. می‌توانید کتاب آنلاین رایگان من درباره طراحی UI، که یک مقدمه کوتاه برای برنامه‌نویسان است، را بخوانید.
اما مهم‌ترین چیز در مورد رابط‌های کاربری این است که اگر برنامه خود را به چند نفر نشان دهید (در واقع پنج یا شش نفر کافی است)، به‌سرعت مشکلات عمده‌ای که افراد با آن‌ها مواجه می‌شوند را کشف خواهید کرد. مقاله جیکوب نیلسن (Jakob Nielsen) را بخوانید که دلیل این موضوع را توضیح می‌دهد. حتی اگر مهارت‌های طراحی رابط کاربری شما ضعیف باشد، تا زمانی که خود را مجبور به انجام آزمایش‌های کاربردپذیری راهرو کنید — که هیچ هزینه‌ای ندارد — رابط کاربری شما بسیار، بسیار بهتر خواهد شد.