Bạn có nên sửa chữa các khiếm khuyết từ trước trong khi làm việc khác không?

Câu hỏi hóc búa: Trong quá trình làm việc với một tính năng mới hoặc sửa một lỗi, bạn tìm thấy một vấn đề di sản trong mã. Những gì bạn nên làm? Sửa nó và có nguy cơ thay đổi hành vi của mã. Nó đã hoặc đang hoạt động cho đến bây giờ bởi một số sán, hoặc nếu không thì khiếm khuyết đã không được phát hiện hoặc đáng để ai đó báo cáo. Bạn có nên để nó một mình và cho phép vấn đề làm cho mã khó hoạt động hơn sau này không? Khắc phục sự cố sẽ chỉ thêm thời gian thực hiện nhiệm vụ ban đầu của bạn và buộc bạn phải kiểm tra hồi quy. Ít người sẽ đánh giá cao công việc. Sửa chữa nó, tuy nhiên, có vẻ đúng bằng cách nào đó. Mã với ít vấn đề hơn sẽ dễ dàng hơn để cấu trúc lại và xây dựng.

Tôi đã thấy mình trong tình huống này hết lần này đến lần khác khi chúng tôi làm việc để hiện đại hóa một ứng dụng web. Tôi không thể biết mình đang bị ám ảnh hay danh dự khi tôi tiếp tục làm việc với những con bọ cũ này. Làm thế nào để bạn xử lý những tình huống này?

Cảm ơn, Corey

Tôi làm việc trong một nhóm rất nhỏ, vì vậy nó phụ thuộc vào sự thay đổi là gì:

Nếu nó là một sửa lỗi nhỏ, rõ ràng, tôi chắc chắn đi cho nó. Tôi cũng gửi thêm ý kiến ​​nếu tôi phải xử lý mã của người khác và các cải tiến nhỏ khác thuộc "quy tắc tẩy chay" đối với tôi.

Nếu mã được đính kèm đến mức bạn phải hỏi "Sẽ thay đổi điều này sẽ phá vỡ thứ gì đó và yêu cầu thử nghiệm" thì không, bạn không nên thay đổi nó. Mang nó lên trong hệ thống theo dõi lỗi của bạn nếu nó làm bạn lo lắng.

Điều này, tình cờ, là lý do tại sao tôi cố gắng viết mã các phương thức nhỏ hơn với chữ ký loại rõ ràng hơn. Nếu bạn biết không có tác dụng phụ và có thể làm cho phần bên trong khớp với nhau, bạn có thể sửa, sắp xếp lại hoặc chỉnh sửa bất kỳ mã nội thất nào mà không gặp rủi ro.

Nhưng đừng cảm thấy thiếu sự đánh giá cao là một lý do để không sửa các lỗi bạn tìm thấy hoặc để cải thiện cơ sở mã vì bất kỳ lý do nào. Nếu không có gì khác, bạn sẽ tử tế với tương lai, người chắc chắn sẽ quay lại đó để sửa chữa thứ khác.

EDIT: Bạn cũng cần xem thời gian của bạn trong dự án. Rõ ràng là dưới thời hạn chặt chẽ, bạn cần tập trung vào việc hoàn thành công việc chính, nhưng nếu bạn chỉ ở dưới "tải bình thường" thì tôi nghĩ rằng một chút dọn dẹp ở đây và làm cho mọi người hạnh phúc hơn về lâu dài.

Như mọi khi, nó phụ thuộc.

• Nếu nó tầm thường và bạn chắc chắn rằng bạn có thể sửa nó, hãy sửa nó.
• Nếu có nhiều bài kiểm tra đơn vị, vì vậy bạn có thể khá chắc chắn rằng mình chưa làm hỏng bất cứ thứ gì, hãy sửa nó.
• Nếu không, hãy thêm // TODO, thêm nó vào theo dõi lỗi của bạn, bất cứ điều gì

Về cơ bản bạn đang thực hiện đánh giá rủi ro: rủi ro thay đổi so với không thay đổi là gì. Nếu bạn không cảm thấy như bạn đã có đủ kinh nghiệm (với lập trình nói chung hoặc hệ thống nói riêng), hãy hỏi người khác trong nhóm.

Lập trình viên thực dụng gọi đây là 'Windows bị hỏng'.

Nếu bạn không sửa các cửa sổ bị hỏng thì có xu hướng chúng sẽ tạo ra một vòng xoáy giảm chất lượng mã. Và càng nhiều trong số họ có công việc sửa chữa chúng lớn hơn, và do đó ít có khả năng chúng sẽ được sửa chữa.

Việc sửa chúng bây giờ hay sau này là tùy thuộc vào vấn đề phán xét. Nó có phải là một sửa chữa đơn giản? Bạn có chắc chắn mã đang làm những gì bạn nghĩ? Có khả năng làm sao lãng công việc hiện tại của bạn? Bạn có bị hạn chế về thời gian không? Có khả năng giới thiệu nhiều lỗi hơn?

Ít nhất, hãy đánh dấu mục trong hệ thống theo dõi của bạn và đảm bảo mục đó sẽ được sửa sau đó. Điều quan trọng là phải đánh dấu nó trong hệ thống theo dõi ngay cả khi bạn quyết định sửa nó ngay bây giờ, để đảm bảo rằng nó cũng được kiểm tra và ghi lại các thay đổi.

Nếu đó là một lỗi rõ ràng, chẳng hạn như một cái gì đó sẽ vi phạm bảo mật, dữ liệu bị hỏng hoặc đưa ra một ngoại lệ được hiển thị cho người dùng, thì hãy sửa nó. Nếu không, hãy hỏi một người hiểu rõ về codebase hơn bạn.

Nó phụ thuộc, nếu đó là một lỗi nhỏ mà bạn chắc chắn rằng bản sửa lỗi của bạn có tác động thấp thì cá nhân tôi sẽ sửa nó như một phần của công việc khác và sau đó cho Thủ tướng biết.

Nếu nó có bất kỳ rủi ro nào đối với khách hàng, người dùng hoặc công ty sẽ đưa nó lên Trình quản lý dự án và thảo luận về một khóa học phía trước. Đó là công việc của họ để đánh giá rủi ro vì vậy hãy chú ý đến nó và trường hợp sửa nó. Sau đó tôn vinh quyết định của họ.

Người thử nghiệm của chúng tôi ghét điều này. Trừ khi nó rất tầm thường, chúng tôi đăng nhập nó vào cơ sở dữ liệu lỗi, sau đó phân bổ nó vào một bản phát hành và viết các bài kiểm tra hồi quy. Nếu các nhà phát triển sẽ thực hiện các thay đổi không theo lịch trình, làm thế nào bạn có thể giữ đúng thời hạn?

Tôi đã ở trong các đội nơi các lỗi không nghiêm trọng hoặc vi phạm tiêu chuẩn được gửi dưới dạng khiếm khuyết "Mã yếu". Tôi muốn nói rằng người tìm thấy một khuyết điểm nghiêm trọng có trách nhiệm ném một loại cờ nào đó

nó phụ thuộc vào lỗi. mối quan tâm chính là giới thiệu các lỗi mới. Tốt hơn để đối phó với một vấn đề được biết đến hơn là một vấn đề chưa biết. Nếu nó đơn giản, giả sử thay đổi văn bản hoặc lỗi logic đơn giản, chúng tôi sẽ sửa nó, nếu không thì để yên.

Một điều cần lưu ý, tho, chúng tôi là một cửa hàng nhỏ gồm 4 nhà phát triển và một nhân viên thực tập và lỗi tôi sửa có lẽ là lỗi tôi tạo ra.

Nếu mã rõ ràng là sai, việc khắc phục khá đơn giản và bạn tin rằng rủi ro ảnh hưởng đến người dùng là thấp, thì hãy tìm cách khắc phục. Nó đi xuống để đánh giá chuyên nghiệp.

Mặc dù vậy, bạn phải nhớ rằng nếu bạn đã tìm thấy thì có lẽ người dùng đã không biết, nếu không họ sẽ báo cáo. Thay vì dành thời gian để khắc phục sự cố mà người dùng không bao giờ gặp phải, bạn có thể nên dành thời gian đó để khắc phục sự cố đang gây ra sự cố cho người dùng của mình.

Vâng ghi lại các quan sát trước, và quyết định xem có nên sửa nó sau không.

Có một số cuộc thảo luận chính thức (ví dụ, trong cuộc họp thường kỳ) hoặc thảo luận không chính thức (ví dụ: trong bữa trưa) với các đồng nghiệp của bạn và thực hiện các thay đổi sau khi bạn có thêm niềm tin vào hành vi của các mã bạn sẽ sửa.

Mặc dù có vẻ như là một lỗi / khiếm khuyết đối với bạn, nhưng nó thực sự có thể là một "tính năng" lần này. Nó có thể là một giải pháp được triển khai kém để khắc phục một số trường hợp góc vào phút cuối của phiên bản trước và "sửa chữa sạch" của bạn có thể làm sống lại một số vấn đề đã được giải quyết trước đó.

Tôi sẽ nắm bắt xu hướng ở đây. Trừ khi bạn đang ở giai đoạn phát triển nguyên mẫu rất sớm, bạn không bao giờ nên sửa nó ngay lập tức, bạn nên nộp báo cáo lỗi. Điều này có một số lợi thế:

• nhóm được đánh giá nó. Có phải là một lỗi thực sự, những rủi ro của việc sửa nó là gì.
• ban quản lý sẽ quyết định xem có đủ quan trọng để thực hiện tác động lịch trình bao gồm nó trong bản phát hành này không
• một phương pháp để phát hiện nó có thể được thêm vào bộ thử nghiệm, hy vọng trong một cách đủ chung để tìm ra các lỗi tương tự.
• nó cung cấp các số liệu có giá trị về số lượng lỗi đang trượt qua các giai đoạn trước