بدهی فنی فقط بهانه ای است

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

ما باید استفاده از اصطلاح “بدهی فنی” را بهانه کنیم.

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

این تصمیم معمولاً برای سرعت بخشیدن به مسائل ، با این درک که تیم توسعه به عقب برگردد و موارد “را برطرف کند” بعداً گرفته می شود – از این رو مفهوم “بدهی بدهی”. می توان استدلال کرد که این بدهی فنی نیست ، مگر اینکه شما بلیط JIRA را در پس زمینه داشته باشید تا بتوانید کد عمدی بد را برطرف کنید.

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

Undebt فنی

اصطلاح “بدهی فنی” معنای خود را از دست داده است. اکنون ، ما از این اصطلاح استفاده می کنیم تا به معنای “تمام کد افتضاح ما در سیستم خود باشد که می دانیم هرگز برنگردیم و اصلاح نخواهیم کرد زیرا تغییر بسیار پرهزینه و بسیار خطرناک است.” 

تمام این کد Crappy دارای سه اصل است:

1. بدهی فنی : این کدی است که شما می دانید فرعی است ، اما تصمیم گرفتید به دلایل خوبی بنویسید ، و برنامه ای برای تصحیح دارید. بیایید با آن روبرو شویم – به سختی هر کد در آنجا متناسب با این توضیحات است. چند تیم توسعه در واقع برنامه ای برای پرداخت بدهی فنی دارند؟ خیلی زیاد نیست
2. پیچیدگی تصادفی : فرد بروکس این اصطلاح را ابداع کرد ، که کدی را کاملاً توصیف می کند که درست نیست و نتیجه آن از سهل انگاری یا مهارت های کد نویسی بد نیست ، بلکه به این دلیل که هیچ کس سیستم را درک نکرده و تصمیمات بدی گرفته است. شاید تیم چارچوبی را انتخاب کند که برای کار مورد نظر بسیار سنگین باشد. شاید این تیم انتزاع های غیر ضروری ایجاد کند یا یک ویژگی را به روشی اضافه کند که با سیستم مطابقت نداشته باشد. متأسفانه ، این نوع چیزی است که پس از واقعیت به خوبی ظاهر نمی شود.
3. فقط کد بد : بیشتر آنچه که بدهی فنی خوانده می شود ، فقط کدهای با عجله ، سیلی زده یا “اضطراری” است که هرگز مورد بررسی قرار نگرفته است ، یا به دلیل “کار” و مشتری فریاد می زد. AIDS برای دریل های آتش نشانی مشتری ، رفع اشکال مهم که در آخر هفته بررسی شده است ، یا مصنوعات توسعه دهندگان که بدون وقت ، وضوح یا پشتیبانی کافی کار می کنند.

یک برچسب زیبا

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

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

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

هر چیز دیگری؟ این بدهی فنی نیست. این کد ساده کد قدیمی است.