فهمیدن کد قدیمی با کمک هوش مصنوعی
سازمانی سامانهای دارد که ده سال کار کرده. کسی که نوشته بود سالها پیش رفته. مستنداتی نیست. هر تغییر کوچک، هفتهها طول میکشد چون اول باید بفهمند این بخش چه میکند.
این شایعترین وضعیت نرمافزار سازمانی در ایران است و بهترین جایی که این ابزارها امروز کمک میکنند.
دلیلش هم روشن است: ریسکش کم است. ابزار چیزی نمینویسد که وارد سامانه شود؛ فقط توضیح میدهد. بدترین حالت این است که توضیحش غلط باشد و شما بفهمید.
چه کارهایی واقعاً خوب انجام میشود
توضیح یک تابع یا کلاس. «این چه میکند؟» — و مهمتر: «چه ورودیهایی میگیرد و در چه حالتهایی چه برمیگرداند؟»
نقشهٔ کلی از یک ماژول. بخشها چهاند، کدام به کدام وابسته است.
پیدا کردن مسیر اجرا. «وقتی کاربر این دکمه را میزند، چه اتفاقی میافتد؟» — در سامانهای با لایههای زیاد، دنبال کردن این مسیر دستی ساعتها طول میکشد.
استخراج قواعد کسبوکاری از کد. شرطهای تودرتویی که در ده سال روی هم انباشته شدهاند. این یکی از ارزشمندترین کاربردهاست — چون نتیجهاش سندی است که کسبوکار میتواند بخواند و بگوید «این قاعده دیگر درست نیست».
ترجمهٔ کد به زبان قابل فهم برای غیرفنی.
پیدا کردن کد مرده. بخشهایی که دیگر صدا زده نمیشوند.
تولید مستندات اولیه، که بعد آدم اصلاحش کند.
کجا نباید اعتماد کرد
ادعای دربارهٔ چیزی که در کد نیست. ابزار فقط کد را میبیند. اگر بخشی از منطق در پایگاه داده است — تریگر، رویه، محدودیت — یا در پیکربندی، یا در یک اسکریپت زمانبندیشده، آن را نمیبیند و ممکن است تصویری ناقص بدهد که کامل به نظر میرسد.
«چرا» بهجای «چه». ابزار میگوید کد چه میکند. نمیداند چرا اینطور نوشته شده. آن شرط عجیب ممکن است رفع یک باگ واقعی باشد یا بقایای نیازی که دیگر وجود ندارد — و تفاوتشان کل تفاوت است.
اثرات جانبی دور. تابعی که به نظر ساده میآید و در جای دیگری چیزی را تغییر میدهد.
رفتار در حجم واقعی. کدی که منطقاً درست است و با میلیون رکورد نمیچرخد.
قاعدهٔ عملی: توضیح ابزار را فرضیه بدانید، نه واقعیت. تأییدش با اجرا، لاگ، یا آزمایش روی محیط تست است.
روشی که در پروژههای نوسازی استفاده میکنیم
۱. از بیرون شروع کنید، نه از کد. اول ورودیها و خروجیهای سامانه: چه صفحاتی، چه سرویسهایی، چه گزارشهایی، چه کارهای زمانبندیشدهای.
۲. مسیرهای پرترافیک را اول بفهمید. لاگ به شما میگوید کدام بخشها واقعاً استفاده میشوند. معمولاً بخش بزرگی از کد سالهاست اجرا نشده.
۳. برای هر مسیر، نقشهٔ اجرا دربیاورید و با اجرای واقعی تأییدش کنید.
۴. قواعد کسبوکاری را استخراج و مستند کنید — و به کسبوکار نشان دهید. این مرحله معمولاً غافلگیرکننده است: قواعدی پیدا میشود که هیچکس نمیدانست وجود دارند، و قواعدی که همه فکر میکردند هست و نیست.
۵. تست مشخصه بنویسید برای رفتار فعلی، پیش از هر تغییری. روشش در تولید تست.
۶. حالا تغییر بدهید — با الگوی خفهکننده اگر سامانه زنده است و نمیشود خاموشش کرد.
مرحلهٔ ۵ را رد نکنید. فهمیدن کد بدون تور ایمنی، اعتمادبهنفس کاذب میسازد.
کد فارسی و ملاحظات محلی
چند نکته که در پروژههای داخلی مکرر دیدهایم:
نام متغیر و توضیحات فینگلیش. mablagh_koll، tarikh_sarresid. ابزار
معمولاً از پس اینها برمیآید و گاهی اشتباه ترجمه میکند. اگر توضیحی
دربارهٔ منطق مالی میگیرید، خودتان تأیید کنید.
قواعد مالیاتی و بانکی که در کد نشستهاند. ابزار شرط را توصیف میکند و نمیداند به کدام بخشنامه برمیگردد. این دقیقاً همان چیزی است که باید استخراج و به داده تبدیل شود — منطقش در سامانهٔ انطباق مالیاتی.
تاریخ شمسی که بهصورت متن ذخیره شده، و محاسباتی که رویش انجام میشود.
محرمانگی، که اینجا جدیتر است
برای فهمیدن کد، باید کد را به ابزار بدهید. و در پروژهٔ نوسازی، آن کد معمولاً مال مشتری است.
سه بند:
قرارداد محرمانگی را بخوانید پیش از فرستادن هر خطی.
رمزها و کلیدها را حذف کنید. کد قدیمی معمولاً پر از اطلاعات اتصال هاردکد شده است.
برای پروژهٔ حساس، مدل روی زیرساخت خودتان — که در مدل زبانی روی زیرساخت خودتان مقایسهاش کردهایم.
ارزش واقعی
در پروژههای نوسازی، مرحلهٔ شناخت معمولاً بیست تا سی درصد کل زمان است و پرابهامترین بخش برآورد.
این ابزارها آن مرحله را کوتاه میکنند — نه حذف. کسی هنوز باید تصمیم بگیرد چه چیزی نگه داشته شود، چه چیزی بازنویسی، و به چه ترتیبی. آن تصمیمها همانهایی هستند که در نوسازی سیستم قدیمی گفتیم و به شناخت کسبوکار نیاز دارند، نه به شناخت کد.
اما کوتاهشدن مرحلهٔ شناخت، خودش دو اثر دارد: برآورد دقیقتر میشود، و پروژهای که قبلاً بهخاطر ابهام رد میشد، حالا قابل قبول است.