Niềm đam mê với các số liệu mã là gì? [đóng cửa]

Gần đây, tôi đã thấy một số câu hỏi liên quan đến 'số liệu mã' trên SO, và tôi phải tự hỏi sức hấp dẫn là gì? Dưới đây là một số ví dụ gần đây:

• những chỉ số mã nào thuyết phục bạn rằng mã được cung cấp là tồi tệ
• khi nào thì số dòng mã là một chỉ số hữu ích
• viết bài kiểm tra chất lượng

Tuy nhiên, theo suy nghĩ của tôi, không có số liệu nào có thể thay thế cho việc xem xét mã:

• một số chỉ số đôi khi có thể chỉ ra những nơi cần được xem xét và
• những thay đổi căn bản về chỉ số trong các khung thời gian ngắn có thể chỉ ra những nơi cần được xem xét

Nhưng tôi không thể nghĩ ra một số liệu nào mà bản thân nó luôn chỉ ra mã 'tốt' hoặc 'xấu' - luôn có những ngoại lệ và lý do cho những thứ mà phép đo không thể nhìn thấy.

Có một số thông tin chi tiết kỳ diệu có được từ các chỉ số mã mà tôi đã bỏ qua không? Lập trình viên / quản lý lười biếng đang tìm lý do để không đọc mã? Mọi người có được giới thiệu với các cơ sở mã kế thừa khổng lồ và đang tìm kiếm một nơi để bắt đầu không? Chuyện gì vậy?

Lưu ý: Tôi đã hỏi một số câu hỏi này trên các chủ đề cụ thể cả trong câu trả lời và nhận xét và không nhận được câu trả lời, vì vậy tôi nghĩ tôi nên hỏi cộng đồng nói chung vì có lẽ tôi đang thiếu điều gì đó. Sẽ thật tuyệt khi chạy một công việc hàng loạt số liệu và không thực sự phải đọc lại mã của người khác (hoặc của chính tôi), tôi chỉ không nghĩ rằng nó thực tế!

CHỈNH SỬA: Tôi quen thuộc với hầu hết nếu không phải là tất cả các số liệu đang được thảo luận, tôi chỉ không nhìn thấy điểm riêng biệt của chúng hoặc như là các tiêu chuẩn tùy ý về chất lượng.

Các câu trả lời trong chủ đề này hơi kỳ quặc khi chúng nói về:

• "nhóm", như "người hưởng lợi duy nhất" của các chỉ số đã nói;
• "các số liệu", giống như tự chúng có ý nghĩa.

1 / Các chỉ số không dành cho một tập hợp , mà cho ba :

• nhà phát triển: họ quan tâm đến các chỉ số mã tĩnh tức thời liên quan đến phân tích tĩnh mã của họ (độ phức tạp theo chu kỳ, chất lượng nhận xét, số dòng, ...)
• các nhà lãnh đạo dự án: họ quan tâm đến các chỉ số mã trực tiếp hàng ngày đến từ thử nghiệm đơn vị, độ phủ mã, thử nghiệm tích hợp liên tục
• các nhà tài trợ kinh doanh (họ luôn bị lãng quên, nhưng họ là bên liên quan, người trả tiền cho sự phát triển): họ quan tâm đến các chỉ số mã toàn cầu hàng tuần liên quan đến thiết kế kiến ​​trúc, bảo mật, phụ thuộc, ...

Tất nhiên, tất cả các chỉ số đó đều có thể được xem và phân tích bởi cả ba nhóm dân số, nhưng mỗi loại được thiết kế để sử dụng tốt hơn cho từng nhóm cụ thể.

2 / Bản thân các chỉ số đại diện cho một bản chụp nhanh của đoạn mã, và điều đó có nghĩa là ... không có gì!

Chính sự kết hợp của các chỉ số đó và sự kết hợp của các cấp độ phân tích khác nhau đó có thể chỉ ra mã "tốt" hoặc "xấu", nhưng quan trọng hơn, đó là xu hướng của các số liệu đó là đáng kể.

Đó là sự lặp lại của các số liệu đó sẽ mang lại giá trị gia tăng thực sự, vì chúng sẽ giúp các nhà quản lý doanh nghiệp / lãnh đạo dự án / nhà phát triển ưu tiên trong số các bản sửa lỗi mã có thể có khác nhau

Nói cách khác, câu hỏi của bạn về "sự hấp dẫn của các số liệu" có thể đề cập đến sự khác biệt giữa:

• mã "đẹp" (mặc dù điều đó luôn nằm trong tầm mắt của người viết mã)
• mã "tốt" (hoạt động và có thể chứng minh nó hoạt động)

Vì vậy, ví dụ, một hàm có độ phức tạp chu kỳ là 9 có thể được định nghĩa là "đẹp", trái ngược với một hàm phức tạp dài có độ phức tạp chu kỳ là 42.

Nhưng nếu:

• hàm thứ hai có độ phức tạp ổn định , kết hợp với độ phủ mã là 95%,
• trong khi cái trước có mức độ phức tạp ngày càng tăng , kết hợp với mức độ bao phủ là ... 0%,

người ta có thể tranh luận:

• mã sau đại diện cho một mã " tốt " (nó hoạt động, nó ổn định và nếu cần thay đổi, người ta có thể kiểm tra xem nó có còn hoạt động sau khi sửa đổi hay không),
• trước đây là một mã " xấu " (nó vẫn cần thêm một số trường hợp và điều kiện để bao gồm tất cả những gì nó phải làm và không có cách nào dễ dàng để thực hiện một số kiểm tra hồi quy)

Vì vậy, để tóm tắt:

một chỉ số duy nhất mà bản thân nó luôn chỉ ra [...]

: không nhiều, ngoại trừ việc mã có thể "đẹp" hơn, bản thân nó không có nhiều ý nghĩa ...

Có một số thông tin chi tiết kỳ diệu có được từ các chỉ số mã mà tôi đã bỏ qua không?

Chỉ sự kết hợp và xu hướng của các số liệu mới mang lại "cái nhìn sâu sắc kỳ diệu" thực sự mà bạn đang theo đuổi.

Tôi đã có một dự án mà tôi đã thực hiện với tư cách là một người làm công việc đo lường độ phức tạp theo chu kỳ vài tháng trước. Đó là lần đầu tiên tôi tiếp xúc với những loại chỉ số này.

Báo cáo đầu tiên tôi nhận được đã gây sốc. Hầu như tất cả các chức năng của tôi đều thất bại trong bài kiểm tra, ngay cả những chức năng (imho) rất đơn giản. Tôi đã giải quyết vấn đề phức tạp bằng cách chuyển nhiệm vụ con logic thành các chương trình con ngay cả khi chúng chỉ được gọi một lần.

Đối với nửa còn lại của thói quen, niềm tự hào của tôi khi là một lập trình viên đã bắt đầu và tôi đã cố gắng viết lại chúng theo cách mà chúng vẫn làm tương tự, chỉ đơn giản hơn và dễ đọc hơn. Điều đó đã hiệu quả và tôi đã có thể đạt được hầu hết ngưỡng phức tạp yclomatic của khách hàng.

Cuối cùng, tôi hầu như luôn có thể nghĩ ra một giải pháp tốt hơn và mã sạch hơn nhiều. Hiệu suất không bị ảnh hưởng bởi điều này (tin tôi đi - tôi hoang tưởng về điều này và tôi kiểm tra việc tháo rời đầu ra của trình biên dịch khá thường xuyên).

Tôi nghĩ các số liệu là một điều tốt nếu bạn sử dụng chúng như một lý do / động lực để cải thiện mã của mình. Mặc dù vậy, điều quan trọng là phải biết khi nào nên dừng lại và yêu cầu trợ cấp vi phạm số liệu.

Các chỉ số là hướng dẫn và trợ giúp, không tự nó kết thúc.

Số liệu tốt nhất mà tôi từng sử dụng là điểm CRAP .

Về cơ bản, đó là một thuật toán so sánh độ phức tạp chu kỳ có trọng số với phạm vi kiểm tra tự động. Thuật toán trông giống như sau: CRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m) trong đó comp (m) là độ phức tạp chu kỳ của phương pháp m và cov (m) là phạm vi bao phủ của mã thử nghiệm được cung cấp bởi các thử nghiệm tự động.

Các tác giả của bài báo đã đề cập ở trên (vui lòng đọc nó ... nó rất đáng để bạn dành thời gian) đề xuất điểm CRAP tối đa là 30, điểm này được chia theo cách sau:

Method’s Cyclomatic Complexity        % of coverage required to be
                                      below CRAPpy threshold
------------------------------        --------------------------------
0 – 5                                   0%
10                                     42%
15                                     57%
20                                     71%
25                                     80%
30                                    100%
31+                                   No amount of testing will keep methods
                                      this complex out of CRAP territory.

Như bạn nhanh chóng thấy, số liệu thưởng cho việc viết mã không phức tạp cùng với phạm vi kiểm tra tốt (nếu bạn đang viết các bài kiểm tra đơn vị, và bạn nên làm như vậy, và không đo độ bao phủ ... tốt, bạn có thể sẽ thích thú khi phát hiện ra gió cũng). ;-)

Đối với hầu hết các nhóm phát triển của tôi, tôi đã thực sự cố gắng để đạt được điểm CRAP dưới 8, nhưng nếu họ có lý do xác đáng để biện minh cho mức độ phức tạp tăng thêm có thể chấp nhận được miễn là họ đã bao quát được mức độ phức tạp đó bằng đủ các bài kiểm tra. (Viết mã phức tạp luôn rất khó để kiểm tra ... một lợi ích ẩn đối với số liệu này).

Hầu hết mọi người cảm thấy khó khăn ban đầu để viết mã vượt qua điểm CRAP. Nhưng theo thời gian, họ đã viết mã tốt hơn, mã có ít vấn đề hơn và mã dễ gỡ lỗi hơn rất nhiều. Trong số bất kỳ chỉ số nào, đây là chỉ số có ít mối quan tâm nhất và mang lại lợi ích lớn nhất.

Đối với tôi, chỉ số quan trọng nhất xác định mã xấu là độ phức tạp theo chu kỳ. Hầu hết tất cả các phương pháp trong các dự án của tôi đều dưới CC 10 và lỗi luôn được tìm thấy trong các phương pháp cũ có CC trên 30. CC cao thường chỉ ra:

• mã được viết vội vàng (tức là không có thời gian để tìm một giải pháp hay và không phải vì vấn đề đòi hỏi một giải pháp phức tạp)
• mã chưa được kiểm tra (không ai viết bài kiểm tra cho những con thú như vậy)
• mã đã được vá và sửa nhiều lần (ví dụ: bị đánh đố với ifs và todo comment)
• một mục tiêu chính để tái cấu trúc

Một bài đánh giá mã tốt không thể thay thế cho một công cụ phân tích tĩnh tốt, tất nhiên không thể thay thế cho một bộ bài kiểm tra đơn vị tốt, bây giờ các bài kiểm tra đơn vị sẽ không tốt nếu không có một bộ bài kiểm tra chấp nhận ......

Số liệu mã là một công cụ khác để đưa vào hộp công cụ của bạn, chúng không phải là một giải pháp theo đúng nghĩa của chúng mà chỉ là một công cụ được sử dụng khi thích hợp (tất nhiên với tất cả các công cụ khác trong hộp của bạn!).

Mọi người bị lôi cuốn vào ý tưởng về những cách cơ học để hiểu và mô tả mã. Nếu đúng, hãy nghĩ đến các phân nhánh cho hiệu quả và năng suất!

Tôi đồng ý rằng chỉ số cho "độ tốt của mã" cũng hợp lý như số liệu cho "văn xuôi hay". Tuy nhiên, điều đó không có nghĩa là các chỉ số là vô dụng, chỉ có thể là sử dụng sai.

Ví dụ: các giá trị cực trị cho một số chỉ số chỉ ra con đường cho các vấn đề có thể xảy ra. Một phương pháp dài 1000 dòng có lẽ là không thể hiểu được . Mã có phạm vi kiểm tra mã không đơn vị có thể có nhiều lỗi hơn mã tương tự với nhiều kiểm tra. Một bước nhảy vọt về mã được thêm vào một dự án ngay trước khi phát hành mà không phải là thư viện của bên thứ ba có thể là nguyên nhân gây ra nhiều sự chú ý.

Tôi nghĩ nếu chúng ta sử dụng các số liệu như một gợi ý - một lá cờ đỏ - có lẽ chúng có thể hữu ích. Vấn đề là khi mọi người bắt đầu đo năng suất trong SLOC hoặc chất lượng theo tỷ lệ phần trăm của các dòng có kiểm tra.

Ý kiến ​​chủ quan của tôi là các thước đo mã thể hiện niềm đam mê không thể thay đổi của thể chế với việc có thể định lượng một cái gì đó vốn dĩ không thể định lượng được.

Theo một cách nào đó, ít nhất là về mặt tâm lý cũng có ý nghĩa - làm thế nào bạn có thể đưa ra quyết định về một thứ mà bạn không thể đánh giá hoặc hiểu được? Cuối cùng, tất nhiên, bạn không thể đánh giá chất lượng trừ khi bạn hiểu biết về chủ đề này (và ít nhất là tốt như những gì bạn đang cố gắng đánh giá) hoặc hỏi một người có kiến ​​thức, điều này tất nhiên chỉ đặt lại vấn đề một bước.

Theo nghĩa đó, có thể một phép tương tự hợp lý sẽ là đánh giá các thí sinh vào đại học bằng điểm SAT, điều đó không công bằng và bỏ sót mọi sự tinh tế nhưng nếu bạn cần định lượng thì bạn phải làm gì đó.

Không phải nói rằng tôi nghĩ đó là một biện pháp tốt, chỉ là tôi có thể thấy tính bất khả xâm phạm của nó. Và, như bạn đã chỉ ra, có lẽ có một vài số liệu hợp lý (rất nhiều phương pháp hơn 500 dòng, độ phức tạp cao - có thể là xấu). Tuy nhiên, tôi chưa bao giờ đến một nơi đã mua nó.

Có một chỉ số mã mà tôi tin tưởng.

Tôi đang làm việc trên một hệ thống lớn. Khi một yêu cầu mới đến với tôi, tôi bắt đầu mã hóa nó. Khi tôi hoàn thành và khắc phục được lỗi, tôi kiểm tra nó vào hệ thống kiểm soát phiên bản. Hệ thống đó thực hiện một sự khác biệt và tính tất cả những thay đổi tôi đã thực hiện.

Con số đó càng nhỏ càng tốt.

Các chỉ số và kiểm tra tự động không có nghĩa là thay thế cho việc đánh giá toàn bộ mã.

Họ chỉ tăng tốc mọi thứ. Với trình kiểm tra tự động, bạn rất dễ dàng biết được quy ước nào bạn đã quên tuân theo, bạn đang sử dụng các gói và phương pháp được chỉ định, v.v. Bạn có thể xem những gì bạn có thể sửa mà không cần sử dụng thời gian của người khác.

Các nhà quản lý cũng thích các chỉ số đo lường họ vì họ cảm thấy họ đang có được một con số chính xác về năng suất (mặc dù điều đó thường không thực sự xảy ra) và họ sẽ có thể sắp xếp mọi người tốt hơn.

Các phép đo chỉ hữu ích nếu:

• Nhóm phát triển chúng
• Nhóm đã đồng ý với họ
• Chúng đang được sử dụng để xác định một khu vực cụ thể

Nhìn chung, bất kỳ chỉ số nào không phù hợp với chỉ số đó sẽ bị nhóm tối ưu hóa nó. Bạn muốn đo các dòng mã? Hãy xem họ có thể viết được bao nhiêu! Bạn muốn đo độ phủ của mã, tuyệt vời, hãy xem tôi phủ mã đó!

Tôi nghĩ rằng các số liệu có thể hữu ích để xác định xu hướng và trên thực tế, tôi đã thấy một số chỉ số hữu ích, chẳng hạn như lập biểu đồ khi bản dựng bị hỏng, mã churn (số dòng mã thay đổi trong suốt dự án) và những thứ khác. Nhưng nếu nhóm không đến với họ, hoặc họ không đồng ý hoặc hiểu họ, bạn có thể đang ở trong một thế giới bị tổn thương.

Đây là một số chỉ số về độ phức tạp từ stan4j .

Một công cụ phân tích cấu trúc lớp nhật thực.

Tôi thích công cụ này và các số liệu. Tôi coi các số liệu là thống kê, chỉ số, thông báo cảnh báo. Đôi khi do một số phương thức hoặc một số lớp thực sự có một số logic phức tạp khiến chúng trở nên phức tạp, điều cần làm là theo dõi chúng, xem lại chúng để xem có cần phải cấu trúc lại chúng hay không hoặc xem xét chúng cẩn thận, do bình thường. chúng dễ bị lỗi. Ngoài ra, tôi sử dụng nó như một công cụ phân tích để học mã nguồn, do tôi thích học từ phức tạp đến đơn giản, thực tế nó bao gồm một số số liệu khác như Robert C. Martin Metrics, Chidamber & Kemerer Metrics, Count Metrics Nhưng tôi thích cái này nhất

Chỉ số độ phức tạp

Số liệu về độ phức tạp Cyclomatic

Độ phức tạp theo chu kỳ (CC) Độ phức tạp theo chu kỳ của một phương pháp là số điểm quyết định trong biểu đồ luồng điều khiển của phương pháp tăng lên một. Các điểm quyết định xảy ra tại các câu lệnh if / for / while, các mệnh đề case / catch và các phần tử mã nguồn tương tự, trong đó luồng điều khiển không chỉ là tuyến tính. Số lượng điểm quyết định (mã byte) được giới thiệu bởi một câu lệnh (mã nguồn) đơn lẻ có thể khác nhau, tùy thuộc vào độ phức tạp của biểu thức boolean. Giá trị độ phức tạp chu kỳ của một phương pháp càng cao thì càng có nhiều trường hợp thử nghiệm được yêu cầu để kiểm tra tất cả các nhánh của đồ thị luồng điều khiển của phương pháp.

Độ phức tạp Cyclomatic Trung bình Giá trị trung bình của chỉ số Độ phức tạp Cyclomatic trên tất cả các phương thức của ứng dụng, thư viện, cây gói hoặc gói.

Số liệu Fat Chỉ số Fat của một tạo tác là số cạnh trong biểu đồ phụ thuộc thích hợp của tạo tác. Loại biểu đồ phụ thuộc phụ thuộc vào biến thể chỉ số và cấu phần phần mềm đã chọn:

Mập Chỉ số Fat của một ứng dụng, thư viện hoặc cây gói là số cạnh của đồ thị phụ thuộc cây con của nó. Biểu đồ này chứa tất cả các phần tử con của tạo tác trong hệ thống phân cấp cây gói, do đó cũng bao gồm các gói lá. (Để xem biểu đồ thích hợp trong Chế độ xem thành phần, phải tắt chuyển đổi Gói phẳng của Trình khám phá cấu trúc. Chuyển đổi Thư viện chương trình phải được bật nếu cấu phần phần mềm được chọn là thư viện, nếu không nó phải bị tắt.)

Chỉ số Fat của một gói là số cạnh của đồ thị phụ thuộc vào đơn vị của nó. Biểu đồ này chứa tất cả các lớp cấp cao nhất của gói.

Chỉ số Fat của một lớp là số cạnh của đồ thị thành viên của nó. Biểu đồ này chứa tất cả các trường, phương thức và các lớp thành viên của lớp. (Biểu đồ này và giá trị Fat chỉ có sẵn nếu phân tích mã được thực hiện với Cấp độ Thành viên Chi tiết, không phải Cấp độ.)

Fat cho sự phụ thuộc thư viện (Fat - Libraries) Chỉ số Fat cho sự phụ thuộc thư viện của một ứng dụng là số cạnh của biểu đồ phụ thuộc thư viện của nó. Biểu đồ này chứa tất cả các thư viện của ứng dụng. (Để xem biểu đồ thích hợp trong Chế độ xem Thành phần, phải bật chuyển đổi Thư viện chương trình của Trình khám phá cấu trúc.)

Chất béo cho phụ thuộc gói phẳng (Chất béo - Gói) Chỉ số chất béo cho sự phụ thuộc gói phẳng của một ứng dụng là số cạnh của đồ thị phụ thuộc gói phẳng của nó. Biểu đồ này chứa tất cả các gói của ứng dụng. (Để xem biểu đồ thích hợp trong Chế độ xem Thành phần, phải bật chuyển đổi Gói phẳng của Trình khám phá cấu trúc và bật chuyển đổi Thư viện Hiển thị phải được tắt.)

Chỉ số Fat cho gói phụ thuộc phẳng của thư viện là số cạnh của đồ thị phụ thuộc gói phẳng của nó. Biểu đồ này chứa tất cả các gói của thư viện. (Để xem biểu đồ thích hợp trong Chế độ xem Thành phần, các chuyển đổi Gói phẳng và Hiển thị Thư viện của Trình khám phá cấu trúc phải được bật.)

Chất béo cho sự phụ thuộc lớp cấp cao nhất (Fat - Đơn vị) Chỉ số chất béo cho sự phụ thuộc lớp cấp cao nhất của một ứng dụng hoặc thư viện là số cạnh của biểu đồ phụ thuộc đơn vị của nó. Biểu đồ này chứa tất cả các lớp cấp cao nhất của ứng dụng hoặc thư viện. (Đối với các ứng dụng hợp lý, nó quá lớn để có thể hiển thị và do đó không thể hiển thị trong Chế độ xem thành phần. Biểu đồ phụ thuộc đơn vị chỉ có thể được hiển thị cho các gói.)

Các chỉ số có thể hữu ích để xác định sự cải thiện hoặc suy thoái trong một dự án và chắc chắn có thể tìm thấy các vi phạm quy ước và phong cách, nhưng không có gì thay thế cho việc đánh giá mã ngang hàng. Bạn không thể biết chất lượng mã của mình nếu không có chúng.

Ồ ... và điều này giả định rằng ít nhất một trong những người tham gia đánh giá mã của bạn có manh mối.

Tôi đồng ý với bạn rằng các chỉ số mã không nên thay thế cho việc đánh giá mã nhưng tôi tin rằng chúng nên bổ sung cho việc đánh giá mã. Tôi nghĩ nó trở lại câu nói cũ rằng "bạn không thể cải thiện những gì bạn không thể đo lường." Các chỉ số mã có thể cung cấp cho nhóm phát triển "mùi mã" có thể định lượng được hoặc các mẫu có thể cần điều tra thêm. Các số liệu được thu thập trong hầu hết các công cụ phân tích tĩnh thường là các số liệu đã được xác định trong quá trình nghiên cứu trong lịch sử ngắn của lĩnh vực của chúng tôi để có ý nghĩa quan trọng.

Các chỉ số không thể thay thế cho việc xem xét mã, nhưng chúng rẻ hơn rất nhiều. Chúng là một chỉ số hơn bất cứ thứ gì.

Một phần của câu trả lời là một số số liệu mã có thể cung cấp cho bạn câu trả lời rất nhanh, ban đầu cho câu hỏi: Mã này như thế nào?

Ngay cả 'dòng mã' cũng có thể cung cấp cho bạn ý tưởng về kích thước của cơ sở mã bạn đang xem.

Như đã đề cập trong một câu trả lời khác, xu hướng của các số liệu cung cấp cho bạn nhiều thông tin nhất.

Các chỉ số về bản thân chúng không đặc biệt thú vị. Đó là những gì bạn làm với chúng quan trọng.

Ví dụ: nếu bạn đang đo lường số lượng bình luận trên mỗi dòng mã, bạn sẽ coi giá trị nào là tốt? Ai biết? Hoặc có lẽ quan trọng hơn, mỗi người đều có ý kiến ​​riêng của họ.

Bây giờ nếu bạn thu thập đủ thông tin để có thể so sánh số lượng nhận xét trên mỗi dòng mã với thời gian thực hiện để giải quyết lỗi hoặc với số lỗi được tìm thấy được cho là do mã hóa, thì bạn có thể bắt đầu tìm thấy một con số hữu ích về mặt kinh nghiệm .

Không có sự khác biệt giữa việc sử dụng số liệu trong phần mềm và sử dụng bất kỳ thước đo hiệu suất nào khác trên bất kỳ quy trình nào khác - trước tiên bạn đo lường, sau đó bạn phân tích, sau đó bạn cải thiện quy trình. Nếu tất cả những gì bạn đang làm là đo lường, bạn đang lãng phí thời gian của mình.

chỉnh sửa: Đáp lại nhận xét của Steven A. Lowe - điều đó hoàn toàn chính xác. Trong bất kỳ phân tích dữ liệu nào, người ta phải cẩn thận để phân biệt giữa mối quan hệ nhân quả và mối tương quan đơn thuần. Và việc lựa chọn các thước đo trên cơ sở phù hợp là rất quan trọng. Không có ích gì khi cố gắng đo lường mức tiêu thụ cà phê và xác định chất lượng mã (mặc dù tôi chắc rằng một số người đã thử ;-))

Nhưng trước khi bạn có thể tìm ra mối quan hệ (nhân quả hay không), bạn phải có dữ liệu.

Việc lựa chọn dữ liệu để thu thập dựa trên quy trình bạn muốn xác minh hoặc cải thiện. Ví dụ: nếu bạn đang cố gắng phân tích mức độ thành công của các quy trình xem xét mã của mình (sử dụng định nghĩa của riêng bạn cho "thành công", đó là giảm lỗi hoặc giảm lỗi mã hóa hoặc thời gian quay vòng ngắn hơn hoặc bất cứ điều gì), thì bạn chọn các chỉ số đo lường tổng tỷ lệ lỗi và tỷ lệ lỗi trong mã được xem xét.

Vì vậy, trước khi thu thập dữ liệu, bạn phải biết mình muốn làm gì với nó. Nếu số liệu là phương tiện, thì cuối cùng là gì?

Tôi không nghĩ rằng những thay đổi nhỏ trong số liệu là có ý nghĩa: một hàm có độ phức tạp 20 không nhất thiết phải sạch hơn một hàm có độ phức tạp 30. Nhưng đáng để chạy các số liệu để tìm kiếm sự khác biệt lớn.

Có lần tôi đang khảo sát vài chục dự án và một trong những dự án có giá trị phức tạp tối đa khoảng 6.000 trong khi mọi dự án khác có giá trị khoảng 100 hoặc ít hơn. Nó đập vào đầu tôi như một cây gậy bóng chày. Rõ ràng là có điều gì đó bất thường, và có thể là tồi tệ, đang diễn ra với dự án đó.

Chúng tôi là lập trình viên. Chúng tôi thích những con số.

Ngoài ra, bạn sẽ làm gì, KHÔNG mô tả kích thước của cơ sở mã vì "các dòng số liệu mã không liên quan"?

Chắc chắn có sự khác biệt giữa cơ sở mã 150 dòng và một trong 150 triệu, để lấy một ví dụ ngớ ngẩn. Và nó không phải là một con số khó để có được.