Mã bảo hiểm nêu bật các phương pháp không sử dụng - tôi nên làm gì?

Tôi đã được giao nhiệm vụ tăng độ bao phủ mã của một dự án Java hiện có.

Tôi nhận thấy rằng công cụ bao phủ mã ( EclEmma ) đã làm nổi bật một số phương thức không bao giờ được gọi từ bất cứ đâu.

Phản ứng ban đầu của tôi không phải là viết các bài kiểm tra đơn vị cho các phương thức này, mà là làm nổi bật chúng cho quản lý / nhóm quản lý trực tuyến của tôi và hỏi tại sao các chức năng này lại bắt đầu.

Cách tiếp cận tốt nhất sẽ là gì? Viết bài kiểm tra đơn vị cho họ, hoặc đặt câu hỏi tại sao họ ở đó?

1. Xóa bỏ.
2. Cam kết.
3. Quên.

Cơ sở lý luận:

1. Mã chết là chết. Bằng chính mô tả của nó, nó không có mục đích. Nó có thể đã có một mục đích tại một thời điểm, nhưng điều đó đã biến mất, và vì vậy mã sẽ bị biến mất.
2. Kiểm soát phiên bản đảm bảo rằng trong sự kiện duy nhất hiếm có (theo kinh nghiệm của tôi) mà ai đó đến sau để tìm mã đó, nó có thể được truy xuất.
3. Là một tác dụng phụ, bạn ngay lập tức cải thiện phạm vi bảo hiểm mã mà không làm gì cả (trừ khi mã chết được kiểm tra, điều này hiếm khi xảy ra).

Hãy cẩn thận từ các bình luận: Câu trả lời ban đầu cho rằng bạn đã xác minh kỹ lưỡng rằng mã này, vượt quá nghi ngờ, đã chết. Các IDE có thể đọc được và có một số cách mà mã trông có vẻ thực sự có thể được gọi. Mang theo một chuyên gia trừ khi bạn hoàn toàn chắc chắn.

Tất cả các câu trả lời khác đều dựa trên giả định rằng các phương pháp trong câu hỏi thực sự không được sử dụng. Tuy nhiên, câu hỏi không chỉ rõ liệu dự án này là độc lập hay một thư viện nào đó.

Nếu dự án đang nói đến là một thư viện, các phương thức dường như không được sử dụng có thể được sử dụng bên ngoài dự án và loại bỏ chúng sẽ phá vỡ các dự án khác. Nếu chính thư viện được bán cho khách hàng hoặc được cung cấp công khai, thậm chí có thể không thể theo dõi việc sử dụng các phương pháp này.

Trong trường hợp này, có bốn khả năng:

• Nếu các phương thức là riêng tư hoặc gói riêng tư, chúng có thể được gỡ bỏ một cách an toàn.
• Nếu các phương thức là công khai, sự hiện diện của chúng có thể được biện minh ngay cả khi không sử dụng thực tế, để hoàn thiện tính năng. Họ nên được kiểm tra mặc dù.
• Nếu các phương thức là công khai và không cần thiết, loại bỏ chúng sẽ là một thay đổi đột phá và nếu thư viện tuân theo phiên bản ngữ nghĩa , điều này chỉ được phép trong một phiên bản chính mới.
• Ngoài ra, các phương thức công khai cũng có thể được phản đối và loại bỏ sau đó. Điều này mang lại một chút thời gian cho người tiêu dùng API chuyển đổi từ các chức năng không dùng nữa trước khi chúng bị xóa trong phiên bản chính tiếp theo.

Trước tiên hãy kiểm tra xem công cụ bảo hiểm mã của bạn có đúng không.

Tôi đã gặp tình huống họ không chọn các phương thức được gọi thông qua các tham chiếu đến giao diện hoặc nếu lớp được tải động ở đâu đó.

Vì Java được biên dịch tĩnh, nên việc gỡ bỏ các phương thức sẽ khá an toàn. Loại bỏ mã chết luôn luôn tốt. Có một số khả năng rằng có một số hệ thống phản chiếu điên rồ chạy chúng trong thời gian chạy, vì vậy hãy kiểm tra trước với các nhà phát triển khác, nhưng nếu không thì hãy loại bỏ chúng.

Cách tiếp cận tốt nhất sẽ là gì? Viết bài kiểm tra đơn vị cho họ, hoặc đặt câu hỏi tại sao họ ở đó?

Xóa mã là một điều tốt.

Khi bạn không thể xóa mã, bạn chắc chắn có thể đánh dấu nó là @Deprecated , ghi lại bản phát hành chính nào bạn đang nhắm mục tiêu để xóa phương thức. Sau đó, bạn có thể xóa nó "sau". Trong lúc này, rõ ràng là không có mã mới nào được thêm vào mà phụ thuộc vào nó.

Tôi sẽ không khuyên bạn nên đầu tư vào các phương pháp không dùng nữa - vì vậy không có thử nghiệm đơn vị mới nào chỉ để đạt các mục tiêu bảo hiểm.

Sự khác biệt giữa hai chủ yếu là liệu các phương thức có phải là một phần của giao diện được xuất bản hay không . Việc tự ý xóa các phần của giao diện được xuất bản có thể gây ngạc nhiên khó chịu cho người tiêu dùng phụ thuộc vào giao diện.

Tôi không thể nói chuyện với EclEmma, ​​nhưng từ kinh nghiệm của tôi, một trong những điều bạn cần cẩn thận là sự phản ánh. Ví dụ, nếu bạn sử dụng các tệp cấu hình văn bản để chọn lớp / phương thức nào sẽ truy cập, thì sự khác biệt được sử dụng / không sử dụng có thể không rõ ràng (Tôi đã bị đốt cháy bởi thời gian được ghép nối đó).

Nếu dự án của bạn là một chiếc lá trong biểu đồ phụ thuộc, thì trường hợp khấu hao sẽ bị suy yếu. Nếu dự án của bạn là một thư viện, thì trường hợp khấu hao sẽ mạnh hơn.

Nếu công ty của bạn sử dụng một repo đơn , thì xóa có rủi ro thấp hơn trong trường hợp đa repo.

Như đã lưu ý bởi l0b0 , nếu các phương thức đã có sẵn trong kiểm soát nguồn, phục hồi chúng sau khi xóa là một bài tập thẳng về phía trước. Nếu bạn thực sự lo lắng về việc cần phải làm điều đó, hãy suy nghĩ về cách tổ chức các cam kết của bạn để bạn có thể khôi phục các thay đổi đã xóa nếu bạn cần chúng.

Nếu độ không chắc chắn đủ cao, bạn có thể xem xét nhận xét mã , thay vì xóa nó. Đó là công việc bổ sung trong đường dẫn hạnh phúc (nơi mã bị xóa không bao giờ được khôi phục), nhưng nó giúp khôi phục dễ dàng hơn. Tôi đoán là bạn nên thích xóa thẳng cho đến khi bạn bị đốt cháy bởi điều đó một vài lần, điều này sẽ cung cấp cho bạn một số hiểu biết về cách đánh giá "sự không chắc chắn" trong bối cảnh này.

câu hỏi tại sao họ ở đó?

Thời gian đầu tư để nắm bắt truyền thuyết không nhất thiết là lãng phí. Tôi đã được biết là thực hiện xóa theo hai bước - trước tiên, bằng cách thêm và cam kết nhận xét giải thích những gì chúng ta đã học về mã, sau đó xóa mã (và nhận xét).

Bạn cũng có thể sử dụng một cái gì đó tương tự như hồ sơ quyết định kiến ​​trúc như một cách để nắm bắt truyền thuyết với mã nguồn.

Một công cụ bao phủ mã không phải là tất cả hiểu biết, nhìn thấy tất cả. Chỉ vì công cụ của bạn tuyên bố rằng phương thức này không được gọi, điều đó không có nghĩa là nó không được gọi. Có sự phản ánh, và tùy thuộc vào ngôn ngữ, có thể có những cách khác để gọi phương thức. Trong C hoặc C ++, có thể có các macro xây dựng tên hàm hoặc phương thức và công cụ có thể không thấy cuộc gọi. Vì vậy, bước đầu tiên sẽ là: Thực hiện tìm kiếm văn bản cho tên phương thức và các tên liên quan. Hỏi đồng nghiệp có kinh nghiệm. Bạn có thể tìm thấy nó thực sự được sử dụng.

Nếu bạn không chắc chắn, hãy đặt một khẳng định () vào đầu mỗi phương thức "không sử dụng". Có lẽ nó được gọi. Hoặc một tuyên bố đăng nhập.

Có lẽ mã thực sự có giá trị. Nó có thể là mã mới mà một đồng nghiệp đã làm việc trong hai tuần, và anh ấy hoặc cô ấy sẽ bật vào ngày mai. Nó không được gọi hôm nay vì cuộc gọi đến nó sẽ được thêm vào ngày mai.

Có lẽ mã thực sự có giá trị phần 2: Mã có thể đang thực hiện một số thử nghiệm thời gian chạy rất tốn kém có thể tìm thấy những thứ không ổn. Mã chỉ được bật nếu mọi thứ thực sự đi sai. Bạn có thể đang xóa một công cụ sửa lỗi có giá trị.

Thật thú vị, lời khuyên tồi tệ nhất có thể "Xóa. Cam kết. Quên." được đánh giá cao nhất. (Đánh giá mã? Bạn không thực hiện đánh giá mã? Bạn đang làm gì để lập trình nếu bạn không thực hiện đánh giá mã?)

Tùy thuộc vào môi trường mà phần mềm chạy vào, bạn có thể đăng nhập nếu phương thức được gọi. Nếu nó không được gọi trong một khoảng thời gian thích hợp, thì phương pháp có thể được gỡ bỏ một cách an toàn.

Đây là một cách tiếp cận thận trọng hơn là chỉ xóa phương thức và có thể hữu ích nếu bạn đang chạy trong môi trường rất nhạy cảm với lỗi.

Chúng tôi đăng nhập vào một #unreachable-codekênh chùng chuyên dụng với một mã định danh duy nhất cho mỗi ứng cử viên để loại bỏ và nó được chứng minh là khá hiệu quả.