Có phải thực tế không tốt khi không xóa các tệp dư thừa ngay lập tức khỏi VCS mà thay vào đó hãy đánh dấu chúng là xóa Để xóa xóa bằng các bình luận?

Tôi muốn biết liệu cách tôi xử lý các tệp nguồn cần xóa khỏi kiểm soát phiên bản có thể bị coi là thực tiễn xấu hay không.

Tôi muốn giải thích cho bạn dựa trên ví dụ đó:

Gần đây tôi đã rất tức giận vì tôi phải sắp xếp các lớp Java một cách tẻ nhạt trong một chương trình về cơ bản là mã chết tuy nhiên nó không được ghi lại và cũng không được nhận xét trong các lớp Java đó. Tất nhiên chúng cần phải được xóa nhưng trước khi tôi xóa những thứ dư thừa như vậy tôi có một - một số có thể nói là lạ - thói quen:

Tôi không xóa các tệp dư thừa đó ngay lập tức qua SVN-> Xóa (thay thế bằng lệnh xóa của hệ thống kiểm soát phiên bản của bạn) mà thay vào đó, đặt các nhận xét trong các tệp đó (tôi giới thiệu cả ở đầu và cuối trang) mà chúng sẽ bị xóa + tên của tôi + ngày và cũng - quan trọng hơn - TẠI SAO HỌ BỊ XÓA (trong trường hợp của tôi, vì chúng đã chết, mã khó hiểu). Sau đó, tôi lưu và cam kết chúng để kiểm soát phiên bản. Lần tới khi tôi phải cam kết / kiểm tra thứ gì đó trong dự án để kiểm soát phiên bản, tôi nhấn SVN-> Xóa và cuối cùng chúng bị xóa trong Kiểm soát phiên bản - tất nhiên vẫn còn lưu lại thông qua các sửa đổi và đây là lý do tại sao tôi chấp nhận thói quen đó.

Tại sao làm điều này thay vì xóa chúng ngay lập tức?

Lý do của tôi là, tôi muốn có các điểm đánh dấu rõ ràng ít nhất là trong lần sửa đổi cuối cùng trong đó các tệp dư thừa đó tồn tại, tại sao chúng đáng bị xóa. Nếu tôi xóa chúng ngay lập tức, chúng sẽ bị xóa nhưng không có tài liệu nào giải thích tại sao chúng bị xóa. Tôi muốn tránh một kịch bản điển hình như thế này:

"Hmm ... tại sao những tập tin đó bị xóa? Tôi đã làm việc tốt trước đây." (Nhấn 'hoàn nguyên' -> anh chàng đã hoàn nguyên sau đó sẽ biến mất vĩnh viễn hoặc không có sẵn trong các tuần tiếp theo và người được giao tiếp theo phải tìm hiểu một cách tẻ nhạt như tôi về những tập tin đó là gì)

Nhưng bạn không lưu ý tại sao những tệp đó bị xóa trong thông điệp cam kết?

Tất nhiên tôi làm nhưng một thông điệp cam kết đôi khi không được đồng nghiệp đọc. Đây không phải là một tình huống điển hình khi bạn cố gắng hiểu mã (trong trường hợp của tôi đã chết) mà trước tiên bạn kiểm tra nhật ký kiểm soát Phiên bản với tất cả các thông báo cam kết liên quan. Thay vì bò qua nhật ký, một đồng nghiệp có thể thấy ngay rằng tệp này là vô dụng. Nó tiết kiệm thời gian của cô ấy và anh ấy / anh ấy biết rằng tập tin này có thể đã được khôi phục cho xấu (hoặc ít nhất là nó đặt ra một câu hỏi.

Vấn đề với việc thêm một bình luận vào một tệp cần được xóa, thay vì xóa nó trong kiểm soát nguồn và đưa ra lời giải thích ở đó, là giả định rằng nếu các nhà phát triển không đọc các thông điệp cam kết thì họ chắc chắn sẽ đọc các bình luận trong mã nguồn.

Từ quan điểm của người ngoài cuộc, phương pháp này dường như bắt nguồn từ một quan điểm rất bảo thủ về kiểm soát nguồn.

"Điều gì sẽ xảy ra nếu tôi xóa tập tin không sử dụng này và sau đó ai đó cần nó?" ai đó có thể hỏi.

Bạn đang sử dụng kiểm soát nguồn. Hoàn nguyên thay đổi hoặc tốt hơn là nói chuyện với người đã xóa tệp (giao tiếp).

"Điều gì sẽ xảy ra nếu tôi xóa tập tin chết, sau đó ai đó bắt đầu sử dụng lại và họ thực hiện thay đổi?" người khác có thể hỏi.

Một lần nữa, bạn đang sử dụng kiểm soát nguồn. Bạn sẽ nhận được một cuộc xung đột hợp nhất mà một người phải giải quyết. Câu trả lời ở đây, như với câu hỏi cuối cùng, là giao tiếp với các đồng đội của bạn.

Nếu bạn thực sự nghi ngờ nên xóa một tập tin, hãy liên lạc trước khi xóa nó khỏi kiểm soát nguồn. Có thể gần đây nó đã ngừng sử dụng, nhưng một tính năng sắp tới có thể yêu cầu nó. Bạn không biết điều đó, nhưng một trong những nhà phát triển khác có thể.

Nếu nó cần được loại bỏ, loại bỏ nó. Cắt chất béo ra khỏi cơ sở mã.

Nếu bạn đã tạo một "oopsie" và bạn thực sự cần tệp, hãy nhớ rằng bạn đang sử dụng kiểm soát nguồn để bạn có thể khôi phục tệp.

Vincent Savard, trong một bình luận về câu hỏi, cho biết:

... Nếu đồng nghiệp của bạn không đọc các thông điệp cam kết và họ hồi sinh một tệp đã bị xóa một cách hợp lý và nó vượt qua việc xem xét mã, chắc chắn có điều gì đó không ổn trong nhóm của bạn và đó là cơ hội tuyệt vời để dạy họ tốt hơn.

Đây là lời khuyên âm thanh. Mã đánh giá nên được bắt loại điều này. Các nhà phát triển cần được tư vấn các thông báo cam kết khi một thay đổi bất ngờ được thực hiện đối với một tệp hoặc một tệp bị xóa hoặc đổi tên.

Nếu các thông điệp cam kết không kể câu chuyện, thì các nhà phát triển cũng cần phải viết các thông điệp cam kết tốt hơn.

Việc sợ xóa mã hoặc xóa các tập tin là dấu hiệu của một vấn đề mang tính hệ thống, sâu sắc hơn với quy trình:

• Thiếu đánh giá mã chính xác
• Thiếu hiểu biết về cách thức kiểm soát nguồn hoạt động
• Thiếu giao tiếp nhóm
• Thông điệp cam kết kém về phía các nhà phát triển

Đây là những vấn đề cần giải quyết, vì vậy bạn không cảm thấy như bạn đang ném đá vào nhà kính khi bạn xóa mã hoặc tệp.

Có nó là thực hành xấu.

Bạn nên đặt lời giải thích cho việc xóa trong thông báo cam kết khi bạn cam kết xóa các tệp.

Nhận xét trong các tệp nguồn sẽ giải thích mã như hiện tại . Thông điệp cam kết sẽ giải thích lý do tại sao các thay đổi trong cam kết được thực hiện, vì vậy lịch sử cam kết trên tệp giải thích lịch sử của nó.

Viết bình luận giải thích các thay đổi trực tiếp trong nguồn sẽ chỉ làm cho mã khó theo dõi hơn nhiều. Hãy suy nghĩ về nó: Nếu bạn nhận xét trong tệp mỗi khi bạn thay đổi hoặc xóa mã, chẳng mấy chốc các tệp sẽ bị tràn ngập với các nhận xét về lịch sử thay đổi.

Theo tôi, cả hai lựa chọn của bạn đều không phải là thực tiễn tốt nhất , trái ngược với thực tiễn xấu :

1. Thêm ý kiến ​​chỉ thêm bất kỳ giá trị nếu ai đó tình cờ đọc những bình luận đó.
2. Chỉ cần xóa khỏi VCS, (với một lý do trong mô tả thay đổi), có thể ảnh hưởng đến khả năng cung cấp quan trọng và nhiều người không đọc mô tả thay đổi, đặc biệt là khi bị áp lực.

Thực tiễn ưa thích của tôi - phần lớn là do bị cắn nhiều lần trong nhiều năm, hãy nhớ rằng bạn không luôn biết mã của mình đang được sử dụng ở đâu hoặc bởi ai - là:

1. Thêm một nhận xét cho biết đó là một ứng cử viên để xóa và phản đối #warning hoặc tương tự, (hầu hết các ngôn ngữ đều có một số loại cơ chế như vậy, ví dụ như trong Java , trong trường hợp xấu nhất, một printtuyên bố hoặc tương tự sẽ đủ), lý tưởng với một số loại thời gian và với chi tiết liên lạc. Điều này sẽ cảnh báo cho bất cứ ai vẫn đang thực sự sử dụng mã. Những cảnh báo này thường nằm trong mỗi chức năng hoặc lớp nếu những thứ đó tồn tại .
2. Sau một thời gian nâng cấp cảnh báo lên phạm vi tệp tiêu chuẩn #warning(một số người bỏ qua cảnh báo không dùng nữa và một số chuỗi công cụ không hiển thị cảnh báo như vậy theo mặc định).
3. Sau đó thay thế phạm vi tệp #warningbằng một #errorhoặc tương đương - điều này sẽ phá vỡ mã khi xây dựng nhưng có thể, nếu cần thiết phải được gỡ bỏ nhưng người gỡ bỏ nó không thể bỏ qua nó. (Một số nhà phát triển không đọc hoặc giải quyết bất kỳ cảnh báo nào hoặc có quá nhiều cảnh báo mà họ không thể tách rời những cảnh báo quan trọng).
4. Cuối cùng đánh dấu (các) tệp, (vào hoặc sau ngày đáo hạn), như đã xóa trong VCS.
5. Nếu xóa toàn bộ gói / thư viện / vv ở giai đoạn cảnh báo, tôi sẽ thêm README.txt hoặc README.html hoặc tương tự với thông tin về thời điểm & lý do tại sao nó được lên kế hoạch để thoát khỏi gói và chỉ để lại tệp đó, với một thay đổi để nói khi nào nó bị xóa, vì là nội dung duy nhất của gói trong một thời gian sau khi loại bỏ phần còn lại của nội dung.

Một lợi thế của phương pháp này là một số hệ thống phiên bản (CVS, PVCS, v.v.) sẽ không xóa một tệp hiện có khi thanh toán nếu nó đã bị xóa trong VCS. Nó cũng cung cấp cho các nhà phát triển có lương tâm, những người sửa chữa tất cả các cảnh báo của họ, rất nhiều thời gian để giải quyết vấn đề hoặc kháng cáo xóa. Nó cũng buộc các nhà phát triển còn lại ít nhất nhìn vào thông báo xóa và phàn nàn rất nhiều .

Lưu ý rằng #warning/ #errorlà một cơ chế C / C ++ gây ra cảnh báo / lỗi theo sau là văn bản được cung cấp khi trình biên dịch gặp mã đó, java / java-doc có @Deprecatedchú thích để đưa ra cảnh báo khi sử dụng & @deprecatedđể cung cấp một số thông tin, v.v. công thức để làm tương tự trong python & tôi đã thấy assertđược sử dụng để cung cấp thông tin tương tự #errortrong thế giới thực.

Vâng, tôi sẽ nói rằng đó là thông lệ xấu, nhưng không phải vì nó nằm trong các tệp so với trong thông điệp cam kết. Vấn đề là bạn đang cố gắng tạo ra sự thay đổi mà không liên lạc với nhóm của bạn.

Bất cứ khi nào bạn thực hiện bất kỳ thay đổi nào đối với trung kế - thêm, xóa hoặc sửa đổi tệp theo bất kỳ cách nào - trước khi bạn cam kết trở lại trung kế, hãy nói về những thay đổi đó trực tiếp với một thành viên (hoặc thành viên) của nhóm sẽ trực tiếp am hiểu về họ (về cơ bản, thảo luận về những gì bạn sẽ đặt trực tiếp vào những tiêu đề đó với đồng đội của bạn). Điều này sẽ đảm bảo rằng (1) mã bạn đang xóa thực sự cần phải xóa và (2) nhóm của bạn sẽ có nhiều khả năng biết rằng mã bị xóa và do đó không thử hoàn nguyên việc xóa của bạn. Chưa kể rằng bạn cũng sẽ nhận được lỗi phát hiện và tương tự cho mã bạn thêm.

Tất nhiên, khi bạn thay đổi nội dung lớn, bạn cũng nên đưa nó vào thông điệp cam kết, nhưng vì bạn đã thảo luận về nó, nên nó không cần phải là nguồn thông báo quan trọng. Câu trả lời của Steve Barnes cũng giải quyết một số chiến lược tốt để sử dụng nếu nhóm người dùng tiềm năng cho mã của bạn quá lớn (ví dụ: sử dụng các dấu hiệu không dùng ngôn ngữ của bạn thay vì xóa các tệp lúc đầu).

Nếu bạn không muốn đi lâu mà không cam kết (nghĩa là thay đổi của bạn có ý nghĩa nhất như một vài sửa đổi), thì nên tạo một nhánh từ thân cây và cam kết với nhánh, sau đó hợp nhất nhánh trở lại vào thân cây khi thay đổi đã sẵn sàng. Bằng cách đó, VCS vẫn sao lưu tệp cho bạn, nhưng những thay đổi của bạn không ảnh hưởng đến trung kế theo bất kỳ cách nào.

Một vấn đề liên quan từ các dự án xây dựng trên nhiều nền tảng và cấu hình. Chỉ vì tôi xác định rằng nó đã chết không có nghĩa đó là một quyết định chính xác. Lưu ý rằng chết trong sử dụng vẫn có thể có nghĩa là sự phụ thuộc vào vết tích vẫn cần được loại bỏ, và một số có thể đã bị bỏ qua.

Vì vậy (trong một dự án C ++) tôi đã thêm

#error this is not as dead as I thought it was

Và kiểm tra xem. Đợi nó đi qua việc xây dựng lại tất cả các nền tảng bình thường và không ai phàn nàn về điều đó. Nếu ai đó đã tìm thấy nó, sẽ dễ dàng loại bỏ một dòng trái ngược với việc hoang mang với một tập tin bị thiếu.

Về nguyên tắc, tôi đồng ý rằng các ý kiến ​​bạn đề cập đang sao chép tính năng nên được thực hiện trong hệ thống quản lý phiên bản . Nhưng, bạn có thể có lý do cụ thể để thay thế điều đó. Không biết công cụ VCS không phải là một trong số họ.

Về tính liên tục của Thực tiễn xấu, điều này khá nhỏ. Tôi sẽ làm điều này vào dịp này, khi tôi muốn kiểm tra một chi nhánh và có thể thấy mã cũ. Điều này có thể dễ dàng so sánh với mã thay thế. Tôi thường nhận được một nhận xét đánh giá mã "cruft". Với một chút giải thích tôi vượt qua xem xét mã.

Nhưng mã này không nên sống lâu. Tôi thường xóa vào đầu nước rút tiếp theo.

Nếu bạn có đồng nghiệp không đọc tin nhắn cam kết hoặc sẽ không hỏi bạn tại sao bạn để lại mã trong dự án, thì vấn đề của bạn không phải là một kiểu mã hóa xấu. Bạn có một vấn đề khác.

bạn cũng có thể cấu trúc lại lớp và đổi tên nó với tiền tố thành UNUSED_Classname trước khi bạn thực hiện các pha nguy hiểm. Sau đó, bạn cũng nên trực tiếp cam kết thao tác xóa

• Bước 1: đổi tên lớp, thêm nhận xét của bạn, cam kết
• Bước 2: xóa tập tin và cam kết

Nếu đó là mã chết, hãy xóa nó. Bất cứ ai cần nó, họ có thể quay lại, nhưng bước đổi tên sẽ ngăn họ sử dụng trực tiếp mà không cần suy nghĩ.

Cũng dạy mọi người cách xem tất cả các thông điệp cam kết cho một tệp, một số người thậm chí không biết điều đó là có thể.