Tính toán nợ công nghệ: Dựa trên tốc độ Vs. Dựa trên vấn đề Vs. Giải thích các phép đo dựa trên chất lượng

Lãi suất tăng 157%!

Không, tôi không nói về quyết định mới nhất của Fed mà nói về sự chậm lại mà Fictional Inc. phải đối mặt sau khi phát hành phiên bản 3.0 của nền tảng của họ.

May mắn thay cho họ, việc phát hành sản phẩm đã thành công ngoài sức tưởng tượng và họ bắt đầu thấy doanh thu tăng nhanh, nhưng bây giờ họ cần suy nghĩ về cách họ sẽ giải quyết khoản nợ kỹ thuật mà họ đã giới thiệu như một phần của việc phát hành.

Khoản nợ công nghệ mới được giới thiệu như một phần của bản phát hành mới có thể được coi là làm tăng lãi suất và làm tăng sự chậm lại mà nhóm phải đối mặt trong tương lai.

(Tôi cho rằng bạn khá quen thuộc với khái niệm nợ kỹ thuật ở đây, nhưng nếu bạn cần ôn lại để bắt kịp tốc độ thì đây là một lót )

Được rồi, có lẽ bạn sẽ không nghe một giám đốc kỹ thuật nói như thế này về khoản nợ kỹ thuật của họ.

Nhưng tại sao không?

Có thể đo lường và định lượng tác động liên tục của nợ công nghệ là rất quan trọng nếu bạn muốn tập hợp một kế hoạch khả thi để giải quyết nó.

Khi chúng ta nghĩ về nợ kỹ thuật, tiền lãi là khoảng thời gian bị mất cho sự phát triển hiện tại và tương lai đối với mức nợ kỹ thuật hiện tại của bạn.

Điều này có nghĩa là đó là phần quan trọng của khoản nợ cần xem xét khi nghĩ về các quyết định trong tương lai để trả lại tiền gốc (chi phí viết lại, tái cấu trúc hoặc sửa mã chịu trách nhiệm về khoản nợ) - vì chúng tôi sẽ chỉ xem xét nó nếu tiền lãi là đủ cao.

Mức nợ kỹ thuật lành mạnh là gì?

Nợ kỹ thuật rõ ràng làm chậm quá trình phát triển mới - nhưng điều đó tự nó không có nghĩa là chúng ta nên giải quyết nợ công nghệ ở mọi nơi. Quay trở lại để viết lại hoặc cấu trúc lại mã hiện có có thể tốn kém đáng kể - vì vậy chúng tôi chỉ muốn trả lại tiền gốc cho khoản nợ kỹ thuật của mình nếu tiền lãi của chúng tôi (số tiền khiến chúng tôi chậm lại trong tương lai) vượt quá tiền gốc của chúng tôi.

Một vấn đề rõ ràng ngay lập tức xuất hiện - tiền gốc là một đơn vị thời gian cố định (giờ để sửa/viết lại) nhưng tiền lãi là tỷ lệ số giờ bị mất mỗi lần. Để giải thích cho điều này, chúng tôi cần đưa ra ý tưởng về khoảng thời gian tác động - khoảng thời gian mà chúng tôi quan tâm đến việc liệu sự chậm lại trong tương lai do nợ kỹ thuật có vượt quá chi phí viết lại hay không. Khoảng thời gian tác động mà bạn quan tâm sẽ phụ thuộc nhiều vào công ty của bạn, quy trình lập kế hoạch điển hình của bạn và giai đoạn của nó hoặc vòng đời của cơ sở mã của bạn - nhưng cá nhân tôi thường xem xét khoảng thời gian tác động là 3 tháng. Ở giai đoạn đầu của chúng tôi với tư cách là một công ty, việc xem xét mọi thứ trong khoảng thời gian dài cả năm + là quá rộng, nhưng bất cứ thứ gì ngắn hơn 2–3 tháng sẽ đánh giá thấp tác động của nợ kỹ thuật như chúng ta sẽ thấy sau.

Điều này có nghĩa là mức nợ công nghệ của chúng ta không đáng để giải quyết nếu:

Ví dụ: nếu chúng tôi có một dự án nhỏ mà chúng tôi biết có khoản nợ công nghệ khiến chúng tôi chậm lại 2 giờ/tuần, chúng tôi sẽ mất 4 ngày để tái cấu trúc khoản nợ đó và quan tâm đến khoảng thời gian tác động 3 tháng thì chúng tôi sẽ không dành thời gian để trả hết món nợ đó.

Bây giờ, điều này không thực sự trả lời mức độ lành mạnh của nợ kỹ thuật - bởi vì tôi nghĩ rằng tất cả chúng ta có thể đồng ý rằng việc đối mặt với sự chậm lại lớn trong nhóm là không lành mạnh. Thay vào đó, giờ đây chúng ta có một cách nhanh chóng để xác định khi nào nên hoặc không nên tập trung vào việc viết lại và tái cấu trúc. Chúng ta sẽ xem xét mức nợ lành mạnh thực sự là bao nhiêu ở phần sau của bài báo.

Làm thế nào để chúng tôi đo lường nợ kỹ thuật?

Việc xác định lãi suất nợ công nghệ của chúng tôi yêu cầu chúng tôi tìm hiểu xem chúng tôi đang bị chậm lại bao nhiêu bởi các quyết định khác nhau mà chúng tôi đã đưa ra. Thật không may, không có cách nào rõ ràng hoặc đơn giản để theo dõi mức độ phát triển của bạn bị chậm lại - nhưng có ba cách tiếp cận khác nhau mà bạn có thể thực hiện để có được ước tính tốt.

Đo lường dựa trên vận tốc

Cách trực tiếp nhất để liên kết sự chậm lại với các phần khác nhau trong cơ sở mã của chúng tôi là xem tốc độ thay đổi như thế nào theo thời gian, qua các phần khác nhau trong dự án của bạn. Nhìn qua các khu vực khác nhau của cơ sở mã, bạn có thể bắt đầu xác định các biến thể (ví dụ: bất kỳ sự phát triển nào chạm vào phần phân tích này đều mất thời gian gấp 3 lần so với bất kỳ điều gì khác) trên các phần khác nhau. Việc xem xét sự thay đổi của một khu vực theo thời gian cũng có thể cho bạn một số dấu hiệu về mức độ ảnh hưởng của sự phát triển mới đến tốc độ phát triển trong tương lai và đưa ra dấu hiệu về mức độ quan tâm mà nhóm của bạn đang giải quyết.

Ví dụ: Nếu chúng tôi có một dự án tương đối đơn giản với 4 lĩnh vực khác nhau mà chúng tôi sẽ làm việc thì chúng tôi có thể xem tốc độ thay đổi như thế nào theo thời gian (ở đây chúng tôi đang theo dõi tốc độ theo điểm câu chuyện/tháng của nhà phát triển).

Đo lường tác động của nợ kỹ thuật dựa trên tốc độ

Từ đây, chúng ta có thể thấy rằng D luôn mất ~3 lần thời gian để hoạt động so với bất kỳ lĩnh vực nào khác đối với các nhiệm vụ phức tạp tương tự. Điều này ngụ ý rằng nó có mức độ quan tâm gấp 3 lần so với tất cả các phần khác của cơ sở mã. B từng tương đối ngang bằng với A & C, nhưng bắt đầu từ tháng thứ 4, nó đột ngột tăng vọt lên gấp đôi thời gian. Điều này cho thấy rằng chúng tôi đã giới thiệu một số khoản nợ ở đây làm tăng gấp đôi lãi suất của chúng tôi so với trước đây đối với B.

Một điều cần lưu ý là chúng tôi không nói về lãi suất cho toàn bộ cơ sở mã, mà thay vào đó là lãi suất cho các thành phần/khu vực riêng lẻ - đó là bởi vì sự chậm lại do nợ kỹ thuật tăng lên thường không phải là vấn đề mà ảnh hưởng đến mọi thứ chúng tôi làm, thay vào đó chúng được bản địa hóa thành một phần của cơ sở mã.

Có một số lưu ý quan trọng cần suy nghĩ khi nói đến phép đo dựa trên vận tốc.

• Vận tốc có thể không ổn định và có thể phụ thuộc vào các yếu tố độc lập với nợ kỹ thuật như lỗi mới (hoặc hiện có), ước tính sai, rào cản kỹ thuật hoặc sự chậm trễ của dự án bên ngoài.

• Các ước tính có một mức độ không chắc chắn vốn có và có thể là một phép đo không chính xác ngay từ đầu.

• Thu thập và phân tích dữ liệu này có thể phức tạp và tốn thời gian.

  
  

Một cách nhanh chóng để đo lường dựa trên vận tốc là yêu cầu nhóm kỹ thuật của bạn ước tính tương đối thời gian cần thiết để hoàn thành một dự án/nhiệm vụ trong từng lĩnh vực chính của cơ sở mã của bạn. Đồng ý về một số đường cơ sở đã thiết lập cho một khu vực được hiểu rõ/được sử dụng thường xuyên và sau đó yêu cầu mọi người ước tính khu vực của nhau theo tỷ lệ phần trăm hoặc bội số của đường cơ sở đó. Mặc dù không hoàn toàn nghiêm ngặt như phương pháp đo lường dựa trên vận tốc đầy đủ, nhưng nó có thể đưa ra ý tưởng nhanh về lãi suất nợ công nghệ tương đối của bạn dựa trên hiểu biết sâu sắc và trực giác của nhóm bạn.

Đo lường dựa trên vấn đề

Một cách tiếp cận khác là xác định các trường hợp nợ kỹ thuật cụ thể trong dự án của bạn và ước tính mức độ mà chúng có thể làm bạn chậm lại. Một phần của điều này có thể được thực hiện bằng cách sử dụng các công cụ tự động, chẳng hạn như công cụ phân tích tĩnh, để tìm các vấn đề phổ biến xung quanh chất lượng mã có thể ảnh hưởng đến khả năng đọc, khả năng mở rộng hoặc khả năng bảo trì của dự án. Đối với mỗi loại vấn đề, bạn có thể chỉ định chi phí lãi vay (ví dụ: 5 phút/tuần hoặc 1%) dựa trên kinh nghiệm của nhóm bạn trong việc xử lý các loại vấn đề này.

Tuy nhiên, điều này sẽ chỉ nắm bắt được một tập hợp con lỗi kỹ thuật gây ra sự cố - những vấn đề khác sẽ phức tạp hơn hoặc phù hợp hơn với cơ sở mã của bạn và sẽ chỉ được quan sát thấy khi nhóm của bạn đang tích cực làm việc trên vùng mã đó. Trong trường hợp này, bạn sẽ muốn ghi lại vấn đề cụ thể (gắn liền với một khu vực trong cơ sở mã của bạn) cùng với tác động ước tính của nó trong việc làm chậm quá trình phát triển. Để theo dõi những vấn đề này, chúng tôi khuyên bạn nên sử dụng một số loại trình theo dõi vấn đề - trong hồ sơ tồn đọng vấn đề trong GitHub, Jira, v.v. hoặc sử dụng trình theo dõi vấn đề nợ công nghệ được xây dựng có mục đích như Cỡ bước chân .

Một số nhược điểm của phương pháp này là:

• Ước tính thời gian gắn liền với các vấn đề cụ thể có thể không chính xác
• Một số vấn đề có thể dễ dàng không bị phát hiện trong một thời gian dài

Đo lường dựa trên chất lượng

Có nhiều chỉ số chất lượng mã mà bạn có thể sử dụng để hiểu tổng thể về trạng thái của cơ sở mã của mình và do đó, ước tính mức độ nợ kỹ thuật mà bạn hiện có ảnh hưởng đến sự phát triển trong tương lai ở từng khu vực. Tại Sourcery, chúng tôi có xu hướng xem xét phức tạp , Bộ nhớ làm việc và Độ dài phương thức là số liệu quan trọng khi tìm kiếm trong một chức năng hoặc lớp - nhưng bạn cũng có thể xem xét những thứ như Chỉ số khả năng bảo trì, Phạm vi tài liệu & kiểm tra, Tỷ lệ sao chép, v.v.

Tương tự như cách tiếp cận dựa trên Vấn đề, bạn có thể chỉ định tác động tương đối của các điểm số khác nhau (hoặc của điểm chất lượng hoặc sức khỏe tổng thể) đối với tình trạng chậm phát triển đang diễn ra và trong tương lai do nợ kỹ thuật. Nghiên cứu đã chỉ ra mối tương quan tiêu cực mạnh mẽ giữa những thứ như Độ phức tạp & Vận tốc cũng như với chất lượng mã và rủi ro lỗi, tải bảo trì, v.v.

Xem xét một ví dụ - hãy xem lại cơ sở mã gồm 4 phần đơn giản mà chúng ta đã xem xét trong phần Đo lường dựa trên vận tốc.

Chúng ta có thể dễ dàng nhìn thấy các phần vấn đề của dự án này trong bảng (được đánh dấu màu đỏ) và việc tính toán Ước tính lãi suất tương đối đơn giản - chỉ cần tổng hợp các tác động lãi suất của các thành phần khác nhau.

Một số nhược điểm của phương pháp này là:

• Bạn cần xác định ước tính tác động Sở thích trên các số liệu chất lượng khác nhau (Tôi đang tìm cách kết hợp một số số liệu lại với nhau làm cơ sở, nhưng nó sẽ phụ thuộc khá nhiều vào cơ sở mã). Để làm điều này, có lẽ bạn sẽ muốn xem xét một số phép đo dựa trên vận tốc và gắn kết đó với chất lượng.
• Bản thân các thước đo chất lượng là không hoàn hảo và có thể thay đổi đáng kể từ ngôn ngữ này sang ngôn ngữ khác .

Phương pháp đo lường dựa trên chất lượng này là phương pháp ít chính xác nhất trong số ba phương pháp mà chúng tôi đã xem xét - nhưng nó rất hiệu quả trong việc đưa ra cái nhìn tổng thể về các lĩnh vực khác nhau trong dự án của bạn theo thời gian. Bạn có thể kết hợp cách tiếp cận này với cách tiếp cận dựa trên vấn đề mà chúng ta vừa thảo luận để cân bằng việc theo dõi các vấn đề cụ thể cùng với việc theo dõi các vấn đề về chất lượng và tình trạng chung trong từng phần của dự án của bạn.

Nhìn vào tần suất tương tác Codebase

Đối với cả ba cách tiếp cận này, chúng tôi cần có một cách để ánh xạ tác động trong các phần khác nhau của cơ sở mã dựa trên tần suất mà chúng tôi thực sự chạm vào phần đó của cơ sở mã. Nếu có một phần trong dự án của chúng tôi là một cơn ác mộng phải giải quyết nhưng không ai chạm vào nữa thì nó không thực sự ảnh hưởng nặng nề đến khoản nợ kỹ thuật đang diễn ra của chúng tôi. Ngược lại, một sự chậm lại nhỏ nhưng liên tục trên một phần của cơ sở mã được đóng góp hàng ngày có thể dẫn đến tổn thất thời gian rất lớn rất nhanh.

Để giải thích cho điều này, chúng ta sẽ cần xem xét tần suất đóng góp của từng lĩnh vực trong dự án của chúng ta. Có một vài cách tiếp cận khác nhau mà chúng ta có thể thực hiện ở đây - xem xét lịch sử Git để hiểu khu vực nào được sử dụng rộng rãi nhất, sử dụng công cụ tập trung hơn như mật mã để có được dữ liệu lịch sử đóng góp dễ hiểu hơn hoặc sử dụng cách tiếp cận hướng tới tương lai bằng cách xem xét các kế hoạch và ưu tiên sắp tới của chúng tôi để hiểu nhóm của chúng tôi sẽ dành phần lớn thời gian của họ vào đâu trong vài tháng tới.

Bất kể chúng tôi lấy dữ liệu bằng cách nào - sau đó chúng tôi có thể phân tích tỷ lệ phần trăm thời gian chúng tôi sẽ dành để tương tác với từng phần trong cơ sở mã của mình. Kết hợp điều này cùng với đóng góp Lãi suất mà chúng tôi đã xác định, giờ đây chúng tôi có thể thấy chính xác mức độ mà chúng tôi mong đợi sẽ bị chậm lại khi xử lý từng phần trong cơ sở mã của chúng tôi trong tương lai.

Tiếp tục với ví dụ của chúng tôi từ trước đó - nếu chúng tôi có quan điểm hướng tới tương lai và làm mới tất cả các dự án mà chúng tôi sẽ thực hiện trong 3 tháng tới và có thể tự tin ước tính rằng đây là lượng thời gian dành cho từng khu vực của cơ sở mã ( hãy nhớ rằng đây là một dự án rất đơn giản):

Giờ đây, chúng tôi có thể liên kết điều đó lại với các ước tính Sở thích mà chúng tôi có được từ phương pháp Dựa trên tốc độ và phương pháp Dựa trên số liệu chất lượng của chúng tôi và biết rõ nơi chúng tôi đang bị chậm lại nhiều nhất.

Ở đây, chúng tôi đang sử dụng sự chậm lại về vận tốc mà chúng tôi đã thấy cho công việc trên các phần B & C từ khi chúng tôi xem xét phép đo dựa trên vận tốc trước đó và đang sử dụng điều đó để tính toán lượng thời gian đã mất mà chúng tôi mong đợi do nợ công nghệ trong ba tháng tới. Nhìn chung, chúng tôi hy vọng sẽ thấy nỗ lực đáng giá hơn 28 tháng của nhà phát triển chỉ được chi trả cho khoản nợ. Một điều quan trọng cần xem xét từ cách tiếp cận này là tất cả những điều này đang xem xét tốc độ tương đối - vì vậy các dự án cơ bản được coi là không có nợ, điều này thường không chính xác. Một vấn đề khác với cách tiếp cận này là nó không tính đến sự khác biệt về mức nợ trong tương lai - điều có thể xảy ra. Nhưng chúng rất khó dự đoán, vì vậy sẽ dễ dàng bỏ qua chúng hơn.

Ở đây, chúng tôi đã thực hiện các độ trễ dự kiến điển hình dựa trên chất lượng mã của từng phần và dự kiến điều đó trong ba tháng tới. Nhìn chung, chúng tôi thấy các dự báo về tác động của nợ thấp hơn đáng kể so với khi chúng tôi sử dụng phương pháp vận tốc. Điều này là do các ước tính về sự chậm lại dựa trên nợ công nghệ thấp hơn so với những gì chúng ta đã thấy trong trường hợp vận tốc - chúng ta có thể cần phải hiệu chỉnh thêm trong trường hợp này! Giống như với số liệu dựa trên vận tốc, điều này không tính đến những thay đổi trong tương lai của nợ công nghệ - nhưng cả hai ước tính có thể giúp chúng tôi xác định cách chúng tôi nên ưu tiên viết lại và tái cấu trúc các phần khác nhau trong dự án của mình.

Quản lý lãi và nợ

Chúng tôi đã xem xét một vài cách khác nhau để giải thích mức độ ảnh hưởng liên tục của khoản nợ kỹ thuật đối với chúng tôi, nhưng chúng tôi chưa trả lời đầy đủ câu hỏi về mức độ hợp lý của khoản nợ kỹ thuật.

Thật không may, thực sự không có một con số chính xác. Trong ngắn hạn, chấp nhận một số khoản nợ có thể là thực dụng. Tuy nhiên, về lâu dài, chúng tôi sẽ muốn đặt mục tiêu giữ cho khoản nợ của mình gần bằng không. Bởi vì lãi suất kéo dài sẽ rất tốn kém và nợ công nghệ tiếp tục tích tụ. Tuy nhiên, chúng tôi không muốn dành toàn bộ thời gian để tái cấu trúc và viết lại các vấn đề chỉ mang lại cho chúng tôi những lợi ích nhỏ.

Như đã thảo luận trước đó, chúng tôi thường không muốn dành thời gian giải quyết các khu vực của cơ sở mã nơi:

Tuy nhiên, trong trường hợp cực đoan này, chúng ta có thể kết thúc với một trường hợp mà chúng ta đang bị chậm lại hàng loạt bởi mức nợ cao mà việc khắc phục là cực kỳ tốn kém - đó cũng không phải là một tình huống tốt.

Cách tiếp cận tốt nhất là rơi vào đâu đó ở giữa. Dành thời gian trong việc lập kế hoạch liên tục của bạn để giải quyết các vấn đề về nợ kỹ thuật và cấu trúc lại mã hiện tại - ưu tiên theo những gì hiện là tốn kém nhất đối với bạn. Và tiếp tục thúc đẩy điều đó cho đến khi bạn thấy lợi nhuận giảm dần đáng kể từ việc giảm nợ của mình.