چند هفته پیش اعضای تیمم که بعضیاشون جونیور هستن و تازه ۴ ماهه به تیم اضافه شدن تو یک جلسه‌ای بهم گفتن ما بدهی فنی یا technical debt داریم. حالا پروژه چند خطه؟ ۴۰۰ خط.
بهشون توضیح دادم که بدهی فنی تو این حجم از کار عملا یه شوخیه و ما بعد از ۴ ماه از شروع پروژه اگر بدهی فنی داریم واقعا آدمهای اشتباهی رو استخدام کردیم.
تو توضیح همین موضوع بودم که یک دوستی تو توییتر پرسید:
آقا ی سوال جدی، زمانی که شرکت زیر بار ریفکتورینگ نمیره و مدام دنبال رسوندن فیچره و هرچقدر هم گفته میشه که نیاز هست کدها اصلاح بشه به خاطر فشار و محدودیت زمانی موقع پیاده سازی، اینجا هم بدهی فنی گردن برنامه نویسه؟
و من جواب دادم که
بدهی فنی همیشه گردن برنامه نویسه. کسی جز برنامه نویس که اونارو ننوشته! کد مگه چیه؟ تفکر و راهکار و رویکرد برنامه نویس برای حل مساله. همه شرکتا میخوان فیچرشون در سریعترین زمان ممکن برسه. این حرف به این معنی نیست که ما باید همه چیز رو فدا کنیم.
به این معنیه که شما با درک درست مسایل و یادگیری پروسه‌های سازمانت تولید کد میکنی. مثلا اگر میدونی که طرف میخواد این فیچر رو بزنه و از روش رد شه بره، زمانی که میخوای فیچر امروزت رو بزنی از پروداکتت بپرس ویژن کجاست؟ رودمپ محصولش چیه؟ فیچر امروز رو با جهت دهی درست بزنی و در زمانبندیت هم لحاظ کنی. از یک جایی به بعد این موضوع باعث سرعت بخشیدن توسعه و ایجاد اعتماد بیشتر میشه.
در نهایت خیلی مهمه که تیم فنی هنر اینو داشته باشه که قسمت‌های مشکل دار رو ایزوله کنه و با پترن‌های موجود مثل proxy یا wrapper یا strangler امکان رشد پروژه با مسیر درست رو ایجاد کنه و بعد با اعمال قانون boy scout هرجایی که دست میخوره رو از قبل بهتر تحویل بده.
شما هیچ وقت بدون ایجاد اعتماد که ناشی از قول دادن و به سرانجام رسوندنه، نمیتونی ریفکتور پر هزینه‌ای رو به شرکت تحمیل کنی. از طرف دیگه هنر دیگه اینه که شما تمام این ریفکتورها رو گره بزنی به رودمپ محصول و اصطلاحا align بشی وگرنه صبح بیای بگی من میخوام این بخش رو درست کنم بدون داشتن هیچ business value ای خب طبیعیه که کسی ازت قبول نکنه.
در نهایت پیشنهاد میکنم مطلب اخر این بلاگ رو بخونی.
https://blog.pragmaticengineer.com/paying-down-tech-debt-further-learnings/
حالا شما چی فکر میکنید؟
