Tôi có nên loại bỏ mã không được ước tính?

Tôi đang làm việc trên cơ sở mã có kích thước trung bình (100 nghìn dòng), đó là tất cả mã tương đối gần đây (chưa đầy một năm) và có phạm vi kiểm tra đơn vị tốt.

Tôi tiếp tục tìm thấy các phương thức không còn được sử dụng ở bất cứ đâu hoặc chỉ được tham chiếu trong các bài kiểm tra đơn vị chỉ kiểm tra phương thức cụ thể đó.

Tôi có nên xóa mã này nếu tôi chắc chắn rằng nó không còn cần thiết nữa?

Những lý do để loại bỏ nó:

• Ít mã hơn, ít lỗi hơn
• Ít mã hơn để người khác dễ tiêu hóa hơn
• Nó vẫn đang được kiểm soát nguồn

Những lý do để giữ nó:

• Có thể được sử dụng làm tài liệu tham khảo
• Nó có thể hữu ích đôi khi
• Nó có thể đã được viết để 'làm tròn' chức năng cho một lớp

Hầu hết các lý do của bạn để giữ nó là hoàn toàn không liên quan, đặt đơn giản. Nếu mã không được sử dụng, hãy vứt nó đi - bất kỳ lợi ích nào liên quan đến việc giữ nó có thể được lấy một cách tầm thường từ kiểm soát nguồn. Nhiều nhất, để lại một bình luận nói rằng sửa đổi để tìm thấy nó trong.

Rất đơn giản, bạn càng cắt mã càng sớm, bạn càng không phải lãng phí thời gian để duy trì nó, biên dịch mã và kiểm tra nó. Những lợi thế đó ồ ạt vượt xa những lợi ích tầm thường mà bạn đã vạch ra, tất cả đều có thể được lấy từ kiểm soát nguồn.

Tất cả các lý do để loại bỏ nó đứng.

Những lý do để giữ nó:

• Có thể được sử dụng làm tài liệu tham khảo
• Nó có thể hữu ích đôi khi
• Nó có thể đã được viết để 'làm tròn' chức năng cho một lớp

Tất cả những lý do để giữ nó sẽ được quản lý bởi kiểm soát nguồn. Xóa nó khỏi mã trực tiếp và bạn sẽ có thể lấy nó nếu / khi cần.

Mã không được ước tính cũng giống như giữ cho các loại pin đó là tốt, chỉ trong trường hợp bạn cần chúng một ngày cho một ngọn đuốc.

Miễn là bạn đang sử dụng một số loại kiểm soát phiên bản, tôi sẽ nói nó loại bỏ mã trực tiếp và sử dụng lịch sử phiên bản trong trường hợp hóa ra nó hữu ích.

Lý do chính đáng duy nhất tôi có thể thấy để giữ mã hiện không được sử dụng là nếu đó là một phần của mô-đun độc lập: Mặc dù một số phần của mã có thể không được sử dụng tại thời điểm này, nhưng có thể chúng sẽ là sử dụng trong tương lai.

Điều này có thể đặc biệt đúng đối với một thư viện mà bạn sử dụng trong các dự án khác nhau: bạn không muốn tiếp tục ném các đoạn mã vào, theo những gì bạn cần cho một dự án cụ thể: Tôi thấy việc này tốn thời gian và dễ bị lỗi.

Cách tiếp cận của tôi là: (1) nếu bạn sử dụng một lần, chỉ giữ lại những gì bạn thực sự cần; (2) nếu bạn sử dụng hai lần, sao chép và điều chỉnh nó lần thứ hai bạn sử dụng; (3) nếu bạn sử dụng nó nhiều hơn hai lần, hãy tạo một mô-đun ổn định, được xác định rõ ràng và sử dụng mô-đun này khi bạn cần.

Tóm tắt: Tôi sẽ vứt bỏ tất cả các mã không sử dụng trừ khi nó là một phần của mô-đun đa năng mà bạn đã thiết kế như vậy và bạn biết rằng bạn sẽ sử dụng lại nhiều lần.

Lưu ý : Tất nhiên, một giải pháp thậm chí sạch hơn sẽ là tạo một dự án riêng cho thư viện và thêm phụ thuộc giữa các dự án.

Nói chung, tôi sẽ cúi chào YAGNI về điều này. Nếu "bạn sẽ không cần nó", thì nó chỉ đơn giản là chiếm không gian trong cơ sở mã, kiểm tra đơn vị và tập hợp của bạn. Cuối cùng bạn có thể cần nó, nhưng cuối cùng bạn cũng cần phải viết lại hoàn toàn bởi vì từ bây giờ đến khi bạn cần bất cứ thứ gì giống như vậy, rất nhiều thứ có thể thay đổi.

Tuy nhiên, điều đó thay đổi phần nào khi bạn viết một tiện ích hoặc API có nghĩa là cho tiêu dùng chung. Giống như bạn không bao giờ có thể mong đợi người dùng cuối phần mềm tương tác với phần mềm theo cách bạn dự định, bạn không bao giờ có thể mong đợi người tiêu dùng mã của bạn muốn sử dụng mã của bạn chính xác theo cách bạn nghĩ họ nên làm. Trong những trường hợp như vậy, miễn là bạn có thể biện minh cho sự tồn tại của một phương thức với "đó là một cách hợp lệ để muốn tương tác với đối tượng của tôi" thì có lẽ nó nên đi vào, bởi vì ngay cả khi bạn không cần nó, rất có thể MỘT SỐ người sẽ tốt .

Cho rằng codebase chưa đầy một năm, có lẽ nó vẫn còn rất nhiều thông tin (vâng?) - vì vậy quan niệm rằng một số bit có thể cần được phục hồi trong tương lai gần là không hợp lý.

Đối với các bit khó lấy ngay từ đầu và dường như có khả năng phục hồi, tôi sẽ giữ cho chúng "sống" hơn một chút so với chỉ trong kiểm soát nguồn. Mọi người sẽ không biết / nhớ rằng họ tồn tại - nói rằng "bạn chỉ có thể tìm thấy nó trong kiểm soát nguồn" giả định rằng bạn biết / nhớ rằng nó ở đó! Trong các loại trường hợp này, hãy xem xét sự phản đối (với một showstopper "khẳng định (sai)") hoặc bình luận.

Nếu mã là tầm thường và không thú vị, tôi chỉ cần vứt nó đi để loại bỏ quán tính không cần thiết của hệ thống phần mềm.

Đối với các mã xác thực thú vị, tôi sử dụng một archivenhánh trong các hệ thống kiểm soát phiên bản của mình.

"Có thể được sử dụng làm tài liệu tham khảo" Tôi sẽ không có xu hướng đồng ý với việc là một lý do chính đáng để lại trong mã không sử dụng. Thông thường, chỉ một phần nhỏ của mã không được sử dụng thực sự thể hiện điều gì đó thú vị. Có nhiều cách để ghi lại và lưu trữ mã hữu ích nhưng không được sử dụng.

Mặc dù kiểm soát phiên bản sẽ chứa một lịch sử sẽ dễ dàng cho phép bạn khôi phục chức năng cụ thể nếu sau đó bạn quyết định mã là cần thiết, biết rằng bạn cần tìm trong lịch sử kiểm soát phiên bản để tìm xy hoặc z từ ai biết bản sửa đổi trước đó có thể là gì một chút tẻ nhạt, và thường bị bỏ qua trừ khi bạn có một ý tưởng khá cụ thể những gì bạn đang tìm kiếm.

Mã này có thể được nhận xét với một ghi chú về thời điểm nó bị xóa và tại sao nó không bị xóa khỏi mã. Tuy nhiên, đây thường được coi là kiểu xấu và mã không được sử dụng và không được bảo trì đúng cách có thể đưa ra tất cả các loại lỗi nếu sau đó không bị lỗi, do đó, đây thường là bước gỡ lỗi / kiểm tra tạm thời trong khi tái cấu trúc giữa một cách để lại mã sản xuất.

Cách ưa thích của tôi để lưu trữ mã đã xóa, nếu nó có vẻ hữu ích trong tương lai, là tạo một tài liệu tham khảo thứ cấp chứa tất cả các đoạn mã bị xóa đáng giá khác nhau. Mỗi khối mã được dán nhãn với một đề cập ngắn gọn về nguồn gốc của nó hoặc bất cứ điều gì khác cần nhớ như khi nó bị xóa hoặc số sửa đổi mà nó là cuối cùng trong mã tại. Mọi thứ bị loại bỏ nhưng "có khả năng hữu ích" đều ở một nơi, có thể dễ dàng tìm kiếm, nhưng không đòi hỏi nỗ lực liên tục để duy trì và kiểm tra trên cơ sở liên tục (thử nghiệm đó được chuyển đến bất kỳ điểm nào mà mã được giới thiệu lại).

Một lý do chính đáng để giữ các phương thức không sử dụng là: chúng có thể được sử dụng trên các nhánh / thẻ khác!

Khám phá tất cả các nhánh và thẻ hoạt động của bạn trước khi loại bỏ chúng.

Nếu bạn sử dụng hệ thống kiểm soát phiên bản, thì đừng lo lắng về các tài liệu tham khảo trong tương lai, vì bạn chỉ có thể xem qua lịch sử của mã đó và tìm phần bị xóa. Nếu bạn không và bạn nghĩ rằng nó sẽ được sử dụng vào một ngày nào đó, thì chỉ cần để nó ở đó, nhưng bình luận nó với một mô tả giải thích lý do tại sao nó nhận xét.

Tuy nhiên, nếu bạn chắc chắn rằng bạn sẽ không sử dụng nó trong tương lai, chỉ cần xóa nó . Tôi nghĩ rằng những lý do bạn đã đề cập là khá đơn giản để loại bỏ mã.

Nhưng vui lòng trước khi gỡ bỏ nó, hãy chắc chắn rằng nó không được sử dụng ở bất cứ đâu. Visual Studio có một tính năng gọi là Tìm tất cả các tham chiếu tìm kiếm toàn bộ giải pháp và tìm thấy bất kỳ tham chiếu nào đến biến hiện tại, phương thức, thuộc tính, lớp, giao diện, v.v. Tôi luôn chắc chắn rằng không có tham chiếu nào được đưa ra trước khi xóa một phần mã của tôi.

Tôi đã thường xuyên có kinh nghiệm tìm kiếm một chức năng có vẻ như nó sẽ làm chính xác những gì tôi cần và tin tưởng nó hoạt động kể từ khi nó được sản xuất trong một thời gian dài, chỉ để tìm ra nó thực sự đã được sử dụng trong vài năm. Mã không được sử dụng không được duy trì và trong khi nó có thể đã hoạt động nhiều năm trước, API xung quanh nó đã thay đổi đủ để bạn không thể tin tưởng vào nó.

Tốt nhất, cuối cùng bạn dành rất nhiều thời gian để đảm bảo rằng nó thực sự vẫn làm những gì bạn muốn. Tệ nhất, nó dường như hoạt động cho đến khi bạn bị cắn với một lỗi khó chịu sau đó và mất nhiều thời gian hơn để theo dõi nó bởi vì bạn cho rằng mã "thử nghiệm sản xuất" hoạt động nên vấn đề phải ở một nơi khác trong mã mới của bạn. Theo kinh nghiệm của tôi, hầu như luôn luôn nhanh hơn chỉ để viết một chức năng mới.

Nếu bạn xóa nó, nhưng phát hiện ra tương đối sớm bạn thực sự cần nó, nó sẽ ở ngay trong kiểm soát nguồn. Nếu bạn không cần nó cho đến khi quá nhiều thời gian trôi qua mà bạn không nhớ nó nằm trong sự kiểm soát nguồn, dù sao bạn cũng nên viết nó từ đầu.

Không có gì tiêu tốn ít thời gian hơn không có mã.

Nếu bạn phải đi sâu vào một cơ sở mã, bạn cần một chút thời gian để tìm hiểu xem, mã đó được sử dụng để làm gì và nếu nó không được sử dụng cho mục đích gì, bạn cần nhiều thời gian hơn nữa.

Ok - điều này có thể được chữa lành là một nhận xét, nhưng sau đó, mọi người sẽ lý do tại sao mã không được sử dụng này vẫn còn trong cơ sở mã, liệu nó có nên được gỡ bỏ hay không.

Nếu không có gì, sẽ không ai mất thời gian với nó.

Nếu thật khó để làm cho đúng, bạn cần một tài liệu tốt, mã này tồn tại, nhưng nếu cơ sở mã hóa phát triển qua một số lần lặp, có thể nó sẽ không hoạt động nữa, nếu nó được kích hoạt lại.

Loại bỏ mã không sử dụng - ít lộn xộn, hiểu rõ hơn. Hệ thống kiểm soát phiên bản của bạn sẽ chăm sóc. Ngoài ra, nếu bạn đang sử dụng bất cứ thứ gì tốt hơn notepad, môi trường của bạn sẽ cho phép bạn sử dụng mã cũ hơn để tham khảo.

Nhận xét dài của mã cũ là gây mất tập trung và làm cho việc điều hướng khó khăn.

Trân trọng

Thực hiện theo thuật toán đơn giản này:

1. Có phải nó được sao lưu trong một SCM? Nếu có, nhảy lên 3.
2. Thiết lập SCM.
3. Vứt các thứ đi .

Tất cả các điểm của bạn ủng hộ loại bỏ là hợp lệ.

Tất cả các điểm của bạn ủng hộ việc giữ sự lộn xộn là không hợp lệ khi bạn có SCM để tìm kiếm hoặc khôi phục nó. Trên thực tế, SCM của bạn sẽ có thể giúp bạn xác định lý do tại sao mã đó ở đây và không được sử dụng, nếu nó được sử dụng đúng cách.

Nó được gọi là "mã chết" vì một lý do. Hãy để nó chết và yên nghỉ.

Nó sẽ ở trong kiểm soát nguồn; nó không nên ở trong cơ sở mã hoạt động.

Một ngoại lệ là nếu mã hoàn thành thiết kế và trong khi bạn không sử dụng mã, cuối cùng bạn có kế hoạch công khai mã và những người khác có thể muốn chức năng cơ bản đó. Sau đó, chỉ cần thiết kế các thử nghiệm để đảm bảo các phần này của mã hoạt động giống với cách bạn đề xuất người khác có thể sử dụng các phần này của mã. Tuy nhiên, nếu bạn thậm chí đang cân nhắc xóa mã và không thể đưa ra một lý do chắc chắn để giữ nó, thì nó sẽ đi. Mã không được sử dụng làm cho nhiều công việc hơn cho mọi người (khó đọc mã hơn; mã có thể bị hỏng; phải duy trì nhiều công việc hơn, v.v.)

Theo kinh nghiệm của tôi, loại bỏ mã không sử dụng cũng có thể phản tác dụng. Bạn có thể quên bạn đã có mã đó và bạn sẽ không tìm kiếm nó trong lịch sử. Hoặc thậm chí bạn có thể không biết ai đó đã triển khai mã đó và sau đó xóa nó sau đó. Một lần nữa, bạn sẽ không tìm kiếm nó trong lịch sử ...

Không có nghi ngờ, có mã không sử dụng là một mùi hôi.

CẬP NHẬT: Tôi chỉ nhận thấy Ed Staub đã đưa ra một câu trả lời rất giống nhau.