Đăng ký mã "đã nhận xét" [đã đóng]

Ok, đây là điều gì đó đã gây ra một số mâu thuẫn trong công việc hiện tại của tôi và tôi thực sự không mong đợi điều đó. Phát triển phần mềm có tổ chức trong nhà là một khái niệm mới ở đây và tôi đã đưa ra bản thảo đầu tiên về một số hướng dẫn viết mã.

Tôi đã đề xuất rằng không bao giờ nên kiểm tra mã "đã nhận xét ra" vào kho lưu trữ. Lý do tôi đã nêu điều này là kho lưu trữ duy trì lịch sử đầy đủ của các tệp. Nếu bạn đang xóa mã chức năng thì hãy xóa nó hoàn toàn. Kho lưu trữ giữ các thay đổi của bạn để có thể dễ dàng xem những gì đã được thay đổi.

Điều này đã gây ra một số mâu thuẫn trong đó một nhà phát triển khác tin rằng việc sử dụng tuyến đường này là quá hạn chế. Nhà phát triển này muốn có thể bình luận về một số mã mà anh ta đang làm việc nhưng chưa hoàn chỉnh. Mã này sau đó sẽ không bao giờ được đăng ký trước đó và sau đó không được lưu ở bất kỳ đâu. Chúng tôi sẽ sử dụng TFS vì vậy tôi đã đề xuất rằng tạm dừng các thay đổi sẽ là giải pháp đúng đắn nhất. Tuy nhiên, nó không được chấp nhận vì anh ta muốn có thể kiểm tra các thay đổi từng phần có thể được triển khai hoặc không.

Cuối cùng, chúng tôi muốn đạt được điểm mà chúng tôi đang tận dụng tối đa Tích hợp liên tục và tự động triển khai lên máy chủ web phát triển. Hiện tại không có phiên bản phát triển của máy chủ web hoặc máy chủ cơ sở dữ liệu nhưng tất cả sẽ sớm được thay đổi.

Dù sao, suy nghĩ của bạn là gì? Bạn có tin rằng mã "đã nhận xét ra" hữu ích để có trong kho lưu trữ không?

Tôi rất muốn nghe ý kiến ​​từ những người khác về chủ đề này.

Chỉnh sửa: Vì lợi ích rõ ràng, chúng tôi không sử dụng các chi nhánh tư nhân. Nếu chúng tôi đã làm thì tôi sẽ nói làm những gì bạn muốn với nhánh riêng của bạn nhưng đừng bao giờ hợp nhất mã đã nhận xét với thân hoặc bất kỳ nhánh nào được chia sẻ.

Chỉnh sửa: Không có lý do hợp lệ nào mà chúng tôi không sử dụng các nhánh riêng tư hoặc theo người dùng. Đó không phải là một khái niệm tôi không đồng ý. Chúng tôi vẫn chưa thiết lập nó theo cách đó. Có lẽ đó là điểm trung bình cuối cùng. Hiện tại chúng tôi sử dụng giá đỡ TFS.

Có thể có những người khác với những trải nghiệm khác nhau, nhưng đối với tôi, kiểm tra mã đã hoàn thành là một ý tưởng kinh khủng.

Dưới đây là những nguyên tắc tôi đã học được và cố gắng làm theo:

• Kiểm tra thường xuyên - ít nhất một lần, nhưng tốt nhất là nhiều lần mỗi ngày
• Chỉ kiểm tra chức năng hoàn chỉnh
• Nếu xung đột đầu tiên và thứ hai (ví dụ: mất hơn một ngày để chức năng hoạt động) thì nhiệm vụ quá lớn - hãy chia nó thành các nhiệm vụ có thể hoàn thành nhỏ hơn.

Điều này có nghĩa là:

• Mã nhận xét không bao giờ được đăng ký vì nó không hoạt động
• Nhận xét không phải là một chiến lược lưu trữ hợp lệ, vì vậy cho dù đó là mã chưa hoàn thành hay mã đang được gỡ bỏ, nhận xét và kiểm tra không có ý nghĩa gì.

Vì vậy, tóm lại, KHÔNG! Nếu mã chưa sẵn sàng để chuyển sang giai đoạn tiếp theo (bất kỳ cái nào dành cho bạn: IntTest / QA / UAT / PreProd / Prod), nó không nên được cam kết với một nhánh hoặc nhánh đa nhà phát triển. Giai đoạn = Stage.

Chỉnh sửa: Sau khi đọc các câu trả lời và nhận xét khác, tôi sẽ nói thêm rằng tôi không nghĩ rằng việc cấm mã nhận xét là một ý kiến ​​hay (không chắc bạn sẽ thực thi mã đó như thế nào). Điều tôi sẽ nói là bạn nên kêu gọi mọi người trong nhóm của bạn mua theo triết lý mà tôi đã mô tả ở trên. Nhóm tôi làm việc hết lòng đón nhận nó. Do đó, kiểm soát nguồn là một thành viên trong nhóm không giới hạn, một thành viên giúp chúng tôi hoàn thành công việc của mình.

Những người không chấp nhận triết lý đó thường gây ra các cửa sổ bị vỡ và thường thất vọng với việc kiểm soát nguồn. Họ coi đó là điều tốt nhất cần thiết và điều tồi tệ nhất nên tránh; dẫn đến các lần kiểm tra không thường xuyên, có nghĩa là các tập thay đổi rất lớn và khó hợp nhất, điều này tạo nên sự thất vọng, khiến các lần kiểm tra trở thành thứ cần tránh nhiều hơn, v.v. Đây cuối cùng là một vấn đề thái độ, không thực sự là một quy trình. Thật dễ dàng để tạo ra những rào cản tinh thần chống lại nó; thật dễ dàng để tìm ra lý do tại sao nó không hoạt động, cũng giống như dễ dàng tìm thấy lý do để không ăn kiêng nếu bạn không thực sự muốn. Nhưng khi người ta muốn làm điều đó và cam kết thay đổi thói quen của họ, kết quả là rất ấn tượng. Bạn phải bán nó một cách hiệu quả.

"Không bao giờ" hiếm khi là một từ hay để sử dụng trong các hướng dẫn.

Đồng nghiệp của bạn có một ví dụ tuyệt vời về thời điểm có thể thích hợp để đăng ký mã được nhận xét: Khi nó chưa hoàn thành và có thể làm hỏng ứng dụng nếu đăng ký trong khi đang hoạt động.

Đối với hầu hết các phần, bình luận về mã chết là không cần thiết trong một hệ thống kiểm soát thay đổi được quản lý tốt. Tuy nhiên, không phải tất cả mã được nhận xét là "chết".

Mã nhận xét không bao giờ được đăng ký với mục đích duy trì lịch sử. Đó là điểm kiểm soát nguồn.

Mọi người đang nói rất nhiều lý tưởng ở đây. Có thể không giống như những người khác, tôi phải làm việc trên nhiều dự án với nhiều lần bị gián đoạn với "thế giới thực" khiến ngày làm việc của tôi vô tình bị gián đoạn.

Đôi khi, thực tế là, tôi phải đăng ký một phần mã hoàn chỉnh. Có nguy cơ bị mất mã hoặc mã đăng ký không đầy đủ. Không phải lúc nào tôi cũng có đủ khả năng để "hoàn thành" một nhiệm vụ dù nhỏ đến đâu. Nhưng tôi sẽ không ngắt kết nối máy tính xách tay của mình khỏi mạng mà không kiểm tra tất cả mã.

Nếu cần, tôi sẽ tạo nhánh làm việc của riêng mình để thực hiện các thay đổi từng phần.

Một trường hợp mà tôi để lại mã đã nhận xét:

// This approach doesn't work
// Blah, blah, blah

khi đó là cách tiếp cận vấn đề rõ ràng nhưng nó lại ẩn chứa một số lỗ hổng tinh vi. Chắc chắn, kho lưu trữ sẽ có nó nhưng kho lưu trữ sẽ không cảnh báo bất kỳ ai trong tương lai không đi theo con đường đó.

Tôi chắc chắn sẽ không khuyến khích, mạnh mẽ, bao giờ kiểm tra mã đã nhận xét. Tuy nhiên, tôi sẽ không tuyệt đối cấm nó. Đôi khi (nếu hiếm khi), kiểm tra mã đã nhận xét vào kiểm soát nguồn là thích hợp. Nói "không bao giờ làm điều đó" là quá hạn chế.

Tôi nghĩ tất cả chúng ta đều đồng ý với những điểm sau:

• Không bao giờ kiểm tra mã chết trong kiểm soát nguồn
• Không bao giờ kiểm tra mã bị hỏng (không hoạt động) trong điều khiển nguồn, ít nhất là không bao giờ chuyển sang trung kế và chỉ rất hiếm khi đến một nhánh riêng, YMMV
• Nếu bạn đã tạm thời nhận xét điều gì đó hoặc bị hỏng điều gì đó cho mục đích gỡ lỗi, đừng kiểm tra mã cho đến khi bạn khôi phục mã về dạng chính xác của nó

Một số người nói rằng có các danh mục khác, chẳng hạn như tạm thời mã bị loại bỏ hoặc cải tiến gia tăng nhưng không hoàn chỉnh bao gồm một lượng nhỏ mã được nhận xét như tài liệu về những gì tiếp theo hoặc một đoạn trích nhận xét rất ngắn (lý tưởng là 1 dòng) ra mã hiển thị một cái gì đó không bao giờ nên được thêm lại. Mã nhận xét LUÔN LUÔN phải được kèm theo một nhận xét cho biết lý do tại sao nó được nhận xét (và không chỉ bị xóa) và cung cấp thời gian tồn tại dự kiến ​​của mã được nhận xét. Ví dụ: "Đoạn mã sau gây hại nhiều hơn lợi, vì vậy sẽ bị đưa ra bình luận, nhưng cần được thay thế trước khi phát hành XXX."

Nhận xét như trên là phù hợp nếu bạn đang phân phối một hotfix để cầm máu cho khách hàng và bạn không có cơ hội ngay lập tức để tìm ra giải pháp cuối cùng. Sau khi gửi hotfix, mã được nhận xét là lời nhắc nhở rằng bạn vẫn còn điều gì đó cần sửa.

Khi nào tôi đăng ký mã bình luận? Một ví dụ là khi tôi đang lưỡng lự loại bỏ một thứ gì đó mà tôi nghĩ có khả năng cao sẽ phải được thêm lại trong tương lai gần, dưới một số hình thức. Mã đã nhận xét ở đó để phục vụ như một lời nhắc nhở trực tiếp rằng điều này chưa hoàn thành. Chắc chắn, phiên bản cũ nằm trong quyền kiểm soát nguồn và bạn có thể chỉ cần sử dụng nhận xét FIXME như một lá cờ rằng cần có thêm thứ gì đó. Tuy nhiên, đôi khi (nếu không thường xuyên) mã là nhận xét tốt hơn.

Ngoài ra, khi một lỗi được khắc phục bằng cách xóa một dòng (hoặc hiếm hơn là hai dòng) mã, đôi khi tôi sẽ chỉ nhận xét dòng bằng một bình luận để không bao giờ bật lại mã đó với lý do tại sao. Loại nhận xét này rõ ràng, trực tiếp và ngắn gọn.

Rex M đã nói: 1) Chỉ kiểm tra chức năng hoàn chỉnh, 2) [Nếu] nhiệm vụ quá lớn - hãy chia nó thành các nhiệm vụ hoàn thành nhỏ hơn.

Đáp lại: Vâng, đây là lý tưởng. Đôi khi cả hai lựa chọn đều không thể đạt được khi bạn đang làm việc trên mã sản xuất và gặp một vấn đề nghiêm trọng, tức thời cần khắc phục. Đôi khi để hoàn thành một nhiệm vụ, bạn cần đặt một phiên bản mã trong trường trong một thời gian. Điều này đặc biệt đúng đối với các thay đổi mã thu thập dữ liệu khi bạn đang cố gắng tìm ra nguyên nhân gốc rễ của sự cố.

Đối với trường hợp cụ thể đang được hỏi trong câu hỏi tổng quát hơn ... miễn là nhà phát triển đang kiểm tra mã được nhận xét vào một nhánh riêng mà không ai sẽ thấy ngoại trừ nhà phát triển đó (và có thể là người mà nhà phát triển đang cộng tác), nó ít gây hại. Nhưng nhà phát triển đó không bao giờ nên (gần như) cung cấp mã như vậy vào trung kế hoặc tương đương. Thân cây phải luôn được xây dựng và phải luôn hoạt động. Cung cấp mã chưa hoàn thành cho thân cây hầu như luôn luôn là một ý tưởng rất tồi. Nếu bạn để một nhà phát triển kiểm tra mã chưa hoàn thành hoặc mã tạm thời vào một nhánh riêng, thì bạn phải dựa vào nhà phát triển để không quên làm sạch mã trước khi chuyển vào thân cây.

Để làm rõ khi trả lời các nhận xét cho các câu trả lời khác, nếu mã được nhận xét ra và được đăng ký, tôi kỳ vọng rằng mã sẽ hoạt động nếu không ghi chú giảm xuống cùng với khoảng thời gian mã được nhận xét. Rõ ràng, các công cụ tái cấu trúc không phải lúc nào cũng bao gồm các nhận xét trong việc tái cấu trúc của chúng. Hầu như luôn luôn, nếu tôi đưa mã bình luận vào sản xuất, thì mã đó ở đó để phục vụ như một bình luận tinh tế, một cái gì đó cụ thể hơn văn xuôi, cần phải làm gì đó ở đó. Nó không phải là một cái gì đó nên có một cuộc sống lâu dài.

Cuối cùng, nếu bạn có thể tìm thấy mã được chú thích trong mọi tệp nguồn, thì có gì đó không ổn. Cung cấp mã đã nhận xét vào trung kế vì bất kỳ lý do gì sẽ là một sự kiện hiếm. Nếu điều này xảy ra thường xuyên, thì nó sẽ trở nên lộn xộn và mất giá trị.

Tôi nghĩ không bao giờ là một điều kiện quá mạnh.

Tôi có xu hướng nhận xét, đăng ký, chạy thử nghiệm, suy nghĩ và sau đó xóa nhận xét sau bản phát hành tiếp theo.

Nói chung, việc kiểm tra mã nhận xét là sai vì nó tạo ra sự nhầm lẫn giữa những người không phải là tác giả gốc và cần phải đọc hoặc sửa đổi mã. Trong mọi trường hợp, tác giả gốc thường bị nhầm lẫn về mã sau 3 tháng trôi qua.

Tôi tán thành niềm tin rằng mã thuộc về công ty hoặc nhóm và rằng bạn có trách nhiệm làm mọi thứ trở nên dễ dàng với các đồng nghiệp của mình. Kiểm tra mã đã nhận xét mà không thêm nhận xét về lý do tại sao nó được giữ lại tương đương với việc nói:

Tôi không phiền nếu bạn hoàn toàn bối rối về lý do tại sao những thứ này lại ở đây. Nhu cầu của tôi quan trọng hơn nhu cầu của bạn, đó là lý do tại sao tôi đã làm điều này. Tôi không cảm thấy cần phải thanh minh cho bạn hoặc bất kỳ ai khác, tại sao tôi lại làm điều này.

Đối với tôi, mã bình luận thường được coi là dấu hiệu của sự thiếu tôn trọng từ một đồng nghiệp kém chu đáo.

Tôi hoàn toàn đồng ý với nguyên tắc rằng không nên đăng nhập mã đã nhận xét. Hệ thống kiểm soát nguồn là một tài nguyên được chia sẻ và đồng nghiệp của bạn, ở một mức độ nào đó, sử dụng nó như một tập giấy nháp cá nhân của mình. Điều này không được chú ý nhiều đối với những người dùng khác, đặc biệt nếu bạn đăng ký ý tưởng về quyền sở hữu chung đối với cơ sở mã.

Nhà phát triển tiếp theo nhìn thấy mã được nhận xét đó sẽ không biết rằng đó là một công việc đang được tiến hành. Anh ta có tự do thay đổi nó không? Nó là mã chết? Anh ấy không biết.

Nếu thay đổi của đồng nghiệp của bạn không ở trạng thái có thể kiểm tra được, anh ấy cần phải hoàn thành thay đổi đó và / hoặc học cách thực hiện những thay đổi nhỏ hơn, gia tăng.

"Kiểm tra các thay đổi từng phần có thể được triển khai hoặc không" - có lẽ điều đó cũng có nghĩa là có thể hoặc không thể kiểm tra? Đó là một con dốc trơn trượt đến một cơ sở mã rất chằng chịt.

Khi bạn cần thêm một tính năng nhỏ hoặc sửa lỗi như NGAY BÂY GIỜ, trong vòng 3 phút tới và bạn phải sửa một tệp mà bạn có một nửa mã đã phát triển trên đó, tôi sẽ nói rằng không sao cả, nhu cầu thực tế sẽ thống trị những lý tưởng thực dụng trên chiến trường.

Điều này cho thấy sự khác biệt cơ bản trong hai trường phái suy nghĩ: Những người chỉ kiểm tra mã làm việc mà họ hài lòng và cảm thấy đáng được lưu, và những người kiểm tra công việc của họ để kiểm soát sửa đổi ở đó để ngăn chặn việc mất dữ liệu.

Tôi mô tả cái sau là "những người thích sử dụng hệ thống kiểm soát sửa đổi của họ như một bản sao lưu băng của người nghèo", nhưng điều đó sẽ khiến tôi không biết tôi đang ở trại nào. :-)

Tôi đoán là bạn thuộc trại "mã tốt", còn anh ta thuộc trại "mã làm việc".

[BIÊN TẬP]

Từ các ý kiến, vâng, tôi đã đoán đúng.

Như tôi đã nói, tôi đi cùng bạn, nhưng gần như tôi có thể nói rằng đây là một ý kiến ​​thiểu số, cả ở đây trên stackoverflow và nơi tôi làm việc. Như vậy, tôi không nghĩ rằng bạn thực sự có thể ghi nó vào các tiêu chuẩn phát triển của mình như một cách duy nhất để vận hành. Không nếu bạn muốn các tiêu chuẩn được tuân theo. Một điều mà một nhà lãnh đạo giỏi biết là không bao giờ ra lệnh mà họ biết sẽ không được tuân theo.

btw: Các biên tập viên giỏi sẽ giúp giữ các phiên bản cũ. Ví dụ: trong Emacs, tôi đặt phiên bản cũ và phiên bản cũ thành 10, điều này sẽ giữ khoảng 10 lần lưu tệp cuối cùng của tôi. Bạn có thể xem xét điều đó như một cách để giúp lập luận của bạn chống lại đám đông kiểm soát sửa đổi-như-dự phòng. Tuy nhiên, bạn sẽ không bao giờ thắng trong cuộc tranh cãi.

Theo kinh nghiệm của tôi, các thiết bị chuyển mạch của nhà phát triển được nhận xét ra mã.

Đôi khi, back-end mới được xây dựng song song, với các công tắc kích hoạt được ghi chú trong điều khiển nguồn.

Một số tính năng kỳ lạ chúng ta cần một lần trên mặt trăng xanh nhưng không khách hàng nào cần thường được triển khai theo cách đó. Những thứ này thường mang rủi ro cao về bảo mật hoặc bỏ qua tính toàn vẹn dữ liệu, vì vậy chúng tôi không muốn chúng hoạt động bên ngoài quá trình phát triển. Yêu cầu một nhà phát triển sử dụng nó để bỏ ghi chú mã trước có vẻ là cách dễ nhất để lấy nó.

Một lý do khác cho mã đã nhận xét đã đăng ký:

Bạn đang sửa đổi mã hiện có và tìm thấy một lỗi nhỏ, một lỗi rất dễ bỏ qua và có lẽ ngay cả khi nhìn sơ qua cũng có thể đúng. Nhận xét nó ra, đặt bản sửa lỗi vào vị trí của nó và thêm nhận xét về những gì đang xảy ra và lý do nó được sửa đổi. Kiểm tra điều đó để nhận xét của bạn về bản sửa lỗi có trong kho lưu trữ.

Có lẽ câu hỏi thực sự ở đây là liệu các nhà phát triển có nên được phép kiểm tra mã chưa hoàn chỉnh hay không?

Thực tiễn này dường như mâu thuẫn với mục tiêu đã nêu của bạn là thực hiện tích hợp liên tục.

Nó phụ thuộc. Nếu nó được để ở đó cho mục đích minh họa, có thể. Nó có thể hữu ích trong quá trình tái cấu trúc. Nếu không, và nói chung, không. Ngoài ra, bình luận về mã chưa hoàn thành chắc chắn sẽ dễ bị lỗi và mất thời gian. Tốt hơn là anh ta nên chia mã thành các phần nhỏ hơn và kiểm tra chúng khi chúng hoạt động.

Quan điểm của tôi: nếu các nhà phát triển đang làm việc trên các chi nhánh của riêng họ hoặc trong khu vực hộp cát của riêng họ, thì họ có thể đăng ký bất cứ thứ gì họ muốn. Đó là khi họ kiểm tra mã vào một nhánh chia sẻ (một nhánh tính năng, hoặc một nhánh của nhóm, hoặc tất nhiên là CHÍNH / thân cây) thì mã đó phải nguyên bản nhất có thể (không có mã nhận xét, không có thêm FIXME, v.v.).

Tôi nghĩ "Không bao giờ" là một quy tắc quá mạnh. Tôi muốn bỏ phiếu để bỏ qua một số thời gian cá nhân xung quanh việc mọi người có kiểm tra mã đã nhận xét trong kho lưu trữ hay không. Mục tiêu cuối cùng phải là năng suất lập trình viên, không phải là "một kho lưu trữ nguyên sơ".

Để cân bằng sự lỏng lẻo đó, hãy đảm bảo rằng mọi người đều biết rằng mã đã nhận xét có ngày hết hạn. Bất kỳ ai cũng được phép xóa mã đã nhận xét nếu nó đã tồn tại cả tuần và chưa bao giờ hoạt động. (Thay "một tuần" bằng bất cứ điều gì bạn cảm thấy phù hợp.) Bằng cách đó, bạn có quyền loại bỏ sự lộn xộn khi bạn nhìn thấy nó, mà không can thiệp quá trực tiếp vào phong cách cá nhân của mọi người.

Tôi hoàn toàn đồng ý rằng không nên kiểm tra mã đã nhận xét vào kho lưu trữ, đó là mục đích kiểm soát mã nguồn.

Theo kinh nghiệm của tôi khi một lập trình viên kiểm tra mã đã nhận xét, đó là bởi vì anh ấy / cô ấy không chắc đâu là giải pháp phù hợp và hạnh phúc hơn khi để giải pháp thay thế trong nguồn với hy vọng rằng ai đó sẽ đưa ra quyết định đó.

Tôi thấy nó làm phức tạp mã và làm cho nó khó đọc.

Tôi không gặp vấn đề gì với việc kiểm tra một nửa mã đã hoàn thành (vì vậy bạn sẽ có được lợi ích của việc kiểm soát nguồn) mà hệ thống trực tiếp không gọi. Vấn đề của tôi là với việc tìm kiếm các phần của mã được nhận xét mà không có lời giải thích, tình huống tiến thoái lưỡng nan đã dẫn đến mã bị loại trừ.

Tôi nghĩ rằng việc đăng ký mã nhận xét trong hệ thống kiểm soát mã nguồn nên được thực hiện hết sức thận trọng, đặc biệt nếu các thẻ ngôn ngữ được sử dụng để nhận xét mã được viết bởi các khối, tức là:

/* My commented code start here
My commented code line 1
My commented code line 2
*/

Thay vì trên cơ sở từng dòng riêng lẻ, như:

// My commented code start here
// My commented code line 1
// My commented code line 2

(bạn có ý tưởng)

Lý do tôi cần hết sức thận trọng là tùy thuộc vào công nghệ, bạn nên rất cẩn thận về công cụ khác biệt / hợp nhất mà bạn đang sử dụng. Với hệ thống kiểm soát mã nguồn nhất định và ngôn ngữ nhất định, công cụ khác biệt / hợp nhất có thể dễ bị nhầm lẫn. Ví dụ, sự khác biệt / hợp nhất tiêu chuẩn của ClearCase nổi tiếng là không tốt cho việc hợp nhất các tệp .xml.

Nếu xảy ra trường hợp các dòng chặn nhận xét không được hợp nhất đúng cách, trước khi mã của bạn sẽ hoạt động trong hệ thống khi không nên. Nếu mã không đầy đủ và phá vỡ bản dựng, đó có lẽ là điều ít ác nhất, vì bạn sẽ phát hiện ra nó ngay lập tức.

Nhưng nếu mã vượt qua bản dựng, nó có thể hoạt động khi không nên ở đó, và từ góc độ CM, đó có thể là một kịch bản ác mộng. QA thường kiểm tra những gì nên có ở đó, họ không kiểm tra mã không được cho là có ở đó, vì vậy mã của bạn có thể kết thúc trong quá trình sản xuất trước khi bạn biết và đến thời điểm nó sẽ được nhận ra mã ở đó khi nó không nên, chi phí bảo trì tăng gấp nhiều lần (vì "lỗi" sẽ được phát hiện trong quá trình sản xuất hoặc khách hàng, địa điểm hoặc thời gian tồi tệ nhất từ ​​trước đến nay).

Ý tưởng cho phép lịch sử kiểm soát nguồn minh họa "cách cũ" của việc làm điều gì đó thay vì nhận xét nó và kiểm tra trong phần nhận xét cùng với giải thích là một ý tưởng hay về lý thuyết.

Tuy nhiên, trong thế giới thực, không ai từng xem lịch sử kiểm soát nguồn trên các tệp mà họ đang làm việc trừ khi đó là một phần của quy trình đánh giá chính thức thuộc một số loại (chỉ được thực hiện định kỳ) hoặc nếu điều gì đó không hoạt động và nhà phát triển không thể tìm ra lý do tại sao.

Ngay cả sau đó, nhìn lại nhiều hơn khoảng 3 phiên bản về cơ bản không bao giờ xảy ra.

Một phần, điều này là do các hệ thống kiểm soát nguồn không làm cho loại đánh giá thông thường này trở nên dễ dàng. Thông thường, bạn phải kiểm tra một phiên bản cũ hoặc khác với một phiên bản cũ, bạn chỉ thấy hai phiên bản và không có cái nhìn ngắn gọn tốt về những gì đã thay đổi có thể cho bạn một cái nhìn thoáng qua về những gì đã thay đổi.

Một phần, đó là sự kết hợp giữa bản chất con người và nhu cầu của đội. Nếu tôi phải sửa điều gì đó và tôi có thể sửa nó trong vài giờ, tôi sẽ không dành một giờ để điều tra các phiên bản mã cũ chưa "tồn tại" trong một tháng (điều này với mỗi nhà phát triển sẽ kiểm tra thường, có nghĩa là quay lại nhiều lần sửa đổi), trừ khi tôi tình cờ biết rằng có điều gì đó trong đó (chẳng hạn như nếu tôi nhớ một cuộc thảo luận về việc thay đổi điều gì đó liên quan đến những gì tôi đang làm bây giờ).

Nếu mã bị xóa và được kiểm tra lại, thì đối với tất cả các ý định và mục đích (ngoại trừ mục đích giới hạn là khôi phục hoàn toàn), mã sẽ không còn tồn tại. Có, nó ở đó cho mục đích sao lưu, nhưng nếu không có một người trong vai trò thủ thư mã, nó sẽ bị mất.

Cây kiểm soát nguồn trong dự án hiện tại của tôi đã được khoảng 10 tuần tuổi, trong một nhóm chỉ có khoảng 4 kỹ sư và có khoảng 200 danh sách thay đổi được cam kết. Tôi biết rằng nhóm của tôi không làm tốt công việc như lẽ ra phải đăng ký ngay khi có điều gì đó chắc chắn và sẵn sàng để đi. Điều đó làm cho nó khá khó khăn khi dựa vào việc đọc lịch sử mã cho mọi phần của mã để nắm bắt mọi thay đổi quan trọng.

Hiện tại, tôi đang làm việc trên một dự án ở chế độ phát triển ban đầu, rất khác với một dự án ở chế độ bảo trì. Nhiều công cụ giống nhau được sử dụng trong cả hai môi trường, nhưng nhu cầu khác nhau khá nhiều. Ví dụ: thường có một nhiệm vụ yêu cầu hai hoặc nhiều kỹ sư làm việc chặt chẽ với nhau để xây dựng một thứ gì đó (giả sử một máy khách và một máy chủ nào đó).

Nếu tôi đang viết máy chủ, tôi có thể viết mã cho giao diện nháp mà máy khách sẽ sử dụng và kiểm tra nó ở trạng thái hoàn toàn không hoạt động, để kỹ sư viết máy khách có thể cập nhật. Điều này là do chúng tôi có chính sách nói rằng cách duy nhất để gửi mã từ kỹ sư này sang kỹ sư khác là thông qua hệ thống kiểm soát nguồn.

Nếu nhiệm vụ diễn ra đủ lâu, có lẽ nên tạo một chi nhánh để hai chúng tôi cùng làm việc (mặc dù điều đó trái với chính sách trong tổ chức của tôi - các kỹ sư và trưởng nhóm cá nhân không có quyền cần thiết đối với máy chủ điều khiển nguồn). Cuối cùng, đó là một sự đánh đổi, đó là lý do tại sao chúng tôi cố gắng không đưa ra quá nhiều chính sách "luôn luôn" hoặc "không bao giờ".

Tôi có thể sẽ phản ứng với chính sách không-bình-luận-code-bao-giờ như vậy bằng cách nói rằng nó hơi ngây thơ. Có chủ đích tốt, có lẽ, nhưng cuối cùng không đạt được mục đích của nó.

Mặc dù nhìn thấy bài đăng này nhưng tôi sẽ quay lại mã mà tôi đã kiểm tra vào tuần trước và xóa phần nhận xét chưa bao giờ là cuối cùng (mặc dù nó đã hoạt động) và cũng không bao giờ có khả năng được mong muốn nữa.

Tôi nghĩ rằng mã bình luận ra được coi là "lãng phí".

Tôi cho rằng bạn đang làm việc trong môi trường đồng đội. Nếu bạn đang làm việc một mình và bạn nhận xét mã bằng 'việc cần làm' và bạn sẽ quay lại với nó thì điều đó đã khác. Nhưng trong môi trường nhóm, bạn có thể yên tâm cho rằng một khi mã đã nhận xét được kiểm tra, nó sẽ ở lại và nó rất có thể sẽ gây ra nhiều đau đớn hơn là sự hài lòng.

Nếu bạn đang thực hiện đánh giá mã ngang hàng thì nó có thể trả lời câu hỏi của bạn. Nếu một nhà phát triển khác đánh giá mã của bạn và nói "tại sao lại có mã được nhận xét này đang cố gắng thực hiện 'blah'" thì mã của bạn đã không thành công trong quá trình xem xét mã và bạn không nên kiểm tra nó.

Mã được nhận xét sẽ chỉ đặt ra câu hỏi với các nhà phát triển khác - do đó lãng phí thời gian và năng lượng.

Bạn cần đặt câu hỏi " tại sao " mã được nhận xét. Một số gợi ý:

Nếu bạn đang bình luận về mã vì bạn "không chắc chắn về các quy tắc kinh doanh" thì có thể bạn đang gặp vấn đề với "phạm vi creep" - tốt nhất đừng làm bẩn cơ sở mã của bạn với các yêu cầu "sẽ rất tốt nhưng chúng tôi không có thời gian để thực hiện "- giữ cho nó sạch sẽ với mã rõ ràng và các thử nghiệm xung quanh những gì thực sự ở đó.

Nếu bạn đang nhận xét mã vì bạn "không chắc đó có phải là cách tốt nhất để làm điều đó hay không" thì hãy nhờ đồng nghiệp mã của bạn xem xét! Thời đại đang thay đổi, bạn sẽ nhìn vào đoạn mã bạn viết ngày hôm nay sau 2 năm và nghĩ rằng nó thật kinh khủng! Nhưng bạn không thể đi bình luận những điều mà bạn 'biết' có thể được thực hiện tốt hơn nhưng bạn không thể tìm ra cách ngay bây giờ. Hãy để bất cứ ai duy trì codebase lâu dài xác định xem có cách nào tốt hơn hay không - chỉ cần viết mã, kiểm tra và làm việc và tiếp tục.

Nếu bạn đang bình luận về mã vì "cái gì đó không hoạt động" thì hãy KHẮC PHỤC NÓ ! Một kịch bản phổ biến là "kiểm tra hỏng" hoặc "việc cần làm" . Nếu bạn có những thứ này, bạn sẽ tiết kiệm được rất nhiều thời gian bằng cách sửa chữa chúng hoặc chỉ cần loại bỏ chúng. Nếu chúng có thể bị "hỏng" trong một khoảng thời gian, rất có thể chúng sẽ bị hỏng vĩnh viễn.

Tất cả những kịch bản tiềm năng này (và những kịch bản tôi chưa đề cập ở đây) đều bị lãng phí thời gian và công sức. Mã được nhận xét có vẻ như là một vấn đề nhỏ nhưng có thể là một chỉ báo cho một vấn đề lớn hơn trong nhóm của bạn.

Kho lưu trữ là bản sao lưu của mã. Nếu tôi đang làm việc trên mã nhưng nó chưa hoàn thành, tại sao không bình luận nó ra và kiểm tra nó vào cuối ngày. Bằng cách đó, nếu ổ cứng của tôi chết qua đêm, tôi sẽ không mất công. Tôi có thể kiểm tra mã vào buổi sáng và bỏ ghi chú nó và tiếp tục.

Lý do duy nhất tôi muốn bình luận nó là bởi vì tôi không muốn phá vỡ cấu trúc chỉ sau một đêm.

Rõ ràng có một sự căng thẳng giữa 1) đăng ký sớm và 2) luôn duy trì kho lưu trữ ở trạng thái hoạt động. Nếu bạn có nhiều hơn một vài nhà phát triển, thì cái sau sẽ được ưu tiên ngày càng tăng, bởi vì bạn không thể có một nhà phát triển nhồi nhét tất cả những người khác vào quy trình làm việc cá nhân của mình. Điều đó nói rằng , bạn không nên đánh giá thấp giá trị của nguyên tắc đầu tiên. Các nhà phát triển sử dụng tất cả các loại cột rào tinh thần khác nhau và quy trình làm việc được cá nhân hóa là một cách mà các nhà phát triển tuyệt vời loại bỏ những dấu X bổ sung đó. Là một nhà quản lý, công việc của bạn không phải là cố gắng hiểu tất cả những sắc thái này - điều mà bạn sẽ thất bại trừ khi bạn là một thiên tài và tất cả các nhà phát triển của bạn đều là những kẻ ngốc - mà là tạo điều kiện cho các nhà phát triển của bạn trở thành những người giỏi nhất có thể thông qua việc ra quyết định của riêng họ.

Bạn đề cập trong bình luận rằng bạn không sử dụng nhánh riêng. Câu hỏi của tôi dành cho bạn là tại sao không? Được rồi, tôi không biết gì về TFS, vì vậy có lẽ có lý do chính đáng. Tuy nhiên, sau khi sử dụng git trong một năm, tôi phải nói rằng một DVCS tốt hoàn toàn làm giảm căng thẳng này. Có những trường hợp tôi thấy bình luận về mã sẽ hữu ích khi tôi đang xây dựng một mã thay thế, nhưng tôi sẽ mất ngủ vì nó nếu tôi gây ra nó cho người khác. Có thể phân nhánh cục bộ có nghĩa là tôi có thể giữ các cam kết có ý nghĩa cho quy trình cá nhân của mình mà không cần phải lo lắng về (hoặc thậm chí thông báo) cho các nhà phát triển hạ nguồn về những rắc rối tạm thời.

Chỉ vang lên điệp khúc. Từ chối điều này bằng mọi giá. Nó làm cho mã khó đọc hơn và khiến mọi người tự hỏi điều gì tốt / xấu về mã đó thậm chí không phải là một phần của ứng dụng vào thời điểm hiện tại. Bạn luôn có thể tìm thấy các thay đổi bằng cách so sánh các bản sửa đổi. Nếu có một số cuộc phẫu thuật lớn và mã đã được nhận xét rõ ràng, nhà phát triển nên ghi chú nó trong ghi chú sửa đổi về đăng ký / hợp nhất.

mã không đầy đủ / thử nghiệm nên nằm trong một nhánh được phát triển để hoàn thành. head / trunk phải là dòng chính luôn biên dịch và vận chuyển là gì. khi nhánh thử nghiệm hoàn tất, nó / được chấp nhận, nó nên được hợp nhất vào dòng tiêu đề / chính. Thậm chí còn có tiêu chuẩn IEEE (IEEE 1042) mô tả điều này nếu bạn cần tài liệu hỗ trợ.

Tôi muốn thấy mã có thể bị hỏng, có thể truy cập được nhưng chưa được sử dụng để đăng ký hơn là mã hoàn toàn không khả dụng. Vì tất cả các phần mềm điều khiển phiên bản đều cho phép một số loại 'bản sao làm việc' tách biệt khỏi thân cây, nên sử dụng các tính năng đó thực sự tốt hơn nhiều.

Mã mới, không chức năng trong cốp cũng được, vì nó mới. Nó có thể không phá vỡ bất cứ điều gì đã hoạt động. Nếu nó phá vỡ mã làm việc, thì nó chỉ nên đi vào một nhánh để các nhà phát triển khác có thể (nếu họ cần) kiểm tra nhánh đó và xem cái gì bị hỏng.

" Scar Tissue " là những gì tôi gọi là mã đã nhận xét. Trong những ngày trước khi hệ thống kiểm soát phiên bản được sử dụng rộng rãi, Code Monkeys sẽ để lại mã nhận xét trong tệp trong trường hợp chúng cần khôi phục chức năng.

Thời gian duy nhất có thể chấp nhận đăng ký "mô sẹo" là

1. Nếu bạn có một chi nhánh riêng và
2. Bạn không có thời gian để biên dịch mã mà không có lỗi và
3. Bạn đang đi nghỉ dài ngày và
4. Bạn không tin tưởng VCS của mình, chẳng hạn như nếu bạn sử dụng Nguồn trực quan An toàn HOẶC .
   [BIÊN TẬP]
5. Bạn có một lỗi nhỏ có thể được giới thiệu lại nếu mã không chính xác không được để lại như một lời nhắc. (điểm tốt từ các câu trả lời khác).

Hầu như không có lý do gì cho # 4 vì có rất nhiều hệ thống VCS mạnh mẽ và miễn phí xung quanh, Git là ví dụ điển hình nhất .

Nếu không, hãy để VCS là nhà phân phối mã và kho lưu trữ của bạn. Nếu một nhà phát triển khác muốn xem mã của bạn, hãy gửi email cho họ về điểm khác biệt và để họ áp dụng trực tiếp những thứ họ muốn. Trong bất kỳ trường hợp nào, việc hợp nhất không quan tâm đến lý do hoặc cách mã hóa của hai tệp khác nhau.

Bởi vì nó là mã, mô sẹo có thể gây mất tập trung hơn cả một nhận xét được viết tốt. Về bản chất của nó là mã, bạn khiến lập trình viên bảo trì phải tiêu tốn chu kỳ cpu tinh thần để tìm ra liệu mô sẹo có liên quan gì đến những thay đổi của anh ta hay không. Không quan trọng là vết sẹo đã 1 tuần tuổi hay 10 năm tuổi, việc để lại mô sẹo trong mã tạo ra gánh nặng cho những người phải giải mã mật mã.

[EDIT] Tôi muốn nói thêm rằng có hai tình huống chính cần được phân biệt:

• phát triển tư nhân, viết mã một dự án cá nhân hoặc đăng ký vào một chi nhánh tư nhân
• Phát triển bảo trì, trong đó mã đang được kiểm tra được dự định đưa vào sản xuất.

Chỉ cần nói "KHÔNG" với mô sẹo!

Tôi không biết - tôi luôn nhận xét những dòng ban đầu trước khi tôi thực hiện thay đổi - nó giúp tôi hoàn nguyên chúng nếu tôi thay đổi ý định. Và có, tôi kiểm tra chúng.

Tuy nhiên, tôi sẽ loại bỏ mọi mã nhận xét cũ từ lần đăng ký trước.

Tôi biết mình có thể xem các bản ghi khác biệt để xem những gì đã thay đổi nhưng thật là khó - thật tuyệt khi thấy những thay đổi cuối cùng ngay trong mã.

Một sự thỏa hiệp tốt đẹp là viết một công cụ nhỏ để lưu các tệp đã kiểm tra / sửa đổi của bạn vào ổ đĩa sao lưu mạng. Bằng cách đó, bạn có thể sửa đổi nội dung trái tim của mình và sao lưu công việc của bạn, nhưng bạn không bao giờ phải kiểm tra mã thử nghiệm hoặc chưa hoàn thành.

Tôi nghĩ rằng mã đăng ký đã nhận xét phải hợp lệ, chỉ vì thay đổi mới đã vượt qua các thử nghiệm nên có thể hữu ích hơn khi xem những gì đã có trước đó và xem liệu thay đổi mới có thực sự là một cải tiến hay không.

Nếu tôi phải quay lại nhiều phiên bản để xem một thay đổi trước đó dẫn đến một cú đánh hiệu suất thì điều đó sẽ rất khó chịu.

Đôi khi mã được nhận xét là một lịch sử tốt, nhưng, hãy đặt ngày khi mã được nhận xét. Sau đó, một người nào đó đang làm việc gần đó có thể xóa mã đã nhận xét vì nó đã được chứng minh là không cần thiết.

Cũng sẽ rất tốt nếu biết ai đã bình luận về đoạn mã đó để nếu cần một số lý do cần thiết thì họ có thể được hỏi.

Tôi thích viết chức năng mới, đảm bảo các bài kiểm tra đơn vị vượt qua, kiểm tra nó, sau đó cho phép người khác sử dụng nó và xem nó hoạt động như thế nào.

Nếu nhà phát triển đã nhận xét ra một số mã vì nó vẫn chưa hoàn tất, thì giá trị đúng "kiểm soát nguồn" cách để đối phó với điều này sẽ cho rằng nhà phát triển để giữ nó trong một nhánh riêng biệt của riêng mình, cho đến khi mã mà là sẵn sàng để kiểm tra trong.

Với một DVCS (như git, bazaar, hoặc tensurial), điều này rất dễ dàng vì nó không yêu cầu thay đổi trong kho lưu trữ trung tâm. Nếu không, có lẽ bạn có thể nói về việc cung cấp cho các nhà phát triển các chi nhánh của riêng họ trên máy chủ nếu họ đang làm việc trên các tính năng cụ thể sẽ khiến họ mất một thời gian đủ dài (tức là nhiều ngày).

Không có gì sai khi kiểm tra mã đã nhận xét trong một số tình huống, chỉ là đây là một tình huống có thể có cách tốt hơn để làm điều đó, vì vậy nhà phát triển có thể theo dõi các thay đổi đối với nguồn của mình ngay cả khi nó chưa sẵn sàng. đã đăng ký vào kho lưu trữ chính.

Rõ ràng, nhà phát triển đang kiểm tra mã nhận xét phải làm việc trong một nhánh riêng biệt, hợp nhất các thay đổi từ nhánh thân là điều cần thiết.

Hệ thống VCS phụ thuộc vào hệ thống VCS để hỗ trợ nhà phát triển trong quy trình làm việc này (git là một hệ thống VCS tuyệt vời hoạt động với điều này rất độc đáo).