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

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

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

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

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

فشار کاری

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

فقدان تست

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

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

این مورد کاملا بدهی است، وقتی شما وقت نوشتن کد تمیز را ندارید، قطعا وقت نوشتن داکیومنت را هم ندارید. در این صورت اگر در تیمی کار می کنید و یکی از اعضای تیم قصد ترک کردن تیم را داشته باشد، اسپاگتی کدی را تجویل می گیرید کسی توانایی درک آن را ندارد.

فاصله ی زمانی زیاد بین merge کردن branch ها

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

فاجعه ی Copy & Past

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

عدم صلاحیت برنامه نویس(دانش ناکافی)

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

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

برای مطالعه قسمت سوم اینجا کلیک کنید.