Mùi xấu khi xem xét mã ảnh hưởng đến phương pháp tiếp cận?

Question

G'day,

Tôi đã suy nghĩ về một nhận xét từ Kristopher Johnson về câu trả lời của tôi cho question về Chất lượng phát triển phần mềm này.

Tôi muốn gửi một danh sách các số liệu chất lượng phần mềm mà tôi có thể nghĩ ra khỏi đỉnh đầu của tôi bao gồm:

1. McCabe Cyclometric phức tạp - về cơ bản là một biện pháp của số đường dẫn tuyến tính thông qua mã.
2. Mức độ thụt đầu dòng - thước đo độ phức tạp khi xem xét các quyết định lồng nhau.
3. Khoảng cách từ việc khai báo đến lần sử dụng đầu tiên - có bao nhiêu câu lệnh tồn tại giữa nơi một biến được khai báo và nơi nó được sử dụng lần đầu tiên.
4. Phần trăm nhận xét - số lượng dòng mã là nhận xét so với mã nguồn.
5. Tỷ lệ phần trăm kiểm tra phần trăm - dưới dạng phần trăm của các dòng mã, số lượng bài kiểm tra được thực hiện bởi bộ thử nghiệm của bạn.
6. Phạm vi kiểm tra đường dẫn - bao nhiêu đường dẫn thực hiện được thực hiện bởi các thử nghiệm của bạn.
7. Bảo hiểm đơn vị - số lượng đơn vị, lớp học, gói, v.v., được thực hiện bởi các bài kiểm tra đơn vị của bạn.

bình luận Kris là:

Chỉ số liệu thử nghiệm bảo hiểm được liệt kê ở đây có thể được coi là một biện pháp của "chất lượng". Những người khác là các phép đo độ phức tạp và dễ đọc, mà thực sự không liên quan gì đến chất lượng.

Ngoài thực tế là tôi không đồng ý với tuyên bố này chút nào, điều đó khiến tôi suy nghĩ.

Khi tôi phải xem lại mã mà hầu như không có bất kỳ thử nghiệm liên quan nào, cho dù đơn vị, hệ thống hoặc tích hợp, tôi có xu hướng tiếp cận mã nhiều, thận trọng hơn nhiều so với khi tôi thấy một bộ kiểm tra tốt đã được chuyển thành công.

Điều tương tự khi thực hiện kiểm tra bảo mật trên mã. Nếu tôi thấy các biến không sử dụng, các hàm lớn, các hỗn hợp kỳ lạ của các cấu hình, trên mỗi máy chủ, mỗi thư mục, vv được sử dụng trong các mô-đun Apache, nó cũng khiến tôi tiếp cận mã rất thận trọng.

Có ai khác sử dụng phương pháp "cảm giác ruột" ban đầu này và liệu nó có ảnh hưởng đến kết quả không?

BTW Tôi không đồng ý với nhận xét của Kris vì tất cả các chỉ số khác chắc chắn là các biện pháp hợp lệ sẽ giúp làm nổi bật mã được thiết kế kém, được thực thi kém. Như Damian Conway nói:

Luôn mã hóa như là kẻ kết thúc việc duy trì mã của bạn sẽ là một kẻ tâm thần bạo lực biết bạn sống ở đâu.

Answer 1

Phát triển "cảm giác ruột" là điều phân biệt người mới bắt đầu với các chuyên gia. Sau khi bạn đạt được một số kinh nghiệm "cảm giác ruột" trở thành một trong những người đóng góp chính cho quyết định cuối cùng. Nó không quan trọng cho dù bạn đang xem xét mã của ai đó hoặc tạo kiến ​​trúc hệ thống, cảm giác ruột sẽ hướng dẫn bạn. Tuy nhiên nhà phát triển thực dụng không được quá tự tin. Luôn luôn có một nơi cho danh sách kiểm tra và các phương tiện khác.

Đối với số liệu, tôi hoàn toàn đồng ý với bạn. Chỉ số là vô nghĩa nếu nó không đóng góp vào chất lượng mã.

Answer 2

Tôi nghĩ bạn và Kris không đồng ý về định nghĩa về chất lượng. Lấy sự tương tự của một bằng chứng trong Toán học.

Bạn có thể tranh luận rằng chất lượng chỉ là liệu bằng chứng là đúng, chính xác là nó đi từ các giả định đến kết quả.Tuy nhiên, hầu hết các nhà toán học đều đồng ý rằng một số bằng chứng tốt hơn những bằng chứng khác vì chúng ngắn hơn, hay khéo léo hơn, hoặc dễ hiểu hơn, và đây là những biện pháp chất lượng. Chỉ định nghĩa đầu tiên là chính thức có thể xác định được, nhưng hầu hết các nhà toán học mà tôi nghĩ có nghĩa là thứ hai nếu họ nói "một bằng chứng tốt hơn".

Những gì Kris nói là đúng theo định nghĩa đầu tiên, chỉ các thử nghiệm thực sự đo lường chính xác, nhưng tôi nghĩ rằng hầu hết các lập trình viên, bao gồm cả tôi, sẽ liên kết chất lượng với các biện pháp của bạn.

Answer 3

Có, "gánh nặng ruột" là một công cụ rất tốt ngay sau khi bạn có một chút kinh nghiệm. Tôi dường như nhớ rằng Hunt và Thomas đề cập đến điều này trong Pragmatic Programmer. Họ nói một cái gì đó như "bạn có rất nhiều kinh nghiệm, vì vậy đừng bỏ qua cảm giác dai dẳng đó" (nếu bạn có báo giá đúng, hoặc nếu nó là từ một cuốn sách khác, hãy sửa tôi).

Carl