Giải quyết xung đột hợp nhất do tái cấu trúc


13

Gần đây tôi đã tham gia vào một cuộc thảo luận về cách xử lý tái cấu trúc nói chung (đây là một chủ đề thú vị). Cuối cùng, câu hỏi sau đây đã được đưa ra:

Làm thế nào để một người xử lý các xung đột hợp nhất xảy ra do ai đó đã thực hiện tái cấu trúc một phần của mã, trong khi một người khác đang làm việc trên một tính năng cho cùng một đoạn mã?

Về cơ bản, tôi không có ý tưởng làm thế nào để đối phó với điều này một cách hiệu quả. Có bất kỳ thực hành tốt nhất mà người ta nên làm theo về điều này? Có sự khác biệt nào về cách người ta nên xử lý việc này đối với một hệ thống có hàng tấn mã kế thừa không?


Tôi có một câu hỏi tương tự, nhưng với các yêu cầu khác nhau, vì vậy tôi đã thêm một câu hỏi khác. lập trình
viên.stackexchange.com/questions/109229 / Google

Câu trả lời:


9

Câu hỏi hay. Chiến lược tốt nhất tôi có thể nghĩ đến là:

Phòng ngừa

Một sự kết hợp của tích hợp liên tục và thực hiện tái cấu trúc nhỏ thường xuyên (thay vì tái cấu trúc lớn thường xuyên) sẽ đi một chặng đường dài để giảm thiểu chi phí và tần suất của các xung đột đó.


3

Tôi nghĩ để trả lời câu hỏi của bạn, trước tiên chúng ta phải xem tại sao xung đột xảy ra, và ý nghĩa thực sự và quá trình hợp nhất là gì?

Mâu thuẫn chỉ xảy ra khi hai hay nhiều nhà phát triển đang làm việc trên cùng một tập tin tại thời và sau đó cả hai đều cố gắng để nhận phòng. Các nhà phát triển đầu tiên sẽ không nhận được bất kỳ xung đột, tất nhiên. Nhưng thứ hai (thứ ba, thứ tư, v.v.) sẽ có xung đột. Tại sao, bởi vì anh ta có một số mã khác một phần hoặc hoàn toàn khác với mã hiện có trên máy chủ.

Điều này về bản chất có nghĩa là nhà phát triển thứ hai có một cái gì đó khác với nhà phát triển đầu tiên. Sự khác biệt này có thể khác nhau từ kiểu dáng, như sử dụng new UserManager().GetUserName()thay vì UserManager userManager = new UserManager(); userManager.GetUserName();đến mức bạn đã đề cập, điều đó có nghĩa là cả hai nhà phát triển đều có ý tưởng khác nhau về cách cấu trúc lại mã để cải thiện mã.

Sáp nhập, mặt khác, không có nghĩa là các nhà phát triển có thể đăng ký mã của họ mà không xem xét xung đột. Họ nênphải giải quyết những xung đột đó. Nếu xung đột không quan trọng, thì họ có thể đăng ký và ghi đè mã trước đó. Nhưng khi họ thấy một cái gì đó hoàn toàn khác, họ nên gọi cho nhà phát triển trước đó và nói chuyện với anh ta, để cả hai có thể phối hợp với nhau để kiểm tra giải pháp tốt nhất.

Ví dụ: nếu bạn yêu cầu hai nhà phát triển cải thiện thư viện thanh toán trực tuyến và công việc của họ chồng chéo, điều này có nghĩa là ít nhất ở một số nơi, có 2 giải pháp khác nhau. Vì vậy, một trong những giải pháp đó nên được nói đến và được chấp nhận, do đó, đăng ký, là giải pháp tốt hơn.

Tôi không đồng ý về việc ngăn chặn những trường hợp này, vì chúng ta nên có xu hướng thực tế hơn là lý thuyết. Đôi khi một anh chàng thực sự giỏi về CSS, trong khi một người khác thực sự giỏi về ASP.NET Markup. Nhưng công việc của họ có thể xung đột khi cả hai nên làm việc trên trang đăng nhập để làm cho nó hoạt động. Ý tôi là, nếu chúng ta nghĩ thực tế (không lý tưởng), chúng ta có thể thấy rằng nhiều lần hiện tượng này (xung đột) xảy ra.

Một điểm khác tôi chỉ muốn đề cập, là sử dụng các công cụ để giúp bạn trong quá trình đăng ký. Các công cụ này thường trực quan hóa sự khác biệt của mã máy chủ và mã nhà phát triển và giúp ích rất nhiều trong việc xác định phần nào cần được đăng ký.


3

Nếu không có quản lý tích cực của các nhiệm vụ, bạn có xung đột.

Tuy nhiên, nếu bạn có một cuộc họp đứng lên hàng ngày hoặc một người quản lý , bạn không thể có vấn đề này.

Hoặc là nói chuyện (thông qua việc đứng lên hàng ngày) hoặc nói chuyện với người quản lý.

Điều này được ngăn chặn tầm thường bằng cách nói chuyện.


+1. Một số nhà phát triển xem các nhà quản lý là một trở ngại. Nhưng các nhà quản lý thực sự tồn tại để cho phép người khác làm việc và đây là một ví dụ tuyệt vời về vấn đề họ có thể giúp đỡ.
MarkJ

@MarkJ: Một người quản lý là một trở ngại để hợp nhất các xung đột không phải là một điều xấu. Điểm tuyệt vời.
S.Lott

+1 Tôi chỉ định thêm một cái gì đó như thế này vào câu trả lời của tôi nhưng bạn đóng đinh nó. Nếu bạn đang sử dụng một cuộc xung đột để cho bạn biết người khác đang làm việc trong cùng khu vực, bạn sẽ phát hiện ra rất muộn trong trò chơi và sau đó phải giải quyết nó. Quản lý tác vụ và truyền thông có thể cho phép các nhà phát triển làm việc trong cùng một khu vực làm việc cùng nhau ngay từ đầu .
Gyan aka Gary Buyn

1

Có một nhánh chung riêng để phát triển một tính năng nhất định, thường xuyên hợp nhất / kéo / đẩy - đó là nó.

giao tiếp . Nói chuyện với các nhà phát triển khác về mã ngay cả khi khởi chạy. Ngay cả khi mã hóa)))


1

Hãy chắc chắn rằng việc hợp nhất càng đơn giản càng tốt. Tái cấu trúc thường là một quy trình khá cơ học làm thay đổi nhiều dòng hiện có : Di chuyển khai báo biến, thay đổi khoảng trắng, định dạng, chuỗi thao tác. Tạo tính năng thường là một liên doanh sáng tạo hơn nhiều, thường dẫn đến mã mới cộng với một vài điều chỉnh nhỏ cho mã hiện có. Bây giờ nếu nhà phát triển thực hiện tái cấu trúc ghi lại các bước (ví dụ như biểu thức thông thường), việc áp dụng các mã này cho mã với chức năng bổ sung sẽ dễ dàng hơn nhiều so với cách khác. Dựa trên điều này, tôi muốn nói rằng như một quy tắc chung , trước tiên bạn nên áp dụng thay đổi phức tạp nhất, sau đó là các thay đổi đơn giản dần dần.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.