Có ai biết nếu có một số loại công cụ để đặt một số vào nợ kỹ thuật của một cơ sở mã, như một loại số liệu mã? Nếu không, có ai biết về một thuật toán hoặc tập hợp các heuristic cho nó không?

Nếu cả hai điều đó không tồn tại cho đến nay, tôi sẽ quan tâm đến ý tưởng làm thế nào để bắt đầu với một thứ như vậy. Đó là, làm thế nào tôi có thể định lượng được khoản nợ kỹ thuật phát sinh theo một phương thức, một lớp, một không gian tên, một tổ hợp, v.v.

Tôi quan tâm nhất đến việc phân tích và đánh giá cơ sở mã C #, nhưng xin vui lòng đồng ý với các ngôn ngữ khác, đặc biệt nếu các khái niệm là ngôn ngữ siêu việt.

Nợ kỹ thuật chỉ là một ý tưởng trừu tượng rằng, ở đâu đó dọc theo các dòng thiết kế, xây dựng, thử nghiệm và bảo trì một hệ thống, một số quyết định đã được đưa ra để sản phẩm trở nên khó kiểm tra và bảo trì hơn. Có nhiều nợ kỹ thuật hơn đồng nghĩa với việc tiếp tục phát triển hệ thống sẽ trở nên khó khăn hơn - bạn cần phải đối phó với nợ kỹ thuật và phân bổ ngày càng nhiều thời gian hơn cho những nhiệm vụ đơn giản hoặc bạn cần đầu tư nguồn lực (thời gian và tiền) vào việc giảm nợ kỹ thuật bằng cách tái cấu trúc mã, cải thiện các bài kiểm tra, v.v.

Có một số số liệu có thể cung cấp cho bạn một số dấu hiệu về chất lượng của mã:

• Mã số bảo hiểm. Có nhiều công cụ khác nhau cho bạn biết bao nhiêu phần trăm chức năng, câu lệnh và dòng của bạn được bao phủ bởi các bài kiểm tra đơn vị. Bạn cũng có thể ánh xạ các kiểm tra hệ thống và chấp nhận trở lại các yêu cầu để xác định tỷ lệ phần trăm các yêu cầu được bao phủ bởi một thử nghiệm cấp hệ thống. Phạm vi bảo hiểm phù hợp phụ thuộc vào bản chất của ứng dụng.
• Khớp nối và sự gắn kết . Mã thể hiện khớp nối thấp và độ gắn kết cao thường dễ đọc, dễ hiểu và kiểm tra hơn. Có các công cụ phân tích mã có thể báo cáo số lượng khớp nối và sự gắn kết trong một hệ thống nhất định.
• Độ phức tạp theo chu kỳ là số lượng đường dẫn duy nhất thông qua một ứng dụng. Nó thường được tính ở cấp độ phương thức / chức năng. Độ phức tạp theo chu kỳ có liên quan đến tính dễ hiểu và khả năng kiểm tra của một mô-đun. Không chỉ các giá trị độ phức tạp chu kỳ cao hơn chỉ ra rằng ai đó sẽ gặp nhiều rắc rối hơn khi theo mã, mà độ phức tạp theo chu kỳ cũng chỉ ra số lượng các trường hợp thử nghiệm cần thiết để đạt được phạm vi bảo hiểm.
• Các biện pháp phức tạp khác nhau của Halstead cung cấp cái nhìn sâu sắc về tính dễ đọc của mã. Chúng đếm các toán tử và toán hạng để xác định khối lượng, độ khó và nỗ lực. Thông thường, những điều này có thể cho biết mức độ khó khăn của việc ai đó nhận mã và hiểu mã, thường là trong các trường hợp như xem xét mã hoặc nhà phát triển mới cho cơ sở mã.
• Số lượng mã trùng lặp. Mã trùng lặp có thể chỉ ra tiềm năng tái cấu trúc cho các phương thức. Có mã trùng lặp có nghĩa là có nhiều dòng hơn cho một lỗi được giới thiệu và khả năng cao hơn là các lỗi tương tự tồn tại ở nhiều nơi. Nếu cùng một logic kinh doanh tồn tại ở nhiều nơi, việc cập nhật hệ thống để tính toán các thay đổi sẽ trở nên khó khăn hơn.

Thông thường, các công cụ phân tích tĩnh sẽ có thể cảnh báo bạn về các vấn đề tiềm ẩn. Tất nhiên, chỉ vì một công cụ chỉ ra một vấn đề không có nghĩa là có vấn đề - cần có sự phán đoán của con người để xác định xem có vấn đề gì xảy ra không. Các số liệu này chỉ cung cấp cho bạn các cảnh báo rằng có lẽ đã đến lúc xem xét một hệ thống hoặc mô-đun chặt chẽ hơn.

Tuy nhiên, các thuộc tính này tập trung vào mã. Họ không sẵn sàng chỉ ra bất kỳ khoản nợ kỹ thuật nào trong kiến ​​trúc hoặc thiết kế hệ thống của bạn có thể liên quan đến các thuộc tính chất lượng khác nhau.

Sonar có một khoản nợ kỹ thuật heuristic cũng như một số tính năng khác hữu ích cho một dự án phần mềm.

Nó cũng hỗ trợ một loạt các ngôn ngữ.

SonarQube (trước đây là Sonar ) là một nền tảng nguồn mở để Kiểm tra liên tục chất lượng mã ...

• Hỗ trợ hơn 25 ngôn ngữ: Java, C / C ++, C #, PHP, Flex, Groovy, JavaScript, Python, PL / SQL, COBOL, v.v.
• SonarQube cũng được sử dụng trong Android Deveopment.
• Cung cấp các báo cáo về mã trùng lặp, tiêu chuẩn mã hóa, kiểm tra đơn vị, phạm vi mã, mã phức tạp, lỗi tiềm ẩn, nhận xét và thiết kế và kiến ​​trúc.
• Cỗ máy thời gian và quan điểm khác biệt.
• Phân tích hoàn toàn tự động: tích hợp với Maven, Ant, Gradle và các công cụ tích hợp liên tục (Atlassian Bamboo, Jenkins, Hudson, v.v.).
• Tích hợp với môi trường phát triển Eclipse
• Tích hợp với các công cụ bên ngoài: JIRA, Mantis, LDAP, Fortify, v.v.
• Có thể mở rộng với việc sử dụng các plugin.
• Triển khai phương pháp SQALE để tính nợ kỹ thuật ...

Tôi ghét sử dụng một sự tương tự từ tài chính nhưng nó có vẻ thực sự thích hợp. Khi bạn định giá một thứ gì đó (tài sản thuộc bất kỳ loại nào), nó có thể có cả giá trị bên trong và bên ngoài. Trong trường hợp này, mã hiện tại có giá trị nội tại sẽ là một đại lượng tương ứng với chất lượng tương đối của mã đã nói và nó cũng sẽ có giá trị bên ngoài (giá trị từ những gì có thể được thực hiện đối với mã) và các đại lượng đó sẽ là phụ gia. Giá trị nội tại có thể được chia thành các khoản tín dụng và ghi nợ (tốt so với xấu) bằng bất kỳ phương pháp nào bạn đang sử dụng để chấm điểm mã (+5 cho nhận xét / khả năng đọc, -10 cho phạm vi bảo hiểm mã, v.v.)

Tôi chắc chắn không biết bất kỳ công cụ nào định lượng điều này ngày hôm nay và tôi nghĩ rằng bạn sẽ có một cuộc thảo luận hoàn toàn mới trong tay nếu bạn tranh luận về các chiến lược "định giá nợ" khác nhau nhưng tôi đồng ý với Matthew - khoản nợ là chi phí tích lũy để có được mã tốt nhất có thể có được, sử dụng bất kỳ phương pháp nào bạn sử dụng để tiêu tốn thời gian cần thiết để đạt được điều đó.

Một điều khác cần xem xét là chắc chắn có một thước đo về hiệu quả chi phí, theo đó khi gần hơn với "sự hoàn hảo", giá trị của một giờ dành cho cơ sở mã nhiều hơn có thể giảm theo cấp số nhân nên có thể có một vấn đề tối ưu hóa bổ sung tối đa hóa tiện ích của công việc được thực hiện.

Ở giữa các nhà phát triển, một biện pháp khá đáng tin cậy về nợ kỹ thuật dường như là WTFs / phút .

_{Vấn đề với "số liệu" này là việc giao tiếp "bên ngoài" thường khá khó khăn.}

Số liệu làm việc cho tôi trong việc truyền nợ kỹ thuật cho "người ngoài" là số lượng thử nghiệm và nỗ lực sửa lỗi (đặc biệt là để sửa lỗi hồi quy ) cần thiết để giao hàng thành công.

Một lời cảnh báo: mặc dù cách tiếp cận này khá mạnh mẽ, người ta sẽ kiểm tra kỹ hơn với WTFs cũ / phút trước khi sử dụng nó. Điều quan trọng là, nó khá cồng kềnh: để có được dữ liệu, người ta phải theo dõi cẩn thận thời gian và đăng nhập chính xác theo từng danh mục phù hợp.

• Tổng cộng đã dành 3 tuần để thực hiện tính năng A dễ dàng hơn nhiều so với
   
  tôi đã dành 14 giờ để thực hiện dự thảo tính năng A sau đó 29 giờ để kiểm tra khói sau đó 11 giờ để thực hiện các bản sửa lỗi cho hồi quy tôi đã phát hiện ra, sau đó 18 giờ để kiểm tra QA -được thực hiện tính năng. Sau đó, các chàng trai QA đã dành 17 giờ để thử nghiệm bản phát hành ứng cử viên ban đầu. Sau đó, tôi đã dành 13 giờ để phân tích các lỗi do QA gửi cho bản phát hành ứng cử viên ban đầu và 3 giờ để thực hiện các bản sửa lỗi. Sau đó, tôi đã dành 11 giờ để kiểm tra khói những thay đổi tôi đã thực hiện để phát hành ứng cử viên ban đầu. Sau đó...

Dù sao dữ liệu về thử nghiệm và nỗ lực sửa lỗi đã khá dễ dàng để giao tiếp theo kinh nghiệm của tôi.

Để phát hành gần đây, chúng tôi đã dành khoảng 90% thời gian để thử nghiệm và sửa lỗi hồi quy. Đối với bản phát hành tiếp theo, đề nghị phân bổ một số nỗ lực để giảm giá trị này xuống 60-70%.

Một lời cảnh báo khác. Dữ liệu như 90% ở trên có thể được hiểu không chỉ là một dấu hiệu của nợ kỹ thuật, mà còn (bất ngờ bất ngờ) là dấu hiệu của một người không thành thạo về lập trình / công nghệ cụ thể. "Bạn chỉ tạo ra quá nhiều lỗi trong mã của bạn".

Nếu có nguy cơ dữ liệu bị hiểu sai theo cách đó, sẽ giúp có thêm một dữ liệu tham khảo về một thứ ít WTF dễ so sánh hơn.

• Giả sử nếu có hai thành phần / ứng dụng tương tự được duy trì bởi cùng một nhà phát triển, lần đầu tiên phát hành với "tỷ lệ lãng phí" khoảng 50% và lần thứ hai là 80-90, thì điều này tạo ra một trường hợp khá mạnh đối với vấn đề thứ hai là nợ kỹ thuật.

Nếu có những người kiểm tra chuyên dụng trong dự án, họ cũng có thể đóng góp cho việc đánh giá khách quan hơn về dữ liệu. Như tôi đã đề cập trong một câu trả lời khác ,

Với người kiểm tra, bạn có được ai đó sao lưu sự hiểu biết của bạn về các vấn đề thiết kế. Khi chỉ có các nhà phát triển phàn nàn về chất lượng mã , điều này thường nghe giống như các WTF chủ quan từ phía sau cánh cửa đóng kín .
 
Nhưng khi điều này được lặp lại bởi anh chàng QA nói rằng component Acó 100 lỗi hồi quy cho 10 tính năng mới, trái ngược với component B10 lỗi hồi quy trên 20 tính năng mới , giao tiếp đột nhiên chuyển sang một trò chơi khác.

Tôi nghĩ câu hỏi là chi phí bao nhiêu để "mua lại" khoản nợ kỹ thuật của bạn - nghĩa là, cần bao nhiêu công sức để khắc phục nó? Vâng, tùy thuộc vào đội để tìm ra điều đó.

Trong quá trình lập kế hoạch nước rút, tôi yêu cầu nhóm ước tính mức độ phức tạp của việc sửa các khoản nợ kỹ thuật giống như cách họ ước tính mức độ phức tạp của câu chuyện người dùng. Vào thời điểm đó, đây là một trò chơi đàm phán giữa nhóm chủ sở hữu sản phẩm để xác định khoản nợ kỹ thuật nào có mức độ ưu tiên đủ cao để thực hiện trong giai đoạn nước rút hiện tại (thay thế câu chuyện người dùng thực tế) và điều gì có thể chờ đợi.

Nếu bạn không làm scrum, tôi sẽ dính vào tiền đề của tôi - nợ kỹ thuật nên được đo bằng chi phí của biện pháp khắc phục.

Có một nền tảng khá mạnh ngoài kia gọi là CASTđể tìm kiếm nợ kỹ thuật trong các ứng dụng lớn. Chúng tôi đã sử dụng nó trong một dự án nơi chúng tôi đã tiếp quản một sự cải tiến lớn cho một hệ thống cũ. Nó không cho bạn biết những gì trong đầu người đã viết mã, nhưng nó kiểm tra mã và tìm ra lỗi và mã kiến ​​trúc, sau đó định lượng cho nợ kỹ thuật nếu bạn muốn. Tuy nhiên, việc sử dụng thực sự trong việc xem xét điều này không phải là số tiền $ mà là danh sách các vấn đề đã có trong mã. Điều này cho bạn biết về một phần của khoản nợ kỹ thuật mà bạn có (vì vậy tôi không đồng ý với một số câu trả lời ở trên). Có một số khoản nợ kỹ thuật hoàn toàn dựa trên thiết kế và rất chủ quan - như nội dung khiêu dâm - bạn biết điều đó khi bạn nhìn thấy nó và biết bối cảnh. Tôi sẽ tranh luận liệu đó có thực sự là nợ "kỹ thuật" hay không. Có một số khoản nợ kỹ thuật hoàn toàn trong việc thực hiện và tôi tin rằng '

Đây là một hội thảo trực tuyến của MIT mô tả nghiên cứu về nợ kỹ thuật trong các hệ thống phần mềm lớn: http://sdm.mit.edu/news/news_articles/webinar_050613/sturtevant-webinar-technical-debt.html

Các tác giả đã viết mã để phân tích một dự án và rút ra các số liệu 'độ phức tạp kiến ​​trúc'. Các số liệu này đã được chứng minh là có mối quan hệ chặt chẽ với mật độ khiếm khuyết, năng suất của nhà phát triển và doanh thu của nhân viên phát triển.

Công trình được mô tả trong Hội thảo trên web dựa trên nghiên cứu mô đun được thực hiện bởi Alan MacCormack và Carliss Baldwin tại Trường Kinh doanh Harvard. Tôi sẽ xem xét giấy tờ của họ là tốt. "Chi phí nhân giống" của họ có thể là những gì bạn đang tìm kiếm.

Tôi muốn nói rằng các số liệu mã tiêu chuẩn có thể được sử dụng như một quan điểm tương đối cấp cao về tình trạng mắc nợ kỹ thuật. VS Ultimate bao gồm Trình phân tích mã sẽ cung cấp cho bạn "Chỉ số duy trì" dựa trên độ phức tạp theo chu kỳ, khớp nối, LoC và độ sâu của kế thừa. Bạn có thể đi sâu vào bất kỳ điểm rắc rối nào và xem chi tiết (xuống mức chức năng). Tôi mới chạy nó trong dự án của mình và điểm số thấp nhất chúng tôi đạt được là 69 trên gói Dữ liệu của chúng tôi (định cấu hình và khởi tạo EF) và Test Suite của chúng tôi. Mọi thứ khác là 90 trở lên. Có những công cụ khác sẽ cung cấp cho bạn nhiều số liệu hơn như những công cụ được thảo luận trong PPP của chú Bob

Tôi sẽ không nghĩ về nợ kỹ thuật là đô la khi bạn cần một mô hình ưa thích để định lượng nó. Tôi sẽ nghĩ về nó như ủng hộ. Nếu ai đó làm bạn một việc và bạn có khả năng quên, bạn viết nó ra. Khi bạn cắt ngắn, viết nó xuống. Điều này giúp bạn ghi nhớ, và bất lực hơn buộc bạn phải thừa nhận nó. Không có công cụ ưa thích là cần thiết. Notepad hoặc Ecxel có thể thực hiện các mẹo.

Tôi làm việc cho một công ty đang xem xét chính xác điều này. Dưới đây là 3 số liệu có thể hành động mà chúng tôi khuyên bạn nên xem xét khi xử lý nợ kỹ thuật. Để biết thêm thông tin về "cách" và "khi nào" để theo dõi chúng, chúng tôi tập hợp một bài viết tóm tắt 3 Số liệu để hiểu và giải quyết nợ kỹ thuật .

Quan điểm của bạn là gì? Rất vui được trả lời bất kỳ câu hỏi nào và khao khát được nghe phản hồi của bạn :).

Quyền sở hữu để ngăn ngừa khuyết điểm và nợ công nghệ không mong muốn

Quyền sở hữu là một chỉ số hàng đầu của sức khỏe kỹ thuật.

Các phần của codebase nhận được sự đóng góp từ nhiều người tích lũy hành trình theo thời gian, trong khi những phần nhận được đóng góp từ ít người hơn có xu hướng ở trạng thái tốt hơn. Việc duy trì các tiêu chuẩn cao trong một nhóm chặt chẽ được thông tin đầy đủ về một phần của cơ sở mã là dễ dàng hơn.

Điều này cung cấp một số sức mạnh dự đoán: các bộ phận thuộc sở hữu yếu của codebase có khả năng tích lũy nợ theo thời gian và ngày càng khó làm việc. Cụ thể, có khả năng nợ vô tình bị xử lý , đơn giản chỉ là tác dụng phụ của thông tin không đầy đủ và quyền sở hữu chất lượng của mã bị pha loãng.

Điều này hơi giống với bi kịch của chung .

Sự gắn kết để cải thiện kiến ​​trúc

Sự gắn kết là một chỉ số kéo dài của các thành phần được xác định rõ.

Sự gắn kết và đối tác của nó, khớp nối, từ lâu đã được công nhận là khái niệm quan trọng cần tập trung khi thiết kế phần mềm.

Mã được cho là có sự gắn kết cao khi hầu hết các yếu tố của nó thuộc về nhau. Sự gắn kết cao thường được ưa thích hơn vì nó liên quan đến khả năng bảo trì, tái sử dụng và mạnh mẽ. Độ gắn kết cao và khớp nối lỏng lẻo có xu hướng đi đôi với nhau.

Ngoài việc được liên kết với mã có thể tái sử dụng và duy trì nhiều hơn, sự gắn kết cao cũng giảm thiểu số lượng người cần tham gia để sửa đổi một phần nhất định của cơ sở mã giúp tăng năng suất.

Churn để xác định khu vực có vấn đề

Churn (hoạt động lặp đi lặp lại) giúp xác định và xếp hạng các khu vực chín muồi để tái cấu trúc trong một hệ thống đang phát triển.

Khi các hệ thống phát triển, các nhà phát triển sẽ khó hiểu kiến ​​trúc của họ hơn. Nếu các nhà phát triển phải sửa đổi nhiều phần của cơ sở mã để cung cấp một tính năng mới, họ sẽ khó tránh khỏi việc đưa ra các tác dụng phụ dẫn đến lỗi và họ sẽ làm việc kém hiệu quả hơn vì họ cần làm quen với nhiều yếu tố và khái niệm hơn.

Đây là lý do tại sao điều quan trọng là phải phấn đấu cho một trách nhiệm duy nhất để tạo ra một hệ thống ổn định hơn và tránh những hậu quả không lường trước được. Mặc dù một số tệp là trung tâm kiến ​​trúc và vẫn hoạt động khi các tính năng mới được thêm vào, bạn nên viết mã theo cách mang lại sự đóng cửa cho các tệp và xem xét nghiêm ngặt, kiểm tra và kiểm tra các khu vực khuấy QA.

Churn hiển thị các tệp đang hoạt động này để bạn có thể quyết định xem chúng có nên được chia nhỏ để giảm diện tích bề mặt thay đổi trong cơ sở mã của bạn hay không.

Nếu bạn có một lịch sử tốt thông qua một bugtracker hoặc một loại phần mềm nhanh nhẹn nào đó, bạn có thể giữ cho nó đơn giản. Thời gian dành để hoàn thành các nhiệm vụ cơ bản. Ngoài ra, độ tin cậy của các ước tính khi dự án còn trẻ so với bây giờ.