Tại sao một nhóm phát triển lại khăng khăng rằng sử dụng một giải pháp duy nhất cho nhiều dự án trong Visual Studio, làm tăng sự phức tạp phụ thuộc lẫn nhau?

Tôi đang giúp quản lý một nhóm bên ngoài đang bắt đầu phát triển phiên bản mới của một số sản phẩm hiện có. Từ trước đến nay, nhóm này luôn sử dụng mô hình của một dự án trong một giải pháp duy nhất cho khoảng 30 mô-đun trong Visual Studio đi cùng nhau để tạo ra một bản dựng có thể triển khai.

Điều này có tác động bất lợi đến độ tin cậy và chất lượng xây dựng, bởi vì họ không luôn gửi cho chúng tôi mã nguồn cập nhật nhất. Chúng tôi đang cố gắng nhấn chúng để thống nhất tất cả mã được tham chiếu vào một giải pháp duy nhất, nhưng chúng tôi đang gặp phải một số kháng cự - cụ thể là họ tiếp tục nói về sự phụ thuộc lẫn nhau giữa các mô-đun (đọc "dự án" trong Visual Studio) nếu mọi thứ được đặt vào một tập tin giải pháp duy nhất. Không có mã nào trong các giải pháp riêng biệt được sử dụng ở nơi khác.

Tôi khẳng định điều này là vô nghĩa và các mô hình phát triển tốt sẽ tránh được bất kỳ vấn đề nào như vậy.

Nhóm nghiên cứu cũng thực hiện sửa lỗi và phát triển tính năng mới trên một sản phẩm hiện có, kinh nghiệm trong đó có thể nói là ít nhất và chịu chính xác vấn đề phân tách trên nhiều giải pháp. Chúng tôi đã bị từ chối truy cập vào kiểm soát nguồn của họ ( TFS ) và cách tiếp cận mà chúng tôi đang thực hiện để thống nhất cơ sở mã là thử và ít nhất là giảm số lượng cập nhật bị thiếu và nhiều hơn là hồi quy không thường xuyên (vâng, các lỗi đã sửa -được giới thiệu vào sản phẩm) bằng cách nói "gửi cho chúng tôi một ZIP của toàn bộ thư mục giải pháp để chúng tôi có thể giải nén, mở nó trong Visual Studio và nhấnF5 để thử nghiệm ". Về mặt cấu trúc và chất lượng chung, mã này khá kém và khó hỗ trợ. Kinh nghiệm này là lý do tại sao tôi có ý định làm cho các quy trình làm việc càng sớm trong chu kỳ phát triển càng tốt.

Có thiếu điều gì không? Có bao giờ một lý do tốt để giữ tất cả các mã đó tách ra? Đối với tiền của tôi, nó sẽ phải là một lý do thuyết phục đến mức nó sẽ là kiến ​​thức phổ biến, nhưng tôi sẵn sàng thừa nhận rằng tôi không biết tất cả mọi thứ.

Bạn không cần nói với họ cách cấu trúc dự án của họ. Thay vào đó, hãy đặt ra một yêu cầu khó khăn là bạn có thể xây dựng hệ thống từ nguồn bằng cách chạy một tập lệnh duy nhất mà không gặp bất kỳ lỗi nào. Nếu các tập lệnh đó chạy Visual Studio hoặc Msbuild hoặc một số công cụ khác và nếu chúng được gọi một lần, 50 hoặc 100 lần thì không thành vấn đề.

Bằng cách đó, bạn có được "kiểm tra tính đầy đủ" của mã giống như bạn sẽ nhận được bằng cách đặt mọi thứ vào một giải pháp duy nhất. Tất nhiên, tập lệnh đó không cho bạn biết nếu nhóm thực sự đã kiểm tra phiên bản mới nhất từ ​​kiểm soát nguồn của họ, nhưng việc có toàn bộ mã trong một giải pháp cũng sẽ không kiểm tra điều đó.

Là một trả lời "phụ thuộc lẫn nhau giữa các module được tăng lên nếu mọi thứ được đặt trong một tập tin giải pháp duy nhất" - đây là proveable vô nghĩa, kể từ khi thêm dự án đến một giải pháp không thay đổi bất kỳ sự phụ thuộc giữa các dự án, sự phụ thuộc này là kết quả từ một dự án tệp tham chiếu tệp khác, hoàn toàn độc lập với giải pháp tham chiếu tệp dự án nào. Không ai ngăn nhóm đó có cả hai - một giải pháp duy nhất tham chiếu tất cả các dự án, và cả các giải pháp riêng lẻ mỗi người chỉ tham khảo một dự án.

Tuy nhiên, tôi sẽ đề nghị thêm một kịch bản xây dựng. Điều này có lợi ích ngay cả khi chỉ có một tệp giải pháp. Ví dụ: nó cho phép một người chạy bản dựng VS với cấu hình ưu tiên, cho phép bạn sao chép các tệp cuối cùng để triển khai (và không có gì nữa) vào thư mục "triển khai" và có thể chạy một số công cụ và các bước khác để hoàn tất quá trình xây dựng. Xem thêm F5 không phải là một quá trình xây dựng! và Thử nghiệm Joel .

Nó sẽ phụ thuộc vào số lượng các tập hợp được biên dịch được sử dụng lại. Nếu không có việc sử dụng lại các hội đồng, thì không có lý do thực sự nào để giữ các "mô-đun" riêng biệt. Trong thực tế theo kinh nghiệm của tôi, điều này là một trở ngại nhiều hơn.

Trong nhóm phát triển, tôi là một phần của chúng tôi có các thư viện độc lập mà chúng tôi đã viết được sử dụng trong nhiều sản phẩm như một giải pháp riêng biệt, trong trường hợp này có ý nghĩa nếu không chúng tôi sẽ phải biên dịch Ứng dụng A để cập nhật Ứng dụng B, có thể được yêu cầu để giữ cho Ứng dụng C được cập nhật.

Mỗi sản phẩm được giữ trong giải pháp riêng của mình, ngay cả khi có nhiều dự án tạo nên sản phẩm. Bằng cách này, chúng tôi chỉ phải xây dựng giải pháp Thư viện để cập nhật mã chia sẻ của nó trong tất cả các sản phẩm được phát triển.

Mỗi công ty phần mềm tôi từng làm việc đều có một nhóm phát triển cốt lõi cung cấp chi nhánh chính bao gồm các trường hợp sử dụng nền tảng cho các sản phẩm của công ty.

Các nhà phát triển chi nhánh sử dụng kho lưu trữ cốt lõi có trách nhiệm khám phá các cải tiến và gửi yêu cầu kéo đến chi nhánh chính để xem xét. Đây thường là cách người ta trở thành một nhà phát triển cốt lõi, bằng cách cho thấy một người có thể đóng góp tốt hơn là chỉ thổi bùng ngọn lửa của một cuộc xung đột kiến ​​trúc.

Có khả năng công ty của bạn đơn giản là không có tài nguyên để ngay lập tức "thống nhất tất cả các mã được tham chiếu một giải pháp". Đề nghị họ làm như vậy mà không hiểu những hạn chế về ngân sách của họ là (ít nhất) có khả năng ngăn người ta trở thành một kỹ sư cốt lõi.

Vì vậy, xây dựng tầm nhìn lớn của bạn vào một vài yêu cầu kéo tàn phá đến cốt lõi, và chuẩn bị để bảo vệ chính mình trong xem xét!

Có một hạt nhân của sự thật trong khẳng định "Sử dụng một giải pháp duy nhất cho nhiều dự án làm tăng độ phức tạp phụ thuộc lẫn nhau".

Một giải pháp duy nhất làm cho việc tham chiếu một dự án từ một dự án khác (tức là sử dụng lại mã của dự án hay còn gọi là "giới thiệu độ phức tạp phụ thuộc lẫn nhau") dễ dàng hơn:

• thay vì duyệt toàn bộ bộ đệm bộ đệm hệ thống tập tin / toàn cầu của bạn cho tập hợp được tham chiếu, bạn có thể chọn dự án từ một tập hợp hạn chế các dự án có liên quan trong giải pháp; và,
• khi đọc mã nguồn, việc chuyển sang một dự án được tham chiếu trong giải pháp sẽ dễ dàng hơn nhiều so với việc lắp ráp tùy ý (nhị phân).

Vì vậy, trong tay của một nhóm vô kỷ luật sử dụng nhiều dự án trong một giải pháp duy nhất có thể dẫn đến rất nhiều phụ thuộc được giới thiệu bất cẩn. Tuy nhiên, một nhóm tốt hơn có thể cố gắng học các kỷ luật cần thiết để quản lý cẩn thận các phụ thuộc và sau đó sử dụng dễ dàng sử dụng lại các giải pháp đó.