ریفکتورینگ - بدهی فنی ( Refactoring - Technical debt) – بخش دوم

تو بخش اول فک کنم درباره بدهی فنی یکم نوشتم؛ از اونجا که علت ریفکتورینگ همین بحث بدهی فنیه، بهتره، یکم بیشتر روش تمرکز کنیم. خب ما تقریبا میدونیم بدهی فنی چیه، همون مثالیه که مارتین فالور درباره "وام گرفتن و پرداخت سود اضافه به ازای دیرکرد پرداخت قسط" زده بود خیلی قشنگ موضوع رو روشن کرد.

اما بدهی فنی دقیقا کی و چرا بوجود میاد؟

هر کسی میتونه از صفر پروژه رو شروع کنه و یه کدی بنویسه و توسعش بده، برای همینه که ما برنامه نویسها معمولا اوایل پروژه حس خوبی داریم و مثل تراکتور کد مینویسیم، هیچ برنامه نویسی هم از قصد کد شلوغ و بد نمی نویسه.ولی این کد بد، که بعد 5 ماه وقتی میریم سراغ پروژه کلی ازش تو کدمون هست از کجا اومده؟ احتمالا یکی با ما دشمنی داشته و رفته کدمونو درهم و برهم کرده وگرنه ما که هیچ وقت کد بد نمی نویسم؟؟؟

بدهی فنی یه شکل محترمانه از "کد کثیف و ناخواناست" که توسط آقای Ward Cunningham تو یکی از مقالاتش پیشنهاد شده. این آقای Cunningham یکی از اون خرخفنهاست؛ از بزرگای دیزاین پترن و بوجود آورنده ی "ویکیه" (ویکیپدیا نه، ویکی، یه نوع وبسایت که مثل ویکی پدیا بی درو پیکره و هر کی میتونه مقالات رو ویرایش کنه، که ویکیپدیا جز وبسایت های ویکیه) .

خب حالا این بدهی فنی چرا بوجود میاد اصلا؟ ما که دلمون نمیخواد کدمون بدهی فنی داشته باشه و اصلا هم اینطوری کد نمینویسیم، پس علتش چیه؟

فشار کاری

همون غر زدنهای مدیر پروژه یا کارفرماست، بعض اوقات(اکثر اوقات) وقت با کلاس بودنو نداریم، یعنی پروژه باید تا ماه دیگه تکمیل بشه، اکثرا هم کاری نداره و چیزی نیست (جمله معروف کارفرماها) فقط یه دکمه قراره رو صفحه بیاد، همین! اما غافل از اینکه همین دکمه قراره زنجیره وار تو کل سیستم تاثیر بذاره(خطاهای زنجیره وارهم بیشتر زمانی اتفاق میفته که کل سیستممون تو یه سولوشن/پکیج باشه، وقتی نرم افزار به سرویس های مختلف تقسیم نمیشه و از لحاظ business جدا سازی نمیشه، این اتفاق بیشتر خودشو نشون میده. یه مثالش میتونه یه وب اپ مدیریت فروشگاه باشه؛ اگه بخش پرداخت و بخش کالا و لاگ سیستم از هم جدا باشن، در این حالت اگه یه بخش ، مثلا پرداخت دچار اشکل بشه یا حتی اگه این بخش down بشه، افرادی که "فقط" قصد دیدن کالارو دارن به مشکل بر نمیخورن و تنها زمانی بحث خرید و پرداخت مطرح میشه ممکنه اپ جوابی بهشون نده، با شناختی که تا الان از شرکت های نرم افزاری ایران دارم؛ کمتر شرکتی از معماری میکروسرویس استفاده میکنه ومعمولا کل اپ یه قسمته یا اصطلاحا سیستم monolith هست). یه متد/کلاس مینویسم و زمانی که برامون کار کرد، که البته علت کار کردنشوهم نمیدونیم؛ میگیم اوکیه و میریم سراغ کار بعدی، همین وقت نداشتنها و سرسری تموم کردن کار باعث میشه که وقتی رئیس/کارفرما/مدیر پروژه بعد دو ماه ازتون بخواد یه ویژگی کوچیک به پروژه اضافه کنید عذاب الهی به جونتون میفته، یا حتی وقتی یه باگ ساده گزارش میشه که شما باید رفعش کنید باز هم غصتون میگیره و اونموقعست که آرزو میکنید هیچوقت برنامه نویس نمیشدید. اینجور موقعها اینطوری میشه : یه ویژگی که تو سه روز به پروژه اضافه کردید تغییرش شاید 4 روز یا یه هفته طول بکشه. اگه فریلنسر باشید که عذابتون چند برابره، علاوه بر این که برای اضافه کاری پول نمیگیرید، از انجام کار جدید هم عقب میفتید و ضرر میکنید.

نداشتن تست

بدهی فنی میتونه شامل نداشتن تست یا کمبود تست خوب هم بشه؛ وقنی مجبورید یه بخشو سریع جمعش کنید، پشت سرش احتمالا یا براش تست نمینویسد، یا دوتا تست بدرد نخور(فقط دارید خودتونو گول میزنید که آره منم تست دارم) رو مینوسید، حاصلشو هم انشالله دو ماه دیگه که وقتی تو یه فرم یه چیز نمایش داده نمیشه میبیند که یه سری از دیتاها از بین رفته و اونموقع باید به کارفرما خیلی مهربون زنگ بزنید و قضیه رو براش توضیح بدید که چه دسته گلی به آب دادید(من اگه بمیرم هم اینکارو نمیکنم میگم تقصیر کاربر بود)

فقدان داکیومنت

واضحست، وقتی شما وقت نوشتن کد درست و حسابی ندارید، قطعا وقت نوشتن داکیومنتو هم ندارید. اینطوری اگه تیمی کار می کنید و یکی از اعضای تیمو ترک کنه شما میمونید با یه اسپاگتی کدی که هیچکی نمیتونه درکش کنه، چون داکیومنتی براش وجود نداره و در واقع کد بدون استفاده میشه(ولی احتمالا میشه تو مسابقات اسپاگتی کد بعنوان کد سوال ازش استفاده کرد)

عدم ارتباط مناسب اعضای تیم

به فرض داشتن داکیومنت برای کد "بد"، حتی با وجود در دسترس بودن اعضای تیم؛ بازم هم دچار مشکل میشید، وقتی مسولیت توسعه کد روی دوش یکی دیگه از اعضای تیم میفته، دردسرهای شما شروع میشه؛ هر چند وقت مجبورید در اختیار اون فردی باشید که در حال توسعه کد شماست؛ باعث عدم تمرکزتون روی کار فعلی میشه به این دلیل که هر بار قراره کل فرایندو به خاطر بیارید و براش توضیح بدید که چی نوشتید.

دیر merge کردن branch ها

این یکی خیلی خطرناکه، وقتی branch ها دیر به دیر merge میشن باعث به وجود اومدنconflict های زیادی تو سیستم میشه، و این خودش یه نوع بدهیه فنیه که اتفاقا خیلی از برنامه نویسارو تو دردسر میندازه.

بلای Copy & Past

فاجعه غم بارومصیبت باریه، وقتی یه تیکه کدو از یه پروژه دیگه کپی میکنید، یا مدیر پروژه یه تیکه کد بهتون میده که ازش استفاده کنید؛ ممکنه کد براتون کار کنه ولی اگه شما ندونید چرا کد کار میکنه و در واقع کد رو درک نکنید، هزینش با گذشتن زمان این میشه که نمیتونید تغییرش یا توسعش بدید.چند برابر زمانی که تو کپی پیست کردن کد سود کردیدو باید بعنوان غرامت برای فهمیدن یا بازنویسیش پرداخت کنید.

عدم صلاحیت برنامه نویس

برنامه نویسی که تازه از دانشگاه بیرون اومده(معمولا بعنوان کارآموز تو شرکتهاست و کمتر پیش میاد که رسما حقوق یه برنامه نویس حتی در حد مبتدیو هم بگیره) توسط مدیر پروژه یا برنامه نویس دیگه مسولیت نوشتن یه بخش از کدو داره؛ شاید در نهایت یکی دیگه کدو چک کنه تا صرفا "کد کار کنه"، ولی در نهایت به احتمال خیلی زیاد کد فاقد ارزش در بلند مدته و امکان نگهداری و توسعش وجود نداره.

خب همه ی اینا مواردی بودن که باعث بوجود اومدن بدهی فنی میشن، کپی پیست کدی که کار میکنه چیز لذت بخشیه، یا اینکه وقتتونو برای نوشتن داکیومنت یا تست نمیذارید حس خوبی به آدم میده و واقعا اوایل پروژه نتیجش مثبته ( سریع تموم شدن کار) ولی عواقبشون میشه شکست خوردن اکثر پروژه های نرم افزاری( حداقل از دید فنی نه بحث بیزنسی و مسائل مروبط به بازار و ..).

تلگرام من