Thực tiễn tốt nhất để chia sẻ các đoạn mã nhỏ trong các dự án

Tôi luôn cố gắng tuân thủ nghiêm ngặt nguyên tắc DRY trong công việc; mỗi lần tôi lặp lại mã vì sự lười biếng, nó sẽ cắn lại sau khi tôi cần duy trì mã đó ở hai nơi.

Nhưng tôi thường viết các phương thức nhỏ (có thể 10 - 15 dòng mã) cần được sử dụng lại trên hai dự án không thể tham chiếu lẫn nhau. Phương thức này có thể là một cái gì đó để làm với mạng / chuỗi / MVVM, v.v. và là một phương thức thường hữu ích không dành riêng cho dự án mà nó ban đầu nằm trong đó.

Cách tiêu chuẩn để sử dụng lại mã này là tạo một dự án độc lập cho mã có thể sử dụng lại và tham chiếu dự án đó khi bạn cần. Vấn đề với điều này là chúng ta kết thúc ở một trong hai tình huống không lý tưởng:

1. Chúng tôi kết thúc với hàng chục / hàng trăm dự án nhỏ - mỗi dự án sẽ chứa các lớp / phương thức nhỏ mà chúng tôi cần sử dụng lại. Có đáng để tạo một cái hoàn toàn mới .DLLchỉ cho một chút mã không?
2. Chúng tôi kết thúc với một dự án duy nhất nắm giữ một bộ sưu tập các phương thức và các lớp không liên quan. Cách tiếp cận này là những gì một công ty tôi từng làm việc đã làm; họ đã có một dự án có tên base.commoncác thư mục cho những thứ như tôi đã đề cập ở trên: mạng, thao tác chuỗi, MVVM, v.v ... Nó rất tiện dụng, nhưng tham chiếu nó không cần phải kéo theo tất cả các mã không liên quan mà bạn không cần.

Vì vậy, câu hỏi của tôi là:

Làm thế nào để một nhóm phần mềm tốt nhất về việc tái sử dụng các đoạn mã nhỏ giữa các dự án?

Tôi đặc biệt quan tâm nếu có ai từng làm việc tại một công ty có chính sách trong lĩnh vực này, hoặc điều đó đã gặp phải vấn đề nan giải như cá nhân tôi.

lưu ý: Việc tôi sử dụng các từ "Dự án", "Giải pháp" và "Tham khảo" đến từ một nền tảng trong phát triển .NET trong Visual Studio. Nhưng tôi chắc chắn vấn đề này là ngôn ngữ và nền tảng độc lập.

Nếu chúng thực sự là các phương thức / lớp có thể tái sử dụng, bạn có thể viết chúng vào một số ít thư viện 'Swiss Army Knife'. Chúng tôi làm điều này khá thường xuyên tại công ty của tôi; chúng tôi gọi chúng là thư viện khung:

• Framework.Data - Tiện ích để làm việc với các truy vấn cơ sở dữ liệu.
• Framework.ESB - Phương pháp tiêu chuẩn để tương tác với xe buýt dịch vụ doanh nghiệp của chúng tôi
• Framework.Logging - Hệ thống đăng nhập thống nhất
• Framework.Services - Tiện ích để tương tác với các dịch vụ web
• Framework.Strings - Tiện ích cho thao tác chuỗi nâng cao / tìm kiếm chuỗi mờ, v.v.
• ...

Trong tất cả, có khoảng một tá thư viện. Bạn thực sự có thể phân phối mã theo cách bạn thấy phù hợp, vì vậy bạn không phải kết thúc với hàng trăm hoặc đổ mọi thứ vào một cụm khổng lồ. Tôi thấy cách tiếp cận này phù hợp bởi vì chỉ một số dự án của chúng tôi sẽ cần Framework.Datavà chỉ một số ít sẽ cần Framework.Strings, vì vậy người tiêu dùng chỉ có thể chọn những phần của khung có liên quan đến dự án cụ thể của họ.

Nếu chúng thực sự chỉ là đoạn trích và không phải là phương thức / lớp thực tế có thể dễ dàng sử dụng lại, bạn có thể thử phân phối chúng dưới dạng đoạn mã vào IDE (ví dụ: Đoạn mã Visual Studio ). Các nhóm tôi đã làm việc trong quá khứ có một thư viện đoạn trích chung giúp mọi người dễ dàng theo dõi các thực hành mã hóa tiêu chuẩn của chúng tôi bằng mã nội bộ.

Tôi không đồng ý với câu trả lời được chấp nhận vì nhiều lý do.

Theo kinh nghiệm của tôi, khi tôi thấy các thư viện "linh tinh" như câu trả lời được chấp nhận, chúng là một cái cớ để phát minh lại bánh xe (hoặc không được phát minh ở đây (NIH) ) - một tội lỗi lớn hơn nhiều so với việc vi phạm Dont Lặp lại chính mình (DRY) .

Đôi khi vi phạm DRY có thể là một sự thỏa hiệp hợp lý, tốt hơn là giới thiệu khớp nối chặt chẽ. Tái sử dụng là một mối quan tâm thứ cấp so với thiết kế hướng đối tượng tốt. Một chút (ý tôi là số lượng nhỏ, áp dụng Quy tắc ba ) sao chép dễ hiểu hơn so với cơ sở mã spaghetti.

Cách tiếp cận của nhiều thư viện mục đích chung đặt một ví dụ xấu. Nó dẫn đến một độ chi tiết tốt của lắp ráp và quá nhiều lắp ráp là xấu. Gần đây tôi đã giảm một thư viện nội bộ từ 24 thư viện xuống còn 6 thư viện. Nó cải thiện thời gian biên dịch từ vài phút đến ~ 20 giây. Visual studio cũng tải chậm hơn và ít phản hồi hơn với nhiều cụm. Có quá nhiều thư viện cũng dẫn đến sự nhầm lẫn về nơi mã nên sống; thích ít hơn, quy tắc đơn giản hơn.

Tại sao các công cụ trong .Net Framework không đủ tốt? Khung này khá lớn; nhiều lần tôi đã thấy mã thực hiện lại những thứ đã tồn tại ở đó. Thực sự đảm bảo rằng các khung của bạn đang lấp đầy các khoảng trống trong khung .Net và không chỉ tồn tại vì lý do thẩm mỹ (ví dụ: "Tôi không thích khung .Net ở đây" hoặc có lẽ là một số tối ưu hóa sớm )

Giới thiệu một lớp khác vào kiến ​​trúc của bạn có chi phí phức tạp đáng kể. Tại sao lớp tồn tại? Tôi đã thấy việc tái sử dụng sai, ý tôi là, mã được xây dựng dựa trên khung công tác nội bộ. Nó sẽ có hiệu quả hơn nhiều để thực hiện nó trực tiếp trên đầu các thư viện tiêu chuẩn.

Sử dụng các công nghệ được tiêu chuẩn hóa (như khung .Net và các thư viện nguồn mở / bên thứ 3 phổ biến) có những lợi ích thường vượt xa lợi ích công nghệ so sánh của việc tự xây dựng nó. Tìm kiếm tài năng biết các công nghệ này sẽ dễ dàng hơn và các nhà phát triển hiện tại của bạn sẽ đầu tư nhiều hơn vào việc học nó.

Khuyến nghị của tôi:

• Đừng chia sẻ mã này.
• Tạo một thư viện mới nếu nó có mục đích gắn kết, không sử dụng mẫu thiết kế bóng của bùn .
• Sử dụng lại các thư viện bên thứ 3 hiện có nếu có thể.
• Thích ít tập hợp hơn, với các quy tắc đơn giản hơn là nơi mã sẽ sống.

Đối với các bit mã nhỏ - giả sử một lớp duy nhất không có phụ thuộc - chúng ta có xu hướng chỉ sao chép và dán mã vào các dự án. Điều này nghe có vẻ như vi phạm DRY và đôi khi tôi sẽ thừa nhận nó có thể xảy ra. Nhưng về lâu dài, nó tốt hơn nhiều so với việc có một số loại dự án chung lớn, nhiều đầu vì một vài lý do.

Đầu tiên, nó chỉ đơn giản hơn để có mã tiện dụng, đặc biệt là khi xây dựng và gỡ lỗi công cụ.

Thứ hai, bạn sẽ luôn muốn thực hiện một số điều chỉnh nhỏ cho mã chung cho dự án đó. Nếu bạn đã có một bản sao nguồn cục bộ hơn bạn chỉ có thể thực hiện chỉnh sửa và gọi nó là một ngày. Nếu có một thư viện dùng chung thì bạn có thể điều chỉnh thư viện đó và sau đó đảm bảo rằng bạn không phá vỡ tất cả các ứng dụng khác hoặc tạo ra một cơn ác mộng phiên bản.

Vì vậy, nếu nó không đủ mạnh cho không gian tên của chính nó, chúng ta có xu hướng chỉ đẩy nó vào các bit thích hợp trong dự án và gọi nó là một ngày.

Giải pháp thứ hai bạn mô tả không phải là xấu. Trong .NET, bạn cũng tham chiếu một hội đồng từ GAC ngay cả khi bạn chỉ sử dụng một lớp duy nhất của nó. 'Kéo mã không liên quan' không phải là vấn đề như bạn nghĩ. Trong trường hợp này, điều tối quan trọng là giữ cho các phương thức và các lớp liên quan được tổ chức sạch sẽ trong các không gian tên khác nhau. Ngoài ra, nên áp dụng các thực tiễn tốt cho thiết kế API để ngăn giải pháp này trở thành một mớ hỗn độn.

Nếu nói đến các đoạn mã rất nhỏ, tôi nghĩ cách tiếp cận sau đây là một bổ sung tốt cho một dự án chung: Cho phép chúng được sao chép trong các giải pháp khác nhau. Đối phó với họ như các thực tiễn tốt nhất: tài liệu và truyền đạt cho nhóm.

Tôi chỉ từng làm việc trong môi trường "doanh nghiệp", nơi điều này là một vấn đề và mỗi lần nó là lựa chọn thứ hai được áp dụng. Đối với hầu hết các phần, nó hoạt động ổn vì không có bất kỳ ràng buộc nào đối với dấu chân ứng dụng.

Tuy nhiên, đã dành tuần trước với một người khởi nghiệp đang chạy máy chủ Nuget của riêng họ, tôi có xu hướng đề xuất đây là một giải pháp thay thế khả thi. Tất nhiên, những vấn đề tôi mong đợi sẽ xuất hiện sẽ xoay quanh khả năng khám phá.

Nếu các dự án có dạng hạt phù hợp và không gian tên hợp lý thì tôi có thể thấy điều này trở thành một cách tiếp cận phổ biến ở những nơi.

Gần đây tôi đã nghĩ về điều này và những gì xảy ra với tôi là một thư viện lớn các phương pháp phổ biến như đã được đề cập cho đến nay, nhưng với một sự thay đổi. Dự án thư viện sẽ cho phép bạn định cấu hình tại thời điểm biên dịch các phần được bao gồm giống như dự án BusyBox . Với cách tiếp cận đó, bạn có thể có một repo thư viện kiểu bồn rửa nhà bếp, nhưng chỉ lấy các công cụ bạn cần khi biên dịch.

GitHub có một công cụ khá hữu ích để lưu đoạn mã https://gist.github.com/

Nó lưu trữ đoạn trích của bạn dưới dạng kho git mà bạn có thể giữ riêng tư hoặc sử dụng để chia sẻ đoạn mã với người khác.

Tùy thuộc vào quy mô của nhóm / dự án / công ty, điều này sẽ khá khó để thực hiện một cách hiệu quả, trừ khi nó đã được xây dựng trong môi trường của bạn bằng cách nào đó, và mọi giải pháp bạn sẽ tìm thấy (nếu bạn thực hiện nó) sẽ tốn một số tiền. (Nó có thể an toàn cho bạn hơn, nhưng bạn sẽ không thể đo lường dễ dàng). Bạn sẽ phải kiểm tra xem nó có đáng giá không. Cũng nên nhớ rằng các giải pháp tái sử dụng có xu hướng trở nên trừu tượng và thường sẽ phù hợp với nhiều tình huống nhưng không tối ưu.

Trong mọi trường hợp, nếu bạn muốn làm điều này cho mã do nhiều người tạo ra, đầu tiên bạn sẽ cần nhận thức về mọi người và sự hợp tác. Điều này bao gồm các nhà phát triển và quản lý.

Sau đó, bạn sẽ cần đảm bảo rằng bạn biết phạm vi mà bạn muốn làm điều này. Đội? Dự án? Phòng ban? Công ty? Tùy thuộc vào câu trả lời, loại mã bạn sẽ đưa vào các giải pháp như vậy sẽ khác nhau, cũng như mức độ chi tiết mà bạn điều chỉnh các dlls. Một khi bạn quyết định về điều này, một người nào đó (tốt nhất là với sự nhiệt tình với ý tưởng - bạn?) Nên ngồi xuống và bắt đầu đưa một số cấu trúc vào đây.

Tuy nhiên, chỉ cần tạo ra các dll như vậy sẽ không đủ để thực hiện thủ thuật. Để làm cho chúng hữu ích, bạn sẽ cần quảng cáo chúng (tới người dùng và cộng tác viên) và duy trì chúng như bất kỳ phần mềm nào khác, điều này thường có nghĩa là bạn cần phải chịu trách nhiệm cho họ trong một thời gian dài. Bạn cũng sẽ cần tài liệu đáng tin cậy, sau đó cũng sẽ cần bảo trì. Với một chút may mắn và hợp tác, bạn có thể kết thúc bằng một số thực tiễn tốt nhất, nhưng nó cũng có thể dễ dàng phát triển thành một dự án của riêng nó, tùy thuộc vào quy mô và số lượng đội tham gia. Và vì thế bạn vẫn sẽ cần hỗ trợ quản lý.

Tôi đã gặp vấn đề rất nhiều, và giải pháp ưa thích của tôi là đăng mã trong kho lưu trữ hỗ trợ web github / pubic. nó giải quyết được rất nhiều vấn đề -

1. dễ dàng truy cập và dễ dàng để chia sẻ. cvs / svn / doanh nghiệp-repos có nghĩa là kiểm tra dự án thành nhiều không gian làm việc IDE và đôi khi phải chuyển đổi không gian làm việc hoặc máy tính chỉ để tham khảo một đoạn mã nhỏ.
2. giả sử các đoạn mã này không phải là các đoạn mã độc quyền / được phân loại và là các biến thể của kiến ​​thức có sẵn công khai, đăng chúng lên một repo công khai như github có nghĩa là những người khác sẽ xem xét nó, và thậm chí có thể đóng góp.
3. đăng một cái gì đó trong phạm vi công cộng dưới tên của bạn có thêm áp lực danh tiếng. bạn sẽ kiểm tra và cập nhật mọi thứ, vì nó phản ánh khả năng của bạn với tư cách là một lập trình viên.
4. cập nhật. Vấn đề của việc duy trì các đoạn mã trong một repo là, nếu một đoạn mã đã không được sử dụng trong một thời gian dài, nó có thể bị cũ (chứa apis / libs lỗi thời). ví dụ - đoạn mã java để đọc tệp. bạn có thể đã tìm ra cách tốt nhất để làm điều này trong năm 2009, nhưng vào năm 2014, một tập tin api mới xuất hiện đã thay đổi mọi thứ. đoạn trích của bạn? vẫn bị kẹt vào năm 2009. trong một repo công khai, mọi thứ sẽ được cập nhật, bởi bạn (vì đạn 3), đồng đội của bạn hoặc một số thành viên của cộng đồng lập trình viên nói chung, và trong quá trình đó, bạn thậm chí có thể nhận được đề xuất để khắc phục điều gì đó bạn có thể đã làm sai trong một thời gian dài.

Một điều tôi muốn giới thiệu - bất kể bạn giữ đoạn trích của mình ở đâu, hãy luôn cập nhật google trước khi sử dụng. mọi thứ thay đổi tất cả các thời gian. tiết kiệm tiết kiệm thời gian, nhưng cũng tự mãn giống .

Chúng tôi có một "tiện ích" dự án riêng biệt, nơi chúng tôi lưu trữ tất cả các phương pháp nhỏ này cùng với các thử nghiệm.

Khi một dự án cần một số tiện ích, nó chỉ cần thêm tệp nguồn với phương thức cần thiết với "add as link".

Điều này có nghĩa là không có phụ thuộc thời gian chạy được thêm vào (trừ khi tệp được bao gồm cần một).

Hệ thống đã hoạt động tốt nhưng giống như tất cả các hệ thống khác, nó cần diciplin về tiện ích là gì. Yêu cầu bảo hiểm thử nghiệm cao đã làm việc tốt cho chúng tôi và các thử nghiệm cũng là tài liệu sử dụng tốt. Khám phá vẫn là một vấn đề chưa được giải quyết đối với chúng tôi.

Một điều phức tạp với dự án tiện ích là quyết định mức độ hiển thị trên các mặt hàng. Một nguyên tắc nhỏ là các phương thức nên được cấu trúc nội bộ và dữ liệu công khai.

Công ty của tôi sử dụng các dịch vụ web mạng nội bộ. Chúng tôi có một vài dịch vụ web được thiết lập là dịch vụ web nội bộ phổ biến và khi dự án khác cần truy cập vào một trong các dịch vụ, nó sẽ gửi yêu cầu http với giao diện được xác định. Vì nó nằm trong mạng nội bộ, được đặt trong cùng một cụm máy chủ, nên các yêu cầu này rất nhanh.

Rõ ràng điều này chỉ hoạt động với các ứng dụng internet (và chỉ hoạt động trong một phần nghìn giây khi trên cùng một mạng cục bộ), nhưng nó có một số lợi thế thực sự tốt đẹp.

Gần đây tôi đã đưa ra dịch vụ này: Snip2Code ( http://www.snip2code.com ).

Đó là một cách thú vị để chỉ chia sẻ đoạn trích của bạn (không hoàn toàn là thư viện) với nhóm của bạn. Nó phá vỡ điểm thông thường để tạo các thư viện chung nên được tham chiếu trong các dự án khác, và theo tôi đây là một tầm nhìn có giá trị.

Hơn nữa, có rất nhiều tình huống là việc sử dụng một thư viện chung đơn giản là không áp dụng: hãy xem xét ví dụ như một số Mẫu thiết kế như Singleton, Chiến lược hoặc Người quan sát. Bạn có thể tạo các thư viện để hỗ trợ các mẫu như vậy nhưng vẫn không có phạm vi bảo hiểm 100%.

Nhu cầu thực sự là có một công cụ để chia sẻ các thông lệ chung trong nhóm. Tôi đã cố gắng sử dụng ý chính của Github nhưng tôi bị mắc kẹt với việc tìm kiếm chúng (thực sự nghèo) và với thực tế là tôi không thể chia sẻ chúng chỉ trong nhóm của mình chứ không phải với ...

(Tuyên bố miễn trừ trách nhiệm: Tôi là một trong những người sáng lập Snip2Code và tôi - cùng với những người đồng sáng lập - trong suy nghĩ rất giống bạn trước đây: đây là lý do tại sao chúng tôi quyết định bắt đầu dự án này !!)