دسته: مطالب فناوری اطلاعات

در دنیای ایده‌آل من، همه پروژه‌ها همیشه به موقع تمام می‌شوند و هیچ وقت خرجشان از بودجه تخمینی بیشتر نمی‌شود. تازه با همان بودجه، تیم‌ها نه تنها می‌توانند Featureهای اضافه بسازند، که می‌توانند قبل از بیرون دادن نسخه نهایی همه چیز را چندین بار هم تست کنند. اما حیف، دنیای واقعی این‌قدرها هم دلنشین نیست؛ بلکه در فرآیند توسعه نرم‌افزار، با هر قدمی که می‌گذاریم مشکلات جدیدی از چپ و راست جلوی پایمان سبز می‌شوند. یکی از رایج‌ترین و همه‌گیرترین این مشکل‌ها، بدهی فنی (Technical Debt) است.

بدهی فنی چیست؟

بدهی فنی، کارهای تکمیلی‌ای است که برای کامل کردن فرآیند توسعه نرم‌افزار، زمانی در آینده باید آنها را انجام بدهیم. بدهی فنی نتیجه عجله کردن در تحویل کارکرد یا پروژه‌ای است که در آینده، نیاز به بازسازی خواهد داشت. به عبارت دیگر، پیامد اولویت دادن تحویل سریع به نوشتن کد ایده‌آل است.

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

اما همانطور که با وام گرفتن می‌شود سریع‌تر به اهداف بزرگ زندگی رسید، بدهی‌های فنی هم الزاماً بد نیستند. اگر آنها را درست مدیریت کنید، مزایای بی‌نظیری برای شرکت‌تان خواهند داشت؛ بخصوص اگر از آن شرکت‌هایی باشید که رشد سریع دارند. در چنین شرکتی باید محصولات را سریع و زودبه‌زود ارائه کنید تا بتوانید تناسب محصول/بازار را پیدا کرده، نیازهای مشتری را برآورده کنید، و از فرصت‌هایی که سر راهتان پیش می‌آید بهره ببرید. با مدیریت بدهی فنی، تضمین خواهید کرد که حرص دویدن، در بلندمدت زمینتان نخواهد زد.

درست است که هیچ دستورالعملی برای همه آدم‌های روی کره زمین جوابگو نیست، اما به نظر می‌رسد آشنایی با انواع بدهی‌های فنی، به تیم‌ها کمک می‌کند تا در مورد بدهی فنی حرف بزنند و مشکلات مربوط به آن را به شکل بهتری حل کنند.

دگ لیودن (Dag Liodden)، کوفاندر و CTO شرکت فناوری تبلیغاتی تپ‌اد (Tapad) بیشتر از ۱۴ سال است که دارد با بدهی فنی سر و کله می‌زند؛ در ادامه نگاهی می‌اندازیم به سه نوع اصلی بدهی فنی که توسعه‌دهندگان بیشتر از همه با آن‌ها سروکار دارند و استراتژی‌هایی که دگ لیودن برای روبه‌رو شدن با هر کدام پیشنهاد می‌کند را مرور می‌کنیم:

۱. بدهی فنی عامدانه

مهندس‌ها معمولا خودشان می‌دانند که کدام راه، راه درست انجام کار است و کدام راه، راه سریع آن. خیلی وقت‌ها، راه سریع همان کار درست است (برای جلوگیری از Over-engineering)، اما بعضی وقت‌ها هم اعضای تیم عمداً کار «اشتباه» را انجام می‌دهند، چرا که باید محصول را به سرعت به بازار برسانند.

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

راه حل: شاید بگویید که این کار خیلی با فرهنگ چابک (Agile) تیم شما سازگار نیست! اما ایده خوبی است که وقت ایجاد این نوع از بدهی فنی، کارهایی که انجام نداده‌اید را در بک‌لاگ محصول (Backlog) یادداشت کنید. اگر این کارهای ناتمام به طور مشخص ثبت نشوند، بعید است که بدهی فنی در آینده پرداخت شود. بدون پرداخت بدهی‌ها، در گذر زمان بدهی فنی عامدانه تبدیل به بدهی ناشی از طراحی اتفاقی خواهد شد. مسئولیت به وجود آمدن این نوع بدهی‌ها بر عهده مالک محصول‌ (Product Owner) و ذی‌نفعان است؛ زیرا به خاطر تصمیمات تجاری است که به وجود می‌آیند.

۲. بدهی فنی ناشی از طراحی تاریخ‌گذشته یا اتفاقی

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

راه حل: اینکه چطور Refactor مفصلی بکنیم خودش چندین پست جدا می‌طلبد، اما نیاز به انجام آن یک چیز طبیعی است. هرچند وقت یک بار، مثلا هر دو سال یک بار یا هر وقت که سیستم در وضعیت باثباتی بود، لازم است که چنین کاری انجام شود. اگر نشود، آنوقت ممکن است Over-engineering کنید و باعث شوید سیستم به شکل غیر ضروری‌ای مرتباً کند باشد. رهبران تیم و مالک محصول‌ها باید اطمینان حاصل کنند که برای بازپرداخت این نوع بدهی در آینده زمان کنار می‌گذارند؛ چرا که علت به وجود آمدن آن، تصمیمات مربوط به طراحی سیستم و تغییر مداوم نیازهای سیستم است.

۳. بدهی فنی ناشی از فرسودگی نرم‌افزاری

بدهی فنی ناشی از فرسودگی نرم‌افزاری (Bit rot)، به مرور زمان به وجود می‌آید. تغییراتی که به تدریج در یک Component یا یک سیستم ایجاد می‌کنیم، باعث می‌شوند که کم‌کم سیستم پیچیدگی‌های غیرضروری‌ای پیدا کند. این پیچیدگی بخصوص زمانی تشدید می‌شود که چندین نفر بدون اینکه طراحی اولیه سیستم را درست فهمیده باشند، روی آن کار کنند. از جمله علایم چنین حالتی، برنامه‌نویسی کپی‌پیستی (یا به عبارتیCargo Cult Programming) است.

راه حل: این تنها نوع از بدهی‌های فنی است که باید با Refactor مداوم کدها، به کلی از آن اجتناب کرد. تیم‌هایی که قوی هستند، برای فهم طراحی سیستمی که رویش کار می‌کنند، وقت کافی می‌گذارند؛ حتی اگر طراحی اولیه آن کار خودشان نبوده باشد. آنها به مرور طراحی را بهبود می‌بخشند و در طول مسیر، کدهای بد را تمیز می‌کنند. مسئولیت جلوگیری از به وجود آمدن این نوع بدهی با تیم توسعه نرم‌افزار است، زیرا این تک‌به‌تک اعضای توسعه‌دهنده هستند که آن را به وجود می‌آورند.

تقسیم‌بندی انواع بدهی فنی یک راه حل معجزه‌آسا نیست. اینطور نیست که چوبدستی را تکان بدهیم و فقط با طبقه‌بندی، مدیریت کردن بدهی را به طور جادویی آسان شود. اما این کار، تیم شما را قدرتمندتر می‌کند و گفتگوهای مفیدتری در این‌باره خواهید داشت. بدهی فنی شما به سیستم هرگز تمام نخواهد شد، و نباید هم بشود. نکته مهم این است که همیشه حواستان باشد که این بدهی چطور باعث کندی تیمتان می‌شود، و سعی کنید بین «تحویل Featureها در کوتاه‌مدت» و «افزایش بازدهی کلی در میان‌مدت و بلندمدت»، تعادل برقرار کنید.

ترجمه و اقتباس از:

• “There are 3 main types of technical debt. Here’s how to manage them“ @ Hackernoon
• “What Technical Debt Is and How to Calculate It” @ DZone
• “What is Technical Debt?” @ ProductPlan

کوئرامگ مجله‌ای تخصصی برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های کوئرامگ، می‌توانید اکانت توئیتر یا کانال تلگرام ما را دنبال کنید.

من یه برنامه نویسم,شش ساله دارم بین کدهام زندگی میکنم.روزا کد میزنم,شبا بهشون فکر میکنم و خوابشون رو میبینم.عاشق قهوه و چای هستم.وقتی به باگ میخورم دلم میخاد لم بدم بین کدها و سیگار بکشم و آهنگ داریوش گوش بدم!اونکه رفته دیگه هیچ وقت نمیاد…

فک میکنم کد مثل ترشی میمونه باید جا بیافته تا کار کنه.شب کار نمیکنه و صبح بلند میشی و میبینی در اوج ناباوری داره کار میکنه.

تصور اطرافیانم از من یک دختر باهوش با یک شغل شیک و باکلاس!لم دادم پای کامپیوترم و با زدن چند تا دکمه فورا یک سایت رو بالا میارم و به پول کلانی میرسم!دقیقا به همین راحتی…

نزدیکانم اما منو یک موجود عجیب می بینن که قادره ساعت ها و حتی تمام طول روز بدون پلک زدن ,حرف زدن و یا حتی بدون اینکه بشنوه و یا چیزی بخوره زل بزنه به صفحه ی سیاه مانیتورش…

کارفرمام اما منو یک ماشین میبینه بدون هیچ گونه احساس و یا حس خستگی…

درون گرایی و غیر اجتماعی بودن توی اکثر برنامه نویسا وجود داره!که همین دو مورد به مرور باعث کاهش اعتماد بنفس اونا میشه.یه جورایی رفتن به سمت یک پدیده ی روانی دیگه به اسم سندروم است که اکثر برنامه نویسا به اون دچار هستند.بر خلاف اینکه من تمام تلاش خودم رو در ارتباط با یک پروژه انجام دادم و شواهد نشون میده که من موفق بودم ولی همچنان احساس میکنم لیاقت این موفقیت رو ندارم!

من یک برنامه نویسم پرم از حس خستگی ذهنی و بی انگیزگی در مواجهه هر روزم با روش های جدید,تکنولوژی جدید,فریمورک جدید و …

من یک برنامه برنامه نویسم مثل همه تفریح رو دوست دارم اما تفریح من پر از استرسه و برام شادی آور نیست!

من یک برنامه نویسم پرم از ترس قضاوت از فیدبک های مختلف کارفرما

من یک برنامه نویسم ,پرم از حس سرزنش و نقد دائمی,پرم از حس مقایسه بین خروجی من و خروجی سایرین …

عاشق شغلم هستم و پرم از حس تردید بین ادامه دادن یا ندادن…

چند روز پیش که با اندروید استدیو کار میکردم با این صحنه روبرو شدم???‍♂ فک کردم که مشکل از کشه و باید پاک بشه، بعد از پاک کردن کش دوباره بازم همین مشکل بود??‍♂ همه لایه ها باز میشن ولی به جز اون لایه ای که تازه طراحی کرده بودم?

بعد که کمی دقت کردم، از کتابخونه متریال گوگل استفاده کرده بودم، نسخه های آلفای این کتابخونه با اندروید استدیو ۳.۴.۱ مشکل دارن و اگه در لایه خودتون از material button استفاده کنید، با این مشکل مواجه میشید.?

ورژن کتابخونه:

۱٫۱٫۰-alpha06

خب حالا میرسیم به راه حل:

ازونجا که ورژن آلفای این کتابخونه امکانات زیادی داره و بهش نیاز دارم باید برم و اندروید استودیو ۳.۵ از چنل بتا دانلود کنم، مشکل در این نسخه حل شده?

راه‌حل دوم اینه که ورژن کتابخونه رو دانگرید کنید به

۱٫۰٫۰

که اصلا پیشنهاد نمیکنم?

جهت مطالعه بیشتر:

منظور از برنامه نویسان راک استار کسانی هستند که توانایی تولید مقادیر زیادی کد و پیاده سازی قابلیت های سیستم با سرعتی زیاد را دارا هستند، به شکلی که در مقابلشون احساس می‌کنید یک دورف کوتوله هستید.

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

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

در فیلم مردان ایکس شخصیتی وجود داشت به نام سایکلاپس، که از چشم هایش لیزری پر قدرت بیرون میزد که میتوانست همه چیز را نابود کند. برنامه نویسای راک استار تقریبا مثل همان شخصیت هستند که پر از استعداد هستند و این قابلیت ها در همه جهات به شکلی کنترل نشده بیرون ریخته می‌شود و در صورتی که کنترل و متمرکز نشوند میتوانند تخریب کننده باشند.

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

اگر به عنوان یک مدیر این مطلب را مطالعه میکنید،

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

اگر به عنوان کسی که با یکی از برنامه نویسان راک استار همکار هست این نوشته را مطالعه می‌کنید،

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

اگر خودتون که این نوشته را مطالعه می‌کنید یک برنامه نویس راک استار هستید،

متوجه باشید که وقتی تنهایی کد می‌نویسید با وقتی که در تیم هستید خیلی تفاوت دارد. شما موقعی که تنها کار می‌ کنید می‌توانید با هر سرعتی که می‌خواهید کار کنید اما برای اینکه بتوانید در یک تیم بازدهی داشته باشید باید با بقیه هم تعامل کنید. تعامل کلید بازدهی یک تیم هست. اگر یاد بگیرید که با دیگر اعضای تیم تعامل و صحبت کنید و نسبت به عواقب تغییراتی که توی سیستم اعمال می‌کنید و کدها و طراحی های خود کمی متواضعانه تر برخورد کنید می‌توانید جزو بهترین اعضای تیم باشید و به حداکثر بازدهی و تاثیر گذاری خود برای تیم برسید.

این مطلب بازنشری از این نوشته بلاگ شخصی ام بود.