Thực tiễn tốt nhất để đổi tên, tái cấu trúc và phá vỡ các thay đổi với các nhóm

Một số thực tiễn tốt nhất để tái cấu trúc và đổi tên trong môi trường nhóm là gì? Tôi nghĩ đến điều này với một vài tình huống:

1. Nếu một thư viện thường được tham chiếu được tái cấu trúc để giới thiệu một thay đổi đột phá cho bất kỳ thư viện hoặc dự án nào tham chiếu nó. Ví dụ, tùy ý thay đổi tên của một phương thức.

2. Nếu các dự án được đổi tên và các giải pháp phải được xây dựng lại với các tham chiếu được cập nhật cho chúng.

3. Nếu cấu trúc dự án được thay đổi thành "có tổ chức hơn" bằng cách giới thiệu các thư mục và di chuyển các dự án hoặc giải pháp hiện có đến vị trí mới.

Một số suy nghĩ / câu hỏi bổ sung:

1. Nên thay đổi như vấn đề này hoặc dẫn đến đau là một dấu hiệu của cấu trúc trở nên tồi tệ?

2. Ai nên chịu trách nhiệm sửa lỗi liên quan đến thay đổi vi phạm? Nếu một nhà phát triển thực hiện thay đổi đột phá, họ có nên chịu trách nhiệm đi vào các dự án bị ảnh hưởng và cập nhật chúng hay họ nên cảnh báo cho các nhà phát triển khác và nhắc họ thay đổi mọi thứ?

3. Đây có phải là một cái gì đó có thể được thực hiện trên cơ sở theo lịch trình hoặc nó là một cái gì đó nên được thực hiện thường xuyên nhất có thể? Nếu quá trình tái cấu trúc bị trì hoãn quá lâu, việc điều hòa sẽ ngày càng khó khăn hơn nhưng đồng thời trong một ngày dành 1 giờ để sửa chữa một bản dựng vì những thay đổi xảy ra ở nơi khác.

4. Đây có phải là vấn đề của một quá trình giao tiếp chính thức hay nó có thể là hữu cơ?

Mỗi kịch bản bạn liệt kê thuộc danh mục "API / mã được xuất bản". Điều này rất khó để cấu trúc lại, vì vậy người ta không nên thay đổi bất cứ điều gì nhẹ nhàng. Thay vào đó, anh ấy nên thương lượng các thay đổi được lên kế hoạch trước với tất cả các bên liên quan. Nó ít nhất là một vấn đề chính trị như kỹ thuật.

Vì vậy, lời khuyên số một về vấn đề này từ Martin Fowler là không xuất bản sớm các giao diện (tên dự án và cấu trúc) của bạn .

Tuy nhiên, nếu nó đã được thực hiện và nó cần được sửa chữa, có lẽ tốt hơn là cố gắng thực hiện các thay đổi cần thiết trong càng ít bước càng tốt, để giảm thiểu sự gián đoạn của các bên khác. Điều này đi lệch khá xa so với khái niệm tái cấu trúc ban đầu, nhưng vì một lý do chính đáng.

Ngoài ra, nếu có thể, hãy xem xét thêm phương thức mới (trong khi không dùng phương thức hiện tại) thay vì đổi tên phương thức hiện có. Điều này đảm bảo rằng mã máy khách không bị phá vỡ và cung cấp thời gian chuyển đổi để họ cập nhật mã của mình để tuân thủ API mới nhất. Hạn chế là nó làm phức tạp API của bạn. Mặc dù trạng thái chỉ là tạm thời, tuy nhiên có thể mất nhiều thời gian trước khi bạn có thể xóa các phương thức API không dùng nữa (trong trường hợp thư viện lớp Java, năm).

Bạn hầu như luôn có thể tránh những vấn đề này bằng cách tái cấu trúc theo hai bước. Trong bước đầu tiên, giới thiệu mã mới và không dùng mã cũ. Khi tất cả các đội đã di chuyển sang mã mới, hãy xóa mã cũ. Tôi cũng sử dụng kỹ thuật này để tăng dần cấu trúc lại một mô-đun. Bằng cách này, tôi có thể giới hạn số lượng mã phải được thay đổi giữa các lần chạy thử.

Lưu ý rằng đây là một trong những lý do chính để có một máy chủ xây dựng, chạy thử nghiệm.

Nếu bất cứ điều gì xảy ra sẽ phá vỡ một chương trình nhất định, bạn sẽ được thông báo nhanh nhất có thể và có thể truy tìm thủ phạm và giải quyết các vấn đề trong khi các chi tiết vẫn còn mới.