Làm thế nào để thúc đẩy tái sử dụng mã và tài liệu? [đóng cửa]

Là nhóm trưởng của khoảng hơn 10 nhà phát triển, tôi muốn thúc đẩy việc tái sử dụng mã. Chúng tôi đã viết rất nhiều mã-- rất nhiều trong số chúng được lặp đi lặp lại trong vài năm qua. Vấn đề bây giờ là rất nhiều mã này chỉ là bản sao của một số mã khác hoặc một biến thể nhỏ của chúng.

Tôi đã bắt đầu phong trào (thảo luận) về cách tạo mã thành các thành phần để chúng có thể được sử dụng lại cho các dự án trong tương lai, nhưng vấn đề là tôi sợ các nhà phát triển mới hoặc các nhà phát triển khác không biết gì về các thành phần sẽ tiếp tục và viết điều riêng của họ.

Có cách nào để nhắc nhở các nhà phát triển sử dụng lại các thành phần / cải thiện tài liệu / đóng góp cho thành phần cơ bản thay vì sao chép mã hiện có và điều chỉnh trên đó hoặc chỉ viết riêng của họ không?

Làm thế nào để làm cho các thành phần dễ dàng khám phá, có thể dễ dàng sử dụng để mọi người sẽ sử dụng nó?

Tôi nghĩ rằng mọi nhà phát triển đều biết về lợi ích của các thành phần có thể tái sử dụng và muốn sử dụng chúng, chỉ là chúng ta không biết cách làm cho chúng có thể khám phá được. Ngoài ra, các nhà phát triển khi họ đang viết mã, họ biết họ nên viết mã có thể sử dụng lại nhưng thiếu động lực để làm điều đó.

Bạn cần tài liệu, một trong những thích hợp. Nó sẽ dễ dàng để tìm và điều hướng. Bạn cũng cần kỷ luật. Nếu đã có một giải pháp được cung cấp trong các thư viện mã có thể sử dụng lại của bạn nhưng nhà phát triển chọn sử dụng giải pháp của riêng anh ấy (không có lý do chính đáng), bạn nên hoàn nguyên giải pháp của anh ấy và bảo anh ấy sử dụng giải pháp hiện có.

Tôi cũng đồng ý với nhận xét của Euphoric cho câu hỏi. Thường không thể sử dụng lại bất cứ thứ gì giữa các dự án khác nhau (thông thường tất cả các hoạt động CRUD trông giống nhau, nhưng thông thường bạn không thể sử dụng lại chúng).

Bên cạnh các yếu tố đã được đề cập "tài liệu", "dễ tìm và điều hướng", "kỷ luật" và "mã hóa"

mã có thể tái sử dụng phải được

• dễ sử dụng (= cần ví dụ, ví dụ như unittests)
• không có quá nhiều phụ thuộc vào các mô-đun khác và
• nó phải có một api ổn định vì vậy tôi không phải cập nhật ứng dụng của mình để sử dụng thư viện.

không có hai mục cuối, việc sử dụng "sao chép & thừa kế" sẽ dễ dàng hơn nhiều mà chúng tôi không muốn.

Tôi nghĩ rằng cách tốt nhất để thực sự làm cho họ sử dụng lại mã là động lực. Nếu bạn đặt các thành phần có thể tái sử dụng trong các dự án bổ sung, như Euphoric đề xuất, hãy nỗ lực nhiều trong đó. Khi tôi làm việc, chúng tôi đã tạo một dự án, chạy một tập hợp các giao diện được xác định trước trong các chương trình thực thi có thể định cấu hình và cung cấp một vài dịch vụ (ví dụ: các lớp khác nhau cho DB_interaction, FTP-Service, ...). Dự án là một thành công lớn, bởi vì các nhà phát triển của chúng tôi thực sự muốn sử dụng khung vi mô, bởi vì nó tiết kiệm cho họ rất nhiều thời gian để viết mã soạn sẵn cho các dự án tương tự. Điều tương tự là đối với các thư viện tiện ích cho Danh sách, Chuỗi, v.v., nhưng trong trường hợp này, bạn sẽ muốn sử dụng một lần. (tại sao lại phát minh ra con trăn?)

Kết luận: Hãy để các nhà phát triển của bạn trải nghiệm những lợi ích của các thành phần tái sử dụng được thử nghiệm tốt. Nhưng tôi cũng đồng ý với câu trả lời của Andrzej Bobak: Nhiều thứ không thể tái sử dụng, vì chúng giống nhau, nhưng không giống nhau.

Điều này sẽ khó khăn, bởi vì mọi người thích viết mã mới cho các thành phần đơn giản và họ thích làm theo cách của họ . Khó hơn nhiều để tận dụng một giải pháp hiện có và mở rộng nó, hơn là viết một triển khai hoàn toàn mới với các yêu cầu mới. Những gì bạn cần làm, như đã nêu, là bắt đầu một quy trình xem xét mã trong nhóm để giúp xác định các tình huống trong đó một thành phần hiện có nên được sử dụng / mở rộng thay vì một cái mới.

Bạn cũng cần duy trì một tài liệu rất tốt và kỹ lưỡng để mọi người có thể tham khảo và dễ dàng tìm thấy những gì họ cần. Nếu tài liệu không đầy đủ hoặc không đồng bộ với thực tế, mọi người sẽ không có động lực để tìm kiếm thông qua nó hoặc nâng cao nó.

Với tư cách là trưởng nhóm, bạn cũng nên khuyến khích mọi người tự hỏi liệu một thành phần tương tự có tồn tại trước khi tự tạo và hướng họ đến tài liệu để họ có thể tra cứu nó. Chắc chắn quá trình xem xét mã sẽ bắt được nó nếu ai đó bỏ lỡ một thành phần hiện có, nhưng nếu họ đã đặt 10 giờ phát triển trong quá trình thực hiện của riêng họ thì sao? Bạn cần tránh những tình huống này bằng cách thực thi hành vi nghiên cứu tốt trong nhóm.

Chúng tôi đã phải đối mặt với vấn đề này trong một dự án lớn mà tôi hiện đang làm. Chúng tôi đã có một số vòng quay của các nhà phát triển trong vài tháng qua, đó cũng là một cơ sở mã khá lớn và ngay cả những người đã tham gia dự án kể từ khi bắt đầu không biết đến từng inch của nó.

Mặc dù mã thường được viết tốt và chia thành các phần nhỏ với các trách nhiệm duy nhất và tài liệu ở đó, khá dễ dàng để bỏ lỡ một cái gì đó đã được thực hiện. Các quy ước đặt tên nhất quán giúp ích rất nhiều vì dễ dàng tìm kiếm thứ gì đó trong bất kỳ IDE nào. Tài liệu có thể là toàn diện nhưng khi nó phát triển lâu hơn, thật khó để đọc qua nó.

Một điều chúng tôi đã làm điều đó, theo tôi, đã cải thiện tình hình rất nhiều là việc giới thiệu một điều mà chúng tôi gọi là các cuộc đàm phán Lightning . Bất cứ khi nào ai đó viết một đoạn mã mà người đó tin rằng nên được biết đến nhóm, một bài thuyết trình ngắn (thường là 5-15 phút) được sắp xếp. Chúng tôi cố gắng làm điều này một lần mỗi tuần. Các đối tượng có xu hướng khác nhau, từ các tính năng mới và cách xử lý các vấn đề phức tạp gần đây, thông qua các phương pháp thử nghiệm / mã hóa, thành phần có thể tái sử dụng, để nói về nền tảng của ứng dụng và tái cấu trúc ứng dụng.

Một số đối tượng được đề cập trên các cuộc đàm phán tương tự, toàn công ty. Chúng tôi đã tìm thấy nó một cách khá hiệu quả để thúc đẩy chia sẻ kiến ​​thức. Dễ dàng hơn để xem và ghi nhớ một bản trình bày ngắn và biết nơi để tìm tài liệu bổ sung hoặc ai sẽ giúp đỡ hơn là tham gia vào các buổi đào tạo rất dài và hiếm khi tổ chức hoặc chỉ ngồi đó, đọc tài liệu để che.

Các cuộc đàm phán toàn công ty thực sự đã đến đầu tiên. Chúng tôi chỉ áp dụng phương pháp này để chia sẻ kiến ​​thức cụ thể theo dự án và tôi nghĩ rằng nó hoạt động khá tốt.

Lập trình cặp cũng làm cho kiến ​​thức lưu thông nhanh hơn rất nhiều.

Tôi nghĩ rằng đây thực sự là hai câu hỏi trong một - tôi sẽ cố gắng trả lời cả hai.

1) Làm thế nào để chúng tôi giảm mã trùng lặp trong một cơ sở mã.
Nó giúp nhắc nhở bản thân về lợi ích của việc này: nó dẫn đến ít lỗi hơn do logic kinh doanh trùng lặp và cần ít mã hơn. Cách tốt nhất để giảm điều này xảy ra là thông qua giao tiếp - như đã đề cập trong các câu trả lời khác. Tôi hoàn toàn đồng ý với khuyến nghị sử dụng các đánh giá mã với sự cảnh báo thêm rằng bạn nên chia sẻ trách nhiệm xem xét mã như nhau để truyền bá kiến ​​thức đúng cách. Bạn cũng nên sử dụng các bản dựng đứng hàng ngày để các nhà phát triển thường nhận ra khi ai đó đang cố gắng giải quyết vấn đề có mã hữu ích hiện có. Bạn cũng nên xem xét việc ghép mã vì nó làm tăng chia sẻ kiến ​​thức và giúp giữ cho các lập trình viên có kỷ luật.

Tôi cũng khuyên bạn nên để các nhà phát triển của mình càng gần nhau càng tốt, tốt nhất là trong cùng một phòng. Với rất nhiều bảng trắng và không gian chia sẻ. Sau đó gửi chúng ra cho bữa ăn cùng nhau. Càng nhiều nhà phát triển của bạn "liên kết", họ sẽ càng giao tiếp với nhau tốt hơn.

Tôi không đồng ý với khuyến nghị sử dụng wiki hoặc tương tự như mã tài liệu. Bất kể các nhà phát triển có kỷ luật cố gắng trở thành tài liệu sẽ trôi dạt từ mã gốc như thế nào. Một cách tiếp cận hiệu quả hơn sẽ là sử dụng đặc tả bằng các thử nghiệm kiểu mẫu. Các tài liệu này mã theo cách làm cho nó rõ ràng cách sử dụng nó và các thử nghiệm của bạn sẽ thất bại nếu ai đó thay đổi mã mà không thay đổi các ví dụ.

Bạn đã có một cơ sở mã lớn với rất nhiều mã trùng lặp, vì vậy bạn có thể nên làm việc để tái cấu trúc điều này. Có thể khó tìm mã trùng lặp không bị cắt và dán. Vì vậy, thay vì làm điều đó tôi đề nghị bạn phân tích lịch sử thay đổi của bạn. Tìm kiếm các tập tin thường thay đổi cùng một lúc. Điều này có thể sẽ chỉ ra các vấn đề với việc đóng gói nếu nó không chỉ ra mã trùng lặp thực tế và dù sao cũng đáng để làm sạch. Nếu bạn cũng có thể phân tích lịch sử sửa lỗi của mình theo các thay đổi mã của bạn, bạn có thể tìm thấy các điểm nóng cụ thể trong đó các bản sửa lỗi thường là cần thiết. Phân tích các điểm nóng này và có thể bạn sẽ thấy nhiều trong số chúng là do logic kinh doanh trùng lặp mà nhà phát triển chỉ thay đổi ở một nơi không nhận ra rằng nó cần thay đổi hai lần.

2) Làm thế nào chúng ta nên tiếp cận việc tạo các widget, thành phần, thư viện, vv mà sau đó có thể được sử dụng trong các dự án khác .
Trong trường hợp này, bạn không nên cố gắng bọc logic kinh doanh mà chia sẻ mã khung hữu ích. Đây có thể là một sự cân bằng khó khăn vì chi phí tạo và duy trì một bộ các thành phần được chia sẻ có thể khá lớn và có thể khó dự đoán trong trường hợp nào đáng để thực hiện. Cách tiếp cận tôi đề nghị ở đây là một quy tắc đình công ba. Đừng lo lắng về việc viết một đoạn mã tương tự hai lần nhưng khi bạn cần thực hiện lại lần thứ ba, nó sẽ tái cấu trúc thành một thành phần được chia sẻ. Tại thời điểm này, bạn có thể chắc chắn chắc chắn rằng nó sẽ hữu ích và bạn có một ý tưởng tốt về các yêu cầu rộng hơn cho thành phần. Rõ ràng, giao tiếp giữa các nhà phát triển là rất quan trọng ở đây.

Xem xét làm cho càng nhiều nguồn mở thành phần được chia sẻ của bạn càng tốt. Đó không phải là logic kinh doanh nên sẽ không mang lại cho đối thủ của bạn nhiều lợi thế nhưng điều đó có nghĩa là bạn sẽ nhận được thêm người đánh giá và người bảo trì miễn phí.

IMMO khóa không phải là tài liệu hay công cụ, khóa là GIAO TIẾP. Hơn 10 nhà phát triển không có nhiều người, một số điều cải thiện giao tiếp này:

• lập trình cặp: với hai người có nhiều thay đổi hơn mà một trong hai người biết rằng vấn đề đã được giải quyết trong một phần khác của dự án và tái sử dụng nó.

• Quyền sở hữu mã tập thể: Tất cả mọi người làm việc với các phần khác nhau của hệ thống, theo cách này dễ dàng hơn nhiều khi họ biết rằng một cái gì đó đã được thực hiện trong một phần khác của dự án, đối với tôi đây là thực hành cơ bản trong một nhóm.

• Dành thời gian để làm việc với các dự án theo chiều ngang: ví dụ: một hoặc sáu thứ sáu trong một tháng và các nhà phát triển trong thời gian này có thể làm việc trong các dự án của riêng mình có khả năng áp dụng cho dự án của công ty bạn. Bằng cách này, các nhà phát triển có thể viết các thư viện và các thành phần có thể tái sử dụng, đôi khi mã của nó đã tồn tại nhưng cần một số tài liệu và làm sạch.

• Thực hiện các cuộc hội thảo và hội thảo: Dành thời gian cho các cuộc thảo luận và hội thảo dành cho nhà phát triển, các nhà phát triển có thể nói về thư viện của anh ta hoặc có lẽ bạn có thể thực hiện các hội thảo tái cấu trúc và lấy một số mã trùng lặp và loại bỏ trùng lặp tạo ra một thành phần có thể sử dụng lại.

Tài liệu có lẽ là cần thiết nhưng nó chỉ là một phần nhỏ trong thực tế bạn cần: cải thiện giao tiếp trong nhóm của bạn.

Còn việc sử dụng một công cụ tìm kiếm cục bộ như Lucene (hoặc một cái gì đó cụ thể hơn cho mã nguồn) để lập chỉ mục mã của bạn thì sao? Khi ai đó bắt đầu viết một lớp mới hoặc một hàm mới (ví dụ), anh ta phải thử (như chính sách nội bộ) một vài tìm kiếm trước khi viết mã của riêng mình. Bằng cách này bạn có thể tránh quá nhiều thông tin liên lạc và bạn có thể dựa vào các bình luận, phương thức và tên lớp tốt. Tôi thấy mình đang làm điều này với các công cụ tìm kiếm nguồn mở có sẵn trên internet: Tôi không biết ai đã viết cái gì hoặc tên của một phương thức hoặc một lớp, nhưng với một vài tìm kiếm hoặc từ đồng nghĩa tôi luôn tìm thấy những gì tôi cần.

Bạn cần một công cụ giúp các nhà phát triển của bạn thực hiện nó một cách liền mạch. Nếu nhà phát triển của bạn khám phá ra họ có thể tiết kiệm được bao nhiêu thời gian bằng cách sử dụng lại đoạn mã (không chỉ về cách viết mã, mà rõ ràng là để đảm bảo chất lượng, tích hợp, v.v.), được trợ giúp bởi một công cụ hiệu quả, dễ sử dụng và tích hợp trực tiếp vào môi trường phát triển, họ sẽ CẦU NGUYỆN để bạn áp dụng một công cụ như vậy!

Hãy cẩn thận rằng rất nhiều lần việc thực hiện các thư viện để tái sử dụng mã sẽ không mang lại lợi thế lớn (chúng có xu hướng trở nên quá mạnh và lớn ...); thay vào đó, tôi muốn tập trung vào các đoạn đơn giản, tức là một vài dòng mã giải quyết một nhiệm vụ cụ thể theo cách hiệu quả.

Bằng cách này, bạn có thể buộc sử dụng các hướng dẫn và thực tiễn tốt nhất bằng cách đưa ra các ví dụ thực tế có thể được các lập trình viên sử dụng trực tiếp.

Có một số công cụ để quản lý đoạn mã, tôi khuyên bạn nên sử dụng công cụ này: http://www.snip2code.com .

. đã nêu ở trên, tức là chia sẻ đoạn trích giữa một nhóm, tích hợp trong các IDE như Visual Studio, Eclipse, IntelliJ, Notepad ++, v.v.)