«پروژه تا ۸۰٪ جلو رفته، برنامه‌نویس قبلی رفته، فقط باید تمامش کنید.» این جمله را کارفرماهای زیادی می‌گویند، و تقریباً هیچ‌وقت دقیق نیست. عدد ۸۰٪ معمولاً درصد صفحه‌هایی است که ظاهر دارند، نه درصد کاری که برای انتشار امن لازم است. این مقاله روشی است که برای تحویل گرفتن و برآورد پروژه Laravel نیمه‌تمام استفاده می‌کنم: چه چیزهایی را در چند روز اول بررسی کنیم، چطور بین ادامه، بازسازی تدریجی و بازنویسی تصمیم بگیریم، و برآورد را طوری بدهیم که بعداً هر دو طرف غافلگیر نشوند.
این مقاله با ممیزی کد Laravel و بدهی فنی فرق دارد. ممیزی برای محصولی است که در حال کار است و می‌خواهیم ریسک‌هایش را بشناسیم. اینجا محصول هنوز منتشر نشده، تیم قبلی در دسترس نیست و سؤال اصلی این است: چقدر دیگر کار دارد؟
چرا برآورد سریع پروژه نیمه‌تمام خطرناک است
برآورد پروژه جدید سخت است، اما برآورد پروژه نیمه‌تمام سخت‌تر است، چون علاوه بر کار باقی‌مانده، باید هزینه فهمیدن کد دیگران، اصلاح کار انجام‌شده و ریسک‌های پنهان را هم حساب کنید. سه چیز تقریباً همیشه از دید کارفرما پنهان است:
- کارهای «نامرئی»: احراز هویت امن، سطح دسترسی، صف‌ها، لاگ، خطایابی، پشتیبان‌گیری، استقرار و تست. صفحه‌ای که کار می‌کند ممکن است هیچ‌کدام از این‌ها را نداشته باشد.
- تصمیم‌های نیمه‌کاره: دو روش متفاوت برای یک کار، migrationهایی که با دیتابیس فعلی هم‌خوان نیستند، پکیج‌هایی که نصب شده‌اند اما استفاده نمی‌شوند.
- دانش از دست رفته: چرا این جدول این ستون را دارد؟ این endpoint را چه کسی صدا می‌زند؟ بدون برنامه‌نویس قبلی، جواب این سؤال‌ها زمان می‌برد.
به همین دلیل پیشنهاد من همیشه یک فاز کوتاه و محدود «شناخت» قبل از برآورد اصلی است، با هزینه و خروجی مشخص.
فاز شناخت: پنج روز کاری، با خروجی مکتوب
روز اول: آیا پروژه اصلاً اجرا می‌شود؟
- دسترسی به مخزن کد کامل با تاریخچه git، نه فقط فایل zip آخرین نسخه. تاریخچه commitها نشان می‌دهد کدام بخش‌ها پایدار و کدام پرتغییرند.
- نسخه Laravel و PHP. پروژه روی Laravel 6 یا 7 که پشتیبانی امنیتی‌اش تمام شده، قبل از ادامه هزینه ارتقا دارد.
- اجرای پروژه روی محیط تمیز با
composer install،php artisan migrateروی دیتابیس خالی و seed. اگر migrationها روی دیتابیس خالی اجرا نشوند، دیتابیس فعلی دستی تغییر کرده و منبع حقیقت دیگر کد نیست. - فایل
.env.exampleکامل است؟ کلیدها، سرویس‌های بیرونی و تنظیمات صف و کش مشخص‌اند؟
روز دوم: نقشه دامنه و داده
- فهرست مدل‌ها، رابطه‌ها و جدول‌ها. یک نمودار ساده از موجودیت‌های اصلی بکشید و با کارفرما مرور کنید؛ اغلب همین‌جا معلوم می‌شود بخشی از نیازمندی اصلاً در مدل داده جایی ندارد.
- فهرست routeها با
php artisan route:list. هر route که در هیچ‌جای رابط کاربری استفاده نمی‌شود یا middleware احراز هویت ندارد، علامت بخورد. - سرویس‌های بیرونی: درگاه پرداخت، پیامک، ذخیره فایل، API شرکای تجاری. کدام واقعاً پیاده‌سازی شده و کدام فقط stub است؟
روز سوم: کیفیت و ریسک
- تست‌ها: وجود دارند؟ اجرا می‌شوند؟ چه بخشی را پوشش می‌دهند؟ پوشش صفر برای پروژه نیمه‌تمام عجیب نیست، اما در برآورد باید دیده شود.
- امنیت پایه: mass assignment، authorization روی هر عملیات حساس، اعتبارسنجی ورودی، آپلود فایل، کلیدهای commitشده در مخزن. چک‌لیست کامل‌تر در مقاله چک‌لیست امنیت Laravel است.
- ساختار: منطق کسب‌وکار در controllerهای هزارخطی است یا جدا شده؟ کد تکراری چقدر است؟
- کارایی: N+1 در صفحه‌های لیست، queryهای بدون index روی جدول‌های بزرگ، کارهای سنگین داخل درخواست به‌جای صف.
روز چهارم: مقایسه با نیازمندی
نیازمندی اصلی را، اگر مستندی وجود دارد، با چیزی که پیاده شده مقایسه کنید. برای هر قابلیت یکی از چهار وضعیت را ثبت کنید: کامل و قابل اعتماد، کامل اما نیازمند اصلاح، نیمه‌تمام، شروع‌نشده. این جدول پایه برآورد است، نه درصدی که کارفرما شنیده.
روز پنجم: گزارش و پیشنهاد
خروجی فاز شناخت یک سند کوتاه است: وضعیت فعلی، ریسک‌ها به ترتیب شدت، جدول قابلیت‌ها، پیشنهاد مسیر (ادامه، بازسازی تدریجی یا بازنویسی) و برآورد با بازه.
ماتریس تصمیم: ادامه، بازسازی تدریجی یا بازنویسی
هر معیار را بین ۱ (وضعیت بد) تا ۵ (وضعیت خوب) امتیاز بدهید. امتیازها جای قضاوت را نمی‌گیرند، اما بحث را از «به نظرم کد بد است» به معیارهای مشخص می‌برند.
| معیار | امتیاز ۱ یعنی | امتیاز ۵ یعنی |
|---|---|---|
| قابلیت اجرا و استقرار | روی محیط تمیز بالا نمی‌آید | با چند دستور مستند اجرا می‌شود |
| صحت مدل داده | با نیازمندی اصلی ناسازگار است | موجودیت‌ها و رابطه‌ها درست‌اند |
| امنیت | حفره‌های پایه در احراز هویت و دسترسی | فقط موارد جزئی |
| ساختار کد | منطق پراکنده و تکراری | لایه‌بندی قابل فهم |
| نسخه فریم‌ورک | بدون پشتیبانی امنیتی، فاصله چند نسخه | نسخه پشتیبانی‌شده |
| تست | وجود ندارد یا اجرا نمی‌شود | بخش‌های حیاتی پوشش دارند |
| درصد قابلیت‌های قابل اعتماد | کمتر از ۲۰٪ | بیش از ۶۰٪ |
- مجموع ۲۸ تا ۳۵: ادامه بدهید. کد قابل اعتماد است؛ کار باقی‌مانده را برآورد کنید و موارد اصلاحی را در مسیر انجام دهید.
- مجموع ۱۸ تا ۲۷: بازسازی تدریجی. مدل داده و بخش‌های سالم را نگه دارید، بخش‌های پرریسک را پشت تست بازنویسی کنید و قابلیت‌های جدید را با ساختار درست بسازید.
- مجموع زیر ۱۸: بازنویسی را جدی بررسی کنید. به‌خصوص اگر مدل داده یا امنیت امتیاز ۱ گرفته باشد. حتی در بازنویسی، نیازمندی‌های کشف‌شده، طراحی رابط و داده‌های موجود ارزش دارند.
دو معیار وزن بیشتری دارند: مدل داده و امنیت. کد بد را می‌شود تدریجی اصلاح کرد؛ مدل داده اشتباه همه چیز را آلوده می‌کند و اصلاحش بعد از ورود داده واقعی گران‌تر می‌شود. اگر یکی از این دو امتیاز ۱ دارد، حتی با مجموع بالا، قبل از ادامه همان را حل کنید.
برآورد با بازه، نه عدد قطعی
بعد از فاز شناخت، برای هر قابلیت سه عدد بدهید: خوش‌بینانه، محتمل و بدبینانه. عدم قطعیت پروژه نیمه‌تمام بیشتر از پروژه جدید است؛ پنهان کردنش فقط مشکل را به وسط پروژه منتقل می‌کند. بخش‌هایی که ریسک بالایی دارند، مثلاً اتصال به سرویسی که مستندات ندارد، را جداگانه و با یک سقف زمانی برای بررسی برآورد کنید. روش کلی برآورد را در مقاله هزینه طراحی و توسعه پروژه Laravel توضیح داده‌ام.
توصیه‌هایی برای کارفرما
- قبل از جدا شدن از تیم قبلی، دسترسی کامل به مخزن، سرورها، دامنه، سرویس‌های بیرونی و پنل‌های پرداخت را تحویل بگیرید.
- از برنامه‌نویس جدید برآورد قطعی بدون دیدن کد نخواهید. برآورد بدون شناخت یا خیلی بالاست تا ریسک را پوشش دهد، یا خیلی پایین است و بعداً تغییر می‌کند.
- فاز شناخت را جداگانه قرارداد کنید. خروجی آن، حتی اگر با همان برنامه‌نویس ادامه ندهید، برای شما ارزش دارد.
- اولین هدف بعد از تحویل را «انتشار امن یک نسخه کوچک» بگذارید، نه تکمیل همه قابلیت‌ها. انتشار زودهنگام بخش زیادی از ریسک‌های پنهان را آشکار می‌کند.
جمع‌بندی
پروژه نیمه‌تمام را نمی‌شود از روی ظاهرش برآورد کرد. چند روز شناخت ساختاریافته، یک ماتریس تصمیم شفاف و برآورد با بازه، فاصله بین «فقط باید تمامش کنید» و واقعیت را قبل از امضای قرارداد اصلی کم می‌کند.
اگر پروژه Laravel نیمه‌تمامی دارید و می‌خواهید قبل از تصمیم درباره ادامه، وضعیتش را مستقل بسنجید، از طریق خدمت توسعه اختصاصی PHP و Laravel یک فاز شناخت کوتاه را شروع کنیم.
پرسش‌های متداول
آیا می‌شود بدون دیدن کد پروژه نیمه‌تمام برآورد دقیق داد؟
نه. برآورد بدون بررسی کد یا برای پوشش ریسک بیش از حد بالاست یا بعداً تغییر می‌کند. یک فاز شناخت کوتاه پایه برآورد واقعی است.
کِی بازنویسی کامل پروژه منطقی است؟
وقتی مدل داده یا امنیت از پایه اشکال دارد و بخش کمی از قابلیت‌ها قابل اعتماد است. حتی در آن حالت نیازمندی‌ها و داده موجود ارزش دارند.