Hy vọng tôi có thể giúp bạn một chút, hoặc ít nhất là chỉ cho bạn đi đúng hướng!
Tuy nhiên, như một chút từ chối, đó là một chủ đề lớn - và một chủ đề mà tôi thực sự nghĩ là " bị ném vào " để hiểu sâu hơn. Điều đó nói rằng, tôi sẽ đưa ra một cách nhanh chóng về hai vấn đề chính:
- Mã và kiểm soát nguồn
- Truyền thông và một số lời khuyên.
Về các dự án OOP cụ thể - Tôi thực sự không thể thấy quá nhiều vấn đề cụ thể đối với OOP không có ở nơi khác.
Trên thực tế, tôi nghĩ lập trình theo kiểu OOP cực kỳ phù hợp để phát triển nhóm. Một đặc điểm chính của OOP là tôi không nên biết tất cả các chi tiết về mọi đối tượng tôi tương tác: Tôi chỉ cần biết những gì nó có thể làm và làm thế nào tôi có thể khiến nó làm điều đó.
Các tóm tắt mà OOP có thể cung cấp là tuyệt vời trong một nhóm.
Kiểm soát nguồn
Cần phải có một vị trí trung tâm cho dự án được lưu trữ và một nơi cho phép nhiều nhà phát triển truy cập vào cơ sở mã bất cứ lúc nào. Đây là nơi các hệ thống như Git (hoặc SVN) đến chơi.
Tôi chỉ có thể nói cụ thể về Git, vì tôi chưa bao giờ sử dụng SVN - tuy nhiên tôi tập hợp chúng giống nhau nhưng với thuật ngữ khác nhau.
Sử dụng Git tôi có thể tạo một kho lưu trữ với tất cả mã nguồn cho một dự án nhất định và sau đó cho phép nhóm của tôi truy cập vào kho lưu trữ. Đối với mọi tính năng hoặc sửa lỗi sau đó được thực hiện, các nhà phát triển riêng lẻ có thể tạo "nhánh" của riêng họ , điều đó có nghĩa là sự phát triển có thể xảy ra trên các rãnh song song.
Khi một tính năng hoặc sửa chữa được hoàn thành, nó có thể được " hợp nhất " trở lại vào cơ sở mã của dự án chính. Bất kỳ " xung đột " nào sau đó có thể được Git phát hiện và giải quyết ở cấp nguồn bởi nhà phát triển chịu trách nhiệm.
Tôi không chắc liệu bạn có từng sử dụng Git trước đây không, nhưng ban đầu nó có vẻ khá phức tạp - nhưng nhờ sự phổ biến gần đây của nó (một phần là với Github ), có rất nhiều hướng dẫn và tài nguyên ngoài kia.
Nếu bạn chưa từng sử dụng nó trước đó, thì tôi khuyên bạn nên đăng ký GitHub và cảm nhận theo cách đó! (Ngoài ra, Bitbucket là một giải pháp thay thế tương tự, nhưng nó cho phép bạn có các kho riêng tư miễn phí.)
Git Flow là một luồng công việc dựa trên Git tuyệt vời rất hữu ích cho các nhóm. Giống như Git nói chung, một khi bạn làm việc với nó một thời gian, thật khó để tưởng tượng làm việc trong một nhóm mà không có nó!
Truyền thông
Khi bạn vượt qua tất cả các rào cản kỹ thuật, bạn thực sự đi đến vấn đề cơ bản gây khó khăn cho hầu hết các dự án (kỹ thuật hay không) - và đó là giao tiếp.
Toàn đội cần nhận thức được ai đang làm gì, khi nào họ làm và những gì nó ảnh hưởng.
Trách nhiệm cần được xác định rõ ràng
Điều này là hiển nhiên, nhưng hầu hết các dự án sẽ sử dụng một số hình thức hệ thống bán vé - trong đó bất kỳ yêu cầu tính năng hoặc lỗi nào được ghi lại, và sau đó được gán cho một thành viên cụ thể của nhân viên. ( JIRA , Unfuddle , v.v.) Thông thường những thứ này được tích hợp vào hệ thống kiểm soát nguồn giúp cuộc sống đơn giản hơn một chút. (BitBucket và GitHub đều cung cấp theo dõi vấn đề cho kho Git được lưu trữ cùng với chúng.)
Điều này dừng lại, hoặc giúp ngăn chặn ít nhất, các nhà phát triển vô tình làm việc trên cùng các vấn đề.
Đây không phải là một sửa chữa hoàn toàn mặc dù; bạn vẫn cần đảm bảo các nhà phát triển nhận thức được về các trách nhiệm của các nhà phát triển khác. Trước đây tôi biết rằng tôi đã sửa các vấn đề khác mà tôi đã vấp phải trong quá trình sửa một lỗi cụ thể, hoàn toàn là vì nó có ý nghĩa. ( " Vâng, tôi đã ở đây. Điều này có thể làm với một cấu trúc lại và có lẽ tôi có thể kiểm tra xem có bất kỳ vấn đề khác. ") Sau đó, tôi đã phải xin lỗi vì các nhà phát triển khác khi họ đang làm việc về các vấn đề khác mà tôi đã cố định - lãng phí cả thời gian của chúng tôi.
Nói chung, những vấn đề này có thể được khắc phục bằng ...
Họp thường kỳ
Một số phương pháp quản lý / phát triển dự án chỉ đạo các phương thức giao tiếp cụ thể hoặc các khoảng thời gian họp. Nói chung, các hệ thống hiệu quả nhất mà tôi đã thấy là các cuộc họp độc lập vào buổi sáng, nơi mọi người trong nhóm sẽ nhanh chóng thực hiện những gì họ đang làm - nếu bạn giới hạn điều này chỉ với các thành viên nhóm phát triển và có hướng dẫn rõ ràng về những gì để giao tiếp sau đó có thể có hiệu quả đáng kinh ngạc. Tôi đã luôn cố gắng bám vào:
Tôi đang làm việc trên X,
Để đạt được / sửa chữa Y,
Mà liên quan đến sửa đổi / sửa đổi Z.
Các thành viên khác trong nhóm có thể ngay lập tức nhận ra rằng " Fergus đang khắc phục lỗi đó đã được ghi vào ngày khác, tuy nhiên điều đó có nghĩa là anh ta đang làm việc với một số mã mà tôi cần xem xét - Tôi sẽ kiểm tra với anh ta trước khi tôi thực hiện bất kỳ thay đổi nào. ".
Cuộc họp kiến trúc
Gần đây tôi đã làm việc với một nhóm tuyệt vời có " cuộc trò chuyện công nghệ " hai tuần một lần , trong đó các vấn đề kiến trúc / lớn hơn sẽ được thảo luận. Mọi thành viên trong nhóm đã có thời gian để hiểu các vấn đề lớn hơn mà dự án phải đối mặt và có thể thảo luận về các bản sửa lỗi tiềm năng.
Cá nhân tôi rất thích điều này, tôi đã không đóng góp nhiều vì tôi còn khá mới với dự án - nhưng việc có thể lắng nghe các cuộc thảo luận đã cho tôi nhiều cái nhìn sâu sắc; Tôi sẽ sớm hiểu được dự án cũng như phong cách tư duy cá nhân.
Truyền thông là một vấn đề có thể khiến bất kỳ đội nào thất vọng. Kỹ thuật hay không, nếu mọi người không biết về bức tranh lớn hơn thì có nhiều khả năng họ sẽ thất bại.
Các vấn đề khác
Thật tốt khi đảm bảo mọi người đều có cùng cấu hình hoặc kiểu dáng khi làm việc trong nhóm. Ý tôi là sao
Cấu hình
Nếu bạn đang làm việc trên một dự án Java - thì có lẽ đảm bảo (ít nhất là cho các môi trường phát triển, chắc chắn không phải để thử nghiệm.) Các phiên bản JVM là phổ biến trong nhóm có thể là một ý tưởng tốt? Sau đó, IDE. Nó giúp ích rất nhiều nếu cả nhóm đang sử dụng Eclipse hoặc NetBeans hoặc IDE bạn chọn.
Trên một dự án web, có thể tất cả các nhà phát triển cần một ngăn xếp cụ thể; với các phiên bản Apache hoặc PHP cụ thể .
Suy nghĩ về các yếu tố như thế này chỉ cho phép nhóm nghiên cứu "gel" nhanh hơn một chút trong tâm trí của tôi.
Phong cách
Tab vs không gian? CamelCase hoặc spaces_with_underscores? Nhỏ như những câu hỏi này có thể là khi bạn làm việc một mình, khi bạn làm việc với một nhóm lớn hơn, bạn thực sự muốn phấn đấu theo một phong cách chung.
Trên thực tế, bạn không thực sự có thể nói ai đã viết một phần mã cụ thể - bạn chỉ nên biết rằng nó thuộc về .
Đây là lý do tại sao nhiều dự án nguồn mở công khai công khai các hướng dẫn / định dạng định dạng mã nguồn - để biết ý tưởng về những thứ này chứa gì, hãy xem Google StyleGuides cho các dự án nguồn mở của riêng họ.
Nhiệm vụ và bài kiểm tra đơn vị
Điều này không giới hạn ở các đội, nhưng tôi sẽ nhanh chóng chạm vào điều này vì một lý do cụ thể: nó làm cho cuộc sống của đội dễ dàng hơn rất nhiều.
Nếu bạn có một quy trình công việc phức tạp với nhiều phụ thuộc hoặc quá trình xây dựng dài - thì thường sẽ rất hữu ích khi tự động hóa việc này bằng cách sử dụng một trình chạy tác vụ. Đối với các dự án web GruntJS là tuyệt vời, mặc dù đến từ Java tôi đoán Apache Ant có thể khá giống nhau.
Là một cá nhân tôi sử dụng GruntJS để xây dựng trang web của tôi trước khi tôi triển khai nó đến máy chủ FTP của tôi - một lệnh Grunt là tất cả những gì cần thiết cho CSS của tôi / Sass được biên dịch và minified , tài sản của tôi để được nén và sau đó tác phẩm của tôi để được tải lên.
Là một thành viên trong nhóm, tôi có thể sử dụng GruntJS để kiểm tra xem tôi đã không phá vỡ bất kỳ thử nghiệm nào chưa - và tôi đã không đưa ra bất kỳ lỗi nào bằng cách không nhận thức đầy đủ về các phần khác của dự án. Tất nhiên, đây là bổ sung cho những lợi ích mà nó mang lại cho tôi với tư cách là một nhà phát triển cá nhân.
Tôi cũng có thể sử dụng nó để tôi có thể sao chép một dự án bằng gói điều khiển nguồn ưa thích (Git) - và chạy một lệnh để cài đặt tất cả các phụ thuộc của tôi. Đây là một điểm cộng lớn, vì thời gian để đưa một nhà phát triển mới vào vị trí mà họ thực sự có thể bắt đầu phát triển có thể khá lớn - thậm chí không cần xem xét đến thời gian cần thiết để làm quen với một cơ sở mã lạ.
Tài liệu
Các dự án tốt nhất tôi từng thấy đã có tài liệu (và thường khá quá mức.) Nhằm vào các nhà phát triển. Những loại tài liệu này có thể giải thích những điều như:
1. Môi trường phát triển:
"Chúng tôi hiện đang triển khai đến một máy chủ chạy ngăn xếp LAMP , vì các nhà phát triển như vậy nên nhắm mục tiêu các phiên bản được nêu trong .."
2. Luồng công việc
"Tất cả các tính năng sẽ được phát triển trên nhánh 'tính năng / *' và được hợp nhất vào nhánh 'thử nghiệm' trước khi được coi là sẵn sàng phát hành."
3. Trách nhiệm trong nhóm:
"Đối với các vấn đề cơ sở dữ liệu, hãy nói chuyện với Steve. Đối với các vấn đề về nền tảng, hãy nói chuyện với David."
4. Một " đường ống " cho tương lai
"Khi phát triển mã mới, hãy nhớ rằng kể từ tháng 6 năm 2014, chúng tôi muốn triển khai mã x - kế thừa có thể cần được xem xét trước khi điều này xảy ra."
Ví dụ
Có thể đáng để xem xét luồng công việc của một dự án nguồn mở để cảm nhận về cách thức hoạt động của nó - cho dù đó là một dự án đã được thiết lập với quy trình công việc của riêng họ (thường được ghi chép nhiều), hoặc một trong nhiều ví dụ trên GitHub.
Một lời cảnh báo cuối cùng
Nếu bạn thấy mình làm việc trong một nhóm quản lý để làm tất cả những điều này đúng .. bạn sẽ ghét ở bất cứ nơi nào khác ..! Lấy nó từ tôi, một khi bạn đã trải nghiệm một nhóm tốt thì đột nhiên các vấn đề ở nơi khác thực sự có thể kéo bạn xuống. (Đó là một câu chuyện cho một bài viết khác!)