Các số liệu hữu ích cho mã nguồn là gì? [đóng cửa]

Các số liệu hữu ích để nắm bắt cho mã nguồn là gì?

Làm thế nào các số liệu, ví dụ như (Có thể thực thi?) Các dòng mã hoặc độ phức tạp theo chu kỳ có thể giúp đảm bảo chất lượng hoặc nói chung chúng có lợi như thế nào cho quy trình phát triển phần mềm?

"Đo năng suất phần mềm bằng các dòng mã giống như đo lường tiến trình trên máy bay bằng bao nhiêu cân." - Bill Gates

Hãy xem bài viết của Jeff về chủ đề này:

Chuyến thăm từ người giúp việc Metrics

Kỹ thuật phần mềm: Chết?

Có một bài viết cũ, nhưng hay, từ Joel cũng vậy, liên quan chặt chẽ đến các số liệu phần mềm và tôi thực sự khuyên bạn nên đọc nó: Phương pháp quản lý EE 101

Điểm mấu chốt, đối với tôi, là điều này, trích dẫn Jeff: "Việc sử dụng có trách nhiệm các số liệu cũng quan trọng như thu thập chúng ở nơi đầu tiên."

Điều khiến tôi bối rối về số liệu mã là nó không được thực hiện nhiều hơn. Hầu hết các công ty báo cáo về hiệu quả của nhân viên, nhà cung cấp và hệ thống của họ, nhưng dường như không ai muốn báo cáo về mã. Tôi chắc chắn sẽ đồng ý với các câu trả lời nói rằng nhiều dòng mã hơn là trách nhiệm pháp lý nhưng những gì mã của bạn làm là quan trọng hơn.

Dòng mã: Như 'Ive đã đề cập, đây là một phép đo quan trọng và cần được thực hiện nghiêm túc nhất, nhưng ở mỗi cấp độ. Các hàm, lớp, tệp và giao diện có thể chỉ ra mã do-mọi thứ khó duy trì và tốn kém trong thời gian dài. Thật khó để so sánh tổng số dòng mã so với những gì một hệ thống làm. Nó có thể là một cái gì đó làm nhiều việc và trong trường hợp đó sẽ có nhiều dòng mã!

Độ phức tạp: Phép đo này rất tốt để thực hiện trên các cơ sở mã mà bạn chưa từng làm việc và có thể cho bạn một dấu hiệu tốt về nơi các khu vực có vấn đề nằm. Là một giai thoại hữu ích, tôi đã đo độ phức tạp trên một trong những cơ sở mã của riêng mình và khu vực có độ phức tạp cao nhất là khu vực mà tôi đã dành nhiều thời gian nhất khi tôi cần thay đổi nó. Làm việc theo hướng giảm sự phức tạp dẫn đến giảm đáng kể thời gian bảo trì. Nếu quản lý có sẵn các phép đo này, họ có thể lập kế hoạch tái cấu trúc các lần lặp hoặc thiết kế lại các khu vực cụ thể của hệ thống.

Sao chép mã: Đây là một phép đo rất quan trọng theo như tôi nghĩ. Sao chép mã là một dấu hiệu rất xấu và có thể chỉ ra các vấn đề sâu sắc ở mức độ thấp của thiết kế hệ thống hoặc nhà phát triển đang sao chép dán, gây ra các vấn đề lớn trong dài hạn và các hệ thống không thể khắc phục được.

Đồ thị phụ thuộc Tìm các phụ thuộc xấu và phụ thuộc vòng là một phép đo quan trọng trong mã. Điều này hầu như luôn luôn chỉ ra một thiết kế cấp cao không chính xác cần sửa đổi. Đôi khi một người phụ thuộc có thể hút rất nhiều người khác không cần thiết, bởi vì ai đó đang sử dụng addNumber trong thư viện email để thực hiện các tính toán tài chính của họ. Mọi người đều sốc khi thư viện e-mail bị thay đổi và tài chính bị phá vỡ. Nếu mọi thứ phụ thuộc vào một thứ, nó cũng có thể chỉ ra các thư viện làm mọi thứ khó bảo trì và được thiết kế tồi.

Một phép đo tốt sẽ luôn cho bạn biết rằng mọi tính năng của hệ thống đều có dấu chân nhỏ. Ít phụ thuộc hơn, ít phức tạp hơn, ít trùng lặp hơn. Điều này chỉ ra khớp nối lỏng lẻo và sự gắn kết cao.

"Số liệu mã nguồn" này có phải là EVER chết không?

Các dòng mã nguồn thô (SLOC) là số liệu cũ nhất, dễ nhất, cơ bản nhất hiện có.

Halstead ban đầu đề xuất một loạt các số liệu. Rất nhiều người đã có rất nhiều chương trình đo lường thú vị cho đến khi một số spoilsport thực hiện nghiên cứu rõ ràng, và chứng minh rằng mỗi số liệu Halstead duy nhất có mối tương quan trực tiếp với SLOC.

Vào thời điểm đó, số liệu của Halstead đã bị hủy bỏ, bởi vì SLOC luôn dễ đo lường hơn.

Số liệu mã nguồn để đảm bảo chất lượng nhằm vào hai mục tiêu:

• viết mã với ít lỗi bên trong
• viết mã để bảo trì dễ dàng

Cả hai đều dẫn đến việc viết mã càng đơn giản càng tốt. Điều này có nghĩa là:

• đơn vị mã ngắn (hàm, phương thức)
• vài phần tử trong mỗi đơn vị (đối số, biến cục bộ, câu lệnh, đường dẫn)
• và nhiều tiêu chí khác ít nhiều phức tạp (xem số liệu Phần mềm trong Wikipedia).

Theo hiểu biết tốt nhất của tôi, số lượng lỗi được tìm thấy tương quan trực tiếp với các dòng mã (có thể là churn), ngôn ngữ modulo, lập trình viên và miền.

Tôi không biết bất kỳ số liệu đơn giản và thực tế nào tương quan tốt với các lỗi.

Một điều tôi muốn làm là bắt đầu chạy các con số cho các dự án khác nhau mà tôi đang thực hiện - Kiểm tra phạm vi :: kLOC, sau đó thảo luận về "chất lượng cảm nhận" để xem liệu có mối tương quan nào không.

Số liệu chỉ hữu ích nếu bạn biết phải làm gì với câu trả lời bạn nhận được. Về bản chất, một số liệu phần mềm giống như một nhiệt kế. Việc bạn đo một cái gì đó ở 98,6 ° F không có nghĩa gì cho đến khi bạn biết nhiệt độ bình thường là bao nhiêu. Nhiệt độ trên tốt cho nhiệt độ cơ thể nhưng thực sự không tốt cho kem.

Các số liệu phổ biến có thể hữu ích là:

• Lỗi phát hiện / tuần
• Lỗi được giải quyết / tuần
• # Yêu cầu xác định / phát hành
• # Yêu cầu thực hiện / phát hành

Hai xu hướng đo lường đầu tiên. Bạn đang tìm lỗi nhanh hơn bạn có thể sửa chúng? Hai kết quả có thể xảy ra: có thể chúng tôi cần nhiều tài nguyên hơn để sửa lỗi, có thể chúng tôi cần ngừng triển khai các tính năng mới cho đến khi chúng tôi bắt kịp. Hai thứ hai cung cấp một hình ảnh về mức độ gần gũi của bạn được thực hiện. Các nhóm Agile gọi đó là biểu đồ "đốt cháy".

Độ phức tạp theo chu kỳ là một số liệu thú vị. Ở khái niệm cơ sở, đó là số lượng đường dẫn thực hiện duy nhất trong một hàm / phương thức. Trong môi trường nặng kiểm tra đơn vị, điều này tương ứng với số lượng kiểm tra cần thiết để xác minh mọi đường dẫn thực hiện. Tuy nhiên, chỉ vì bạn có một phương pháp có Độ phức tạp Cyclomatic là 96 không có nghĩa là nó nhất thiết phải là mã lỗi - hoặc bạn phải viết 96 bài kiểm tra để cung cấp độ tin cậy hợp lý. Không có gì lạ khi mã được tạo (thông qua WPF hoặc trình tạo trình phân tích cú pháp) để tạo ra thứ gì đó phức tạp này. Nó có thể cung cấp một ý tưởng sơ bộ về mức độ nỗ lực cần thiết để gỡ lỗi một phương thức.

Dòng dưới cùng

Mọi phép đo bạn cần phải có các định nghĩa sau hoặc không có ích:

• Một sự hiểu biết về "bình thường" là gì. Điều này có thể được điều chỉnh trong suốt vòng đời của dự án.
• Một ngưỡng bên ngoài "bình thường" nơi bạn cần thực hiện một số hành động.
• Một kế hoạch xử lý mã khi vượt quá ngưỡng.

Các số liệu bạn thực hiện có thể khác nhau từ dự án để dự án. Bạn có thể có một vài số liệu mà bạn sử dụng trên các dự án, nhưng định nghĩa "bình thường" sẽ khác nhau. Ví dụ: nếu một dự án phát hiện trung bình 5 lỗi / tuần và dự án mới phát hiện ra 10 lỗi / tuần thì điều đó không nhất thiết có nghĩa là có gì đó không đúng. Nó chỉ có thể là nhóm thử nghiệm tỉ mỉ hơn trong thời gian này. Ngoài ra, định nghĩa của "bình thường" có thể thay đổi trong vòng đời của dự án.

Số liệu chỉ là một nhiệt kế, những gì bạn làm với nó là tùy thuộc vào bạn.

Mã nguồn là một trách nhiệm, không phải là một tài sản. Với ý nghĩ đó, việc đo các dòng mã tương tự như theo dõi số tiền chi tiêu trong khi xây dựng một ngôi nhà. Nó cần phải được thực hiện nếu bạn muốn ở trong ngân sách, nhưng bạn không nhất thiết nghĩ rằng chi 1000 đô la một ngày sẽ tốt hơn chi 50 đô la một ngày; bạn muốn biết bao nhiêu ngôi nhà được xây dựng cho số tiền đó. Nó giống với các dòng mã trong một dự án phần mềm.

Nói tóm lại, không có số liệu hữu ích nào cho mã nguồn bởi vì bản thân việc đo mã nguồn không hữu ích.

Vì mã nguồn chỉ đơn giản là sự kết hợp của chuỗi, lựa chọn và lặp lại. Nếu tôi mô tả phần mềm tối ưu nhất mà chúng ta có thể mong đợi một cách hợp lý để sản xuất thì nó sẽ như sau. Phần mềm với độ bao phủ mã thử nghiệm gần 100% sử dụng ít dòng mã nhất cần thiết để thực hiện công việc và đủ linh hoạt để chịu được các thay đổi.

Một giai thoại cho thấy lý do tại sao số lượng KLOC là vô dụng (và thậm chí có hại) để đánh giá hiệu suất.

Cách đây nhiều năm, tôi đã làm việc trong một dự án lớn (hơn 70 người trong công ty của chúng tôi, hơn 30 khách hàng khác) sử dụng số lượng KLOC làm thước đo duy nhất về hiệu suất của các nhóm và cá nhân.

Đối với nỗ lực Y2K của chúng tôi (cho bạn biết cách đây bao lâu :)) chúng tôi đã dọn sạch phần mã mà nhóm của tôi chịu trách nhiệm. Chúng tôi đã kết thúc việc phát hành viết khoảng 30.000 dòng mã, không phải là 3 tháng làm việc tồi tệ cho 5 người. Chúng tôi cuối cùng cũng đã loại bỏ 70.000 dòng mã khác, một công việc rất tốt trong 3 tháng làm việc, đặc biệt là kết hợp với mã mới.

Kết quả cuối cùng cho quý: -40.000 dòng mã. Trong quá trình đánh giá hiệu suất sau quý, chúng tôi đã nhận được lời khiển trách chính thức từ công ty vì đã không đáp ứng yêu cầu năng suất của chúng tôi là 20.000 dòng mã được sản xuất mỗi quý (sau tất cả, các công cụ đã cho thấy chúng tôi đã sản xuất -40.000 dòng mã), trong đó sẽ dẫn đến việc tất cả chúng ta bị liệt kê là hoạt động kém và bị bỏ qua cho các chương trình khuyến mãi, đào tạo, tăng lương, v.v., không phải người quản lý dự án và nhóm QA đã can thiệp và bị khiển trách lật lại và thay thế bằng một lời khen.

Vài tháng sau (những việc như vậy mất thời gian) chúng tôi được thông báo rằng công ty đang xem xét tiêu chuẩn năng suất của họ và đã thuê một nhóm chuyên gia để tạo ra một hệ thống mới dựa trên phân tích điểm chức năng.

Tôi ngạc nhiên khi không ai đề cập đến Tuyên bố / Bảo hiểm Quyết định của các bài kiểm tra Đơn vị (phần trăm mã được thực hiện bằng các bài kiểm tra đơn vị).

Bảo hiểm mã rất hữu ích ở chỗ bạn biết bao nhiêu phần trăm của ứng dụng không thất bại thảm hại; với phần còn lại của tính hữu dụng của nó phụ thuộc vào chất lượng của các bài kiểm tra đơn vị.

Cam kết càng nhỏ càng tốt. Đây là về các công cụ SCM, không phải mã per-se, nhưng nó là một số liệu rất có thể đo lường được. Cam kết càng nhỏ thì càng dễ thấy mỗi thay đổi là một đơn vị nguyên tử; càng dễ dàng để hoàn nguyên các thay đổi cụ thể và điểm chốt khi mọi thứ bị phá vỡ.

Miễn là không có cam kết phá vỡ bản dựng ...

Đây không phải là số liệu tuyệt đối rất hữu ích về mặt tiến độ, nhưng có thể được sử dụng để đưa ra ý tưởng chung về trạng thái của mã.

Đáng chú ý là độ phức tạp Cyclomatic tôi đã thấy là hữu ích về mặt trực quan hóa cách thức mô đun hóa một cơ sở mã đã cho. Bạn thường muốn độ phức tạp thấp vì điều này có nghĩa là số lượng nguồn trên mỗi mô-đun thấp và có nhiều mô-đun.

Tôi thường làm việc trên một gói C ++ khổng lồ và khi tìm kiếm mã có vấn đề đáng để cấu trúc lại Cyclomatic Complexity hoặc FanIn / FanOut khủng khiếp thường là những lá cờ đỏ khá tốt để tìm kiếm. Khắc phục sự cố thường sẽ dẫn đến các cải tiến trong toàn bộ cơ sở mã.

Tất nhiên những con số này chỉ có thể phục vụ như một gợi ý về những gì sẽ đáng xem. Làm cho điều này trở thành một ngưỡng cứng sau đó để thất bại trong việc xây dựng hoặc từ chối một cam kết sẽ là vô lý.

Có nhiều tình huống trong công việc của tôi khi tôi sử dụng số liệu mã:

Trong khi viết mã

Công dụng lớn nhất và có lẽ là quan trọng nhất trong công việc hàng ngày của tôi là trong Checkstyle , một công cụ dành cho các nhà phát triển java liên tục kiểm tra các số liệu (trong số những thứ khác) của mã của tôi theo một bộ quy tắc mà chúng tôi đã xác định và gắn cờ những nơi mà mã của tôi không tuân thủ các quy tắc đó. Khi tôi phát triển mã, nó sẽ cho tôi biết trong thời gian thực nếu các phương thức của tôi trở nên dài, phức tạp hoặc được ghép nối cho phép tôi lùi lại và suy nghĩ về việc tái cấu trúc nó thành một thứ gì đó tốt hơn.

Các nhà phát triển hoàn toàn tự do để phá vỡ tất cả các quy tắc vì chúng sẽ không bao giờ áp dụng cho tất cả các tình huống. Các "quy tắc" là có để kích thích suy nghĩ và nói "Này, đây có phải là cách tốt nhất để làm điều này?"

Trong QA / Code Nhận xét

Điều đầu tiên tôi thường làm khi thực hiện đánh giá mã là kiểm tra mức độ bao phủ mã của mã mà tôi đang xem xét kết hợp với một công cụ bao trùm mã làm nổi bật dòng mã nào đã được bảo hiểm. Điều này cho tôi một ý tưởng chung về mức độ kỹ lưỡng của mã kiểm tra. Tôi không thực sự quan tâm nếu phạm vi bảo hiểm là 20% hoặc 100% miễn là mã quan trọng được kiểm tra tốt. Do đó, phần trăm được bảo hiểm có phần vô nghĩa, nhưng 0% chắc chắn nổi bật như ngón tay cái đau như một thứ tôi muốn xem xét cẩn thận.

Tôi cũng kiểm tra xem các số liệu mà nhóm đã đồng ý đã bị 'phá vỡ', nếu có, để xem liệu tôi có đồng ý với nhà phát triển rằng nó ổn hay không nếu tôi có thể đề xuất các cách để cải thiện nó. Việc các số liệu phát triển này được thống nhất trong nhóm của chúng tôi để viết mã mới đã giúp cải thiện mã của chúng tôi. Chúng tôi viết các phương pháp nguyên khối ít hơn nhiều và tốt hơn nhiều theo nguyên tắc trách nhiệm duy nhất bây giờ.

Xu hướng cải tiến cho mã kế thừa Chúng tôi có rất nhiều mã kế thừa xung quanh mà chúng tôi muốn cải thiện. Các số liệu tại bất kỳ thời điểm nào đều khá vô dụng, nhưng điều quan trọng đối với chúng tôi là độ bao phủ mã theo thời gian tăng lên và những thứ như độ phức tạp và khớp nối đi xuống. Do đó, số liệu của chúng tôi được cắm vào máy chủ Tích hợp liên tục của chúng tôi cho phép chúng tôi xem xét theo thời gian để đảm bảo chúng tôi đang đi đúng hướng.

Làm quen với một cơ sở mã mới Giới thiệu lần duy nhất tôi từng sử dụng các dòng số liệu mã nguồn là khi nhìn vào một cơ sở mã mà tôi không quen thuộc. Nó cho phép tôi nhanh chóng đánh giá kích thước thô của dự án so với các dự án khác mà tôi đã làm việc cùng. Sử dụng các số liệu khác tôi cũng có thể có được một ý tưởng sơ bộ hơn về chất lượng của dự án.

Điều quan trọng là sử dụng các số liệu làm điểm khởi đầu cho xu hướng, thảo luận hoặc cách chuyển tiếp và không quản lý chúng theo số liệu chính xác. Nhưng tôi thực sự tin tưởng rằng họ có thể giúp bạn cải thiện mã bạn ngay khi được sử dụng đúng cách.

Q: các số liệu hữu ích để nắm bắt cho mã nguồn là gì?

Cho doanh nghiệp:

A: Số giờ

Đối với người giám sát của coder:

A: Không quan trọng. Hôm nay hãy làm mọi thứ

Vì lòng tự trọng của coder:

A: Số SLOC (Dòng mã nguồn)

Dành cho mẹ của coder:

A: Ăn nhiều những cuộn Pháp mềm và uống trà

tiếp tục trong các bình luận bên dưới ...

Ghi nhớ: Tất cả các mã có thể được giảm ít nhất 1 lệnh. Tất cả các mã có ít nhất 1 lỗi. Do đó, tất cả các mã có thể được giảm xuống thành một lệnh không hoạt động. Mong rằng sẽ giúp!