Làm thế nào để xác định xem có mã xóa hữu ích trong kiểm soát nguồn không?


9

Vì vậy, tôi đã đọc qua câu hỏi này Tôi có nên xóa mã không được kiểm tra không?

Một số lời khuyên là xóa mã không được ước tính vì mã nằm trong kiểm soát nguồn để tham khảo trong trường hợp cần thiết sau này.

Làm thế nào để bạn tổ chức mã bị xóa này để một phiên bản mới hơn của bạn (hoặc một số lập trình viên khác) có thể tìm thấy nó sau này? Bạn có tạo một nhánh riêng hoặc gắn thẻ nó trong kiểm soát nguồn bằng cách nào đó không?

Tôi chưa bao giờ phục hồi mã bị xóa khỏi kiểm soát nguồn trước đây, tôi hầu như chỉ sử dụng nó để theo dõi các thay đổi trên mã vẫn còn tồn tại. Tôi đã tham chiếu các nhánh trước đây khi chúng chứa tác phẩm thử nghiệm của người khác, vì vậy có lẽ đó là một cách hay để đánh dấu các phần mã thú vị bị xóa trong thân cây?


bạn đang hỏi vcs gì? âm thanh như svn
gnat

svn là những gì tôi có trong đầu, nhưng tôi có thể áp dụng cho bất kỳ kiểm soát nguồn nào không?
Peter Smith

Bạn nói: "Những gì tôi có nhiều hơn trong tâm trí là các dự án bị hủy bỏ hoặc hoãn lại" trong một phản ứng với một câu trả lời. Tôi nghĩ bạn nên chỉnh sửa câu hỏi của mình vì điều đó hoàn toàn khác với "mã không được kiểm tra".
Pieter B

Câu trả lời:


6

Trừ khi bạn đang thử nghiệm trong một chi nhánh và chưa chắc chắn giải pháp nào cuối cùng sẽ được tái hòa nhập, bạn thường không tham khảo mã đã bị xóa.

Trong một trường hợp rất hiếm , bạn có thể đào một cách rõ ràng mã bị loại bỏ mà bạn mơ hồ nhớ lại việc giải quyết một vấn đề bạn gặp phải ngay bây giờ . Nhưng, lý do điển hình hơn bạn sẽ thấy mã bị xóa là khi bạn xem qua hồ sơ tồn đọng để hiểu điều gì đó về mã hoặc hành vi hiện tại của ứng dụng liên quan đến mã hoặc hành vi lịch sử của nó.

Cụ thể, bạn có thể ...

  • thực hiện đánh giá mã chung / hiểu một công cụ tái cấu trúc
  • tìm kiếm cam kết giới thiệu lỗi X
  • thỏa mãn sự tò mò của bạn / tìm kiếm cam kết đã giải quyết một lỗi
  • thực hiện lại một tính năng hoặc tính năng tương tự
  • hiểu mã hoặc dữ liệu có vẻ như nó hoạt động cùng với mã không tồn tại

... Vân vân.

Và trong những trường hợp đó, bạn thường không phục hồi mã cũ. Bạn chỉ cần hiểu một cái gì đó bạn thấy ngay bây giờ bằng cách sử dụng mã bị xóa cho ngữ cảnh hoặc hướng dẫn.


4

Tôi đoán, câu trả lời là: Đại đa số các lập trình viên không quan tâm đến việc tham chiếu mã bị xóa. Vì nhiều lý do. Một số lý do xuất hiện trong tâm trí của tôi là:

  • Có lẽ quan trọng nhất là sự lười biếng thuần túy ...

  • Hầu hết không bao giờ cảm thấy cần phải phục hồi một số mã, vì vậy họ không có bất kỳ kinh nghiệm nào thúc đẩy họ làm cho mã phục hồi dễ dàng hơn.

  • Hầu hết các mã đã bị xóa sẽ bị xóa vì một lý do. Thông thường, nó được thay thế bằng một số mã khác, tốt hơn, tương đương về chức năng hoặc mạnh hơn. Tại sao bất cứ ai cũng muốn phục hồi mã kém hơn?

    Lưu ý rằng đây cũng là một vấn đề tâm lý một lần nữa: Hầu hết các lập trình viên đều khá tự hào về kết quả công việc của họ. Làm thế nào có thể nghĩ rằng vẫn còn một số giá trị trong những gì họ thay thế?

  • Vì hầu hết mã không bị xóa hoàn toàn, nhưng được thay thế, các giao diện đã được thay đổi trong quá trình chuyển đổi cung cấp đủ thông tin nếu bạn thực sự cần theo dõi mã đã bị xóa do một số hồi quy được giới thiệu bởi mã mới.

Nhưng, độc lập với bao nhiêu hoặc ít hơn những lý do hợp lệ mà bạn có thể đưa ra đằng sau sự coi thường mã chết này, tôi nghĩ đó thực sự chỉ là "không quan tâm" đối với các lập trình viên. Và ngay cả khi bạn cố gắng đánh dấu những thứ đã bị xóa theo cách này hay cách khác, hãy chuẩn bị để bị bỏ qua triệt để với nỗ lực đó ...


Tôi đoán tôi sẽ cố gắng trả lời tại sao. Nếu nó được thay thế mã, nó có ý nghĩa sau một khoảng thời gian ngắn, mã bị xóa không còn thực sự cần thiết. Những gì tôi có nhiều hơn trong tâm trí là các dự án bị hủy bỏ hoặc hoãn lại. Đặc biệt là những nơi mà một số lượng lớn chức năng đã được phát triển hoặc thay đổi, nhưng cuối cùng không hoàn thành đầy đủ và không được sử dụng trong sản xuất hiện tại.
Peter Smith

1
@PeterSmith: Bạn nên tạo các nhánh riêng cho mã đó. Sau đó, không cần phải xóa mã, vì dù sao nó không tồn tại trong nhánh làm việc.
JacquesB

Thêm vào những gì @JacquesB đã nói, nếu bạn có bất kỳ mã nào hoàn toàn không được sử dụng, nó có xu hướng bị lỗi thời khá nhanh. Bạn có thể hồi sinh một nhánh chết sau một năm, sau năm năm bạn sẽ phải khởi động lại từ đầu. Nhánh chết có thể vẫn hữu ích như một nguồn ý tưởng, nhưng bản thân mã của nó dường như không thể sử dụng được nữa.
cmaster - phục hồi monica

1

Câu hỏi này có lẽ rơi vào "Làm thế nào để bạn có thể theo dõi các kiểm tra VCS của bạn đối với cơ sở dữ liệu lỗi và các yêu cầu hệ thống của bạn?"

Thời gian khi mọi người tìm lại mã từ Kiểm soát nguồn có xu hướng là những lúc bạn phát hiện ra rằng một cái gì đó đã vô tình bị hỏng và cần phải được đưa trở lại.

Điều quan trọng nhất trong kịch bản đó đối với ai đó đang tìm kiếm một đoạn mã bị loại bỏ cụ thể là họ có thể dễ dàng theo dõi nó bằng cách xem qua cơ sở dữ liệu yêu cầu và công cụ theo dõi lỗi; bởi vì họ có khả năng đang tìm kiếm yêu cầu cụ thể hoặc các từ mô tả chức năng. Họ không thể biết tên của tệp nguồn hoặc lớp / hàm đã bị xóa.

Nếu bạn muốn theo dõi một số mã thử nghiệm / thú vị cần được loại bỏ trước khi phát hành, bạn chỉ cần theo dõi nó bằng một số vé "lỗi" dọc theo dòng "Xóa mã không sử dụng cho ..." . Hoặc có thể giới thiệu một loại vé mới cho hệ thống cho tính năng Prototype .

Vì vậy, để trả lời câu hỏi trực tiếp - không sử dụng các nhánh / thẻ trong hệ thống VCS của bạn để theo dõi mã bị xóa - hãy sử dụng công cụ theo dõi thay đổi của bạn.


0

Lời khuyên dành cho những người giữ mã lỗi thời trong cơ sở mã "chỉ trong trường hợp". Vì mã vẫn sẽ tồn tại trong kiểm soát nguồn, bạn không nên sợ xóa nó. Bạn không thực sự tổ chức mã bị xóa như vậy, vì toàn bộ vấn đề là nó không cần thiết nữa. Bạn chỉ cần thêm thông báo cam kết cho biết những gì đã thay đổi và bị xóa trong cam kết. Thông báo cam kết phù hợp nhất cho mã bị xóa là tin nhắn tại thời điểm mã được thêm vào ban đầu, không phải là tin nhắn khi nó bị xóa lần nữa.

"Công việc thử nghiệm" thực sự là một vấn đề khác. Bạn nên có một chi nhánh riêng cho việc đó.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.