Làm thế nào để xử lý TODO trong yêu cầu kéo?

Khi tôi xem xét các thay đổi trong yêu cầu kéo, đôi khi tôi tình cờ nhận thấy một bình luận có ghi chú "TODO" có thể có vì những lý do khác nhau, trong trường hợp của chúng tôi chủ yếu là vì:

• giải pháp được sử dụng để giải quyết vấn đề có thể được cải thiện nhưng sẽ cần đầu tư nhiều thời gian hơn. Một tác giả đã chọn một giải pháp nhanh hơn nhưng đưa ra nhận xét rằng một lựa chọn tốt hơn có khả năng có sẵn
• có một mã tạm thời để khắc phục lỗi hiện có cần được khắc phục sớm

Biết rằng TODOthường ở trong cơ sở mã hóa suốt đời của cơ sở mã, tôi nên phản ứng với chúng như thế nào trong yêu cầu kéo? Làm thế nào tôi có thể yêu cầu một cách lịch sự để tránh nó, hoặc nếu nó thực sự hợp lý, làm thế nào tôi có thể chắc chắn rằng tác giả của PR sẽ theo dõi nó sau này trong tương lai?

Khi bạn nói rằng họ "thường ở trong cơ sở mã hóa suốt đời của cơ sở mã hóa" trong nhóm / bộ phận / tổ chức của bạn, hãy xem xét những điều sau:

• Viết nó xuống trong bạn DoD rằng TODO, FIXMEhoặc thẻ tương tự nên tránh.
• Sử dụng một công cụ phân tích mã tĩnh như SonarQube để tự động đánh dấu bản dựng không ổn định.
• Tạm thời cho phép họ nếu và chỉ khi có một vé tương ứng trong trình theo dõi vấn đề của bạn. Sau đó, mã có thể trông giống nhưTODO [ID-123] Description ...

Như đã đề cập trong nhận xét của tôi , tuyên bố cuối cùng có lẽ chỉ có ý nghĩa trong một môi trường không cho phép vé bị thối (ví dụ: nếu bạn tuân theo chính sách không có lỗi ).

Cá nhân, tôi nghĩ rằng TODOs là đôi khi cả hợp lý, nhưng người ta không nên sử dụng chúng quá mức. Lấy từ "Mã sạch: Cẩm nang về thủ công phần mềm linh hoạt" của Robert C. Martin (trang 59):

TODOs là những công việc mà lập trình viên nghĩ rằng nên được thực hiện, nhưng vì một số lý do không thể làm vào lúc này. Nó có thể là một lời nhắc để xóa một tính năng không dùng nữa hoặc một lời cầu xin cho người khác xem xét một vấn đề. Nó có thể là một yêu cầu cho người khác nghĩ về một cái tên tốt hơn hoặc một lời nhắc nhở để thực hiện một sự thay đổi phụ thuộc vào một sự kiện theo kế hoạch. Dù TODOcó thể là gì đi nữa , đó không phải là lý do để để lại mã xấu trong hệ thống.

Bản thân họ không phải là ác quỷ. Tôi là một fan hâm mộ lớn của việc không bao giờ đi sâu hơn một lớp và luôn khắc phục 1 sự cố cho mỗi vé theo dõi.

Tôi thường sử dụng TODO hoặc FIXME như một cách để tự nhắc nhở bản thân rằng tôi cần hoặc muốn quay lại để khắc phục sự cố.

Ví dụ, tôi có thể gọi add (a, b) và thêm TODO để cấu trúc lại phương thức add. Bây giờ tôi không muốn làm việc với phương thức add, nhưng tôi muốn quay lại với nó.

Vì vậy, trong một yêu cầu kéo, bạn sẽ thấy TODO hoặc FIXME. Tôi sử dụng FIXME chẳng hạn để cảnh báo cho các nhà phát triển khác về các lĩnh vực mã mà họ có trách nhiệm, rằng tôi không nên gây rối. Ví dụ, FIXME thêm không thể chấp nhận số âm.

Để giải quyết vấn đề chúng không được nhìn thấy hoặc bị bỏ qua, tôi sử dụng một tập lệnh liệt kê tất cả các dòng TODO FIXME và DEGUG. Và điều đó được thêm vào thông điệp cam kết.

Thật khó để bỏ qua một thông điệp cam kết 400 dòng là tất cả TODO. Vì vậy, mọi người sửa chúng, trong khi đã chạm vào mã được đề cập hoặc bằng cách tạo vé mới và sửa lỗi mã độc lập.

Để công bằng, tôi cũng đảm bảo rằng mọi dự án đều có mã xây dựng thời gian dọn dẹp. Có thể có thể sẵn sàng để khởi chạy vào ngày 15, nhưng đã làm sạch mã từ ngày 15 đến ngày 30. (có vẻ kỳ quặc nhưng nếu bạn đã từng quản lý một sản phẩm, bạn biết rằng nếu bạn cố gắng thực hiện các nhiệm vụ tầm nhìn thấp trước khi ra mắt, bạn sẽ không bao giờ được phép nhận chúng. Một số thứ khác sẽ được ưu tiên.)

Nó sẽ xảy ra rằng có những yêu cầu kéo không hoàn hảo. Ngay bây giờ tôi đang làm một số công việc có thể được thực hiện "đủ tốt" trong thời gian có sẵn, nhưng không hoàn hảo. Vì vậy, tôi gửi yêu cầu kéo, tôi đặt TODO với các bình luận vào đúng chỗ trong mã, đồng thời tôi thêm một yêu cầu thay đổi khác để thay đổi mọi thứ từ "đủ tốt" thành "hoàn hảo".

Yêu cầu thay đổi mới này sau đó có thể được ưu tiên và nó sẽ được xử lý khi đó là mục ưu tiên cao nhất. Nếu nó được quyết định rằng nó cần phải hoàn hảo ngay bây giờ , thì nó sẽ là thứ tiếp theo được trao.

Bây giờ câu hỏi của bạn: "Làm thế nào tôi có thể yêu cầu một cách lịch sự để tránh nó, hoặc nếu nó thực sự hợp lý, làm thế nào tôi có thể chắc chắn rằng tác giả của PR sẽ theo dõi nó sau này trong tương lai?" Với những gì tôi mô tả, điều đó dường như khá buồn tẻ. Nếu tôi có lựa chọn giữa vận chuyển trễ và vận chuyển những gì đủ tốt, thì đó không phải là quyết định của bạn. Bạn có thể hỏi người quản lý sản phẩm của bạn về nó nếu bạn thích. Và "chắc chắn rằng tác giả của PR sẽ theo dõi nó"? Nếu bạn có một nhóm, thì bạn nên đảm bảo rằng điều này đã được đăng nhập vào hệ thống của bạn và hy vọng nhóm của bạn đủ tổ chức để những thứ được ghi lại không bị mất và cuối cùng sẽ có ai đó sửa nó, khi không có mục ưu tiên cao hơn. Hãy nhớ rằng, đó là một nỗ lực của nhóm.

Nếu dự án của bạn theo dõi các mục đang chờ xử lý trong mã nguồn bằng các TODObình luận, thì bạn phải cho phép nó.

Thực tế là sự hiện diện của một TODOnhận xét trong yêu cầu kéo đang làm phiền bạn nên cho bạn biết rằng theo dõi các mục đang chờ xử lý trong mã nguồn là một ý tưởng tồi. Mọi thứ có xu hướng bị mất hoặc bỏ qua theo cách đó. Bây giờ, nếu bạn đang nói về một yêu cầu kéo đến một "ngã ba làm việc", thì tình huống sẽ khác. Một "ngã ba làm việc" chỉ là như vậy - một công việc đang tiến hành. Nhưng một ngã ba như thế thường không yêu cầu kéo. Các "House Rules" gợi ý ở đây là cho các yêu cầu kéo cho chủ chi nhánh.

Quy tắc nội bộ số 1 - Tất cả các cam kết với chủ nên sẵn sàng để thử nghiệm, vì chủ được xây dựng hàng ngày sau bất kỳ đăng ký nào. Những cam kết cũng nên bao gồm bất kỳ thử nghiệm bổ sung cần thiết.

Nếu TODOnhận xét ở đó vì mã chưa kết thúc hoặc các thử nghiệm chưa kết thúc hoặc mã theo bất kỳ cách nào chưa sẵn sàng để thử nghiệm, thì mã đó thuộc về một cam kết cục bộ, không phải là yêu cầu kéo. Gọi cho tôi khi nó sẵn sàng.

Quy tắc nội bộ số 2 - Tất cả thông tin liên quan đến các vấn đề mở được lưu trữ trong trình theo dõi vấn đề. Tất cả. Ghi chú, viết nguệch ngoạc, linh cảm, bất cứ điều gì.

Nếu TODObình luận liên quan đến một vấn đề mở và không phải là một sửa chữa thực sự cho vấn đề đó, thì thông tin đó thuộc về trình theo dõi vấn đề. Bằng cách đó, trước khi một vấn đề được đóng lại, tất cả các thông tin có thể được xem xét và xác minh, nếu cần, để đảm bảo vấn đề thực sự được giải quyết.

Quy tắc nội bộ số 3 - Tất cả thông tin liên quan đến các nhiệm vụ dự án đang chờ xử lý thuộc hàng đợi ưu tiên (hoặc bất kỳ tên hệ thống nào của bạn cho điều đó).

Để làm rõ, một nhiệm vụ dự án đang chờ xử lý là điều cần được thực hiện trong dự án có mức độ ưu tiên đã đặt, cho dù đó là lỗi được phát hiện trước khi nó tạo ra một vé vấn đề, hoặc việc thực hiện một yêu cầu thiết kế cụ thể, hoặc một trong những thành phần cần thiết đó.

Nếu có TODObình luận để nói rằng mã mới sẽ tác động đến một nhiệm vụ đang chờ xử lý hoặc chỉ ra một cái gì đó khác trong cơ sở mã cần xem xét khi phát hiện mã mới, thì thông tin đó sẽ nằm trong hàng ưu tiên, hoặc trên nhiệm vụ hiện có hoặc như một nhiệm vụ mới.

Quy tắc nhà số 4 - Gợi ý thuộc về Hộp ý tưởng (hoặc bất cứ điều gì).

Nếu TODObình luận gợi ý sự thay đổi trong thiết kế hoặc triển khai phần mềm, thì thông tin đó thuộc về hộp ý tưởng của dự án, hoặc "vNext", hoặc "Ghi chú thiết kế" hoặc bất cứ điều gì bạn có cho loại điều đó.

Quy tắc nội bộ số 5 - TODOý kiến ​​không được phép trong mã nguồn. GIAI ĐOẠN.

Nếu bạn tuân thủ quy tắc này, thì bạn sẽ không phải lo lắng về bất cứ ai theo dõi bất cứ điều gì.