Làm thế nào tôi có thể định nghĩa và đo lường sự đơn giản trong mã?

Có nhiều câu trả lời trong câu hỏi trước đây của tôi về tính đơn giản liên quan đến tính dễ đọc giúp tôi thấy định nghĩa và sự hiểu biết về tính đơn giản trong mã là, rất có thể, không chính xác.

Làm thế nào tôi có thể định nghĩa sự đơn giản trong mã? Những phép đo và số liệu phần mềm nào có sẵn để đo lường sự đơn giản của mã?

Các số liệu phổ biến nhất để đo độ phức tạp (hoặc đơn giản, nếu bạn coi sự đơn giản là đối lập với độ phức tạp) là Độ phức tạp theo chu kỳ của McCabe và Số liệu độ phức tạp Halstead .

Độ phức tạp theo chu kỳ đo số lượng các đường dẫn riêng biệt thông qua một đơn vị nhất định, thường là một phương thức hoặc hàm, mặc dù nó cũng có thể được tính trên một lớp. Khi số lượng đường dẫn tăng lên, việc ghi nhớ luồng dữ liệu thông qua một mô-đun đã cho sẽ trở nên khó khăn hơn, có liên quan đến khái niệm bộ nhớ làm việc . Độ phức tạp chu kỳ cao có xu hướng cho thấy khó khăn trong khả năng kiểm tra một mô-đun - cần nhiều trường hợp thử nghiệm hơn để bao quát các đường dẫn khác nhau thông qua hệ thống. Cũng đã có những nghiên cứu đã liên kết độ phức tạp chu kỳ cao với tỷ lệ khuyết tật cao. Thông thường, độ phức tạp theo chu kỳ là 10 chỉ ra rằng một đơn vị nên được xem xét và có thể được tái cấu trúc.

Các biện pháp phức tạp Halstead sử dụng đầu vào của các toán tử và toán hạng tổng và riêng biệt để tính toán khối lượng, độ khó và nỗ lực của một đoạn mã. Khó khăn, đó là (số toán tử duy nhất / 2) * (tổng số toán hạng / số toán hạng duy nhất), gắn liền với khả năng đọc và hiểu mã cho các tác vụ như tìm hiểu hệ thống hoặc thực hiện đánh giá mã. Một lần nữa, bạn có thể tính điều này ở cấp độ hệ thống, cấp độ lớp hoặc cấp độ phương thức / chức năng. Có một vài bài đăng về tính toán các phép đo này ở đây và đây .

Chỉ cần đếm các dòng mã cũng có thể cho bạn một ý tưởng về sự phức tạp. Nhiều dòng mã hơn có nghĩa là có nhiều thứ để đọc và hiểu trong một mô-đun. Tôi sẽ do dự khi sử dụng nó như một phép đo độc lập. Thay vào đó, tôi sẽ sử dụng nó với các phép đo khác, chẳng hạn như số lượng khuyết tật trong một mô-đun nhất định để có được mật độ khuyết tật. Mật độ khiếm khuyết cao có thể chỉ ra các vấn đề trong việc viết bài kiểm tra và thực hiện đánh giá mã, điều này có thể hoặc không thể gây ra bởi mã phức tạp.

Fan-in và fan-out là hai số liệu khác, liên quan đến luồng dữ liệu. Như được định nghĩa ở đây , fan in là tổng của các thủ tục được gọi, đọc tham số và biến toàn cục đọc và quạt là tổng các thủ tục gọi một thủ tục đã cho, các tham số được ghi (tiếp xúc với người dùng bên ngoài, được truyền qua tham chiếu), và các biến toàn cục được viết thành. Một lần nữa, fan-in và fan-out cao có thể là dấu hiệu của một mô-đun có thể khó hiểu.

Trong các mô hình cụ thể, có thể có các biện pháp hoặc số liệu khác cũng hữu ích. Ví dụ, trong thế giới hướng đối tượng, khớp nối giám sát (ham muốn thấp), sự gắn kết (ham muốn cao) và độ sâu của thừa kế (ham muốn thấp) có thể được sử dụng để đánh giá mức độ đơn giản hoặc phức tạp của một hệ thống.

Tất nhiên, điều quan trọng là phải nhận ra rằng rất nhiều biện pháp và số liệu chỉ đơn giản là các chỉ số. Bạn cần sử dụng phán đoán của mình để xác định xem có cần thiết phải cấu trúc lại để tăng tính đơn giản hay không nếu nó không đáng để nỗ lực làm điều đó. Bạn có thể thực hiện các phép đo, tính toán các số liệu và tìm hiểu về mã của mình, nhưng bạn không muốn thiết kế hệ thống của mình theo các con số. Cuối cùng, làm những gì có ý nghĩa.

Thay vì nhìn vào một chế độ chính thức để xác định tính đơn giản, tôi muốn xác định tính đơn giản là một thuộc tính của chất lượng viết mã.

Tôi không đặt ra một số biện pháp đơn giản nhưng khi nào bạn gọi một cái gì đó đơn giản hay không.

1. Code Traversal:
Dễ dàng điều hướng qua mã như thế nào? Có dễ dàng nhận ra nơi các hàm API được viết không? Có dễ hiểu các luồng cuộc gọi không, ví dụ các phương thức nào đang gọi các phương thức khác (và tại sao) - có các máy trạng thái tốt được triển khai hoặc xác định rõ ràng các thuật toán không?

Khi truyền tải mã dễ dàng, mã rất đơn giản để làm theo.

2. Đặt tên
Trong khi các tiêu chuẩn mã hóa khác giúp làm cho mã trông gọn gàng hơn - điều quan trọng nhất là việc đặt tên các lớp / đối tượng / Biến / phương thức. Việc sử dụng tên rõ ràng và rõ ràng rõ ràng có tác động lớn đến tính Đơn giản của mã. Khi khó xác định một tên đơn giản, đó là một dấu hiệu cho thấy bạn có thể muốn nghĩ lại ý tưởng là biến / phương thức đó.

3. Giải thích và tham khảo
Mỗi phương pháp của bạn có vai trò rõ ràng. Có phải mỗi biến / thuộc tính đều dễ dàng xác định vai trò họ đang chơi không? Khi một đoạn mã thực hiện điều gì đó ngụ ý các giả định hoặc ảnh hưởng đến tập hợp các biến không liên quan, có thể trở thành một cơn ác mộng bảo trì.

4. Sự phụ thuộc hoặc khớp nối
Điều này rất khó để đánh giá chỉ bằng cách xem mã, nhưng sẽ trở nên rất rõ ràng nếu ai đó cố gắng sửa lỗi của bạn. Khi một số thứ khác thay đổi trong một số đối tượng khác, hoạt động ở đây có thay đổi không? Là những thay đổi rõ ràng? Bạn có yêu cầu thay đổi API thường xuyên để chứa đồ không. Những điều này cho thấy các mối quan hệ giữa các mô hình không đơn giản

5. Đầu vào Người dùng hoặc Ứng dụng
Cuối cùng, đầu vào hoặc ứng dụng của người dùng được chấp nhận đơn giản như thế nào trên API / UI? Khi nhiều người dùng / ứng dụng có thể (cho các mục đích khác nhau) cần cung cấp cho bạn - chúng có rõ ràng không? Có các trạng thái / chi tiết không liên quan đến độ trừu tượng cao hơn nhưng vẫn đi ngược lại giao diện không?

Một câu hỏi đơn giản tôi thường hỏi là như sau: Nếu thay vì một chương trình, nếu tôi đã yêu cầu chức năng tương tự được thực hiện bởi một con người, tôi có điền thông tin này vào một biểu mẫu giấy không? Nếu không, tôi không đủ đơn giản ở đây.

Tôi sẽ không nói danh sách này là đầy đủ, nhưng tôi đoán rằng tiêu chí là việc sử dụng và sửa đổi phần mềm dễ hay khó như thế nào. Điều đó thật đơn giản.

Tôi không biết về bất kỳ số liệu tốt hiện có nào về tính đơn giản của mã (điều đó không có nghĩa là chúng không tồn tại - chỉ là tôi không biết về chúng). Tôi có thể đề xuất một số, có thể một số sẽ giúp:

• Tính đơn giản của các tính năng ngôn ngữ được sử dụng: nếu ngôn ngữ có các tính năng có thể được coi là "nâng cao" và "đơn giản", bạn có thể đếm số lần xuất hiện của các tính năng nâng cao. Cách bạn định nghĩa "nâng cao" có thể chủ quan hơn một chút. Tôi cho rằng một số người có thể nói rằng điều này cũng giống như đo lường "sự thông minh" của một chương trình. Một ví dụ phổ biến: một số có thể nói rằng ?:toán tử phải là một tính năng "nâng cao", những người khác có thể không đồng ý. Tôi không biết việc viết một công cụ có thể kiểm tra việc này dễ đến mức nào.

• Tính đơn giản của các cấu trúc trong chương trình: Bạn có thể đo số lượng tham số mà hàm sẽ chấp nhận. Nếu bạn có> n % của tất cả các hàm có tham số > m , bạn có thể chọn tính nó là không đơn giản, tùy thuộc vào cách bạn xác định n và m (có thể n = 3 và m = 6?). Tôi nghĩ rằng có một số công cụ phân tích tĩnh có thể đo lường điều này - Tôi nghĩ rằng JTest chỉ đơn giản là các hàm được đo với các tham số > m .

• Bạn có thể thử đếm số vòng lặp lồng nhau hoặc cấu trúc điều khiển. Điều này tôi nghĩ thực sự không phải là một số liệu tồi và tôi nghĩ rằng có một cái tên cho nó (không thể nhớ ra khỏi đỉnh đầu của tôi). Một lần nữa, tôi nghĩ rằng có những công cụ (một lần nữa, như JTest) có thể đo lường điều này, ở một mức độ.

• Bạn có thể thử đo "khả năng tái cấu trúc". Nếu mã của bạn chứa nhiều đoạn mã có thể được cấu trúc lại nhưng không , có lẽ điều đó sẽ không đơn giản. Tôi cũng nhớ lại từ khi tôi làm việc với JTest rằng họ cũng đã cố gắng đo lường điều này, nhưng tôi nhớ rằng tôi thường không đồng ý với nó trong trường hợp này, vì vậy YMMV.

• Bạn có thể thử đo số lớp giữa các phần khác nhau trong hệ thống của bạn. Ví dụ: có bao nhiêu đoạn mã khác nhau sẽ chạm vào dữ liệu xuất phát từ một biểu mẫu web trước khi nó được lưu trữ trong cơ sở dữ liệu? Đây có thể là một mẹo khó để đo lường chính xác ...