Nghiệp xấu trong lập trình. Nợ kỹ thuật là gì và cách khắc phục

Nợ kỹ thuật. Hầu hết các lập trình viên đang làm việc tích cực trong chuyên ngành của họ đều phải đối mặt với thuật ngữ này. Đối với nhiều người, việc đề cập đến nó thậm chí có thể gây đau đầu cũng như cảm giác khó chịu ở các bộ phận khác trên cơ thể xuất hiện bất cứ khi nào bạn giải quyết nợ kỹ thuật khi thực hiện một dự án. Do đó, hôm nay chúng ta sẽ nói về nợ kỹ thuật (TD): nó là gì, nó xuất hiện như thế nào, có những loại nợ kỹ thuật nào và cách quản lý nó một cách hiệu quả.

Nợ kỹ thuật là gì?

Tuy nhiên, trước tiên hãy hiểu thuật ngữ. Nợ kỹ thuật là một phép ẩn dụ về kỹ thuật phần mềm cho các vấn đề tích lũy trong mã hoặc kiến ​​trúc phần mềm do bỏ qua chất lượng trong quá trình phát triển phần mềm và gây ra chi phí lao động bổ sung trong tương lai. Đây là định nghĩa về nợ kỹ thuật do Wikipedia đưa ra . Nói một cách đơn giản, nợ kỹ thuật là kết quả của việc áp dụng các giải pháp đơn giản và ngắn hạn trong quá trình phát triển, sau này dẫn đến chi phí tiền bạc và thời gian cho quá trình sàng lọc tiếp theo ngày càng tăng (tất nhiên trừ khi khoản nợ được “hoàn trả”). viết lại mã hoặc duy trì sản phẩm ở dạng hiện có. Trong thế giới của những lập trình viên bình thường, nợ kỹ thuật là một trong những loại nghiệp tiêu cực, một yếu tố làm mất động lực và là nguồn gốc của nỗi buồn đến từ quả báo cho mã xấu, việc sử dụng nạng và các giải pháp “tạm thời” (nhưng thực tế là không nhiều) mà giúp giải quyết các vấn đề ngắn hạn và tăng tốc độ phát triển “dựa trên tín dụng”, nghĩa là phải trả giá bằng một loạt vấn đề ngày càng gia tăng trong tương lai. Trong ngành CNTT, nợ kỹ thuật là một vấn đề khá nghiêm trọng. Theo một nghiên cứu gần đây , các công ty trên thế giới hàng năm chi hơn 85 tỷ USD chỉ để sửa mã xấu. Tổng cộng, khoảng 300 tỷ USD mỗi năm được chi cho các dự án liên quan đến hỗ trợ các hệ thống lỗi thời và phần mềm “xấu”. Đây là những con số đáng kể. Các nhà nghiên cứu ước tính rằng nếu nỗ lực của tất cả các nhà phát triển đang xử lý nợ kỹ thuật và hậu quả của nó được tập trung lại vào sự phát triển “đúng đắn”, thì GDP toàn cầu sẽ tăng thêm khoảng 3 nghìn tỷ USD trong suốt thập kỷ hiện tại.

Lý do xuất hiện

Cần hiểu rằng nợ kỹ thuật không phải lúc nào cũng là điều xấu, cũng như việc mắc nợ tài chính có thể là tích cực nếu, chẳng hạn, bạn vay tiền để phát triển kinh doanh (hoặc khởi nghiệp ). Trong trường hợp của TD, điều này có thể chấp nhận được đối với các công ty đang phát triển nhanh chóng cần tung ra sản phẩm hoặc dịch vụ mới một cách nhanh chóng và thường xuyên để đánh giá thành công của họ và nghiên cứu nhu cầu thị trường hoặc nhanh chóng nắm bắt các thị trường ngách mới chẳng hạn. Tuy nhiên, cũng như nợ tài chính, bạn cần cẩn thận với nợ kỹ thuật và biết cách quản lý nó, nếu không những vấn đề nghiêm trọng có thể phát sinh. Càng tích lũy nhiều nợ kỹ thuật trong quá trình phát triển một sản phẩm phần mềm thì nó càng có thể ảnh hưởng đến công ty, làm chậm việc phát hành các bản phát hành mới, làm giảm tinh thần của những lập trình viên bình thường, những người chịu trách nhiệm “duy trì” khoản nợ đó và tăng chi phí. , mà cuối cùng thậm chí có thể phá hủy công ty . Nguyên nhân dẫn đến nợ kỹ thuật, ngoài mong muốn cao cả là hoàn thành sản phẩm càng sớm càng tốt hoặc làm hài lòng người dùng bằng bản phát hành mới, thường là do quản lý sản phẩm kém, thời hạn không thực tế hoặc hạn chế về nguồn lực, và tất nhiên là sự lười biếng của lập trình viên. Cùng với trình độ chuyên môn thấp và sự thiếu hiểu biết về các nguyên tắc phát triển quan trọng cũng thường góp phần làm tăng nợ. Điều thường xảy ra là bản thân các nhà phát triển nhận thức rõ về sự hiện diện và tăng trưởng liên tục của nợ kỹ thuật, nhưng không có đủ quyền lực để thay đổi nó hoặc không thể truyền đạt thông tin cho ban quản lý về sự tồn tại của vấn đề đó và tầm quan trọng của việc giải quyết nó.

Phân loại

Như đã đề cập ở trên, nợ kỹ thuật có nhiều dạng khác nhau và vì bản thân định nghĩa chỉ là một phép ẩn dụ nên các loại nợ kỹ thuật khác nhau có thể được phân loại theo nhiều cách khác nhau. Đặc biệt, Dag Liodden, đồng sáng lập và CTO của Tapad, người được coi là một trong những chuyên gia thế giới về nợ kỹ thuật, trong bài phát biểu tại sự kiện CTO Summit thường niên, đã đề xuất chia nợ kỹ thuật thành ba loại chính.

1. Nợ kỹ thuật có chủ ý.

   Nó xuất hiện trong trường hợp các nhà phát triển cố tình chọn không phải giải pháp tốt nhất, vì nó thực hiện dễ dàng hơn và nhanh hơn, do đó sẽ giúp nhanh chóng tung ra thị trường một sản phẩm mới.

   “Đôi khi chúng tôi cố tình gánh nợ kỹ thuật để giảm thời gian phát triển. Nếu bạn quyết định đi theo con đường này, hãy cân nhắc không chỉ thời gian bạn sẽ tiết kiệm được trong quá trình phát triển mà còn cả thời gian bạn sẽ phải bỏ ra sau này để “trả hết” khoản nợ đó. Ngoài ra, hãy đảm bảo rằng các bên liên quan [quản lý cấp cao của công ty] biết rằng quyết định như vậy chắc chắn sẽ làm chậm quá trình triển khai các chức năng khác trong tương lai,” Dag Ljodden nói.

   Một cách tiếp cận để giải quyết loại nợ kỹ thuật này

   Chuyên gia khuyên nên ghi chép cẩn thận những trường hợp như vậy để quay lại và sửa chúng trước khi khoản nợ kỹ thuật này bị mất, trở thành một phần không thể thiếu trong cấu trúc dự án.

2. Nợ kỹ thuật vô tình hoặc phát sinh từ kiến ​​trúc dự án lỗi thời.

   Ngoài ra, nợ kỹ thuật thường phát sinh theo thời gian, do sai sót, thiếu sót ở giai đoạn tạo kiến ​​trúc dự án. Khi hệ thống phát triển và yêu cầu phần mềm thay đổi, lỗi thiết kế trở nên rõ ràng hơn và việc bổ sung các tính năng mới đòi hỏi nhiều thời gian và công sức hơn. Chất lượng của kiến ​​​​trúc dự án ban đầu đóng một vai trò quan trọng ở đây - nó phải vừa đơn giản vừa tiện dụng, khi đó sẽ dễ dàng thích ứng hơn với những thay đổi.

   Một cách tiếp cận để giải quyết loại nợ kỹ thuật này

   Để ngăn loại nợ kỹ thuật này tích lũy và không vượt quá mức tới hạn, Dag Llodden khuyến nghị tái cấu trúc thường xuyên - khoảng hai năm một lần, trong khoảng thời gian hệ thống ở trạng thái ổn định. Trưởng nhóm và quản lý sản phẩm phải phân bổ thời gian để “thanh toán” loại nợ kỹ thuật phát sinh do kiến ​​trúc và các yêu cầu thay đổi thường xuyên của dự án.

3. Nợ kỹ thuật phát sinh theo thời gian.

   Chuyên gia này gọi khoản nợ kỹ thuật như vậy là “mục nát lâu dài”. Nó tích lũy theo thời gian khi một thành phần hoặc hệ thống dần trở nên phức tạp hơn do có nhiều thay đổi liên tục được bổ sung. Điều này thường trở nên trầm trọng hơn nếu những người khác nhau làm việc trên hệ thống ở các giai đoạn khác nhau và không hiểu đầy đủ về kiến ​​trúc ban đầu.

   Một cách tiếp cận để giải quyết loại nợ kỹ thuật này

   Chuyên gia cho biết đây là một trong ba loại nợ kỹ thuật mà bạn nên cố gắng tránh thường xuyên thông qua việc tái cấu trúc thường xuyên. Lý tưởng nhất là nhóm phát triển nên dành thời gian để hiểu kỹ kiến ​​trúc của hệ thống mà họ đang làm việc, ngay cả khi nó ban đầu được tạo ra bởi người khác. Hiểu hệ thống sẽ cho phép bạn dần dần cải thiện và sửa mã xấu mà không đưa dự án đến giai đoạn “ mục nát”.

Giải pháp quản lý nợ kỹ thuật

Có nhiều lựa chọn để quản lý hiệu quả nợ kỹ thuật, nhưng tất cả các chuyên gia đều đồng ý rằng điều này phải được thực hiện vì nợ kỹ thuật là một phần không thể thiếu trong hầu hết mọi hoạt động phát triển và những công ty bỏ qua nó luôn phải đối mặt với các vấn đề ở giai đoạn sau. Dưới đây là một số giải pháp và cách tiếp cận hiệu quả để quản lý nợ kỹ thuật cho nhóm phát triển.

1. Phân bổ một tỷ lệ phần trăm cố định thời gian làm việc của bạn để xử lý nợ kỹ thuật.

   Vấn đề về nợ kỹ thuật là không bao giờ có thời gian để loại bỏ nó (vì luôn có những nhiệm vụ có mức độ ưu tiên cao hơn) trừ khi bạn thực hiện nó một cách có mục đích. Vì vậy, một giải pháp tốt là phân bổ một tỷ lệ phần trăm thời gian làm việc cố định nhất định cho những mục đích này - khoảng 20-25%.

   Điều này có thể được thực hiện theo những cách khác nhau.

2. Làm việc về nợ kỹ thuật 1 ngày một tuần

   Если выделять на работу над устранением ТД всей командой один день в неделю, это How раз будет около 20% от общего рабочего времени. Для некоторых команд такой подход работает просто отлично и, говорят, даже повышает мораль, ведь в этот конкретный день недели вся команда занимается решением проблем, которые достают их все остальное время разработки.

3. Посвящать работе над ТД каждую четвертую задачу

   Такая система подходит тем командам, которые склонны разделять работу над проектом на примерно равномерные по времени и усorям для их выполнения задачи. Если один из каждых четырех тасков посвящать “выплате” ТД, это будет занимать около четверти всего времени разработки. А введение такого подхода в качестве правила позволит убедиться, что codeеры не будут откладывать технический долг “на потом”.

4. Переходящая роль

   Еще одним подходом к проблеме устранения технического долга будет назначать на данную задачу разных членов команды поочередно, чтобы равномерно распределить эту порой далеко не самую приятную работу среди членов коллектива. Количество разработчиков, назначенных заниматься “разгребанием” ТД, может быть разным — для команды из 4-5 человек будет достаточно одного, тогда How коллективы побольше могут назначать двух-трех. Но суть остается прежней — на работу над ТД должно уходить около 20-25% всех ресурсов и человеко-часов.

5. Правило бойскаутов.

   Правило бойскаутов состоит в том, чтобы всегда оставлять туристический лагерь (стоянку для палаток) в лучшем состоянии, чем он был до их прихода, то есть убирать даже тот мусор, который был оставлен не ими. Этот принцип, How выяснor заокеанские codeеры, отлично подходит и для управления техническим долгом. Согласно данному правилу, все члены команды должны заниматься исправлением ТД каждый раз, когда сталкиваются с ним в том or ином виде. Конечно, это правило нужно применять разумно, чтобы время, которое уходит на исправление ТД, не превышало “разумные” 25-30% от общих временных ресурсов.

6. Приоритизация “дорогого” технического долга

   Также эксперты в массе своей рекомендуют не забывать о том, что технический долг может различаться в том числе и по важности. Далеко не каждый тип ТД требует немедленного устранения, поэтому важно работать над классификацией разных видов технического долга и приоритезацией работы с ними соответственно. Проще говоря, прежде всего закрывать надо те долги, которые оказывают прямое влияние на speed разработки продукта, будучи частью его базовой архитектуры. Такие долги являются самыми опасными, потому что ведут к появлению новых долгов, которые могут расти How снежный ком.

Заключение

Cuối cùng, tôi muốn nhấn mạnh một lần nữa rằng không thể thiếu nợ kỹ thuật trong quá trình phát triển phần mềm, bởi vì chúng là một phần không thể thiếu của quá trình phát triển. Tuy nhiên, dù mang tính chất kỹ thuật nhưng TD vẫn là vấn đề do yếu tố con người trong phát triển gây ra. Và mặc dù bạn sẽ không thể làm gì nếu không có nó hoàn toàn, nhưng số nợ kỹ thuật có thể giảm đi nhiều nhất có thể nếu bạn viết mã “sạch” và tiếp cận quá trình phát triển một cách có trách nhiệm và chuyên nghiệp nhất có thể. Đây là điều chúng tôi mong muốn cho mọi người!