Làm thế nào để đo lường khả năng duy trì một cách có ý nghĩa?

Bối cảnh: Tôi là một nhà phát triển doanh nghiệp trong một cửa hàng toàn MS.

Bất cứ ai cũng có thể đề xuất một cách tốt để đo lường một cách khách quan khả năng duy trì của một đoạn mã hoặc một ứng dụng?

Tại sao khả năng bảo trì : Tôi mệt mỏi với các số liệu "chất lượng" trong nhóm của mình chỉ xoay quanh số lượng lỗi và phạm vi bảo hiểm mã. Cả hai số liệu đều dễ chơi, đặc biệt là khi bạn không đo lường khả năng bảo trì. Sự thiển cận và thời hạn dẫn đến một khoản nợ kỹ thuật khổng lồ không bao giờ thực sự được giải quyết.

Tại sao khả năng đo lường khách quan : Tôi làm việc trong một nhóm doanh nghiệp lớn. Nếu bạn không thể đo lường một cách khách quan, bạn không thể buộc mọi người phải chịu trách nhiệm về điều đó hoặc khiến họ trở nên tốt hơn. Các phép đo chủ quan không xảy ra hoặc không xảy ra nhất quán.

Tôi đang xem số liệu mã VS2010 , nhưng tôi tự hỏi liệu có ai có bất kỳ đề xuất nào khác không.

Thông báo trước về khả năng duy trì là bạn đang cố gắng dự đoán tương lai. Mã bảo hiểm, số lỗi, LỘC, độ phức tạp chu kỳ tất cả đối phó với hiện tại .

Thực tế là trừ khi bạn có bằng chứng cụ thể rằng mã không thể duy trì được như vậy..ie ... sửa một lỗi gây ra N số giờ không cần thiết do mã không thể duy trì được; sau đó có một chân để đứng sẽ vốn đã khó khăn. Trong ví dụ này, điều này có thể được gây ra bởi thực tế là một phương pháp quá phức tạp đã được sử dụng khi một cái gì đó đơn giản hơn nhiều sẽ có hiệu lực. Đi vào một khu vực nơi bạn cố gắng đo lường các phương pháp, mô hình và thực tiễn tốt nhất trở nên ngày càng khó khăn với ít hoặc không có lợi ích lâu dài.

Đi xuống con đường này không may là một con đường đến hư không. Tập trung vào việc phát hiện ra các vấn đề gốc có giá trị đáng kể và không bị ràng buộc với cảm xúc cá nhân về một vấn đề như thiếu quy ước đặt tên trên cơ sở mã và tìm cách đo lường thành công và thất bại xung quanh vấn đề gốc đó. Điều này sau đó sẽ cho phép bạn bắt đầu tập hợp một tập hợp các khối xây dựng mà từ đó bạn có thể bắt đầu hình thành các giải pháp xung quanh.

Chà, biện pháp tôi sử dụng, hoặc muốn nghĩ rằng tôi sử dụng, là:

Đối với mỗi yêu cầu chức năng độc lập, một dòng, một dòng, mang theo hoặc để lại nó, hãy chụp nhanh cơ sở mã trước khi thực hiện nó. Sau đó thực hiện nó, bao gồm cả việc tìm và sửa bất kỳ lỗi nào được giới thiệu trong quy trình. Sau đó chạy một diffgiữa cơ sở mã trước và sau. Các diffsẽ cho bạn thấy một danh sách của tất cả các chèn, xóa, và sửa đổi mà thực hiện sự thay đổi. (Giống như chèn 10 dòng mã liên tiếp là một thay đổi.) Có bao nhiêu thay đổi? Thông thường, số đó càng nhỏ, mã càng dễ bảo trì.

Tôi gọi đó là sự dư thừa của mã nguồn, vì nó giống như sự dư thừa của mã sửa lỗi. Thông tin được chứa trong 1 đoạn, nhưng được mã hóa thành N khối, tất cả phải được thực hiện cùng nhau, để thống nhất.

Tôi nghĩ rằng đây là ý tưởng đằng sau DRY, nhưng nó chung chung hơn một chút. Lý do tốt cho số đó là thấp, nếu N thay đổi để thực hiện một yêu cầu điển hình và với tư cách là một lập trình viên dễ hiểu, bạn chỉ thực hiện đúng N-1 hoặc N-2 trong số đó, bạn đã đưa vào 1 hoặc 2 lỗi. Trên nỗ lực lập trình O (N), những lỗi đó phải được phát hiện, định vị và sửa chữa. Đó là lý do tại sao N nhỏ là tốt.

Duy trì không nhất thiết có nghĩa là có thể đọc được, đối với một lập trình viên chưa học cách làm việc của mã. Tối ưu hóa N có thể yêu cầu thực hiện một số điều tạo ra một lộ trình học tập cho các lập trình viên. Đây là một ví dụ. Một điều có ích là nếu lập trình viên cố gắng dự đoán những thay đổi trong tương lai và để lại hướng dẫn trong phần bình luận của chương trình.

Tôi nghĩ rằng khi N được giảm đủ xa (tối ưu là 1) thì mã nguồn sẽ đọc giống như ngôn ngữ dành riêng cho tên miền (DSL). Chương trình không "giải quyết" vấn đề nhiều như nó "giải quyết" vấn đề, bởi vì lý tưởng là mỗi yêu cầu chỉ được trình bày lại dưới dạng một đoạn mã.

Thật không may, tôi không thấy mọi người học cách làm điều này rất nhiều. Thay vào đó, họ dường như nghĩ rằng các danh từ tinh thần nên trở thành các lớp và động từ trở thành phương thức, và tất cả những gì họ phải làm là biến quây. Theo kinh nghiệm của tôi, điều đó dẫn đến mã có từ 30 trở lên.

Khả năng bảo trì không phải là có thể đo lường được thực sự. Đó là một cái nhìn chủ quan của một cá nhân dựa trên kinh nghiệm và sở thích của anh ta.

Đối với một đoạn mã đưa ra một ý tưởng về một thiết kế hoàn hảo .

Sau đó, đối với bất kỳ sai lệch nào của mã thực so với mã hoàn hảo đó sẽ làm giảm giá trị 100 của một số. Bởi những gì chính xác phụ thuộc vào hậu quả của một cách tiếp cận không hoàn hảo đã chọn.

Một ví dụ:

Một đoạn mã đọc và nhập một số định dạng dữ liệu và có thể hiển thị thông báo lỗi nếu có gì đó không đúng.

Một giải pháp hoàn hảo (100) sẽ có các thông báo lỗi được giữ ở một nơi chung. Nếu giải pháp của bạn có mã hóa cứng là hằng số chuỗi trực tiếp trong mã, bạn hãy bỏ qua, tắt 15. Vì vậy, chỉ số duy trì của bạn trở thành 85.

Một kết quả của mã khó bảo trì là nó sẽ khiến bạn mất nhiều thời gian hơn (trung bình ") để sửa lỗi. Vì vậy, thoạt nhìn, một số liệu dường như là thời gian để sửa lỗi từ khi được chỉ định (tức là quá trình sửa lỗi được bắt đầu) cho đến khi "sẵn sàng để thử nghiệm".

Bây giờ, điều này sẽ chỉ thực sự hoạt động sau khi bạn đã sửa một số lỗi hợp lý để có thời gian "trung bình" (nghĩa là bao giờ). Bạn không thể sử dụng số liệu cho bất kỳ lỗi cụ thể nào vì việc theo dõi nó khó đến mức nào không chỉ phụ thuộc vào "khả năng bảo trì" của mã.

Tất nhiên, khi bạn sửa nhiều lỗi hơn, mã sẽ trở nên "dễ bảo trì" hơn vì bạn đang làm cho nó tốt hơn (hoặc ít nhất là bạn nên như vậy) và bạn đang trở nên quen thuộc hơn với mã. Chống lại thực tế đó là các lỗi sẽ có xu hướng tối nghĩa hơn và do đó khó theo dõi hơn.

Điều này cũng gặp phải vấn đề là nếu mọi người sẽ có xu hướng vội vàng sửa lỗi để có điểm thấp hơn, do đó gây ra lỗi mới hoặc không sửa lỗi hiện tại dẫn đến nhiều công việc hơn và thậm chí có thể tệ hơn.

Tôi thấy các Số liệu Mã của Visual Studio khá tốt để cung cấp số liệu "khả năng bảo trì" nhanh chóng. 5 số liệu chính được nắm bắt:

• Phức tạp cyclomatic
• Độ sâu của sự kế thừa
• Lớp học
• Các dòng mã (mỗi phương thức, mỗi lớp, mỗi dự án, bất cứ điều gì, tùy thuộc vào mức độ cuộn lên của bạn)

Chỉ số bảo trì là một trong những tôi thấy tiện dụng. Đây là một chỉ số tổng hợp, dựa trên:

1. Tổng kích thước (Dòng mã)
2. Số lớp hoặc tệp
3. # của phương pháp
4. Độ phức tạp theo chu kỳ trên 20 (hoặc 10 - có thể định cấu hình, 10 là tùy chọn của tôi)
5. Sao chép

Thỉnh thoảng tôi sẽ xem xét các phương pháp của mình với Chỉ số duy trì thấp (thấp = xấu cho phương pháp này). Hầu như không thất bại, các phương thức trong dự án của tôi với Chỉ số duy trì thấp nhất là những phương pháp cần viết lại nhất và khó đọc nhất (hoặc duy trì).

Xem giấy trắng để biết thêm thông tin về các tính toán.

Hai cái sẽ có ý nghĩa là độ phức tạp chu kỳ và khớp nối lớp. Bạn không thể loại bỏ sự phức tạp, tất cả những gì bạn có thể làm là phân vùng nó thành các phần có thể quản lý được. Hai biện pháp này sẽ cung cấp cho bạn ý tưởng về nơi có thể đặt mã khó bảo trì hoặc ít nhất là nơi khó tìm nhất.

Độ phức tạp theo chu kỳ là thước đo xem có bao nhiêu đường dẫn trong mã. Mỗi đường dẫn nên được kiểm tra (nhưng có lẽ là không). Một cái gì đó có độ phức tạp trên khoảng 20 nên được chia thành các mô-đun nhỏ hơn. Một mô-đun có độ phức tạp không gian mạng là 20 (người ta có thể nhân đôi điều này với 20 if then elsekhối liên tiếp ) sẽ có giới hạn trên là 2 ^ 20 đường dẫn để kiểm tra.

Khớp nối lớp là thước đo mức độ ràng buộc chặt chẽ của các lớp. Một ví dụ về một số mã xấu mà tôi đã làm việc với chủ nhân trước đây của tôi bao gồm thành phần "lớp dữ liệu" với khoảng 30 mục trong hàm tạo. Người chủ yếu "chịu trách nhiệm" cho thành phần đó tiếp tục thêm các tham số lớp UI và giao diện người dùng vào hàm tạo / cuộc gọi mở cho đến khi nó là một quả bóng bùn thực sự lớn. Nếu bộ nhớ phục vụ cho tôi một cách chính xác, có khoảng 15 cuộc gọi mới / mở khác nhau (một số cuộc gọi không còn được sử dụng nữa), tất cả đều có các tham số hơi khác nhau. Chúng tôi đã thiết lập các bài đánh giá mã cho mục đích duy nhất là ngăn anh ta làm nhiều việc như thế này - và để tránh làm cho chúng tôi giống như anh ta, anh ta đã xem lại mã của mọi người trong đội, vì vậy chúng tôi đã lãng phí khoảng nửa ngày cho 4 - 6 mọi người mỗi ngày bởi vì chúng tôi đã không

Ở điểm mấu chốt, khả năng bảo trì thực sự chỉ có thể được đo sau khi được yêu cầu, không phải trước đó . Đó là, bạn chỉ có thể nói, liệu một đoạn mã có thể duy trì được hay không, khi bạn phải duy trì nó.

Nó là tương đối rõ ràng để đo mức độ dễ dàng để thích ứng một đoạn mã với các yêu cầu thay đổi. Nó gần như không thể đo lường trước thời hạn, làm thế nào nó sẽ đáp ứng với những thay đổi trong yêu cầu. Điều này có nghĩa là, bạn phải dự đoán những thay đổi trong yêu cầu. Và nếu bạn có thể làm điều đó, bạn sẽ nhận được một mức giá cao quý;)

Điều duy nhất bạn có thể làm là đồng ý với nhóm của mình, dựa trên một bộ quy tắc cụ thể (chẳng hạn như các nguyên tắc RẮN), mà tất cả các bạn tin rằng nói chung đều tăng khả năng bảo trì.
Nếu các nguyên tắc được lựa chọn tốt (tôi nghĩ rằng bắt đầu với RẮN sẽ là một lựa chọn tốt để bắt đầu), bạn hoàn toàn có thể chứng minh rằng họ đang bị vi phạm và buộc các tác giả phải chịu trách nhiệm về điều đó.
Bạn sẽ có một thời gian rất khó khăn, cố gắng thúc đẩy một biện pháp tuyệt đối cho khả năng duy trì, trong khi dần dần thuyết phục nhóm của bạn tuân thủ một tập hợp các nguyên tắc đã được thiết lập thực tế.

khoản nợ kỹ thuật khổng lồ không bao giờ thực sự được giải quyết

Thế còn nợ kỹ thuật "bị vượt qua bởi các sự kiện" thì sao?

Tôi viết mã crappy và đưa nó vào sản xuất.

Bạn quan sát - chính xác - rằng nó không thể duy trì.

Tuy nhiên, mã đó là vòng tính năng cuối cùng cho một dòng sản phẩm sẽ ngừng hoạt động vì bối cảnh pháp lý đã thay đổi và dòng sản phẩm không có tương lai.

"Nợ kỹ thuật" được loại bỏ bởi một sự thay đổi về mặt lập pháp khiến tất cả trở nên lỗi thời.

Số liệu "khả năng duy trì" đã chuyển từ "xấu" sang "không liên quan" do những cân nhắc bên ngoài.

Làm thế nào mà có thể được đo?

Điều tốt nhất tiếp theo để đánh giá mã ngang hàng là tạo ra một kiến ​​trúc có thể làm việc trước khi mã hóa một đơn vị hoặc sản phẩm. Red-green-refactor là một cách khá gọn gàng để đi về nó. Có một anh chàng Sr. kết hợp một giao diện hoàn toàn khả thi và sắp xếp công việc. Mọi người đều có thể lấy mảnh ghép của mình và xanh đỏ để chiến thắng. Sau này, một đánh giá và tái cấu trúc mã ngang hàng sẽ được thực hiện theo thứ tự. Điều này đã làm việc khá tốt trên một sản phẩm lớn trong quá khứ tôi đã làm việc.

Bảng câu hỏi

Điều gì về việc tạo một bảng câu hỏi ẩn danh cho các nhà phát triển, để điền vào mỗi tháng một lần hoặc lâu hơn? Các câu hỏi sẽ giống như:

• Bạn đã dành bao nhiêu thời gian trong tháng trước cho dự án X (khoảng) [0% ... 100%]
• Làm thế nào bạn đánh giá trạng thái của cơ sở mã về khả năng duy trì [thực sự nghèo, nghèo, trung lập, ổn, tốt, thực sự tốt].
• Mức độ phức tạp của bạn sẽ đánh giá cơ sở mã so với độ phức tạp của dự án [cách quá phức tạp, vừa phải, quá đơn giản].
• Bạn có thường xuyên cảm thấy bạn bị cản trở trong việc giải quyết các nhiệm vụ của mình do sự phức tạp quá mức của cơ sở mã không? [hoàn toàn không, thỉnh thoảng, thường xuyên, liên tục].

(Vui lòng thêm các câu hỏi bổ sung mà bạn nghĩ sẽ hữu ích trong việc đo lường khả năng duy trì trong các nhận xét và tôi sẽ thêm chúng.)

Tôi có thể nghĩ ra hai cách để xem xét khả năng bảo trì (tôi chắc chắn có nhiều hy vọng người khác có thể đưa ra các định nghĩa tốt.

Sửa đổi mà không hiểu.

Một người sửa lỗi có thể đi vào mã và khắc phục sự cố mà không cần phải hiểu toàn bộ hệ thống hoạt động như thế nào.

Điều này có thể đạt được bằng cách cung cấp các bài kiểm tra đơn vị toàn diện (kiểm tra hồi quy). Bạn sẽ có thể kiểm tra xem mọi thay đổi đối với hệ thống không thay đổi cách hệ thống hoạt động với bất kỳ đầu vào tốt cụ thể nào.

Trong tình huống này, một người sửa lỗi sẽ có thể đến và sửa một lỗi (đơn giản) chỉ với một kiến ​​thức tối thiểu về hệ thống. Nếu sửa chữa hoạt động thì không có thử nghiệm hồi quy nào thất bại. Nếu bất kỳ bài kiểm tra hồi quy nào thất bại thì bạn cần chuyển sang giai đoạn 2.

maintainabilty1 = K1 . (Code Coverage)/(Coupling of Code) * (Complexity of API)

Sửa đổi với sự hiểu biết.

Nếu một sửa lỗi trở nên không tầm thường và bạn cần hiểu hệ thống. Sau đó, các tài liệu của hệ thống như thế nào. Chúng tôi không nói về tài liệu của API bên ngoài (chúng tương đối vô dụng). Những gì chúng ta cần hiểu là làm thế nào hệ thống hoạt động trong đó bất kỳ thủ thuật thông minh (đọc hack) nào được sử dụng trong việc triển khai, v.v.

Nhưng tài liệu không đủ mã cần phải rõ ràng và dễ hiểu. Để đo lường mức độ dễ hiểu của một mã chúng ta có thể sử dụng một mẹo nhỏ. Sau khi nhà phát triển hoàn thành mã hóa, hãy cho anh ấy / cô ấy một tháng để làm việc khác. Sau đó yêu cầu họ quay lại và ghi lại hệ thống đến một mức mà giờ đây một bến tàu có thể hiểu hệ thống. Nếu mã tương đối dễ hiểu thì nên nhanh chóng. Nếu nó được viết xấu, họ sẽ mất nhiều thời gian hơn để tìm ra những gì họ đã xây dựng và viết tài liệu.

Vì vậy, có lẽ chúng ta có thể đưa ra một số biện pháp này:

maintainability2 = K2 . (Size of doc)/(Time to write doc)

Tôi thường thấy rằng giải pháp "tương đương ngắn nhất" có xu hướng dễ bảo trì nhất.

Ở đây ngắn nhất có nghĩa là các hoạt động ít nhất (không phải dòng). Và tương đương có nghĩa là giải pháp ngắn hơn không nên phức tạp về thời gian hoặc không gian hơn so với giải pháp trước đó.

Điều này có nghĩa là tất cả các mẫu lặp lại tương tự logic nên được trích xuất để trừu tượng hóa phù hợp: Các khối mã tương tự? Giải nén nó để hoạt động. Các biến dường như xảy ra với nhau? Trích xuất chúng thành một cấu trúc / lớp. Các lớp có thành viên chỉ khác nhau theo loại? Bạn cần một cái chung. Bạn dường như tính toán lại điều tương tự ở nhiều nơi? Tính toán ở đầu và lưu trữ giá trị trong một biến. Làm những điều này sẽ dẫn đến mã ngắn hơn. Đó là nguyên tắc DRY về cơ bản.

Chúng ta cũng có thể đồng ý rằng các khái niệm trừu tượng không được sử dụng nên bị xóa: các lớp, các hàm không còn cần thiết là mã chết, vì vậy nó sẽ bị xóa. Kiểm soát phiên bản sẽ ghi nhớ nếu chúng ta cần khôi phục nó.

Những gì thường được tranh luận là trừu tượng chỉ được tham chiếu một lần: các hàm không gọi lại chỉ được gọi một lần mà không có lý do nào được gọi nhiều hơn một lần. Một cái chung được khởi tạo chỉ bằng một loại, và không có lý do gì nó sẽ được khởi tạo với loại khác. Các giao diện được triển khai chỉ một lần và không có lý do thực sự nào mà nó sẽ được thực hiện bởi bất kỳ lớp nào khác, v.v. Tôi cho rằng những thứ này là không cần thiết và cần được loại bỏ, về cơ bản đó là nguyên tắc YAGNI.

Vì vậy, cần có một công cụ có thể phát hiện sự lặp lại mã, nhưng tôi nghĩ đó là vấn đề gần giống với việc tìm ra cách nén tối ưu, đó là vấn đề phức tạp Kolmogorov không thể giải quyết được. Nhưng ở đầu bên kia không được sử dụng và dưới sự trừu tượng được sử dụng rất dễ phát hiện dựa trên số lượng tài liệu tham khảo: một kiểm tra cho điều đó có thể được tự động.

Tất cả chỉ là chủ quan và bất kỳ phép đo nào dựa trên chính mã này cuối cùng đều không liên quan. Cuối cùng, khả năng của bạn là đáp ứng nhu cầu. Bạn vẫn có thể cung cấp các tính năng đang được yêu cầu và nếu bạn có thể, những thay đổi đó sẽ trở lại với bạn thường xuyên như thế nào vì điều gì đó chưa hoàn toàn đúng và những vấn đề đó nghiêm trọng đến mức nào?

Tôi chỉ (tái) xác định khả năng bảo trì nhưng nó vẫn chủ quan. Mặt khác, điều đó có thể không quan trọng lắm. Chúng tôi chỉ cần làm hài lòng khách hàng và tận hưởng nó, đó là những gì chúng tôi đang hướng tới.

Rõ ràng bạn cảm thấy bạn phải chứng minh với sếp hoặc đồng nghiệp của mình rằng cần phải làm gì đó để cải thiện trạng thái của cơ sở mã. Tôi sẽ cho rằng nó đủ để bạn nói rằng bạn đang thất vọng bởi thực tế là với mỗi điều nhỏ bạn phải thay đổi hoặc thêm bạn phải sửa chữa hoặc khắc phục khoảng 10 vấn đề khác có thể tránh được. Sau đó, đặt tên cho một khu vực khét tiếng và làm cho một trường hợp để đảo lộn nó. Nếu điều đó không nâng cao bất kỳ sự hỗ trợ nào trong nhóm của bạn, bạn có thể tốt hơn ở một nơi khác. Nếu mọi người xung quanh bạn không quan tâm, chứng tỏ quan điểm của bạn sẽ không thay đổi suy nghĩ của họ.