Vấn đề của bạn rất phổ biến. Và một vấn đề thực sự nữa, bởi vì không có giải pháp tốt.
Chúng tôi đang ở trong tình trạng tương tự ở đây, tôi cũng nói tồi tệ hơn, với 13 triệu dòng mã, doanh thu và hơn 800 nhà phát triển làm việc trên mã. Chúng ta thường thảo luận về cùng một vấn đề mà bạn mô tả.
Ý tưởng đầu tiên - các nhà phát triển của bạn đã sử dụng - là để cấu trúc lại mã chung trong một số lớp tiện ích. Vấn đề của chúng tôi với giải pháp đó, ngay cả với lập trình cặp, tư vấn và thảo luận, là chúng tôi chỉ đơn giản là quá nhiều để điều này có hiệu quả. Trong thực tế, chúng tôi phát triển trong các đường phụ, với những người chia sẻ kiến thức trong subteam của họ, nhưng kiến thức không chuyển tiếp giữa các subteams. Có lẽ chúng tôi đã sai nhưng tôi nghĩ rằng ngay cả lập trình cặp và các cuộc đàm phán cũng không thể giúp ích trong trường hợp này.
Chúng tôi cũng có một nhóm kiến trúc. Nhóm này chịu trách nhiệm đối phó với các mối quan tâm về thiết kế và kiến trúc và để tạo ra các tiện ích chung mà chúng tôi có thể cần. Nhóm này trong thực tế sản xuất một cái gì đó chúng ta có thể gọi là một khuôn khổ của công ty. Vâng, đó là một khuôn khổ, và đôi khi nó hoạt động tốt. Nhóm này cũng chịu trách nhiệm thúc đẩy thực hành tốt nhất và nâng cao nhận thức về những gì nên được thực hiện hay không, những gì có sẵn hoặc những gì không có.
Thiết kế Java API cốt lõi tốt là một trong những lý do cho sự thành công của Java. Thư viện nguồn mở của bên thứ ba tốt cũng tính rất nhiều. Ngay cả một API nhỏ được chế tạo tốt cũng cho phép cung cấp một sự trừu tượng thực sự hữu ích và có thể giúp giảm kích thước mã rất nhiều. Nhưng bạn biết đấy, việc tạo khung công tác và API công khai không phải là điều tương tự chút nào khi chỉ viết mã một lớp tiện ích trong 2 giờ. Nó có chi phí thực sự cao. Một lớp tiện ích mất 2 giờ để mã hóa ban đầu, có thể là 2 ngày với việc gỡ lỗi và kiểm thử đơn vị. Khi bạn bắt đầu chia sẻ mã chung trên các dự án/nhóm lớn, bạn thực sự tạo một API. Bạn phải đảm bảo tài liệu hoàn hảo sau đó, mã thực sự dễ đọc và có thể bảo trì. Khi bạn phát hành phiên bản mới của mã này, bạn phải tương thích ngược. Bạn phải quảng cáo cho công ty rộng (hoặc ít nhất là đội ngũ rộng). Từ 2 ngày đối với lớp tiện ích nhỏ của bạn, bạn phát triển đến 10 ngày, 20 ngày hoặc thậm chí 50 ngày đối với API chính thức.
Và thiết kế API của bạn có thể không tuyệt vời như vậy. Vâng, nó không phải là kỹ sư của bạn không sáng - thực sự họ đang có. Nhưng bạn có sẵn sàng để họ làm việc 50 ngày trên một lớp tiện ích nhỏ chỉ giúp phân tích cú pháp số theo cách nhất quán cho giao diện người dùng không? Bạn có sẵn sàng để họ thiết kế lại toàn bộ điều khi bạn bắt đầu sử dụng giao diện người dùng trên thiết bị di động với các nhu cầu hoàn toàn khác nhau không? Ngoài ra, bạn có nhận thấy cách các kỹ sư sáng nhất trong từ tạo API sẽ không bao giờ phổ biến hoặc sẽ mờ dần không? Bạn thấy đấy, dự án web đầu tiên chúng tôi thực hiện chỉ sử dụng khung nội bộ hoặc không có khung công tác nào cả. Sau đó chúng tôi đã thêm PHP/JSP/ASP. Sau đó, trong Java, chúng tôi đã thêm Struts. Bây giờ JSF là tiêu chuẩn. Và chúng tôi đang nghĩ đến việc sử dụng Spring Web Flow, Vaadin hoặc Lift ...
Tất cả những gì tôi muốn nói là không có giải pháp tốt, chi phí phát triển theo cấp số nhân với kích thước mã và kích thước nhóm. Chia sẻ một codebase lớn hạn chế sự nhanh nhẹn và sự đáp ứng của bạn.Bất kỳ thay đổi nào cũng phải được thực hiện cẩn thận, bạn phải nghĩ đến tất cả các vấn đề hội nhập tiềm năng và mọi người phải được đào tạo về các tính năng và đặc điểm mới.
Nhưng điểm năng suất chính trong công ty phần mềm không phải là để đạt được 10 hoặc thậm chí 50 dòng mã khi phân tích cú pháp XML. Một mã chung để thực hiện điều này sẽ phát triển tới hàng nghìn dòng mã và tái tạo một API phức tạp sẽ được phân lớp theo các lớp tiện ích. Khi anh ta tạo một lớp tiện ích để phân tích cú pháp XML, nó là một sự trừu tượng tốt. Anh ta đặt tên cho một tá hoặc thậm chí một trăm dòng mã chuyên biệt. Mã này rất hữu ích vì nó là chuyên ngành. API phổ biến cho phép hoạt động trên luồng, URL, chuỗi, bất kỳ thứ gì. Nó có một nhà máy để bạn có thể chọn bạn thực hiện phân tích cú pháp. Lớp tiện ích rất tốt vì nó chỉ làm việc với trình phân tích cú pháp này và với các chuỗi. Và bởi vì bạn cần một dòng mã để gọi nó. Nhưng tất nhiên, mã tiện ích này bị hạn chế sử dụng. Nó hoạt động tốt cho ứng dụng di động này hoặc để tải cấu hình XML. Và đó là lý do tại sao nhà phát triển đã thêm lớp tiện ích cho nó ngay từ đầu.
Tóm lại, những gì tôi sẽ xem xét thay vì cố gắng để củng cố các mã cho toàn bộ codebase là để chia trách nhiệm mã như các đội bóng lớn:
- chuyển đội bóng lớn của bạn mà làm việc trên một dự án lớn thành nhỏ các nhóm hoạt động trên một số tiểu dự án;
- đảm bảo rằng giao tiếp là tốt để giảm thiểu các vấn đề tích hợp, nhưng hãy để nhóm có mã riêng của họ;
- nhóm bên trong đề tài và các mã tương ứng, đảm bảo bạn có các phương pháp hay nhất. Không có mã trùng lặp, trừu tượng tốt. Sử dụng các API đã được chứng minh từ cộng đồng. Sử dụng lập trình ghép đôi, tài liệu API mạnh mẽ, wiki ... Nhưng bạn nên thực sự cho phép các nhóm khác nhau lựa chọn, xây dựng mã riêng của họ, ngay cả khi điều này có nghĩa là mã trùng lặp giữa các nhóm hoặc các quyết định thiết kế khác nhau. Bạn biết đấy, nếu các quyết định thiết kế khác nhau, điều này có thể là do nhu cầu khác nhau.
Điều bạn đang thực sự quản lý là phức tạp. Cuối cùng, nếu bạn tạo một codebase nguyên khối, bạn có thể tăng thời gian cho những người mới đến tăng lên, bạn tăng nguy cơ các nhà phát triển sẽ không sử dụng mã chung của bạn, và bạn làm chậm mọi người vì bất kỳ thay đổi nào có cơ hội lớn hơn để phá vỡ chức năng hiện có.
Xem http://stackoverflow.com/questions/4188919/how-to-search-for-java-api-methods-by-type-signature – meriton
Tôi tưởng tượng bạn cũng có thể điều chỉnh giải pháp đó để liệt kê tất cả các phương pháp có trùng lặp loại chữ ký. – meriton