در دنیای مهندسی نرمافزار، مفاهیمی مثل کدنویسی تمیز، معماری مناسب، تستنویسی، و مدیریت بدهی فنی سالهاست بهعنوان اصول پایه شناخته میشوند. تقریباً همه برنامهنویسان باتجربه میدانند که رعایت این اصول در بلندمدت سرعت توسعه را افزایش میدهد، خطاها را کاهش میدهد و هزینه نگهداری سیستم را پایین میآورد. با این حال، در بسیاری از شرکتها واقعیتی متفاوت جریان دارد:
تا زمانی که کد کار میکند، کیفیت آن چندان اهمیتی ندارد.
این شکاف میان منطق مهندسی و منطق مدیریتی یکی از رایجترین تنشها در تیمهای نرمافزاری است.
ریشه اصلی این مسئله در نحوه ارزیابی موفقیت در شرکتها قرار دارد. بیشتر کسبوکارها با شاخصهایی مانند سرعت تحویل فیچر، رشد محصول و درآمد سنجیده میشوند. مدیران معمولاً تحت فشار هستند تا در بازههای زمانی کوتاه نتایج ملموس ارائه دهند. در چنین شرایطی، فعالیتهایی مثل ریفکتور کد، طراحی معماری بهتر، یا نوشتن تستهای خودکار اغلب بهعنوان هزینهای دیده میشوند که بازگشت سرمایه فوری ندارند.
مشکل اینجاست که مزایای کدنویسی اصولی معمولاً در کوتاهمدت دیده نمیشوند. زمانی که یک تیم تصمیم میگیرد بدهی فنی را کاهش دهد یا ساختار پروژه را اصلاح کند، سرعت تحویل فیچرها برای مدتی کاهش مییابد. این کاهش موقت سرعت ممکن است از نگاه مدیریت بهعنوان نشانهای از ناکارآمدی تیم تفسیر شود، حتی اگر هدف آن افزایش بهرهوری در آینده باشد.
در نتیجه، الگویی تکرارشونده در بسیاری از شرکتها شکل میگیرد. در مقطعی تیم فنی تلاش میکند کیفیت کد را بالا ببرد و ساختار سیستم را بهبود دهد. اما وقتی این تلاشها در کوتاهمدت به خروجی تجاری ملموسی تبدیل نمیشوند، فشار برای «بازگشت به روال قبلی» شروع میشود. تمرکز دوباره بر تحویل سریع تسکها قرار میگیرد و مسائل ساختاری به آیندهای نامعلوم موکول میشوند.
این چرخه معمولاً یک پیامد مشخص دارد: انباشت بدهی فنی.
بدهی فنی مانند بهرهای است که روی تصمیمات عجولانه گذشته جمع میشود. کدهایی که بدون طراحی مناسب نوشته شدهاند، وابستگیهای پیچیده، نبود تست و معماریهای موقتی که هرگز اصلاح نشدهاند، به مرور زمان توسعه سیستم را کند و پرهزینه میکنند. در چنین شرایطی، هر تغییر کوچک ممکن است ریسک ایجاد باگهای غیرمنتظره را بالا ببرد و زمان توسعه را چند برابر کند.
نکته پاردوکسیکال (متناقضنمای) ماجرا این است که همان تصمیماتی که در ابتدا برای «سریعتر پیش رفتن» گرفته شده بودند، در بلندمدت دقیقاً نتیجه معکوس میدهند. تیمها در نهایت زمان بیشتری صرف حل مشکلات سیستم میکنند تا توسعه قابلیتهای جدید.
با این حال، بسیاری از سازمانها این چرخه را بارها تکرار میکنند. یکی از دلایل مهم این موضوع، فاصله میان زمان تصمیم و زمان بروز پیامد است. مدیری که امروز تصمیم میگیرد از اصلاح ساختار پروژه صرفنظر کند، ممکن است چند ماه یا حتی چند سال بعد اثرات آن را ببیند. زمانی که احتمالاً تیم یا شرایط پروژه تغییر کرده است. این فاصله زمانی باعث میشود هزینه واقعی تصمیمها کمتر دیده شود.
گاهی این تصمیمات در بلند مدت باعث مرگ و نابودی پروژه و یا حتی کسب و کار میشوند. گاهی نیز برنامه نویسان تصمیم میگیرند که پروژه را تبدیل به زمین بازی یادگیری خود کنند و به دلیل کم بودن دانش فنی مدیر مربوطه صرفا سعی در رفع چسب زخمی ایرادها دارند.
عامل دیگر، تفاوت زبان میان مهندسان و مدیران است. مهندسان درباره کیفیت کد، معماری سیستم، و پایداری بلندمدت صحبت میکنند، در حالی که مدیران بیشتر با مفاهیمی مانند زمان تحویل، هزینه، و درآمد سروکار دارند. اگر این دو زبان به یکدیگر ترجمه نشوند، گفتوگو بهراحتی به سوءتفاهم تبدیل میشود.
در بسیاری از موارد، حتی تلاش برای بهبود کیفیت فنی ممکن است به اشتباه بهعنوان کندی یا ضعف مدیریتی برداشت شود. وقتی تمرکز صرفاً روی تعداد تسکهای بستهشده باشد، مدیری که سعی میکند زمان مشخصی را به اصلاح ساختار پروژه اختصاص دهد، ممکن است در مقایسه با کسی که صرفاً تسکها را به سرعت جلو میبرد ناکارآمد به نظر برسد. در حالی که تفاوت واقعی در نوع نگاه به آینده سیستم است.
ممکن است برخی از اعضای تیم ساختار یا وضعیتی را برای توسعه در نظر بگیرند که در مجموع از نظر سرعت بسیار مطلوب باشد ولی از لحاظ تولید میزان باگ بسیار خطرناک و با سرعتی چند برابر حالت عادی باشد.
با گذشت زمان، چنین محیطهایی اغلب برای مهندسانی که به کیفیت اهمیت میدهند فرساینده میشوند. برخی از آنها تلاش میکنند با آموزش و توضیح، اهمیت بدهی فنی را روشن کنند. برخی دیگر شرکت یا تیم خود را تغییر میدهند. و برخی در نهایت با شرایط موجود سازگار میشوند و تمرکز خود را صرفاً بر تحویل کار میگذارند.
با این حال، شرکتهایی هم وجود دارند که مسیر متفاوتی را انتخاب کردهاند. در این سازمانها کیفیت کد نه بهعنوان یک تجمل، بلکه بهعنوان بخشی از سرمایهگذاری بلندمدت در محصول دیده میشود. آنها میدانند که سرعت پایدار توسعه تنها زمانی ممکن است که سیستم نرمافزاری قابل فهم، قابل تست و قابل تغییر باقی بماند.
تا اینجا به دلایل ارزش کمیت کد نسبت به کیفیت کد پرداختیم و گفتیم دلیل تولید کارخانهوار فیچر و افزایش بدهی فنی بیشتر به اقتصاد و مدیریت پروژه برمیگردد تا خود برنامهنویس.
بیشتر شرکتها روی این معیارها سنجیده میشوند:
چقدر سریع محصول به بازار میرسد (Time to Market)
آیا فیچر جدید سریع اضافه میشود
آیا مشتری پول میدهد
کدنویسی اصولی (تست، معماری تمیز، ریفکتور) معمولاً سرعت کوتاهمدت را کم میکند، حتی اگر در بلندمدت خیلی مفید باشد.
کد بد معمولاً مشکلاتش را ماهها یا سالها بعد نشان میدهد:
باگهای عجیب
توسعه کند
سختی تغییرات
اما مدیران اغلب روی نتیجه کوتاهمدت تمرکز دارند، نه بدهی فنی (Technical Debt).
در خیلی از شرکتها تصمیمگیرندهها برنامهنویس نیستند. برای آنها تفاوت بین:
کد تمیز و معماری درست
کدی که فقط کار میکند
واضح نیست. پس معیارشان فقط این است: «کار میکند یا نه».
در استارتاپها مخصوصاً:
باید سریع MVP ساخته شود
باید سریع رشد نشان دهند
در این حالت شعار نانوشته این است:
Make it work first. Make it right later.
مشکل اینجاست که «later» یا بعدا خیلی وقتها هیچوقت نمیآید.
در پروژههای کوچک:
معماری پیچیده لازم نیست
کد ساده و حتی کمی شلخته هم جواب میدهد
پس شرکت حس نمیکند که استانداردهای سخت لازم است.
خیلی جاها برنامهنویسی به شکل feature factory انجام میشود:
فیچر بگیر
سریع بنویس
تحویل بده
نه طراحی سیستم، نه تست درست، نه ریفکتور جدی.
شرکتهای خیلی قوی تکنولوژی از جمله گوگل،آمازون، استرایپ، نت فلیکس و ... دقیقاً برعکس عمل میکنند. در این شرکتها:
کد ریویو جدی است
تست زیاد است
معماری اهمیت دارد
چون فهمیدهاند کد تمیز سرعت بلندمدت تیم را چند برابر میکند.
