Làm cách nào để đảm bảo mã được sử dụng lại chính xác?

Question

Thường khi chúng tôi giới thiệu một tính năng mới vào một ứng dụng, chúng tôi có thể tạo ra các hiện vật, chẳng hạn như các phương pháp hoặc lớp hữu ích có thể được sử dụng lại trong các lĩnh vực khác của ứng dụng của chúng tôi. Các tạo tác này không nhất thiết được ghi nhận là các yêu cầu chức năng vì chúng thường là một tác dụng phụ của các lựa chọn thực hiện của chúng ta. Vì chúng ta thường phát triển theo nhóm, điều quan trọng là chia sẻ các đoạn mã này để ngăn chặn việc làm lại và sao chép.

Ví dụ:

• phương pháp Utility và các lớp
• Một lớp cơ sở
• Một Interface
• Một giao diện điều khiển

gì có bạn tìm thấy là cách hiệu quả nhất của chia sẻ những hiện vật này?

Làm cách nào để truyền tải các giả định bạn đã tạo khi tạo chúng?

Làm cách nào để đảm bảo chúng được tiêu thụ chính xác?

Tôi quan tâm đến các phương pháp hay nhất và các kỹ thuật đã được chứng minh xung quanh tài liệu, sơ đồ mã, cuộc họp (?) Để đảm bảo mã được sử dụng lại chính xác.

Câu hỏi này rất giống với: Finding Reusable code nhưng tôi quan tâm đến một cách chủ động hơn so với cách tiếp cận phản ứng.

Answer 1

Nhóm của chúng tôi có một số thư viện hữu ích mà chúng tôi sử dụng trong suốt quá trình phát triển của mình. Các thư viện này được lưu giữ trong một kho lưu trữ chung trong một loại phương pháp "nguồn mở". Có một người giám sát mỗi thư viện (hoặc nhiều thư viện) và các nhà phát triển có thể gửi các bản vá lỗi.

Thư viện sau đó được phát hành/xây dựng đến một vị trí chung (chúng tôi triển khai tới máy chủ web) nơi mọi người có thể tải xuống và sử dụng chúng trong bất kỳ dự án nào họ muốn. Cho đến nay, nó đã hoạt động khá tốt. Điều duy nhất chúng tôi phải chú ý là, nếu có thay đổi về API, chúng tôi phải đảm bảo rằng chúng tôi đảm bảo mọi người nhận ra điều này. Chúng tôi thực hiện điều này thông qua số phiên bản và thông qua thông tin trên wiki thư viện của chúng tôi.

Chỉnh sửa: Ngoài ra, chúng tôi xuất bản tài liệu được tạo cho thư viện của chúng tôi (Javadoc, Crystal Report, bất kỳ điều gì) để nhà phát triển có thể sử dụng chúng.

Answer 2

Kiểm tra điều kiện tiên quyết của bạn với các xác nhận.

Bên cạnh đó, hãy nghĩ đến một số kiểm tra đơn vị để kiểm tra xem mã của bạn có đủ mạnh để xử lý các tình huống không phổ biến hoặc không mong muốn.

Đối với phần còn lại, hãy đảm bảo rằng mọi người thực sự hiểu mã nào, ít nhất là ở cấp độ hộp đen. Có một cuộc họp ngắn với một tấm bảng và làm một chương trình đôi chút khi mọi người phải bắt đầu bằng cách sử dụng mã mới cho họ.

Answer 3

Chúng tôi là một đội Net, vì vậy đây làm việc cho chúng tôi ...

Chúng tôi tạo ra thư viện lớp của chúng ta cho các chức năng mà chúng tôi nghĩ sẽ được sử dụng phổ biến. Những thứ như tính toán số kiểm tra Luhn Mod 3, tạo một regex để xác nhận địa chỉ phù hợp với trường cơ sở dữ liệu là n ký tự, v.v. nó trong đó. Và giữ cho nó được tổ chức.

Answer 4

Chúng tôi là một nhóm phát triển Java và cũng áp dụng cho chúng tôi. Chúng tôi đã tạo các dự án tiện ích trong SVN của chúng tôi theo các tiêu đề khác nhau, ví dụ: Phân tích cú pháp XML, xử lý Vector và mã có thể tái sử dụng được kiểm tra trong các thư viện tiện ích này và được tái sử dụng trong các dự án khác.

Answer 5

Xem sách về các phương pháp hay nhất bằng ngôn ngữ lập trình của bạn. Áp dụng chúng và xem những gì hoạt động và thích nghi cho phù hợp. Về cơ bản một giao diện tốt, sạch sẽ và súc tích/api đi một chặng đường dài. Cũng viết rất nhiều bài kiểm tra đơn vị để bao gồm các loại chức năng khác nhau. Ngoài ra hãy xem các thư viện được xây dựng trong ngôn ngữ/nền tảng của bạn hoặc tìm kiếm các ví dụ tốt về thư viện và xem giao diện của chúng.

Answer 6

Nói từ hoàn toàn thiếu kinh nghiệm trong vấn đề này, tình huống lý tưởng có thể là tạo ra một hệ thống kiểm soát phiên bản được chia sẻ giữa các đội.Sau đó, sau một vài cuộc họp tổ chức/nhận thức ban đầu, hãy coi kho lưu trữ được chia sẻ là dự án nguồn mở mà mọi người có thể đóng góp. Vì vậy, nhìn vào một vài trường hợp:

1. Bạn viết một số mã để được chia sẻ: điều này đòi hỏi việc tạo ra một lĩnh vực mới trong kho cho mã, thêm một số tài liệu cơ bản, kiểm tra, mã dọn dẹp, vv ... nhưng có động cơ để làm điều đó ngay nếu nó được coi là "công khai".

2. Bạn muốn sử dụng mã và chất lượng tốt: Âm thanh như một thư viện tốt nhưng có một số hạn chế. Bạn thêm tài liệu, bài kiểm tra và các chức năng bổ sung khác, v.v.

3. Bạn muốn sử dụng mã, nhưng nó là rác: Bạn cần trò chuyện với nhà phát triển ban đầu. Sau đó, làm một việc làm chính của mã, nhưng nó vẫn còn tốt hơn một chút so với việc phát minh lại bánh xe. Cả hai đội đều được hưởng lợi khi bạn hoàn thành.

Bí quyết là làm cho mọi kiến ​​thức công khai. Vì vậy, bạn cần nhà vô địch trên mỗi đội để thúc đẩy mọi người sử dụng lại và đóng góp. Đó là những gì bạn nhận được từ vòng họp ban đầu. Giả sử mô hình mã nguồn mở là một thực tế đã được chứng minh, không có lý do gì nó không thể hoạt động nếu bạn có nhà vô địch.

Answer 7

Sử dụng SOLID và giữ mã của bạn sạch sẽ. Kiểm tra: http://www.lostechies.com/content/pablo_ebook.aspx

Nếu bạn thấy điều gì đó có khả năng được triển khai, hãy hỏi nhóm. Luôn ghi nhớ kiến ​​thức của bạn về các dự án trước đó, nếu bạn biết dự án x có tính năng đó thì bắt đầu từ đó;)

Tái sử dụng là rất quan trọng và tránh trùng lặp, đặc biệt khi bạn ở cùng một sản phẩm/thậm chí là hệ thống phụ. Điều quan trọng là luôn luôn tìm kiếm nó, nhưng đừng để điều đó diễn ra theo cách tiến bộ trong các dự án.