Làm thế nào để bạn quản lý tái cấu trúc với một cơ sở mã lớn và nhiều nhà phát triển?

Tôi muốn ngăn chặn tình huống hai nhà phát triển tái cấu trúc cùng một mã mà không nói về nó trước, có thể sử dụng một công cụ nào đó, có thể là một trình cắm thêm Eclipse. Bạn có thể giúp?

Chúng tôi đã có 4,5 triệu dòng mã và hơn 20 nhóm nhà phát triển trên bốn lục địa.

Lý tưởng nhất là tôi muốn người thứ hai trong số các nhà phát triển được đề cập trước đó nhận thấy rằng ai đó đang làm việc trên cùng một đoạn mã và nói chuyện với mã đầu tiên trước khi sửa đổi bất cứ điều gì.

Bạn có biết một giải pháp?

Nhiều hệ thống kiểm soát nguồn thế hệ 2 hoạt động bằng cách sử dụng "kiểm tra" được kết nối để thông báo cho máy chủ rằng bạn đang có ý định sửa đổi một tệp. Ví dụ bao gồm TFS, SourceGear Vault và nhiều thứ khác. Bằng cách này, bạn có thể hoàn thành về mặt kỹ thuật yêu cầu của bạn. Như Adam Butler đã chỉ ra, các loại công cụ này đi kèm với các vấn đề của riêng họ (mà không cần phải tranh luận lâu dài - hỗ trợ hạn chế cho công việc ngoại tuyến và quy trình phát triển phản tác dụng nói chung).

Tôi chắc chắn sẽ đề xuất một số cách tiếp cận phân cấp để phân bổ công việc tái cấu trúc. Các nhà phát triển có thể được nhóm hợp lý thành các nhóm phụ, mỗi nhóm chịu trách nhiệm cho các khu vực cụ thể của mã. Tùy thuộc vào cách bạn muốn cấu trúc các nhóm, mỗi người có thể có vai trò "lãnh đạo", người chịu trách nhiệm thiết kế cấp cao cho khu vực của đội. Cấu trúc này nên được các nhà phát triển biết đến và nó sẽ đơn giản hóa việc giao tiếp để tái cấu trúc. Tôi chắc chắn rằng cách tiếp cận này có vẻ quá trang trọng và lạc hậu với một số người, nhưng tôi nghĩ rằng rất nên để các nhà phát triển 20+ sử dụng cách tiếp cận "miễn phí cho tất cả" để tái cấu trúc một hệ thống lớn. Một số phép tái cấu trúc sẽ diễn ra ở mức cao (ví dụ như mô-đun X sẽ giao tiếp với mô-đun Y như thế nào), trong trường hợp đó bạn sẽ cần những người có thể thực hiện cuộc gọi ở cấp độ thích hợp. Không phải mọi nhà phát triển trong nhóm nên đưa ra quyết định kiến ​​trúc, do đó, một hệ thống phân cấp gần như được áp đặt trong mọi trường hợp, ngay cả khi người ta chọn không biết gì về nó.

Về cơ bản, có những công cụ để đáp ứng yêu cầu cơ bản mà bạn đưa ra, nhưng không có công cụ nào thay thế thông tin liên lạc phù hợp và có một số ít người điều khiển kiến ​​trúc chung của dự án của bạn.

1. Đảm bảo các nhà phát triển được chỉ định các mô-đun cụ thể.
2. Có một hệ thống theo dõi nhiệm vụ / lỗi theo dõi mọi thay đổi tái cấu trúc. Chỉ định từng vấn đề cho chỉ một nhà phát triển
3. Một số hệ thống kiểm soát phiên bản có khả năng khóa tệp để chỉ một nhà phát triển có thể có quyền cập nhật đối với tệp. Tôi chưa bao giờ sử dụng tính năng đó nhưng nếu các nhà phát triển liên tục bước qua nhau, đây là điều bạn có thể muốn xem xét.
4. Có các bài kiểm tra đơn vị để ngay cả khi các nhà phát triển làm việc trên cùng một tệp, bạn biết các thay đổi của họ không phá vỡ ứng dụng theo bất kỳ cách nào.
5. Tất cả những điều trên sẽ giúp ích nếu tái cấu trúc của bạn được chứa trong các mô-đun. Tuy nhiên, nếu ai đó thực hiện tái cấu trúc về mối quan tâm xuyên suốt như ghi nhật ký hoặc bảo mật, nó sẽ ảnh hưởng đến nhiều tệp theo định nghĩa. Những người cần được xử lý cẩn thận đặc biệt là nếu bạn chưa tận dụng lợi thế của phương pháp tiếp cận.

Có / là các hệ thống kiểm soát phiên bản làm cho các nhà phát triển kiểm tra mã trước khi họ có thể chỉnh sửa nhưng chúng có các vấn đề riêng. Thực hành tốt hơn là để các nhà phát triển cam kết và cập nhật thường xuyên. Sau đó, một nhà phát triển có thể đánh dấu một lớp là khấu hao và cam kết sau đó nếu nhà phát triển khác cập nhật trước khi họ bắt đầu cấu trúc lại, họ sẽ thấy ý định đó.

Công nghệ không thể giải quyết các vấn đề xã hội. Bạn cần phải khiến các nhà phát triển của bạn nói chuyện với nhau và điều phối công việc của họ. Với 20 đội, một số cấu trúc và quy tắc sẽ rất cần thiết. Bạn sẽ muốn hỗ trợ họ với các giải pháp công nghệ, nhưng mọi người đến trước.

Nếu bạn rời đi notice that someone else is working on the same piece of code and talk to the first one before modifying anything, theo như những gì bạn nói, bạn cần một hệ thống kiểm soát phiên bản (CVS / SVN / GIT). Tôi không chắc chắn, nhưng nếu bạn cũng muốn bao gồm điều đó, bạn sẽ cần một số thứ nâng cao (một số loại cơ chế kích hoạt / một số điều tùy chỉnh có thể).

Các nhà phát triển khóa các tệp trong kiểm soát nguồn sẽ giải quyết vấn đề của bạn một cách dễ dàng, nhưng sau đó tôi nghĩ bạn có thể gặp vấn đề lớn hơn.

4,5 triệu LỘC là một hộp cát khổng lồ để chơi trong một giải pháp được thiết kế và kiến ​​trúc tốt, bạn hiếm khi gặp phải tình huống trong đó nhiều nhóm nhà phát triển đang dẫm lên nhau. Thực tế là điều này xảy ra nhiều hơn là trùng hợp ngẫu nhiên đang nói về một số lỗi thiết kế tiềm năng nghiêm trọng cần được xem xét.

Một vài thứ:

1. Các mô-đun riêng biệt để làm việc
2. Nói về những thay đổi trước khi chúng được thực hiện [với tất cả các nhà phát triển]
3. Kiểm tra đơn vị [để xác minh và tránh phá vỡ những thứ liên quan]
4. Như những người khác đã đề cập đến một VCS