هشدار دوات: کتاب Facts and Fallacies of Software Engineering برای اولین بار در سال ۲۰۰۲ چاپ شده و بعضی از مواردی که نویسنده کتاب و همچنین نویسنده مقاله ذکر میکنند به وضوح امروزه صادق نیست (به عنوان مثال موارد مربوط به تست نرم افزار را مشاهده کنید). با این همه، بسیاری از موارد، مخصوصا موارد مربوط به مدیریت پروژه همچنان سودمند هستند.
من دوست دارم هر چند سال یک‌بار کتاب‌های موردعلاقه‌ام را دوباره بخوانم؛ بنابراین، در سفر اخیرم، کتاب بنیادین Facts and Fallacies of Software Engineering اثر رابرت گلس (Robert Glass) را با خودم برداشتم. وقتی در سال ۲۰۰۴ آن را خریدم، به نظرم خواندنی خوب ولی ناقص بود. اکنون که به مقدمه و فهرست مطالب آن نگاه می‌کنم، متوجه می‌شوم که تقریباً درباره هر چیزی که در این کتاب آمده، در طول این سال‌ها نوشته‌ام.
فقط مرور کوتاه حقایق و تصورات غلط، به مانند یک کوآن ذن برای مهندسی نرم‌افزار است. حتی بدون بررسی کامل جزئیات و توضیحات، تأمل درباره این خلاصه‌ها اثر درمانی دارد. بر اساس تجربه شما، هنگام خواندن این جملات، چه چیزی به ذهن‌تان می‌آید؟
افراد
- مهم‌ترین عامل در کار نرم‌افزار، کیفیت برنامه‌نویسان است.
- بهترین برنامه‌نویسان می‌توانند تا ۲۸ برابر بهتر از بدترین برنامه‌نویسان عمل کنند.
- اضافه کردن افراد به یک پروژه تأخیر دار، تأخیر آن را بیشتر میکند.
- محیط کاری تأثیر عمیقی بر بهره‌وری و کیفیت دارد.
ابزارها و تکنیک‌ها
- تبلیغات درباره ابزارها و فناوری‌ها مانند یک آفت به صنعت نرم‌افزار هجوم می‌آورد.
- ابزارها و تکنیک‌های جدید، باعث کاهش اولیه بهره‌وری و کیفیت میشوند.
- توسعه‌دهندگان نرم‌افزار زیاد درباره ابزارها صحبت میکنند اما به ندرت از آنها استفاده میکنند.
تخمین
- یکی از دو علت رایج پروژه‌های پرهزینه، تخمین نادرست است.
- تخمین نرم‌افزار اغلب در زمان نامناسبی انجام می‌شود.
- تخمین نرم‌افزار معمولاً توسط افراد نامناسب انجام می‌شود.
- تخمین‌ها به ندرت در طول پروژه تصحیح میشوند.
- عجیب نیست که تخمین‌های نرم‌افزاری ضعیف هستند. اما با این وجود، به آنها متکی هستیم!
- یک گسست بین مدیریت نرم افزار و برنامه نویسان آنها وجود دارد.
- پاسخ مطالعه امکان‌سنجی تقریباً همیشه “بله” است.
استفاده مجدد
- استفاده مجدد در مقیاس کوچک، مشکلی حل‌شده است.
- استفاده مجدد در مقیاس بزرگ هنوز تا حد زیادی حل‌نشده است.
- استفاده مجدد در مقیاس بزرگ در سیستم‌های مرتبط عملکرد بهتری دارد.
- اجزای قابل استفاده مجدد سه برابر سخت‌تر ساخته میشوند و باید در سه محیط مختلف آزمایش شوند.
- تغییر کد بازاستفاده‌شده به‌خصوص مستعد خطاست.
- الگوهای طراحی یکی از راه‌حل‌های مشکلات بازاستفاده کد هستند.
نیازمندی‌ها
- یکی از دو علت رایج پروژه‌های پرهزینه، تغییرات نیازمندی‌ها است.
- اشتباهات نیازمندی‌ها در مرحله تولید هزینه بیشتری دارند.
- نیازمندی‌های از قلم افتاده، سخت‌ترین خطاهای نیازمندی برای اصلاح هستند.
طراحی
- زمانی که نیازمندی های ضمنی یک راه حل تکامل پیدا میکنند، تعداد نیازمندی های صریح به شدت افزایش پیدا میکند.
- به ندرت تنها یک راه حل برای مشکل نرم افزاری وجود دارد.
- طراحی یک فرآیند پیچیده و تکراری است. راه‌حل‌های اولیه معمولاً نادرست و قطعاً بهینه نیستند.
کدنویسی
- اصول شخص طراح به ندرت با اصول شخص برنامه‌نویس همخوانی دارند.
- زبان COBOL بسیار ضعیف است، اما بقیه زبان‌ها به مراتب بدتر هستند.
حذف خطا
- حذف خطا زمان‌برترین مرحله از چرخه عمر نرم‌افزار است.
آزمون (Testing)
- نرم‌افزار معمولاً در بهترین حالت تا ۵۵ تا ۶۰ درصد مورد آزمایش قرار میگیرد.
- پوشش آزمون ۱۰۰ درصدی هنوز کافی نیست.
- ابزارهای آزمون ضروری هستند، اما به ندرت مورد استفاده قرار می‌گیرند.
- خودکارسازی آزمون به ندرت انجام میگیرد. بسیاری از فعالیت های آزمون را نمیتوان خودکار کرد.
- کدهای دیباگ داخلی که توسط برنامه‌نویس ایجاد میشوند، مکمل مهمی برای ابزارهای آزمایشی هستند.
بازبینی‌ها و بازرسی‌ها
- بازرسی‌های دقیق می‌توانند تا ۹۰ درصد از خطاها را قبل از اجرای اولین تست شناسایی کنند.
- بازرسی‌ها باید مکمل آزمون‌ها باشند و نه جایگزین آنها.
- بررسی بعد از تحویل، کالبدشکافی و نگاه به عقب مهم بوده و به ندرت انجام میشوند.
- بررسی‌ها هم جنبه فنی دارند و هم جنبه اجتماعی و باید هر دو عامل را در نظر گرفت.
نگهداری
- نگهداری معمولاً ۴۰ تا ۸۰ درصد هزینه‌های نرم‌افزار را مصرف میکند و احتمالاً مهم‌ترین مرحله از چرخه عمر نرم‌افزار است.
- حدود ۶۰ درصد از هزینه‌های نگهداری مربوط به ارتقا و بهبود است.
- نگهداری یک راه‌حل است، نه یک مشکل.
- درک محصول موجود سخت‌ترین وظیفه نگهداری است.
- روش‌های بهتر به نگهداری بیشتر منجر میشوند، نه کمتر.
کیفیت
- کیفیت مجموعه‌ای از ویژگی‌ها است.
- کیفیت به معنای رضایت کاربر، برآورده کردن نیازمندی‌ها، دستیابی به هزینه و زمان‌بندی یا قابلیت اطمینان نیست.
قابلیت اطمینان
- اکثر برنامه نویسان مرتکب بعضی از خطاها میشوند.
- خطاها معمولاً در نقاط خاصی متمرکز میشوند.
- هیچ رویکردی به تنهایی بهترین برای حذف خطاهای نرم‌افزاری نیست.
- خطاهای باقی‌مانده همیشه وجود خواهند داشت. هدف باید کاهش یا حذف خطاهای شدید باشد.
کارایی
- کارایی بیشتر ناشی از طراحی خوب است تا کدنویسی خوب.
- کد زبان سطح بالا می‌تواند تا حدود 90 درصد به اندازه کد اسمبلی قابل مقایسه کارآمد باشد.
- بین بهینه سازی زمانی و بهینه سازی فضا یک بالانس و بده بستان وجود دارد.
پژوهش
بسیاری از پژوهشگران به‌جای تحقیق، از نظرات خود دفاع میکنند.
فراموش کرده بودم که این کتاب چقدر گسترده است؛ این کتاب یک سکوی پرتاب عالی برای تمام موضوعات اساسی در مهندسی نرم‌افزار است.
در طی چهار سال از اولین خواندن کتاب، تقریباً درباره همه این واقعیت‌ها مطلب نوشته‌ام. وقتی به فهرست مطالب ارائه‌شده نگاه کردم، به‌سختی خودم را کنترل کردم. هر پست را که خواندم، در ذهنم علامت زدم: تیک، تیک، تیک. قبلاً به خود پیونددهی بیش از حد متهم شده‌ام، پس قوانین را با ده‌ها پیوند به پست‌های قدیمی‌ام پر نمی‌کنم. اگر علاقه دارید، می‌توانید آنها را پیدا کنید. این بخشی از هدف است.
اگر این‌ها پنجاه و پنج واقعیت باشند، پس این‌ها ده اشتباه پایانی هستند. اشتباهات طوری به نظر می‌رسند که گویی درست هستند، اما با نگاهی دقیق‌تر، متوجه می‌شوید که در پروژه‌های زنده نرم‌افزاری مشکل‌ساز میشوند.
- نمی‌توانید چیزی را که قابل اندازه‌گیری نیست مدیریت کنید.
- می‌توانید کیفیت را به یک محصول نرم‌افزاری مدیریت کنید.
- برنامه‌نویسی می‌تواند و باید بدون خودخواهی باشد.
- ابزارها و تکنیک‌ها: یک راه حل برای همه مناسب است.
- نرم‌افزار به روش‌شناسی‌های بیشتری نیاز دارد.
- برای تخمین هزینه و زمان‌بندی، ابتدا باید خطوط کد را تخمین زد.
- ورودی تصادفی آزمایش راهی خوب برای بهینه‌سازی آزمایش است.
- “با وجود چشمان کافی، همه اشکالات سطحی هستند.”
- راه پیش‌بینی هزینه‌های نگهداری آینده و تصمیم‌گیری برای جایگزینی محصول این است که به داده‌های هزینه گذشته نگاه کنید.
- به افراد نحوه برنامه‌نویسی را با نشان دادن نحوه نوشتن برنامه‌ها آموزش می‌دهید.
اگر به استدلال‌های پشت این واقعیت‌ها و اشتباهات کنجکاو هستید، این دقیقاً همان دلیل وجود کتاب است: برای یادآوری اینکه باید درباره آنچه انجام می‌دهیم پرسش کنیم. هر روز، در پروژه‌های نرم‌افزاری خودمان، باید به نوعی به مهارت خود فکر کنیم. این‌گونه است که به‌طور جمعی مهندسی نرم‌افزار را ارتقا می‌دهیم – با ساختن حافظه و تاریخ مشترک خود در این حوزه. همان‌طور که آقای گلس (Glass) در مقدمه بیان میکند:
“با ارائه این واقعیت‌ها، من همچنین مشکلات موجود در این حوزه را شناسایی می‌کنم. هدف من ارائه راه‌حل برای این مشکلات نیست. این کتابی درباره آنچه هست است، نه چگونگی. این برای من مهم است. می‌خواهم این واقعیت‌ها را به‌صورت آزاد در دسترس قرار دهم تا بتوانیم آنها را آزادانه بحث کنیم و اقداماتی برای پیشرفت انجام دهیم.”
من شما را تشویق می‌کنم یک نسخه کامل از این کتاب را برای بررسی عمیق‌تر تهیه کنید. به نظرم، تجربه یادگیری یا تجربه به یادآوردن ارزشمندی برای کسانی که ادامه می‌دهند در این کتاب وجود دارد.