Cách duy trì các đoạn mã giống nhau trên nhiều dự án [đã đóng]

Tôi là một nhà phát triển độc lập làm việc trên nhiều dự án Android. Tôi gặp vấn đề với việc duy trì cùng chức năng trên các dự án khác nhau. Ví dụ: ba ứng dụng của tôi sử dụng cùng 2 lớp; vì chúng là các dự án khác nhau, khi tôi cần thay đổi các lớp đó, tôi cần thực hiện ba lần. Có một giải pháp đơn giản cho loại vấn đề phổ biến này?

Tách mã được chia sẻ thành một thư viện và bao gồm thư viện trong các dự án.

Là một nhà phát triển Android, có lẽ bạn đang sử dụng Java. Cân nhắc sử dụng một công cụ quản lý phụ thuộc như Maven hoặc Ivy .

Một tác dụng phụ là điều này sẽ giúp duy trì sự tách biệt các mối quan tâm bằng cách thực thi mô đun. Chi phí là nó có thể mất một số công việc để tách; lợi ích là khả năng duy trì trong tương lai tốt hơn. Ngoài ra, nếu bạn từng quyết định, bạn có thể phát hành thư viện riêng (dưới dạng thương mại hoặc dưới dạng nguồn mở) khỏi các ứng dụng của mình.

Kiểm soát phiên bản. Git. Submodules Git.

Đặt các dự án của bạn dưới sự kiểm soát phiên bản, sử dụng một dvcs như git hoặc mercurial, v.v. Đặt mã được chia sẻ trong một mô hình con trong git. Sử dụng mô hình con trong các dự án cần nó. Khi bạn cập nhật mô hình con, có thể kéo các thay đổi sang các dự án khác bằng một lệnh duy nhất.

Không ai khác đề cập đến con dao hai lưỡi, vì vậy tôi sẽ thêm 2 xu của mình. Nếu bạn có nhiều dự án và tất cả chúng đều chia sẻ một số mã có thể tái sử dụng, theo các nguyên tắc / nguyên tắc lập trình tốt (ví dụ DRY), bạn nên đặt mã ở một nơi toàn cầu và cấu trúc nó theo cách sao cho có thể chia sẻ được tất cả dự án của bạn mà không có bất kỳ sửa đổi. Nói cách khác, xác định các giao diện là chung chung và đủ phổ biến để phù hợp với tất cả mọi người.

Có một vài lựa chọn để làm điều này: 1) Tạo một dự án cơ sở mà những người khác phụ thuộc vào. Dự án này có thể tạo ra một phân phối nhị phân mà các dự án khác tiêu thụ. 2) Kéo một mô hình nguồn mở trong tổ chức của bạn. Có mã chung là nhánh mã riêng của nó và có các dự án khác lấy mã giống như cách bạn lấy mã nguồn từ bất kỳ OSS trực tuyến nào.

Bây giờ đây là nơi thanh kiếm xuất hiện ...

Đặt mã vào một nơi chung mà các dự án / người khác phụ thuộc vào có thể trở nên khá tốn kém. Giả sử bạn có một đoạn mã và 4 dự án khác phụ thuộc vào nó. Một trong những khách hàng của bạn sử dụng dự án A tìm thấy một lỗi và bạn phải sửa. Bạn vội vàng sửa chữa và khách hàng hài lòng. Nhưng bạn chỉ sửa đổi một số mã mà 3 dự án khác phụ thuộc vào. Bạn đã kiểm tra lại tất cả những điều đó để đảm bảo không có điều kiện cạnh nào được đưa ra?

Mã chung cũng phải được chế tạo cẩn thận hơn nhiều và giao diện mô-đun phải được thiết kế tốt hơn nhiều vì mã đó phải chứa không chỉ một mà là 4 máy khách và mỗi máy khách chỉ có thể sử dụng mã này với một chút khác biệt.

Nếu các dự án của bạn đang ở các chu kỳ phát hành khác nhau, bạn cần cẩn thận hơn nữa trong việc quản lý mã chung. Bạn không thể đơn giản thực hiện các thay đổi trong mã chung vì dự án B cần chức năng mới, nếu bạn còn 3 ngày nữa để cắt hình ảnh cuối cùng cho dự án C.

Tôi không nói rằng thư viện chung không phải là giải pháp đúng. Tôi là một người ủng hộ mạnh mẽ cho DRY và tôi đã tạo và hỗ trợ mã chung trước đó và tiếp tục làm như vậy. Chỉ muốn đưa nó ra khỏi đó rằng chỉ cần làm cho mã phổ biến sẽ có chi phí riêng của nó.

Nếu bạn là người duy nhất sử dụng lại mã này, thì điều này không tệ. Nếu bạn có một nhóm các kỹ sư và họ bắt đầu sử dụng mã chung, chi phí sẽ tăng lên nhiều hơn. Nếu những người khác có liên quan, mong đợi việc đặt mã vào một thư viện chung sẽ mất gấp 3 lần thời gian cần thiết để đưa nó đến một điểm mà bạn nghĩ rằng nó "hoàn tất". Bạn sẽ cần phải làm cho thư viện mạnh mẽ hơn để bảo vệ chống lại tất cả các điều kiện cạnh và sử dụng không hợp lệ, b) cung cấp tài liệu để người khác có thể sử dụng thư viện và c) giúp người khác gỡ lỗi khi họ sử dụng thư viện theo cách mà bạn sử dụng không lường trước được và tài liệu của bạn không bao gồm trường hợp sử dụng cụ thể của họ.

Một số gợi ý tôi có thể cung cấp:

1. Có mã chung được bao phủ bởi các bài kiểm tra đơn vị tự động có thể đi một chặng đường dài và mang đến cho bạn một chút suy nghĩ rằng khi bạn thực hiện thay đổi, bạn đã không phá vỡ một số dự án khác.
2. Tôi sẽ chỉ đặt chức năng rất ổn định vào mã phổ biến. Nếu bạn đã viết một lớp vào năm ngoái để thực hiện quản lý hẹn giờ và bạn đã không thay đổi nó trong 9 tháng và bây giờ bạn có 3 dự án khác cần bộ tính giờ, thì chắc chắn đó là một ứng cử viên tốt. Nhưng nếu bạn vừa mới viết một cái gì đó vào tuần trước, thì ... bạn không có nhiều lựa chọn đó (và tôi ghét mã sao chép / dán có lẽ nhiều hơn người tiếp theo) nhưng tôi nghĩ hai lần về việc làm cho nó trở nên phổ biến.
3. Nếu đoạn mã là tầm thường nhưng bạn đã sử dụng nó ở một số nơi, có lẽ tốt hơn là cắn viên đạn, hãy để DRY một mình và để nhiều bản sao sống.
4. Đôi khi, nó trả tiền để không chỉ đơn giản là đặt mã chung vào một vị trí chung và để mọi người tham khảo nó. Nhưng thay vì coi mã phổ biến là có thể tin cậy được với các phiên bản, ngày phát hành và mọi thứ. Theo cách này, dự án C có thể nói: "Tôi sử dụng thư viện chung v1.3" và nếu dự án D cần chức năng mới, bạn để lại v1.3, phát hành v1.4 và dự án C không bị ảnh hưởng. Hãy nhớ rằng, RẤT NHIỀU, RẤT NHIỀU khi coi mã phổ biến là sản phẩm của chính nó thay vì chỉ đơn giản là kiểm tra nó vào một vị trí chung.

Đây là một giải pháp lý tưởng hóa, và có thể mất một số nỗ lực để làm việc.

Nguyên tắc DRY nói rằng cần phải có một nguồn sự thật có thẩm quyền duy nhất. Điều này chỉ ra việc sử dụng một kho lưu trữ nguồn duy nhất cho tất cả logic chương trình, không có sự trùng lặp; các tập tin được tổ chức để thúc đẩy chia sẻ và tái sử dụng các tài liệu.

Các yêu cầu thực tế của giao tiếp trong môi trường nhiều nhóm phân tán cho thấy rằng cần có nhiều kho lưu trữ độc lập, mỗi kho cho mỗi dự án hoặc cộng tác.

Tôi sẽ tiếp cận vấn đề này bằng cách gửi đến điều không thể tránh khỏi: bạn sẽ cần phải thực hiện đồng thời cả hai cách tiếp cận và chúng tôi sẽ sử dụng kịch bản & tự động hóa để giải quyết vấn đề là các phương pháp này trái ngược nhau.

:-)

Kho lưu trữ hợp nhất sẽ là nguồn có thẩm quyền duy nhất của bạn. Quá trình xây dựng cho mỗi dự án sẽ sao chép tất cả các tệp được sử dụng bởi dự án đó (và chỉ các tệp đó) vào một vị trí trung gian, sau đó xây dựng từ vị trí trung gian đó. (Unison hoặc một số công cụ tương tự có thể được sử dụng để di chuyển deltas thay vì toàn bộ tệp).

Các vị trí trung gian này có thể được sử dụng làm bản sao làm việc cục bộ cho tập hợp các kho lưu trữ thứ cấp, dẫn xuất hoặc hạ nguồn. Các tập lệnh hook sau cam kết trên kho lưu trữ có thẩm quyền sẽ cập nhật tất cả các vị trí trung gian và lần lượt kiểm tra xem nó có thay đổi hay không và thực hiện cùng một cam kết với kho lưu trữ thứ cấp tương ứng nếu phát hiện thay đổi.

Bằng cách này, nhiều kho lưu trữ thứ cấp được giữ đồng bộ với kho lưu trữ nguồn có thẩm quyền duy nhất và quy trình xây dựng đảm bảo rằng kho lưu trữ thứ cấp chứa tất cả các tài liệu (có thể được chia sẻ) và các tệp khác cần thiết để quá trình xây dựng thành công. Cuối cùng, và quan trọng nhất, quá trình phát triển và xây dựng đảm bảo rằng các tệp được chỉnh sửa ở một nơi và một nơi duy nhất và tất cả các bản sao được giữ nhất quán và cập nhật.