Làm thế nào để xác định mức độ ưu tiên và mức độ nghiêm trọng của một cải tiến mã cải tiến

Chúng tôi có các trường "ưu tiên" và "mức độ nghiêm trọng" trong hệ thống theo dõi lỗi của chúng tôi. Chúng tôi định nghĩa mức độ nghiêm trọng là "cách nó tác động đến người dùng" và ưu tiên là "cách nó tác động đến sản phẩm".

Câu hỏi của tôi là về cách phân loại một nhiệm vụ "cải thiện mã" theo mức độ nghiêm trọng và mức độ ưu tiên. Giả sử sự cải tiến không thay đổi bất kỳ hành vi nào nhưng làm cho nó trở thành một "mã tốt hơn". Chúng tôi dự đoán một cải tiến bảo trì dài hạn nói chung nhưng thật khó để định lượng.

Khi chúng tôi sử dụng các định nghĩa về mức độ ưu tiên và mức độ nghiêm trọng, một cải tiến mã sẽ nhận được các giá trị thấp nhất cho cả hai trừ khi bạn đưa ra một số khó khăn để dự đoán lợi ích lâu dài vào bức tranh. Do đó, nó ngụ ý rằng cải tiến mã là một nhiệm vụ phù phiếm và không bao giờ nên thử.

Tuy nhiên, tôi tin rằng nó liên tục cải tiến và cấu trúc lại mã, bởi vì:

• Phát triển phần mềm tự nó là một quá trình học hỏi liên tục và không cải thiện mã, bạn không thể cải thiện nó.
• Một nhóm nên tự hào về mã của họ.
• Bảo trì trong tương lai sẽ mất ít thời gian hơn và trong thời gian dài tiết kiệm sẽ rất đáng kể.

Hoặc bạn có nghĩ rằng những nhiệm vụ như vậy không bao giờ nên được tạo ra và những cải tiến như vậy chỉ thực hiện "theo yêu cầu", "khi liên quan đến lỗi"? Ngay cả khi nó liên quan đến một lỗi, đó sẽ không phải là một điểm thảo luận về đánh giá mã, ví dụ: "tại sao bạn lại thực hiện thay đổi mạnh mẽ này trong cấu trúc?".

Thông thường, tôi không thích xem các hoạt động "cải tiến mã" như một nhiệm vụ có thể phân công riêng biệt bởi vì chính cải tiến mã không bao giờ trực tiếp đưa bạn đến gần hơn để hoàn thành các câu chuyện hoặc yêu cầu của người dùng. Đây là lý do tại sao các nhiệm vụ cải tiến mã sẽ luôn được ưu tiên thấp đến mức chúng không bao giờ được giao.

Tôi thấy cải tiến mã là một hằng số, điều mà mọi nhà phát triển nên làm một cách tự nhiên như gõ trên bàn phím. Tôi tính nó vào ước tính của tôi cho bất kỳ nhiệm vụ. Nếu nhiệm vụ của tôi liên quan đến việc tôi chạm vào một lớp hoặc một số mã nguồn đã không được xem xét trong một thời gian dài, thì tôi sẽ cho rằng một số công việc của người quản lý có thể theo thứ tự và tăng ước tính của tôi theo đó.

Kịch bản trường hợp tốt nhất tôi hoàn thành nhiệm vụ sớm và có thể sử dụng thời gian còn lại để cải thiện mã hoặc thậm chí thiết kế. Trường hợp xấu nhất là nhiệm vụ mất nhiều thời gian hơn dự kiến ​​nhưng tôi có thêm thời gian làm bộ đệm.

Nếu bạn muốn cấu trúc lại mã của mình, hãy đặt mức độ ưu tiên của tác vụ theo định nghĩa của bạn (nghĩa là "cách nó tác động đến sản phẩm"). Một số tái cấu trúc sẽ không ảnh hưởng đến sản phẩm nhiều và một số sẽ, tùy thuộc vào phạm vi công việc cần thiết. Đặt mức độ ưu tiên cao hơn sẽ chỉ ra rằng cần phải thực hiện thêm thử nghiệm sau khi quá trình tái cấu trúc được hoàn thành để đảm bảo không có gì bất ngờ xảy ra.

Bạn cũng có thể muốn giới thiệu một danh mục mới trong hệ thống theo dõi lỗi của mình để phân loại các loại nhiệm vụ này thành các nhiệm vụ "Tái cấu trúc". Bằng cách này bạn sẽ biết cách diễn giải giá trị ưu tiên; nghĩa là, mức độ ưu tiên cao hơn có nghĩa là tác động lớn hơn và do đó cần nhiều thử nghiệm hơn.

Điều còn thiếu là xác minh các giả định của bạn về mã hiện tại: có thể đạt được ít thời gian hơn và tiết kiệm đáng kể nếu chúng tôi cải thiện mã. Là mỹ phẩm này hoặc có vấn đề nghiêm trọng?

Kiểm tra các ước tính gỡ lỗi và nâng cao của bạn. Nếu họ mất nhiều thời gian hơn và có những bình luận liên tục về việc phải cấu trúc lại mã trước hoặc làm sạch nó, đó có thể là phép đo tốt nhất của bạn. Sau đó, bạn có thể xác định cơ sở mã của mình là: Tốt, cần làm lại nhỏ hoặc yêu cầu tái cấu trúc nghiêm trọng.

Tất cả điều này là tương đối. Thật khó để đưa ra mức ưu tiên cao này khi có những khách hàng muốn có nhiều tính năng hơn và sẵn sàng trả tiền ngay lập tức cho các giờ có thể thanh toán.

Câu hỏi thú vị.

Tôi nghĩ rằng bạn phải ước tính có bao nhiêu dòng mã và bao nhiêu mô-đun mà một thay đổi có thể ảnh hưởng.

Có lẽ bạn có thể xem xét có bao nhiêu bài kiểm tra đơn vị, nếu bạn có chúng, sẽ bị phá vỡ bằng cách thực hiện thay đổi. Điều này có thể có nghĩa là thử thay đổi trong một chi nhánh trước để có ý tưởng.

Sau đó, có ngưỡng cho các mức độ phù hợp và mức độ nghiêm trọng.

Bạn cũng nên tính đến việc thử nghiệm nhiều sẽ cần phải tham gia. Nếu thay đổi chạm vào diện tích bề mặt lớn của ứng dụng, thì rất nhiều thử nghiệm hệ thống có thể cần phải được xem xét lại.

Hãy bắt đầu với hai giả định ở đây.

1. Đối với mỗi câu chuyện mới, bạn viết mã của bạn với khả năng tốt nhất của bạn, có thể được bảo vệ với kiến ​​thức xung quanh của nhóm của bạn.
2. Bất cứ khi nào bạn có một câu chuyện thay đổi chức năng của mã hiện có, bạn sử dụng kiến ​​thức mới về hệ thống và các kỹ năng tốt hơn để cải thiện mã trong quá trình triển khai câu chuyện mới.

Với hai giả định đó, không bao giờ cần một nỗ lực "cải tiến mã" rõ ràng. Mã của bạn được cải thiện khi bạn viết hệ thống. Điều này có nghĩa là không phải tất cả các mã đều tuân theo các tiêu chuẩn mới nhất và lớn nhất của bạn về khả năng bảo trì nhưng "Nếu nó không bị hỏng thì đừng sửa nó." Tôi coi mã tái cấu trúc không cần phải thay đổi thành "mạ vàng" cũng như thêm chức năng hiển thị không cần thiết. Nếu mã bị hỏng theo một cách nào đó, hãy viết một bài kiểm tra hợp lệ không thành công; đăng nhập một lỗi; và sau đó refactor để giải quyết lỗi đó.

Tôi sẽ đánh cắp phiếu bầu từ phong trào Agile:

Nhập lỗi, đoán sơ bộ về mức độ nghiêm trọng và mức độ ưu tiên,

Sau đó, hàng ngày, hàng tuần hoặc hàng tháng xem xét tất cả các lỗi mới và bỏ phiếu cho xếp hạng của chúng. Lý tưởng nhất là bạn làm điều này trong một cuộc họp lập kế hoạch nước rút với người dùng cuối. Sau đó, bạn có thể nói về các tính năng tiếp theo tại thời điểm đó và tích cực,