Làm thế nào để bạn theo dõi những lớp và chức năng mà nhóm của bạn đã viết?

Khi làm việc với mã, tôi phải đối mặt với nhiều thử thách giống như các đồng đội của mình và tôi đã viết một số hàm và lớp hữu ích, và chúng cũng vậy. Nếu có sự giao tiếp tốt, tôi sẽ nghe về một điều tuyệt vời mà ai đó kết hợp lại, và sáu tháng sau khi tôi cần, tôi có thể nhớ nó và gọi chức năng đó, tiết kiệm thời gian cho bản thân. Nếu tôi không nhớ nó, hoặc không bao giờ biết về nó, tôi có thể sẽ phát minh lại bánh xe.

Có một thực hành cụ thể của tài liệu những loại điều này? Làm thế nào để bạn làm cho chúng dễ dàng để tìm thấy?

Nếu nhóm của bạn không có tài liệu như vậy, làm thế nào để bạn biết nếu bánh xe của bạn đã tồn tại?

BIÊN TẬP:

Tất cả trừ một trong những câu trả lời cho đến nay đều liên quan đến một tình huống lý tưởng, vì vậy hãy để tôi tổng hợp các giải pháp đó: tài liệu & truyền thông; wiki, cuộc họp độc lập, vv Đó là những điều tuyệt vời, nhưng họ dựa vào các lập trình viên có thời gian (và kỹ năng) để viết tài liệu và tham dự các cuộc họp và ghi chú và ghi nhớ mọi thứ.

Câu trả lời phổ biến nhất cho đến nay (Caleb's) là câu trả lời duy nhất có thể được sử dụng bởi một lập trình viên không có khả năng về tài liệu và các cuộc họp và chỉ thực hiện một điều: lập trình. Lập trình là những gì một lập trình viên làm, và vâng, một lập trình viên tuyệt vời có thể viết tài liệu, kiểm tra đơn vị, v.v., nhưng hãy đối mặt với nó - hầu hết chúng ta thích lập trình hơn là viết tài liệu. Giải pháp của anh ấy là một trong đó lập trình viên nhận ra mã có thể sử dụng lại và kéo nó ra lớp hoặc kho lưu trữ của riêng mình hoặc bất cứ điều gì, và thực tế là nó bị cô lập, nó trở nên có thể tìm thấy và giảm bớt đường cong học tập khi sử dụng nó ... và điều này đã được thực hiện bằng lập trình.

Theo một cách tôi thấy nó như thế này: Tôi vừa mới viết ba chức năng, và điều đó xảy ra với tôi rằng người khác nên biết về chúng. Tôi có thể ghi chép chúng, viết chúng lên, thông báo chúng tại một cuộc họp, v.v. - điều mà tôi có thể làm, nhưng đó không phải là thế mạnh của tôi - hoặc .... Tôi có thể trích xuất chúng vào một lớp học, đặt tên cho nó tốt, làm cho chúng hoạt động như một hộp đen và dán nó ở nơi các tệp lớp khác đi. Sau đó, một email ngắn thông báo nó là dễ dàng. Các nhà phát triển khác có thể quét mã và hiểu nó tốt hơn so với chức năng bị cô lập được sử dụng trong mã mà họ không hiểu đầy đủ - bối cảnh đó đã bị xóa.

Tôi thích điều này bởi vì nó có nghĩa là có một tập hợp các tệp lớp được đặt tên tốt, với các phương thức được đặt tên tốt, là một giải pháp tốt được thực hiện bằng lập trình tốt. Nó không yêu cầu các cuộc họp, và nó làm dịu nhu cầu về tài liệu chi tiết.

Có bất kỳ ý tưởng nào trong tĩnh mạch này ... cho các nhà phát triển bị cô lập và bị ép thời gian không?

Thư viện. Khung. Kiểm soát phiên bản.

Nếu bạn đã có mã có thể tái sử dụng, điều cuối cùng bạn muốn là cho các thành viên khác trong nhóm sao chép mã nguồn vào dự án của họ. Nếu họ làm điều đó, rất có thể họ sẽ thay đổi một chút ở đây và điều chỉnh một chút ở đó, và chẳng mấy chốc bạn đã có hàng tá hàm hoặc phương thức có cùng tên nhưng mỗi cái hoạt động khác nhau một chút. Hoặc, có lẽ nhiều khả năng, tác giả ban đầu sẽ tiếp tục tinh chỉnh mã để sửa lỗi, làm cho nó hiệu quả hơn hoặc thêm các tính năng, nhưng mã được sao chép sẽ không bao giờ được cập nhật. Tên kỹ thuật cho điều đó là một mớ hỗn độn khổng lồ .

Giải pháp phù hợp là lấy thứ đó có thể tái sử dụng ra khỏi bất kỳ dự án nào bạn đã xây dựng nó ở nơi đầu tiên và đưa nó vào thư viện hoặc khung trong kho lưu trữ kiểm soát phiên bản của chính nó. Điều đó giúp bạn dễ dàng tìm thấy, nhưng cũng không khuyến khích thực hiện các thay đổi mà không xem xét cho tất cả các dự án khác có thể đang sử dụng nó. Bạn có thể cân nhắc việc có một số thư viện khác nhau: một cho mã được kiểm tra tốt không còn có khả năng thay đổi, một cho các công cụ có vẻ ổn định nhưng chưa được kiểm tra và xem xét kỹ lưỡng, một cho các bổ sung được đề xuất.

Một cách tiếp cận đó là thiết lập Wiki cho mục đích đó và viết một số tài liệu cấp cao về những thành phần có thể tái sử dụng, cách bạn giải quyết vấn đề, v.v.

Điều khó khăn là làm cho mọi người trong nhóm của bạn liên tục duy trì Wiki đó. Nhưng bất kỳ loại tài liệu nào khác cũng bị vấn đề tương tự.

Một số mã của bạn cũng có thể đủ tốt để được đưa vào thư viện có thể sử dụng lại. Điều này làm cho nó cũng dễ dàng hơn để tìm lại mã sau này.

Ở trong một công ty có 700 nhân viên, trong các nhóm khác nhau từ 2 đến 20 người, đây là kinh nghiệm của tôi.

Ở cấp độ đội

Chúng tôi có "cuộc họp chờ" mỗi ngày trong khoảng 15-20 phút. Chúng ta có thể nhanh chóng chia sẻ kiến ​​thức phổ biến như "Tôi đã thực hiện chức năng này ngày hôm qua, nó rất khó khăn".

Chúng tôi cũng có một wiki cho mỗi dự án. Điều đó có nghĩa là chúng ta có thể chia sẻ thông tin (kỹ thuật) về những gì đã thực hiện trong dự án, bao gồm các lớp / chức năng tùy chỉnh được tích hợp sẵn.

Ở cấp cơ quan

Ở cấp độ đại lý, chúng tôi có 4 công cụ:

• Một wiki khác. Nó chủ yếu ở đó để cung cấp cho chúng tôi thông tin về phần cứng và công cụ, nhưng đôi khi chúng tôi sử dụng nó để chia sẻ thông tin kỹ thuật để được xem xét trước khi đưa nó lên cấp công ty.
• Những cuộc gặp gỡ cuối tuần. Họ chủ yếu là để biết tiến trình của từng nhóm / dự án, nhưng vì chúng tôi chủ yếu là những người đam mê công nghệ, chúng tôi có thể đưa ra những thứ hay ho.
• Danh sách gửi thư. Chúng tôi có một thư với tất cả mọi người trong cơ quan. Rất nhiều thứ hay ho / những thứ thú vị / những thứ hữu ích có được thông qua đó.
• Kho lưu trữ VCS. Mỗi cơ quan có kho lưu trữ cá nhân nơi chúng tôi có các dự án nhỏ, chủ yếu là các mô-đun mà chúng tôi sử dụng trong các dự án khác nhau.

Ở cấp độ công ty

Ở cấp độ công ty, nó có tổ chức hơn.

Wiki "cấp cơ quan" thực sự là một phần của wiki công ty.

Và wiki sau đó được phân tách dựa trên các công nghệ. Do đó, bất cứ ai cũng có thể cải thiện nó, tìm kiếm thông qua nó và về cơ bản mang lại sự sống cho wiki.

Ngoài ra còn có danh sách gửi thư có sẵn mà chúng tôi có thể đăng ký. Bất cứ ai trong cơ quan đều có thể đăng ký và hầu hết mọi người theo dõi ít ​​nhất một hoặc hai công nghệ, thực tế hầu hết mọi người đều theo dõi 5-10.

Và VCS tất nhiên là hệ thống chia sẻ mã tốt nhất.

Phần kết luận

Tóm lại, không có giải pháp cắt rõ ràng. Chia sẻ kiến ​​thức luôn là một vấn đề lớn, và có lẽ sẽ vẫn còn. Có rất nhiều giải pháp để tạo cơ sở tri thức , và người ta có thể phù hợp với hóa đơn của bạn. Tuy nhiên, một số người đang cố gắng để có được KB tốt hơn vì các giải pháp hiện tại không phải lúc nào cũng rất thông minh.

Vâng, tất cả là do giao tiếp.

Wiki rất tuyệt và bạn chắc chắn nên cài đặt và sử dụng nó. Một mạng lưới lập trình viên nội bộ tốt là tốt nếu mọi người đọc nó và cập nhật nó, vì vậy bạn thực sự đang nói về một vấn đề của mọi người ở đó. Bạn có thể đề xuất các cuộc họp "cập nhật nhóm" hàng tuần, nơi mọi người cùng nhau và đưa ra một cái nhìn tổng quan về những gì công việc đang diễn ra. Các nhà lãnh đạo công nghệ (ít nhất là!) Nên tập trung lại và trò chuyện về những gì mỗi đội đang làm. Các phiên không chính thức "Túi màu nâu" rất tuyệt, lên lịch vào giờ ăn trưa và khiến mọi người nói chuyện.

Bạn cũng cần một cách chia sẻ mã, đóng gói, phiên bản và phân phối nó. Mọi thứ sẽ dễ dàng hơn nếu bạn có một kho lưu trữ mã nguồn thực sự được quản lý tốt, được sắp xếp tốt vào các thư mục "chung" và dự án.

Nếu không có gì như thế này được thực hiện, hãy đưa nó lên với sếp của bạn, giải thích nó sẽ mang lại lợi ích gì cho công ty và đề xuất một con đường phía trước :)

Phiên xem xét mã có thể giúp đỡ. Nếu nhóm của bạn gặp gỡ thường xuyên để thảo luận về những gì đã được phát triển, thì người đưa ra giải pháp có thể chỉ cho những người khác cách sử dụng nó. Nếu ai đó đưa ra một điểm mà họ đang gắn bó, các thành viên khác trong nhóm có thể đề xuất một phương pháp làm tăng việc tái sử dụng các thành phần hiện có.

Cách tốt nhất để xử lý một cái gì đó tương tự là có một cấu trúc kho lưu trữ có một số quy ước đơn giản để tôi biết, với tư cách là một lập trình viên, nếu có một hàm doXYZ, đại khái là nơi tôi nên tìm hàm đó. Cho dù bạn đang sử dụng không gian tên, thư mục, mô-đun, plugin, gói, bất cứ điều gì, mã của bạn phải là mô-đun để các chức năng thực hiện cùng một thứ hoặc truy cập cùng một nguồn dữ liệu ở cùng một vị trí.

Tốt nhất, nên có ít nhất một người khác ngoài tác giả thực hiện đánh giá mã trên mỗi lần đăng ký. Quá trình xem xét mã có thể giúp giảm thiểu vấn đề của nhiều phương thức trùng lặp đang được kiểm tra. Tất nhiên, bạn bị hạn chế bởi kiến ​​thức của người đánh giá.

TL; DR: Mã đánh giá cho mỗi lần đăng ký.