استیو مککانل (Steve McConnell) درباره عدم مقیاسپذیری اقتصادی در توسعه نرمافزار میگوید:
اندازه پروژه به راحتی مهمترین عامل تعیینکننده میزان تلاش، هزینه و برنامهریزی برای یک پروژه نرمافزاری است.*
مردم به طور طبیعی فرض میکنند که سیستمی که ۱۰ برابر بزرگتر از سیستم دیگری است، به حدود ۱۰ برابر تلاش بیشتری برای ساخت نیاز دارد. اما تلاش مورد نیاز برای یک سیستم با ۱,۰۰۰,۰۰۰ خط کد (LOC) بیشتر از ۱۰ برابر تلاش لازم برای سیستمی با ۱۰۰,۰۰۰ خط کد است.
[با استفاده از میانگینهای بهرهوری در صنعت نرمافزار]، یک سیستم ۱۰,۰۰۰ خط کدی به ۱۳.۵ نفرماه نیاز دارد. اگر تلاش بهصورت خطی افزایش مییافت، یک سیستم ۱۰۰,۰۰۰ خط کدی به ۱۳۵ نفرماه نیاز داشت. اما در واقع به ۱۷۰ نفرماه نیاز دارد.
این مهمترین تصمیمی است که میتوانید در پروژه نرمافزاری خود بگیرید اگر میخواهید موفق باشید: آن را کوچک نگه دارید. ممکن است پروژههای کوچک کارهای زیادی انجام ندهند، اما احتمال شکست قطعی – که نتیجه رایجی برای اکثر پروژههای نرمافزاری است – کمتر است.
من فکر نمیکنم رابطه معکوس و غیرخطی بین اندازه و بهرهوری در پروژههای نرمافزاری برای کسی شوکهکننده باشد؛ افراد در 37signals مدت بیش از یک سال است که بر مزایای پروژههای کوچک تأکید میکنند. آیا کوچک قبلاً به “بزرگ جدید” تبدیل نشده است؟
اما چیزی که واقعاً میخواهم بر آن تمرکز کنم این است که چگونه اندازه یک پروژه را اندازهگیری میکنید. “بزرگ” چیست؟ “کوچک” چیست؟ مککانل از خطوط کد (LOC) به عنوان معیار اصلی خود برای اندازهگیری استفاده میکند. در اینجا یک جدول نشاندهنده رابطه بین اندازه پروژه و بهرهوری آورده شده است:
اندازه پروژه | تعداد خط کد (در سال) | میانگین COCOMO |
۱۰۰۰۰ خط | ۲۰۰۰ – ۲۵۰۰۰ | ۳۲۰۰ |
۱۰۰۰۰۰ خط | ۱۰۰۰-۲۰۰۰۰ | ۲۶۰۰ |
۱۰۰۰۰۰۰ خط | ۷۰۰-۱۰۰۰۰ | ۲۰۰۰ |
۱۰۰۰۰۰۰۰ خط | ۳۰۰-۵۰۰۰ | ۱۶۰۰ |
خطوط کد یک معیار معقول برای تعیین اندازه پروژه است، اما مشکلاتی نیز دارد که بهخوبی در مقاله ویکیپدیا درباره خطوط کد مستند شده است.
به عنوان مثال، این چند خط کد است؟
for(i=0; i<100; ++i) printf("hello");
برای یک چیز، زبانهای مختلف در تعداد خطوط کدی که تولید میکنند بهطور گستردهای متفاوت هستند. ۱۰۰ خط پرل (Perl) احتمالاً خیلی بیشتر از ۱۰۰ خط C کار انجام میدهد. بنابراین باید مراقب باشید که واقعاً دارید مقایسه “سیب با سیب” انجام میدهید. علاوه بر این، توسعهدهندگان ماهر میدانند که هرچه کمتر کد بنویسید، کمتر خطا ایجاد میکنید – بنابراین آنها بهطور طبیعی به هر معیاری که بهرهوری را بر اساس خطوط کد مطلق ارزیابی کند، اعتماد ندارند. و آیا کدهای تولید شده نیز حساب میشوند؟
حتی با تمام مشکلات آن، مککانل معتقد است که معیار خطوط کد همچنان باید نقطه شروع باشد:
نتیجه شخصی من درباره استفاده از خطوط کد برای تخمین نرمافزار شبیه به نتیجهگیری وینستون چرچیل (Winston Churchill) درباره دموکراسی است: اندازهگیری خطوط کد یک راه وحشتناک برای اندازهگیری اندازه نرمافزار است، مگر اینکه همه راههای دیگر بدتر باشند. برای بیشتر سازمانها، با وجود مشکلات آن، معیار خطوط کد تکنیک اساسی برای اندازهگیری اندازه پروژههای گذشته و ایجاد تخمینهای اولیه برای پروژههای جدید است. معیار خطوط کد زبان مشترک تخمین نرمافزار است و معمولاً نقطه خوبی برای شروع است، تا زمانی که محدودیتهای آن را در نظر داشته باشید.
محیط شما ممکن است به اندازه کافی متفاوت باشد که خطوط کد با اندازه پروژه همبستگی زیادی نداشته باشند. اگر اینطور است، چیزی را پیدا کنید که بیشتر با میزان تلاش مرتبط باشد، آن را بشمارید و تخمینهای خود را بر اساس آن پایهگذاری کنید. سعی کنید چیزی را پیدا کنید که شمارش آن آسان باشد، با میزان تلاش همبستگی زیادی داشته باشد و برای استفاده در پروژههای متعدد معنیدار باشد.
مقاله ویکیپدیا شامل این نمودار از اندازه سیستم عامل ویندوز بر اساس خطوط کد در طول زمان است:
1993 | Windows NT 3.1 | 6 میلیون |
1994 | Windows NT 3.5 | 10 میلیون |
1996 | Windows NT 4.0 | 16 میلیون |
2000 | Windows 2000 | 29 میلیون |
2002 | Windows XP | 40 میلیون |
2007 | Windows Vista | ~50 میلیون |
اگر از خود میپرسید که یک برنامهنویس متوسط در روز چقدر کد تولید میکند، فکر میکنم ممکن است دارید سؤال اشتباهی میپرسید. خطوط کد مطمئناً یک معیار کلیدی برای تعیین اندازه پروژه است، اما به راحتی قابل تغییر و تفسیر نادرست است. این نباید تنها دادهای باشد که برای تصمیمگیری استفاده میشود؛ فقط یکی از علائم راهنمایی است که به شما در جهتدهی پروژه کمک میکند.
* دیگر عوامل تعیینکننده مهم کدامند؟ دومین عامل نوع نرمافزاری است که در حال توسعه آن هستید، و عوامل نیروی انسانی به طرز نزدیکی در رتبه سوم قرار دارند.