Làm thế nào để bạn xóa một đoạn mã có vẻ như chưa bao giờ được nhập?

Bạn đã tìm thấy một số mã có vẻ thừa và trình biên dịch không nhận thấy điều đó. Bạn làm gì để chắc chắn (hoặc càng gần chắc chắn càng tốt) rằng việc xóa mã này sẽ không gây ra hồi quy.

Hai ý tưởng mùa xuân đến tâm trí.

1. "Đơn giản" sử dụng khấu trừ dựa trên việc mã có trông giống như nó sẽ thực thi hay không. Tuy nhiên, đôi khi đây có thể là một công việc phức tạp, tốn thời gian, hơi rủi ro (đánh giá của bạn dễ bị lỗi) vì không có lợi nhuận kinh doanh đáng kể.

2. Đặt đăng nhập trong phần mã đó và xem tần suất nhập vào thực tế. Sau khi thực hiện đủ, bạn nên tự tin hợp lý loại bỏ mã là an toàn.

Có bất kỳ ý tưởng tốt hơn hoặc một cái gì đó như một cách tiếp cận kinh điển?

Trong thế giới tưởng tượng hoàn hảo của tôi, nơi tôi có phạm vi kiểm tra đơn vị 100%, tôi sẽ chỉ xóa nó, chạy thử nghiệm đơn vị của mình và khi không có thử nghiệm nào chuyển sang màu đỏ, tôi cam kết.

Nhưng thật không may, tôi phải thức dậy mỗi sáng và đối mặt với thực tế khắc nghiệt nơi có rất nhiều mã không có bài kiểm tra đơn vị hoặc khi chúng không thể tin tưởng để thực sự bao quát mọi trường hợp cạnh có thể. Vì vậy, tôi sẽ xem xét rủi ro / phần thưởng và đi đến kết luận rằng nó đơn giản là không xứng đáng:

• Phần thưởng: Mã dễ dàng hơn một chút để duy trì trong tương lai.
• Rủi ro: Phá mã trong một số trường hợp khó hiểu mà tôi không nghĩ tới, gây ra sự cố khi tôi ít mong đợi nhất và có lỗi vì tôi phải đáp ứng OCD chất lượng mã của mình và thay đổi mà không có giá trị kinh doanh nào có thể nhận thấy cho bất kỳ bên liên quan nào không phải là một lập trình viên.

Có hai nửa cho quá trình này. Đầu tiên là xác nhận rằng mã thực sự đã chết. Thứ hai là hiểu được các chi phí sai và đảm bảo rằng chúng được giảm nhẹ đúng cách.

Nhiều câu trả lời ở đây có giải pháp tuyệt vời cho nửa trước. Các công cụ như máy phân tích tĩnh rất tốt để xác định mã chết. grepcó thể là bạn của bạn trong một số trường hợp. Một bước bất thường tôi thường làm là cố gắng xác định mục đích ban đầu của mã là gì. Việc tranh luận về phần mềm X không còn là một tính năng của sản phẩm của chúng tôi nữa và phân đoạn mã Y được thiết kế để hỗ trợ tính năng XTHER hơn là nói rằng tôi không thấy mục đích nào cho phân đoạn mã Y.

Nửa thứ hai là một bước quan trọng để phá vỡ bất kỳ chặn lưới nào về việc bạn có nên xóa mã hay không. Bạn cần hiểu ý nghĩa của việc trả lời sai. Nếu mọi người sẽ chết nếu bạn trả lời sai, hãy chú ý! Có lẽ đó là thời điểm tốt để chấp nhận rằng hành trình mã phát triển theo thời gian và thay vào đó cố gắng không tự viết thêm hành trình. Nếu mọi người sẽ không chết, hãy tự hỏi người dùng của bạn tha thứ như thế nào. Bạn có thể gửi cho họ một hotfix nếu bạn đã phá vỡ một cái gì đó và duy trì quan hệ khách hàng của bạn? Bạn có nhóm Hỏi & Đáp được trả tiền để tìm các vấn đề như thế này không? Những loại câu hỏi này rất cần thiết để hiểu mức độ chắc chắn của bạn trước khi bạn nhấn phím xóa.

Trong các bình luận, rmun đã chỉ ra một cụm từ xuất sắc về khái niệm hiểu mục đích ban đầu của mã trước khi loại bỏ nó. Báo giá bây giờ được gọi là hàng rào Chesterton . Mặc dù nó quá lớn để được trích dẫn trực tiếp trong một bình luận, tôi nghĩ rằng nó xứng đáng được trích dẫn chính xác ở đây:

Trong vấn đề cải cách mọi thứ, khác với việc làm biến dạng chúng, có một nguyên tắc đơn giản và đơn giản; một nguyên tắc có thể sẽ được gọi là nghịch lý. Có tồn tại trong trường hợp như vậy một thể chế hoặc luật nhất định; Hãy để chúng tôi nói, vì đơn giản, một hàng rào hoặc cổng được dựng lên trên một con đường. Kiểu nhà cải cách hiện đại hơn rất thích thú với nó và nói rằng, tôi không thấy việc sử dụng cái này; Hãy để chúng tôi xóa nó đi. Để mà loại cải cách thông minh hơn sẽ làm tốt để trả lời: thì Nếu bạn không thấy việc sử dụng nó, tôi chắc chắn sẽ không để bạn xóa nó đi. Đi đi và suy nghĩ. Sau đó, khi bạn có thể quay lại và nói với tôi rằng bạn thấy việc sử dụng nó, tôi có thể cho phép bạn phá hủy nó.

Tôi cũng có xu hướng grepcho tên hàm / lớp trong mã, có thể cung cấp một số lợi ích bổ sung mà bộ phân tích mã có thể không có, như nếu tên được đề cập trong một nhận xét hoặc trong tệp tài liệu, hoặc tập lệnh, chẳng hạn. Tôi chạy grep trên các tệp trong cây nguồn và lưu kết quả vào một tệp; thông thường kết quả cung cấp thông tin cô đọng: tên tệp / đường dẫn, số dòng và dòng gặp tên, có thể đưa ra manh mối về nơi hàm / lớp được gọi hoặc được đề cập mà không có bất kỳ ý nghĩa ngữ nghĩa nào (trái ngược với trình phân tích mã ) và bất kể phần mở rộng tập tin. Chắc chắn không phải là giải pháp cuối cùng mà là một bổ sung tốt đẹp cho một phân tích.

• Xác định mã trông như đã chết (phân tích tĩnh, v.v.).
• Thêm một thông điệp tường trình cho mỗi lần gọi mã được cho là đã chết. Thật dễ dàng với các hàm / phương thức; với các thành viên tĩnh như hằng số thì khó hơn. Đôi khi bạn chỉ có thể đánh dấu mã là không dùng nữa và bộ thực thi sẽ tự động ghi thông báo cho bạn. Để lại mã còn nguyên vẹn.
  • Ghi thông báo khi mô-đun chết được tải: hầu hết các ngôn ngữ có cách chạy khởi tạo tĩnh tại thời điểm tải, có thể được hỗ trợ.
  • Hãy chắc chắn rằng thông điệp tường trình của bạn bao gồm một dấu vết ngăn xếp hợp lý, để bạn hiểu những gì được gọi là mã được cho là đã chết.
• Chạy mã đã thay đổi thông qua tất cả các bộ thử nghiệm của bạn. Các bộ kiểm tra của bạn cũng nên kiểm tra các thời điểm đặc biệt, như vượt qua nửa đêm, một phần tư, một năm của một năm, v.v. Hãy nhìn vào nhật ký, cập nhật hiểu biết của bạn về những gì đã chết. Lưu ý rằng các thử nghiệm đơn vị có thể kiểm tra cụ thể mã chết, trong khi không có thử nghiệm đơn vị nào khác và không có thử nghiệm tích hợp nào chạm vào nó.
• Chạy mã thay đổi trong sản xuất trong một vài tuần. Hãy chắc chắn rằng mọi quy trình định kỳ, như các công việc định kỳ ETL mỗi tháng một lần, được thực hiện trong giai đoạn này.
• Nhìn vào nhật ký. Bất cứ điều gì đã được ghi lại là không thực sự chết. Việc đóng tạm thời của biểu đồ cuộc gọi so với phần còn lại của mã chết cũng có khả năng không chết, ngay cả khi nó không được gọi. Phân tích nó. Có thể một số chi nhánh đã chết một cách an toàn (ví dụ: làm việc với API của dịch vụ hiện đã tuyệt chủng), trong khi một số chi nhánh chưa hoạt động. Có thể toàn bộ mô-đun / lớp chỉ được tải cho một hằng số được xác định trong nó và bạn có thể dễ dàng loại bỏ nó.
• Bất cứ điều gì còn lại là chết an toàn, và có thể được gỡ bỏ.

Ngoài các câu trả lời hiện có, bạn cũng có thể xóa mã qua nhiều phiên bản.

Trong phiên bản ban đầu, bạn có thể thực hiện cảnh báo không dùng nữa với khối mã vẫn hoạt động. Trong phiên bản sau đó, bạn có thể xóa khối mã nhưng để lại thông báo lỗi cho phép người dùng không sử dụng tính năng này và không còn khả dụng. Trong phiên bản cuối cùng, bạn sẽ loại bỏ khối mã và bất kỳ tin nhắn nào.

Điều này có thể giúp xác định chức năng không lường trước mà không có cảnh báo cho người dùng cuối. Trong trường hợp tốt nhất, mã thực sự không làm gì cả và tất cả những gì xảy ra là mã không cần thiết được giữ lại qua một số phiên bản trước khi bị xóa.

Rất nhiều người đề nghị rằng điều "an toàn" cần làm là để lại mã nếu bạn không chứng minh được nó không được sử dụng.

Nhưng mã không phải là một tài sản, nó là một trách nhiệm pháp lý.

Trừ khi bạn có thể giải thích tại sao nó quan trọng và chỉ ra các thử nghiệm của nó, thì phương án "an toàn hơn" rất có thể là xóa nó.

Nếu bạn vẫn không chắc chắn, thì ít nhất hãy đảm bảo thêm các bài kiểm tra để thực thi mã zombie.

Bạn có thể sử dụng các tính năng bật tắt để thay đổi đường dẫn thực thi của phần mềm để hoàn toàn bỏ qua mã được đề cập.

Bằng cách này, bạn có thể triển khai thay đổi của mình một cách an toàn với mã không được sử dụng và tắt. Nếu bạn nhận thấy một số lỗi lớn liên quan đến mã, hãy bật lại và điều tra đường dẫn có thể tới nó.

Cách tiếp cận này sẽ mang lại cho bạn sự tự tin nếu bạn thấy không có vấn đề gì trong thời gian dài cũng như khả năng biến nó trở lại khi triển khai w / oa trực tiếp. Tuy nhiên, một cách thậm chí tốt hơn là cũng áp dụng bảo hiểm ghi nhật ký và kiểm tra bổ sung xung quanh khu vực được đề cập sẽ cung cấp thêm bằng chứng cho dù nó được sử dụng hay không.

Đọc thêm về các toggles tại đây: https://martinfowler.com/articles/feature-tlass.html

Tất nhiên, phân tích tĩnh ... và điều tuyệt vời là, bạn không cần bất kỳ công cụ mới nào; trình biên dịch của bạn có tất cả các công cụ phân tích tĩnh bạn cần.

Chỉ cần thay đổi tên của phương thức (ví dụ: thay đổi DoSomethingthành DoSomethingX) và sau đó chạy bản dựng.

Nếu bản dựng của bạn thành công, phương thức, rõ ràng, sẽ không được sử dụng bởi bất cứ thứ gì. An toàn để xóa.

Nếu quá trình xây dựng của bạn thất bại, hãy tách dòng mã gọi nó và kiểm tra xem ifcâu lệnh nào bao quanh cuộc gọi để xác định cách kích hoạt nó. Nếu bạn không thể tìm thấy bất kỳ trường hợp sử dụng dữ liệu nào có thể kích hoạt nó, bạn có thể xóa nó một cách an toàn.

Nếu bạn thực sự lo lắng về việc xóa nó, hãy cân nhắc việc giữ mã nhưng đánh dấu nó bằng ObsoleteAttribution (hoặc tương đương trong ngôn ngữ của bạn). Phát hành nó như thế cho một phiên bản, sau đó loại bỏ mã sau khi không có vấn đề nào được tìm thấy trong tự nhiên.

• Tôi sẽ bắt đầu sử dụng một bộ phân tích mã để kiểm tra xem đây có phải là mã chết không
• Tôi sẽ bắt đầu kiểm tra các bài kiểm tra của mình và cố gắng đạt được mã. Nếu tôi không thể truy cập mã trong trường hợp thử nghiệm thì đó có thể là mã chết
• Tôi sẽ loại bỏ mã và ném một ngoại lệ thay thế. Đối với một bản phát hành, ngoại lệ được kích hoạt và trong bản phát hành thứ hai, ngoại lệ có thể được loại bỏ. Để an toàn, hãy đặt cờ khẩn cấp (trong Java, thuộc tính hệ thống) để có thể kích hoạt mã gốc, khi khách hàng nhận thấy ngoại lệ. Vì vậy, ngoại lệ có thể bị vô hiệu hóa và mã gốc có thể được kích hoạt trong môi trường sản xuất.

Xóa mã không thể truy cập

Trong một ngôn ngữ được nhập tĩnh theo nguyên tắc, bạn phải luôn biết liệu mã có thực sự có thể truy cập được hay không: xóa nó, biên dịch, nếu không có lỗi thì không thể truy cập được.

Thật không may, không phải tất cả các ngôn ngữ đều được gõ tĩnh và không phải tất cả các ngôn ngữ được nhập tĩnh đều có nguyên tắc. Những điều có thể sai bao gồm (1) phản ánh và (2) quá tải không được xử lý.

Nếu bạn sử dụng ngôn ngữ động hoặc ngôn ngữ có phản xạ đủ mạnh để đoạn mã được xem xét kỹ lưỡng có thể có thể được truy cập tại thời điểm chạy thông qua phản xạ, thì bạn không thể dựa vào trình biên dịch. Những ngôn ngữ như vậy bao gồm Python, Ruby hoặc Java.

Nếu bạn sử dụng một ngôn ngữ có quá tải không được xử lý, thì việc loại bỏ quá tải chỉ có thể chuyển đổi độ phân giải quá tải sang trạng thái quá tải khác một cách im lặng. Một số ngôn ngữ như vậy cho phép bạn lập trình cảnh báo / lỗi thời gian biên dịch liên quan đến việc sử dụng mã, nếu không bạn không thể dựa vào trình biên dịch. Các ngôn ngữ như vậy bao gồm Java (sử dụng @Deprecated) hoặc C ++ (sử dụng [[deprecated]]hoặc = delete).

Vì vậy, trừ khi bạn rất may mắn khi làm việc với các ngôn ngữ nghiêm ngặt (Rust xuất hiện trong tâm trí), bạn có thể thực sự tự bắn vào chân mình bằng cách tin tưởng vào trình biên dịch. Và thật không may, bộ thử nghiệm thường không đầy đủ vì vậy cũng không giúp được gì nhiều.

Đưa ra phần tiếp theo ...

Xóa mã không sử dụng

Nhiều khả năng, mã thực sự được tham chiếu, tuy nhiên bạn nghi ngờ rằng trong thực tế các nhánh mã tham chiếu nó không bao giờ được sử dụng.

Trong trường hợp này, bất kể ngôn ngữ, mã có thể truy cập một cách rõ ràng và chỉ có thể sử dụng thiết bị đo thời gian chạy.

Trước đây, tôi đã sử dụng thành công cách tiếp cận 3 giai đoạn để xóa mã đó:

1. Trên mỗi nhánh nghi ngờ KHÔNG được thực hiện, đăng nhập một cảnh báo.
2. Sau một chu kỳ, đưa ra một ngoại lệ / trả lại lỗi khi nhập đoạn mã cụ thể.
3. Sau một chu kỳ khác, xóa mã.

Chu kỳ là gì? Đó là chu kỳ sử dụng mã. Ví dụ, đối với một ứng dụng tài chính, tôi sẽ mong đợi một chu kỳ ngắn hàng tháng (với tiền lương được trả vào cuối tháng) và một chu kỳ dài hàng năm. Trong trường hợp này, bạn phải đợi ít nhất một năm để xác minh rằng không có cảnh báo nào được phát ra cho khoảng không quảng cáo cuối năm có thể sử dụng các đường dẫn mã không bao giờ được sử dụng.

Hy vọng, hầu hết các ứng dụng có chu kỳ ngắn hơn.

Tôi khuyên nên đặt một bình luận TODO, kèm theo một ngày, tư vấn khi nào nên chuyển sang bước tiếp theo. Và một lời nhắc nhở trong lịch của bạn.

Loại bỏ mã khỏi sản xuất cũng giống như làm sạch nhà. Khoảnh khắc bạn vứt bỏ một vật thể trên gác mái, vợ bạn sẽ giết bạn vào ngày hôm sau vì vứt đi món quà quê hương của người cháu thứ ba của bà cố của cô ấy từ người hàng xóm đã chết năm 1923.

Nghiêm túc, sau khi phân tích chữ thảo bằng các công cụ khác nhau mà mọi người đã đề cập, và sau khi sử dụng phương pháp khấu hao từng bước đã đề cập, hãy nhớ rằng bạn có thể rời khỏi công ty khi việc loại bỏ thực sự diễn ra. Để mã vẫn còn và thực thi mã được ghi lại và đảm bảo rằng bất kỳ cảnh báo nào về việc thực thi mã đó chắc chắn được liên lạc với bạn (hoặc người kế thừa và chuyển nhượng của bạn) là điều cần thiết.

Nếu bạn không làm theo phương pháp này, bạn có khả năng bị vợ giết. Nếu bạn giữ mã (như mọi vật phẩm lưu giữ) thì bạn có thể giữ lương tâm của mình trong thực tế rằng luật Moore đưa ra để giải cứu bạn và chi phí cho không gian đĩa rác được sử dụng bởi mã có cảm giác như "đá trong giày của tôi", giảm mọi năm và bạn không có nguy cơ trở thành trung tâm của nhiều tin đồn về nước mát và vẻ ngoài kỳ lạ trên hành lang.

PS: Để làm rõ khi trả lời một bình luận .. Câu hỏi ban đầu là "Làm thế nào để bạn xóa an toàn .." tất nhiên, Kiểm soát phiên bản được giả sử trong câu trả lời của tôi. Cũng giống như đào trong thùng rác để tìm giá trị được giả định. Không có cơ quan nào có ý nghĩa vứt bỏ mã và kiểm soát phiên bản nên là một phần của sự nghiêm ngặt của mọi nhà phát triển.

Vấn đề là về mã có thể là thừa. Chúng ta không bao giờ có thể biết một đoạn mã là thừa, trừ khi chúng ta có thể đảm bảo 100% các đường dẫn thực thi không đạt tới nó. Và nó giả định rằng đây là một phần mềm đủ lớn mà sự đảm bảo này là không thể. Và trừ khi tôi đọc sai câu hỏi, lần duy nhất toàn bộ chuỗi hội thoại này có liên quan là cho các trường hợp trong quá trình sản xuất mà mã bị loại bỏ có thể được gọi và do đó chúng tôi gặp vấn đề về thời gian chạy / sản xuất. Kiểm soát phiên bản không cứu được ai phía sau do lỗi sản xuất, do đó, nhận xét về "Kiểm soát phiên bản" không liên quan đến câu hỏi hoặc quan điểm ban đầu của tôi, tức là không được chấp nhận đúng khung thời gian cực kỳ dài nếu bạn thực sự phải làm, '

IMHO, bình luận là không cần thiết và là một ứng cử viên để loại bỏ.

Có lẽ trình biên dịch không nhận thấy rằng, nó chỉ không làm om sòm.

Chạy một bản dựng với tối ưu hóa trình biên dịch đầy đủ, hướng đến kích thước. Sau đó xóa mã nghi ngờ và chạy lại bản dựng.

So sánh các nhị phân. Nếu chúng giống hệt nhau, thì trình biên dịch đã chú ý và âm thầm xóa mã. Bạn có thể xóa nó khỏi nguồn an toàn.

Nếu các nhị phân khác nhau ... thì không thể kết luận được. Nó có thể là một số thay đổi khác. Một số trình biên dịch thậm chí bao gồm ngày và thời gian biên dịch trong tệp nhị phân (và có thể nó có thể được cấu hình đi!)

Gần đây tôi thực sự đã gặp tình huống chính xác này, với một phương pháp gọi là "xóaFoo". Không ở đâu trong toàn bộ cơ sở mã là chuỗi đó được tìm thấy ngoài khai báo phương thức, nhưng tôi đã khôn ngoan viết một dòng nhật ký ở đầu phương thức.

PHP:

public function deleteFoo()
{
    error_log("In deleteFoo()", 3, "/path/to/log");
}

Hóa ra là mã đã được sử dụng! Một số phương thức AJAX gọi "phương thức: xóa, elem = Foo" sau đó được nối và gọi với call_user_func_array () .

Khi nghi ngờ, đăng nhập! Nếu bạn đã đi đủ thời gian mà không thấy nhật ký được điền, thì hãy xem xét xóa mã. Nhưng ngay cả khi bạn loại bỏ mã, hãy để lại vị trí đăng nhập và nhận xét với ngày để giúp việc tìm kiếm cam kết trong Git dễ dàng hơn đối với anh chàng phải duy trì nó!

Sử dụng grephoặc bất kỳ công cụ nào bạn có sẵn trước tiên, bạn có thể tìm thấy các tham chiếu đến mã. (Không phải hướng dẫn / lời khuyên ban đầu của tôi.)

Sau đó quyết định xem bạn có muốn mạo hiểm xóa mã hay không, nếu đề xuất của tôi có thể được sử dụng:

Bạn có thể sửa đổi chức năng / khối mã để viết rằng nó đã được sử dụng cho một tệp nhật ký. Nếu không có thông báo nào là "bao giờ" được ghi lại trong tệp nhật ký, thì có lẽ bạn có thể xóa mã đăng nhập.

Hai vấn đề:

1. Lấy nhật ký từ những người dùng khác. Có lẽ bạn có thể đặt cờ toàn cầu sẽ làm sập chương trình khi thoát và vui lòng yêu cầu người dùng gửi cho bạn nhật ký lỗi.

2. Truy tìm người gọi. Trong một số ngôn ngữ cấp cao (ví dụ: Python), bạn có thể dễ dàng nhận được dấu vết. Nhưng trong các ngôn ngữ được biên dịch, bạn sẽ phải lưu địa chỉ trả về nhật ký và buộc kết xuất lõi khi thoát (điểm 1).
   Trong C, điều này khá đơn giản: sử dụng khối có điều kiện (ví dụ: #ifdef ... #endif) để chỉ sử dụng điều này khi bạn biết nó sẽ hoạt động (và đã kiểm tra xem nó có hoạt động không) và chỉ cần đọc địa chỉ trả về từ ngăn xếp (có thể hoặc không yêu cầu ngôn ngữ lắp ráp nội tuyến).

Lưu các đối số trong tệp nhật ký có thể hoặc không hữu ích.

Nếu bạn biết mã xung quanh nó làm gì, hãy kiểm tra xem nó có bị hỏng không. Đây là cách đơn giản và hiệu quả nhất về chi phí để tái cấu trúc một đoạn mã bạn đang làm việc và dù sao cũng nên thực hiện bất kỳ thay đổi nào đối với mã bạn đang làm việc ở nơi đầu tiên.

Mặt khác, nếu bạn đang tái cấu trúc một đoạn mã mà bạn không biết nó làm gì , đừng xóa nó . Hiểu nó trước, sau đó cấu trúc lại nó nếu bạn xác định nó an toàn (và chỉ khi bạn có thể xác định rằng tái cấu trúc sẽ sử dụng đúng thời gian của bạn).

Bây giờ, có thể có một số trường hợp (tôi biết tôi đã tự mình chạy vào đó) trong đó mã "chết" thực sự không được kết nối với bất cứ điều gì . Chẳng hạn như các thư viện mã được phát triển bởi một nhà thầu chưa bao giờ thực sự được triển khai ở bất kỳ đâu vì chúng trở nên lỗi thời ngay sau khi ứng dụng được gửi (tại sao có, tôi có một ví dụ cụ thể trong đầu, làm sao bạn biết?).

Cá nhân tôi đã làm gió lên loại bỏ tất cả các mã này, nhưng nó là một khổng lồ nguy cơ mà tôi không khuyên bạn nên tham gia vào nhẹ - tùy thuộc vào cách nhiều mã thay đổi này có thể có khả năng tác động (vì luôn có những tiềm năng mà bạn đã bỏ qua một cái gì đó), bạn cần hết sức cẩn thận và chạy thử nghiệm đơn vị tích cực để xác định xem việc xóa mã di sản cổ này có làm hỏng ứng dụng của bạn không.

Bây giờ tất cả những gì đang được nói, có lẽ không đáng để bạn mất thời gian hay sự tỉnh táo để thử và xóa mã như thế. Trừ khi nó trở thành một vấn đề nghiêm trọng với ứng dụng của bạn (ví dụ: không thể hoàn thành quét bảo mật vì sự phình to của ứng dụng ... tại sao tôi vẫn có một ví dụ trong tâm trí), vì vậy tôi sẽ không đề xuất trừ khi bạn tiếp cận một tình huống như vậy mà mã đã thực sự bắt đầu thối rữa một cách có tác động.

Vì vậy, trong ngắn hạn - nếu bạn biết những gì mã làm, trước tiên hãy kiểm tra nó. Nếu bạn không, có lẽ bạn có thể để nó một mình. Nếu bạn biết bạn không thể để nó một mình, hãy dành thời gian để kiểm tra sự thay đổi mạnh mẽ trước khi thực hiện thay đổi.

Cách tiếp cận của tôi, mà tôi luôn cho là tiêu chuẩn công nghiệp trong trường hợp này, kỳ lạ chưa được đề cập cho đến nay:

Có được một đôi mắt thứ hai.

Có nhiều loại "mã không sử dụng" khác nhau và trong một số trường hợp, việc xóa là phù hợp, trong các trường hợp khác, bạn nên cấu trúc lại nó, và trong các trường hợp khác, bạn chạy trốn càng xa càng tốt và không bao giờ nhìn lại. Bạn cần phải tìm ra nó là cái gì, và để làm như vậy, bạn nên kết hợp tốt nhất với một người thứ hai - có kinh nghiệm! - nhà phát triển, một người rất quen thuộc với cơ sở mã. Điều này làm giảm đáng kể rủi ro cho một lỗi không cần thiết và cho phép bạn thực hiện các cải tiến cần thiết để giữ cho cơ sở mã ở trạng thái duy trì. Và nếu bạn không làm điều này, đôi lúc bạn sẽ hết những nhà phát triển rất quen thuộc với cơ sở mã.

Tôi cũng đã thấy cách tiếp cận đăng nhập - chính xác hơn, tôi đã thấy mã đăng nhập: thậm chí nhiều mã chết hơn còn sót lại ở đó trong 10 năm. Cách tiếp cận ghi nhật ký khá tốt nếu bạn đang nói về việc xóa toàn bộ tính năng, nhưng không phải nếu bạn chỉ xóa một đoạn mã chết nhỏ.

Câu trả lời đơn giản cho câu hỏi của bạn là bạn không thể xóa mã mà bạn không hiểu một cách an toàn, bao gồm cả việc không hiểu cách gọi nó. Sẽ có một số rủi ro.

Bạn sẽ phải đánh giá cách tốt nhất để giảm thiểu rủi ro không thể tránh khỏi. Những người khác đã đề cập đến đăng nhập. Ghi nhật ký tất nhiên có thể chứng minh rằng nó được sử dụng, nhưng không thể chứng minh rằng nó không. Vì vấn đề chính với mã chết là nó được duy trì, bạn có thể thoát khỏi việc thêm một bình luận nói rằng nó bị nghi ngờ là mã chết và không thực hiện bất kỳ sự bảo trì nào đối với nó.

Nếu mã nằm dưới sự kiểm soát nguồn, bạn luôn có thể tìm ra khi nó được thêm vào và xác định cách nó được gọi sau đó.

Cuối cùng, bạn có thể hiểu nó, để nó một mình, hoặc nắm lấy cơ hội.

Trong trường hợp nhà phát triển mã đang đề cập vẫn có sẵn, hãy xem lại việc xóa mã với anh ta . Ngoài ra, đọc ý kiến ​​trong mã .

Bạn sẽ nhận được lời giải thích phù hợp, tại sao mã này đã được thêm vào và nó phục vụ cho chức năng nào. Nó có thể dễ dàng hỗ trợ cho trường hợp sử dụng cụ thể hoặc thậm chí bạn có thể không đủ chuyên môn để đánh giá nếu thực sự không bắt buộc. Trong trường hợp cực đoan, người ta có thể xóa tất cả các báo cáo miễn phí khỏi chương trình C và không nhận thấy bất cứ điều gì sai (có thể mất vài phút để hết bộ nhớ).

Đó thực sự là một văn hóa xấu khi tác giả của mã ngồi cạnh bạn, nhưng bạn không thấy lý do gì để nói vì bạn chắc chắn anh ta chỉ viết mã xấu, và tất cả của bạn đều rất hoàn hảo. Và, tất nhiên, anh chỉ viết những từ ngẫu nhiên trong các bình luận, không cần phải lãng phí thời gian đọc.

Một trong những lý do quan trọng nhất để viết bình luận trong mã là để giải thích TẠI SAO nó đã được thực hiện theo cách này. Bạn có thể không đồng ý với giải pháp, nhưng bạn cần xem xét vấn đề.

Thảo luận với tác giả cũng có thể tiết lộ rằng mã là tàn dư lịch sử của một cái gì đó bị xóa hoặc không bao giờ kết thúc, vì vậy an toàn để xóa.

Tôi hoàn toàn đồng ý với quan điểm đầu tiên của Markus Lausberg: Mã này chắc chắn phải được phân tích với sự trợ giúp của các công cụ. Bộ não Ape không được tin tưởng với loại nhiệm vụ này !!

Hầu hết các ngôn ngữ lập trình tiêu chuẩn có thể được sử dụng trong các IDE và mọi IDE đáng được gọi là có "tìm tất cả các cách sử dụng" - tính năng chính xác là công cụ phù hợp cho loại tình huống này. (Ctrl + Shift + G trong Eclipse chẳng hạn)

Tất nhiên: Công cụ phân tích tĩnh không hoàn hảo. Người ta phải nhận thức được các tình huống phức tạp hơn trong đó quyết định rằng phương thức đang được đề cập chỉ xảy ra trong thời gian chạy và không sớm hơn (các cuộc gọi thông qua Reflection, gọi đến các hàm "eval" trong các ngôn ngữ kịch bản, v.v.).

Hai khả năng:

1. Bạn có phạm vi kiểm tra 99% + : Xóa mã và được thực hiện với nó.
2. Bạn không có phạm vi kiểm tra đáng tin cậy: Sau đó, câu trả lời là thêm cảnh báo khấu hao . Tức là, bạn thêm một số mã vào nơi đó thực hiện một cái gì đó lành mạnh (ví dụ như đăng một cảnh báo đến một nơi dễ nhìn thấy không xung đột với việc sử dụng hàng ngày của ứng dụng của bạn chẳng hạn). Sau đó để nó sôi trong vài tháng / năm. Nếu bạn chưa bao giờ tìm thấy bất kỳ sự xuất hiện nào của nó, hãy thay thế sự phản đối bằng thứ gì đó ném ra một ngoại lệ. Hãy để nó đứng trong một thời gian. Cuối cùng, loại bỏ mọi thứ hoàn toàn.