Theo dõi cấu trúc lại trong cơ sở dữ liệu lỗi

Question

Giả sử bạn làm việc ở nơi mà mọi thay đổi mã nguồn phải được liên kết với báo cáo lỗi hoặc yêu cầu tính năng và không có cách nào để cải thiện chính sách đó. Trong môi trường như vậy, cách tốt nhất để đối phó với việc tái cấu trúc mã (nghĩa là, những thay đổi cải thiện mã nhưng không sửa lỗi hoặc thêm một tính năng) là gì?

• Viết báo cáo lỗi và liên kết việc tái cấu trúc với nó.
• Viết một yêu cầu tính năng và liên kết việc tái cấu trúc với nó.
• Lén lút trong cấu trúc lại khi làm việc trên mã được liên kết với báo cáo lỗi/yêu cầu tính năng.
• Chỉ cần không thực hiện bất kỳ việc tái cấu trúc nào.
• Khác

Lưu ý rằng tất cả báo cáo lỗi và mô tả tính năng sẽ hiển thị cho người quản lý và khách hàng.

Answer 1

Tôi bỏ phiếu cho cách tiếp cận "lén lút trong refactorings", đó là, tôi tin rằng, cách tái cấu trúc có nghĩa là phải được thực hiện ngay từ đầu. Nó có thể là một ý tưởng tồi để refactor chỉ vì lợi ích của "làm sạch mã." Điều này có nghĩa là bạn đang thực hiện thay đổi không có lý do thực sự. Tái cấu trúc, theo định nghĩa, sửa đổi mà không có ý định sửa lỗi hoặc thêm tính năng. Nếu bạn tuân theo nguyên tắc KISS, bất kỳ tính năng mới nào cũng sẽ cần ít nhất một số tái cấu trúc vì bạn không thực sự nghĩ về cách làm cho hệ thống mở rộng nhất có thể lần đầu tiên.

Answer 2

Cách chúng tôi làm việc đó là: Phải có lý do chính đáng để cấu trúc lại mã, nếu không thì tại sao?

Nếu lý do là cho phép một tính năng khác sử dụng cùng một mã, hãy liên kết các thay đổi với yêu cầu của đối tượng địa lý khác.

Nếu nó làm nhanh hơn, hãy tạo yêu cầu tính năng cho 'xyz' nhanh hơn và kết hợp các thay đổi với điều đó - sau đó khách hàng thấy bạn đang cải thiện sản phẩm.

Nếu thiết bị xuất hiện lỗi, hãy đăng nhập lỗi.

Điều đáng chú ý là trong môi trường của tôi, chính sách không thể được thực thi. Nhưng các nhà quản lý thông minh có thể nhận được các báo cáo về những thay đổi và nếu họ không có một tham chiếu yêu cầu của lỗi trong văn bản cam kết thì nó sẽ được theo dõi.

Answer 3

Cho phép có một cái nhìn tại mỗi tùy chọn:

• Viết lên một lỗi-báo cáo và liên kết refactoring với nó.

Nếu bạn cảm thấy điều đó, theo ý kiến ​​của bạn, mã ban đầu đặt ra nguy cơ bảo mật hoặc khả năng gặp sự cố hoặc mất ổn định. Viết một báo cáo lỗi nhỏ phác thảo mối nguy hiểm, và sau đó sửa chữa nó.

• Viết lên yêu cầu tính năng và liên kết việc tái cấu trúc với nó.

Nó có thể khó mã phản ứng hơn dựa trên yêu cầu tính năng. Nhưng bạn có thể sử dụng yêu cầu tính năng hợp lệ để làm điều này dẫn tôi vào điểm tiếp theo ...

• Lén trong cấu trúc lại khi làm việc trên mã được liên kết với báo cáo lỗi/yêu cầu tính năng.

Nếu có lỗi hoặc tính năng hợp lệ, hãy nói rằng chức năng x phải được thay đổi một chút để sửa lỗi hoặc thêm đối tượng địa lý.

• Chỉ cần không thực hiện bất kỳ việc tái cấu trúc nào.

Điều này dường như đề xuất việc tự phát triển thông qua cải thiện một ứng dụng không được phép. Các nhà phát triển nên được cho phép, nếu không, khuyến khích khám phá các kỹ thuật và công nghệ mới.

• khác

lẽ bạn có thể thảo luận về cải thiện của bạn tại cuộc họp liên quan, đưa ra lý do thuyết phục vì sao những thay đổi nên được thực hiện. Sau đó, ít nhất bạn sẽ có sự hỗ trợ quản lý để thay đổi mà không cần phải lẻn vào mã thông qua một phương pháp khác.

Answer 4

Nếu bạn đang làm việc trên một khối mã, trong hầu hết các trường hợp đó là do sửa lỗi hoặc tính năng mới yêu cầu khối mã đó thay đổi và việc tái cấu trúc trước khi thay đổi để thực hiện nó dễ dàng hơn, hoặc sau khi thay đổi để dọn dẹp kết quả. Trong cả hai trường hợp, bạn có thể liên kết việc tái cấu trúc với tính năng hoặc sửa lỗi đó.

Answer 5

• khác

Nếu bạn làm việc tại một nơi với loại chính sách cứng nhắc (và lố bịch), giải pháp tốt nhất là tìm một công việc khác!