https://virgool.io/feed/@FarshidRoohi Senior Software Engineer fa 2026-07-06 11:20:57 https://files.virgool.io/upload/users/10719/avatar/VqPc5V.jpg?height=120&width=120 https://virgool.io/@FarshidRoohi https://virgool.io/@FarshidRoohi/%DA%86%D8%B1%D8%A7-%D8%AF%D8%B1%DA%AF%DB%8C%D8%B1-%DA%A9%D8%AF-%DA%A9%D8%AB%DB%8C%D9%81-%D9%88-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D8%A7%D8%B3%D9%BE%D8%A7%DA%AF%D8%AA%DB%8C-%D9%85%DB%8C%D8%B4%DB%8C%D9%85-i9fg2tjblmy3 تو این مقاله سعی دارم راجب نکاتی صحبت کنم که باعث میشه کد کثیف زده بشه و در نهایت پروژه نرم‌افزاریمون تبدیل به یه پروژه اسپاگتی بشه و در نهایت باهم راه‌حل‌های احتمالی رو بررسی میکنیم.در ادامه به این چندتا سوال میخوایم جواب بدیم:کد کثیف به چه کدی گفته میشه؟پروژه نرم‌افزاری اسپاگتی؟راه حل چیه؟کد کثیف به چه کدی گفته میشه؟غیرقابل فهم بودن: پیچیدگی غیرضروری و معماری نامناسبکدهای تکراری: عدم توجه به قابل استفاده بودن کدها(متدها، کلاس‌ها، ...)نبود تست: امکان نوشتن تست وجود نداشته باشه یا زمانی برای تست نویسی گذاشته نشود.غیرقابل اعتماد: وجود اشکالات مختلف و سخت بودن دیباگ و رفع مشکل.خیلی از برنامه‌نویس‌ها زمانی که یک پروژه جدید رو شروع میکنن، حساسیت خیلی زیادی برای نوشتن کدهای تمیز، قابل نگه داری و قابل توسعه دارن، ولی چی میشه که اون حساسیت‌ها به مرور کم میشه و به یکسال نکشیده پروژه تبدیل به یک اسپاگتی بزرگ میشه؟متاسفانه دلایل زیادی وجود داره که منجر به این اتفاقات میوفته که به بعضی از اون موارد اشاره میکنم:کمبود مهارت برنامه‌نویس: کمبود مهارت یا عدم درک کافی به اندازه و آینده پروژه نرم‌افزاری(نمیدونیم قراره چقدر بزرگ بشه این پروژه).عدم مدیریت مناسب زمان: انتخاب ددلاین‌های نزدیک بدون توجه به عمق کار و نادیده گرفتن نقاط تاریک هر پروژه یا تسک.عدم وجود قرارداد برای سبک کدنویسی: وقتی یک استاندارد یا قرارداد تیمی برای یک پروژه وجود نداشته باشه احتمال زیادی وجود داره که هر برنامه‌نویس به سبک شخصی خودش کد بنویسه و این باعث بی نظمی و یکپارچه نبودن کدهای پروژه میشه.تغییرات زیاد: خیلی مواقع درگیر پروژه‌هایی میشیم که خود مدیر محصول هم تعریف درستی از پروژه نداره و شفاف نیست براش، بخاطر این موضوع، ناخواسته مجبور به تغییرات زیاد با بازه زمانی کم میشیم که باعث بوجود اومدن بدهی‌های فنی زیادی میشیم.مدیریت ضعیف: عدم وجود مستندات کافی، عدم وجود ارتباطات مناسب بین هم تیمی و بین تیمیپروژه نرم‌افزاری اسپاگتی؟خروجی موارد بالا میشه یک پروژه نرم‌افزاری به شکل اسپاگتی که ساختار درستی نداره و اجزای پروژه در هم و بر هم و پیچیده شده.اشکالات پروژه‌های اسپاگتی:دشوار شدن توسعه: پیاده سازی هر امکان جدید به شدت زمان‌بر و سخت میشه، و بجایی میرسه که ساخت پروژه جدید هزینه زمانی خیلی کمتری برامون داره تا توسعه پروژه کثیف و اسپاگتی.دشوار شدن نگهداری: هر پروژه نرم‌افزاری نیاز به نگهداری و اصطلاحا باگ فیکس داره، ولی در این مدل از پروژه‌ها پیدا کردن و حل یک مشکل نرم‌افزاری به شدت دشوار میشه و عملا بازنویسی یک کلاس یا ماژول منطقی تر از پیدا کردن یک مشکل از هزارتو به وجود اومده است.افزایش هزینه: توسعه و نگهداری یک پروژه اسپاگتی میتونه بسیار پر هزینه‌تر از پروژه‌های با ساختار مناسب باشه.کاهش کیفیت: متاسفانه در این نوع پروژه‌ها، کیفیت کد نویسی به حداقل رسیده و احتمالا خروجی خوبی هم نخواهد داشت.راه حل؟اولین و آسون‌ترین تصمیم معمولا ایجاد یک پروژه دیگه‌س که خیلی از برنامه‌نویس‌ها این تصمیم رو میگیرن.ولی آیا راه حل بهتری هم هست؟ بنظر من بله هست، طبق تجربه‌های مختلفی که توی پروژه‌های نرم‌افزاری داشتم راه حل ساخت یک پروژه مجدد با رویکرد کد تمیز بدون در نظر گرفتن نقاط ضعف پروژه قبلی هم منجر به شکست شده(تبدیل شدن به اسپاگتی در طولانی مدت)، تاکید من روی زمان طولانی مدته چون در کوتاه مدت هم باز حساسیت زیادی به خرج میدیم، تو ریویوها سختگیری بیشتری داریم، ولی به مرور زمان باز شاهد کدهای کثیف هستیم که گاهی این حس به وجود میاد که باز برگشتیم سر نقطه اول.من زمانی راه حل ساخت یک پروژه جدید با رویکرد کد تمیز رو پیشنهاد میدم که ساعت‌ها راجب پروژه کثیف قبلی جلسه گذاشته بشه، عیب یابی بشه، از نقاط ضعف و چرایی پروژه کثیف مستند تهیه بشه و در نهایت شفافیتی شکل بگیره که امکان تکرار اشتباه وجود نداشته باشه و درصد خوبی از موارد بالا که بهش اشاره شد رو پوشش بده.راه حل دوم تمیز کردن پروژه کثیف فعلی میتونه چالش های زیادی برامون داشته باشه بعلاوه هزینه زمانی و مالی زیادی برای صاحب پروژه، ولی مزیت‌هایی داره که بد نیست مرور کنیم:تجربه: بزرگترین مزیت ریفکتور کردن پروژه‌های نرم‌افزاری تجربه کردن میتونه باشه که کمک شایانی از لحاظ فنی به تیم میکنه.امکان یادگیری فنی: خیلی از بدهی‌های فنی رو میشه به دید یک موضوع یادگیری و تجربه نگاه کرد که در نهایت باعث رشد فنی تیم و فرد میشه.امکان تغییر: خیلی از بازنویسی‌هایی ک اتفاق میوفته دست برنامه‌نویس رو باز میزاره که درگیر تکنولوژی‌های جدید بشه و از کدبیس‌های قدیمی فاصله بگیریم.رشد مهارت تیمی: حل بدهی‌های فنی نیاز به ارتباط بین تیمی و درون تیمی، پوشش نقطه ضعف‌های موجود رو داره که همین موضوع باعث پیشرفت تیم میشه.جمع‌بندی:بدهی‌های فنی، کد کثیف و پروژه‌های اسپاگتی جز مواردی هستن که باهاشون به صورت روزانه سرکار داریم، این خوبه بشناسیم و بدونیم که چه مشکلاتی تو پروژه داریم و مطمئن بشیم که همه تیم در جریان هستن، برنامه کوتاه و بلند مدت برای رفع این مشکلات داشته باشیم، چون اگه برنامه‌ای برای حل این مشکلات وجود نداشته باشه، هم تیم درگیر توسعه فرسایشی میشه که در طولانی مدت آثار مخربی مانند جدا شدن برنامه‌نویس از تیم و عقب افتادن فرد از رشد فنی میشه و هم صاحب محصول یا پروژه هزینه‌های گذافی رو باید متقبل بشه برای توسعه و نگهداری پروژه.در مورد بدهی‌های فنی اینجا بیشتر توضیح دادم: نگاهی به بدهی فنی پروژه های نرم‌افزاریمنابع:https://en.wikipedia.org/wiki/Technical_debthttps://en.wikipedia.org/wiki/Don%27t_repeat_yourselfhttps://en.wikipedia.org/wiki/Code_smellhttps://stackoverflow.blog/2023/12/27/stop-saying-technical-debt/https://en.wikipedia.org/wiki/Spaghetti_code فرشید روحی فرشید روحی Fri, 23 Feb 2024 19:33:55 +0330 https://virgool.io/@FarshidRoohi/technical-debts-axbzjjqvrrzq تو این مقاله سعی دارم بدهی فنی رو توضیح بدم و مشکلات و سودهای احتمالیش رو باهم بررسی کنیم که در طولانی مدت میتونه چه مشکلاتی برامون ایجاد کنه و در کوتاه مدت چه سودی میتونه برامون داشته باشه.بدهی فنی چیه و به چه دلایلی ایجاد میشن؟مزایا و معایب؟اصطلاح این کد بو میده یعنی چی؟چطوری میتونیم با بدهی فنی کنار بیایم؟بدهی فنی چیست و به چه دلایلی ایجاد میشن؟فرض کنید روی پروژه‌ای کار میکنید که اضافه کردن فیچر جدید زمان‌بر شده، دیباگ کردن یه باگ بسیار سخت شده، اصطلاحا توسعه پذیر و یا قابل بهبود نیست یا زمان زیادی برای بهبود نیار داره.مواردی که در بالا بهش اشاره شد نتایج بدهی‌های فنی ساختاریه که به مرور زمان باعث کند شدن پروسه توسعه محصول میشه.ما میتونیم بدهی‌های فنی داشته باشیم که مشکلی برای توسعه پروژه ایجاد نکنه و به طور مثال خروجی به درستی داره کار میکنه ولی بهینه نیست و میشه بهترش رو نوشت و احتمالا اتفاق فورسی براش پیش نمیاد.بدهی فنی میتونه علل‌های مختلفی داشته باشه ولی معمولا میتونه تو این دوتا دسته جا بگیره:محدودیت زمانیبی‌تجربه بودن تیم یا فردمحدودیت زمانی: با یک مثال این مورد رو توضیح میدم فرض کنید پیاده کردن یه پروژه نرم افزاری به اسم X با فیچرهای a, b, c طبق بررسی نیازمندی‌ها و توان نیروها ۶ ماه زمان برآورد شده، ولی مدیر پروژه با توجه به محدودیت ها و از دست ندادن زمان عرضه در مارکت درخواست انجام این پروژه را در ۳ ماه دارد، یعنی نصف زمان برآورد شده است.بی‌تجربه بودن تیم یا فرد: زمانی اتفاق میوفتد که تقریبا همه چیز متناسب با زمانش پیش میرود، ولی در حین پیاده سازی پروژه بخاطر عدم تجربه کافی، تصمیم های غلط گرفته میشود، این تصمیم‌های غلط میتواند انتخاب اشتباه معماری یا حتی انتخاب تکنولوژی یا فریمورک اشتباهی برای آن پروژه خاص باشد که در بلند مدت میتوان آثارش را مشاهده کرد.بدهی فنی، مزایا و معایببدهی فنی میتونه مزیت های کوتاه مدتی برای محصول داشته باشه که حتی میتونه نقش برگ برنده برای تیم محصول رو بازی کنه، فرض کنید که یک ایده‌ای وجود دارد که در این بازه زمانی امکان درآمد زایی برای شرکت داشته باشه، با فرض این موضوع اگر تیم برنامه نویسی در زمان ایده آل خود بخواهد این فیچر یا پروژه را توسعه دهد احتمالا تیم محصول با یک فرصت سوزی بزرگ روبرو خواهد شد، و بخاطر این موضوع مدیر تیم فنی با قبول عواقب بدهی فنی که در آینده احتمالا گریبان گیر تیم فنی خواهد شد توسعه نرم افزار را جلو ببرد.معمولا مشکلات بدهی فنی در طولانی مدت و در روند توسعه محصول خودشان را نشان میدهند که هزینه‌های زیادی هم با خودشون میارن، به طور مثال وقتی روی معماری یک پروژه نرم‌افزاری وقت زیادی گذاشته نشود و انتخاب درستی در پیاده سازی نداشته باشیم احتمالا در آینده هزینه خیلی زیاد برای توسعه محصول خواهیم داشت که با بزرگ شدن پروژه روند کارها کندتر و کندتر از قبل پیش میرود، یا موردی رو فرض کنید که شخص جدیدی وارد تیم یا پروژه شده است، چون پروژه بدهی‌های فنی زیادی دارد، از جمله تست خوبی نوشته نشده، وقت زیادی برای معماری، دیزاین پترن‌ها گذاشته نشده، ... در این شرایط هم سرعت توسعه تحت تاثیر قرار گرفته میشه، هم به پیچیده‌تر شدن Code base پروژه اضافه میشه.بدهی‌های فنی میتونه موارد زیادی رو در بر بگیره با اولویت‌های کم یا زیاد و شرایط خاص و غیر خاص، به طور مثال معمولا در پروژه‌های برنامه‌نویسی اولین چیزی که به عنوان بدهی فنی پیش میاد نوشتن Unit Test، استفاده از دیزاین پترن‌ها برای بهینه‌سازی یا قابلیت استفاده مجدد یا پیروی از اصول های توسعه نرم افزار مانند ۵ اصل SOLID یا DRY و خیلی از موارد دیگه که در توسعه پذیر بودن پروژه نرم‌افزاری نقش‌های مهمی دارن.اصطلاح این کد بو میده یا Code Smellدر مهندسی نرم‌افزار، به ویژگی‌ها یا نشانه‌هایی در کد یک برنامه که حاکی از وجود مشکلاتی در عمق برنامه باشند، Code Smell گفته می‌شود. بوهای کد خطا نیستند، اما می‌توانند کد را برای نگهداری، درک و گسترش دشوارتر کنند.بوی کد به ۳ سطح از پروژه نرم افزاری اشاره میکنه:بوهای بد کد در سطح برنامهبوهای بد کد در سطح کلاسبوهای بد کد در سطح متدهر کدوم از موارد بالا یک لیستی از اشتباهات رایج رو شامل میشه که عدم رعایت اون موارد تو پروژه نرم افزاری حکایت از بوی بد کد داره.اینجا به چندتا از موارد خیلی عمومی اشاره میکنم:کد تکراری: کدی که در چندین مکان در پروژه تکرار می‌شود.کد مرده: کدی که استفاده نمیشه ولی داخل پروژه وجود داره.متدهای طولانی: متدهایی که بیش از حد طولانی و پیچیده هستند.لیست‌های پارامتر طولانی: متدهای با تعداد زیادی پارامتر، راه حلش این میتونه باشه که بجای پارامترهای زیاد یک کلاس یا مدل پاس بدیم.تغییر واگرا: کلاس‌هایی که به‌طور مکرر و به روش‌های مختلف تغییر می‌کنند.جراحی تفنگ ساچمه‌ای: کلاس‌هایی که برای یک تغییر واحد در چندین مکان تغییر می‌کنند.چطوری میتونیم بدهی‌های فنی رو صاف کنیم؟راه حل دقیق برای همه تیم های برنامه نویسی و پروژه ها وجود نداره و خیلی بستگی به نوع پروژه و وضعیت پروداکت داره، ولی دو راه حل مشترک وجود داره که بیشترین مشکلات رو پوشش میده:ساخت پروژه جدید و درس گرفتن از اشتباهات گذشتهریفکتور کردن بخش های مختلف پروژه به مرور زمانمورد اول زمانی اتفاق میوفته که پروژه به حدی از پیچیدگی و بدهی‌های فنی رسیده که دیگه قابل توسعه نیست و راه حل کم هزینه میتونه گزینه ساخت پروژه جدید و توجه زیاد به نقطه ضعف های پروژه قبلی باشه.مورد دوم ریفکتور کردن بخش‌های مختلف پروژه در کنار انجام نیازمندی‌های پروداکت، با یک مثال توضیح بیشتری میدم:فرض کنید روی یک پروژه کار میکنید که بدهی فنی در رابطه با معماری و ساختار پروژه وجود داره و تستی برای قسمت‌های مختلف پروژه نوشته نشده، در همین حین، تیم پروداکت فیچرهایی رو برای توسعه نیاز داره. تو این شرایط احتمالا امکان ساخت پروژه جدید وجود نداره و از طرفی هم بدهی‌فنی های زیادی هم وجود داره، یکی از راه حل‌های موجود میتونه این باشه که تیم برنامه‌نویسی واقعیت بدهی فنی رو به تیم پروداکت یا مدیر پروژه شرح بده و ازشون وقت برای حل کردن این مشکلات بگیره و شرح کار به این شکل میشه که در هر دوره(ماه، هفته، هر اسپرینت اسکرام، ...) چند درصد از زمان رو برای ریفکتور کردن و حل کردن بدهی‌های فنی اختصاص داده بشه، و چند درصد از زمان تیم رو به پیاده کردن نیازمندی‌های تیم پروداکت اختصاص دهیم.با این راه حل احتمالا حل کردن تمام بدهی‌های فنی امری زمان بر باشه، ولی میتونیم با این شرایط، هم کدهای موجود رو ریفکتور کنیم، هم به نیاز مندی‌های بیزینس برسیم که معمولا باعث روند پیشرفت تدریجی پروژه و بیزینس میشه.نتیجه‌گیریبدهی‌فنی لزوما خیلی بد یا خیلی خوب نیست، پروژه های برنامه نویسی میتونه بدهی‌های فنی متعددی داشته باشه ولی تا زمانی که توسعه محصول رو تحت تاثیر قرار نده میتونیم باهاشون کنار بیایم و درگیر موارد با اولویت بالاتر بشیم، از جمله حل مشکلات مهم و ریفکتور کردن، یا حتی استفاده از تکنولوژی جدیدتر.اگه در حال شروع یک پروژه هستید و از لحاظ زمانی محدودیت دارید، باید دونسته هزینه‌های بدهی فنی در آینده رو انتخاب کنید.همیشه ساخت پروژه جدید بهترین راه حل برای حل کردن بدهی فنی های زیاد نیست و میتونیم به صورت خرد موارد مهم رو انجام بدیم در حالی که نیازمندی های بیزینس هم رفع بشه.همیشه باید به Code smell توجه داشته باشیم تا بدهی های فنی پروژه روز به روز بیشتر نشه و کدهای کثیف باعث ایجاد کدهای کثیف بیشتر نشه.منابعhttps://en.wikipedia.org/wiki/Code_smellhttps://en.wikipedia.org/wiki/Shotgun_surgeryhttps://martinfowler.com/bliki/CodeSmell.htmlhttps://www.youtube.com/watch?v=w9YhmMPLQ4Uhttps://en.wikipedia.org/wiki/SOLIDhttps://en.wikipedia.org/wiki/Don%27t_repeat_yourself فرشید روحی فرشید روحی Wed, 01 Nov 2023 14:12:13 +0330