Chuyển từ dự án một người đàn ông sang dự án nhóm trong tương lai. Tôi nên làm gì bây giờ để chuẩn bị và những gì có thể chờ đợi?

Để giải thích, tôi muốn biết mọi người nghĩ bạn cần đặt gì khi vẫn là một dự án một người (kiểm soát nguồn nhóm, tài liệu, xây dựng, v.v.) và những điều không cần phải làm cho đến thời điểm đó khi người thứ hai đến vào dự án.

Bất cứ ai có bất kỳ kinh nghiệm di chuyển qua kịch bản này, những hiểu biết của họ sẽ được đánh giá cao.

Những gì tôi đã học được. (Tôi đã thử một thứ tự khác. Tôi đã sai. Đây là thứ tự mà mọi thứ trở nên có liên quan.)

1. Đặt mọi thứ vào kiểm soát mã nguồn. Sử dụng một cái gì đó mọi người có quyền truy cập và bắt đầu ngay bây giờ . Không có ngoại lệ. Không chậm trễ. Không có lời bào chữa.

2. Tạo khu vực QA / Test hoàn toàn tách biệt với môi trường "làm việc" hoặc "phát triển" cá nhân của bạn. Ít nhất là một id người dùng riêng biệt. Lý tưởng trên một VM riêng.
   Hoàn toàn riêng biệt. Không thể trùng lặp với môi trường làm việc hiện tại của bạn.

3. Dừng thử nghiệm ngoài kiểm tra đơn vị trong môi trường làm việc của riêng bạn. Mã và đơn vị kiểm tra bạn làm "như chính mình". Tất cả các thử nghiệm khác (tích hợp, hiệu suất, bất cứ điều gì) bạn làm trên VM riêng. Đừng bao giờ tự kiểm tra. Luôn kiểm tra như một người dùng QA riêng biệt. Lý tưởng trên một VM riêng.

   "Làm việc cho tôi," là một điều tồi tệ phải nói với (các) thành viên trong nhóm của bạn. Rất tệ. Bạn cần phải tìm ra những gì họ đang làm sai. Vài lần một ngày.

4. Kế hoạch viết ra tất cả mọi thứ. Sử dụng công cụ đánh dấu văn bản đơn giản (RST hoặc Markdown hoặc một cái gì đó) để tất cả tài liệu là văn bản thuần túy trong kho điều khiển phiên bản. Một công cụ có thể tạo các trang HTML (ví dụ: Tài liệu cho RST) hoặc PDF hoặc bất cứ thứ gì có vẻ tốt nhất. Không sử dụng các định dạng tài liệu độc quyền (ví dụ MS-Word). Họ có thể không chơi tốt với một số hệ thống kiểm soát mã nguồn.

5. Những điều đầu tiên bạn cần viết ra là như sau.

   • Làm thế nào để tạo ra một môi trường phát triển làm việc. Khi nghi ngờ, hãy tạo một máy ảo và thực hiện toàn bộ thao tác trên máy ảo đó. Hãy chắc chắn rằng các bước thực sự làm việc và tài liệu rõ ràng . Các dòng thực tế gõ vào loại dòng lệnh thực tế rõ ràng.

   • Làm thế nào để chạy bộ kiểm tra đơn vị. Lần nữa. Hãy chắc chắn rằng các hướng dẫn hoạt động và không cần suy nghĩ. "Nhập cái này:" "Xác nhận rằng:" loại công cụ. Không phải là các thành viên trong nhóm của bạn là ngu ngốc. Đó là bạn không nhớ những gì bạn đang giả sử trừ khi bạn viết tất cả ra.

   • Làm thế nào để chạy bộ kiểm thử tích hợp.

   Đừng lãng phí nhiều thời gian để mô tả kiến ​​trúc hoặc các nguyên tắc thiết kế. Bạn cần phải có người đứng dậy và chạy trước. Bạn có thể giải thích công cụ sau.

6. Những điều tiếp theo để tài liệu là những câu chuyện của người dùng. Và các trường hợp thử nghiệm hỗ trợ những câu chuyện. Và các đồ đạc dữ liệu cần thiết cho các trường hợp thử nghiệm hỗ trợ những câu chuyện của người dùng đó.

   Bạn sẽ được chia sẻ điều này. Nó đi dưới sự kiểm soát mã nguồn.

7. Cuối cùng, bạn có thể ghi lại 4 lượt xem khác.

   • Xem logic là công cụ hữu ích cho tài liệu. Hình ảnh được chấp nhận ở đây. Điều này có xu hướng phát triển nhanh chóng, vì vậy đừng dành thời gian để nắm bắt thông tin di sản. Tìm ra cách hợp tác với (các) thành viên trong nhóm của bạn.

   • Quá trình xem thường hữu ích. Phụ thuộc vào ứng dụng tổng thể này quan trọng như thế nào.

   • Quan điểm phát triển - mô-đun, thư viện, khung, v.v. - thường được mô tả không chính thức. Một bức tranh có thể giúp ích, nhưng thật khó để làm cho nó hoàn chỉnh đủ để ai đó có thể lấy một tài liệu và tạo ra đầu hoặc đuôi của nó. Ngay cả các dự án rất lâu đời, rất công khai cũng có tài liệu thư viện đơn giản là bị bỏ qua. (Dẫn đến rất nhiều câu hỏi về Stack Overflow.)

     Bên cạnh việc được chấp nhận để không chính thức, điều này có xu hướng thay đổi nhanh chóng.

   • Thông tin triển khai. May chủ. Các địa chỉ IP. Thông tin cơ sở dữ liệu. Tất cả những thứ đó phải được viết ra. Cuối cùng.

Công cụ và phương pháp

Điều gì là cần thiết để hợp tác thành công và có hiệu quả?

• Xác định các bộ phận / thành phần của dự án của bạn: Phân biệt rõ ràng giữa các phần khác nhau (cơ sở dữ liệu, lớp truy cập dữ liệu, trang web, dịch vụ, API, dự án thử nghiệm, tập lệnh xây dựng, ...) và môi trường (dev, dàn dựng, sản xuất) và đặt tên cho chúng luôn có tác động đến giao tiếp bằng miệng và bằng văn bản của bạn (tài liệu, tên dự án, ...)
• Sử dụng hệ thống quản lý mã nguồn (chỉ trong trường hợp bạn chưa có). Hãy suy nghĩ về cách sử dụng phân nhánh với dự án và thiết lập của bạn.
• Tự động hóa các bản dựng của bạn - làm cho nó dễ dàng nhất có thể để thiết lập một môi trường từ kho lưu trữ nguồn của bạn.
• Các dự án thử nghiệm là điều bắt buộc đối với các dự án lớn, ít nhất là đối với các dự án phức tạp hơn.
• Sử dụng môi trường dàn dựng nơi dự án của bạn đã sẵn sàng để được sử dụng. Ngoài ra, tạo và duy trì dữ liệu mẫu cho thiết lập dàn tự động.
• Sử dụng một hệ thống theo dõi lỗi có thể giúp ưu tiên và lập kế hoạch phát triển, đồng thời đóng vai trò là bộ nhớ cho các lỗi trong quá khứ và cách chúng được giải quyết.
• Tài liệu từng phần của dự án của bạn, một số nhiều hơn những phần khác. Cá nhân tôi thích: Tổng quan - Kiến trúc - Phụ thuộc - Cấu hình - Các sự cố thường gặp (từ đây ). Đôi khi ít hơn là nhiều hơn - để không để tài liệu của bạn bị lỗi thời, tốt hơn hết là ngắn gọn và để tài liệu trở thành một phần trong hoạt động hàng ngày của bạn.

Quản lý / làm việc nhóm

... hoặc bất cứ điều gì khác ở cấp độ giữa các cá nhân

• Xác định kỳ vọng của bạn về các nhà phát triển khác. Hãy hợp lý, không ai có thể mang lại sự tham gia và đam mê giống như bạn - ít nhất là không ngay từ đầu. Truyền đạt những gì bạn mong đợi và những gì không, xác định trách nhiệm của bạn và của người khác. Không phải ai cũng là kỹ sư, kiến ​​trúc sư, nhà phát triển, dba và sysadmin, nhưng nếu đó là điều bạn đang tìm kiếm, hãy chọn đúng người hoặc bạn sẽ thất vọng.
• Đầu tiên , xác định chính xác các nhiệm vụ , và xem xét và thảo luận về kết quả. Dần dần, bắt đầu ngày càng ít quản lý vi mô. Ý tưởng là xây dựng niềm tin và tăng trách nhiệm.
• Lập kế hoạch dự án của bạn , đặt mục tiêu cho dự án của bạn và cho nhóm của bạn trong năm tới. Viết nó xuống và kiểm tra nó sau, điều này sẽ đưa ra quan điểm . Những mục tiêu đó có thể hoặc không thể truyền đạt cho người khác (miễn là chúng là mục tiêu bạn cần đạt được, không phải khác), đó có thể chỉ là danh sách kiểm tra của riêng bạn.
• Dành một ngày để chuẩn bị và lên kế hoạch cho tháng đầu tiên (hoặc hai hoặc ba tháng) của nhà phát triển mới của bạn. Tôi thấy nó cực kỳ động lực khi làm việc với những người được chuẩn bị tốt. Không ai có được ấn tượng rằng thời gian của mình bị lãng phí.
• Buông . Đó là con của bạn, nó cũng sẽ trở thành của người khác. Cho phép người khác trở thành một chuyên gia giỏi hơn bạn, ít nhất là trong một số phần của dự án. Điều này có nghĩa là bạn thực sự đã thành công.
• Nghe - nếu bạn thuê cô ấy, cô ấy có điều muốn nói. Hãy sẵn sàng để học hỏi.
• Hãy sẵn sàng chia sẻ kiến thức và kinh nghiệm của bạn (và do đó thời gian - hãy kiên nhẫn).
• Sai lầm sẽ được tạo ra, đó là cách họ xử lý và mọi người đang tìm hiểu về họ những gì được tính.
• Dành thời gian để tìm hiểu và thử nghiệm

Sách tham khảo

Tôi sẽ liệt kê một số sách thường được đề cập mà tôi thực sự đã đọc và tôi nghĩ là đáng đọc, để mô tả chi tiết hơn hoặc để biết thêm sách bạn có thể muốn kiểm tra một số câu hỏi trên SO hỏi chính xác về điều đó, như cái này hay cái này câu hỏi.

Những cuốn sách đó thực sự đáng đọc đối với các nhóm, tổ chức và dự án lập trình:

• Đồ dùng cá nhân
• Tháng đàn ông huyền thoại
• Dự toán phần mềm, làm sáng tỏ nghệ thuật đen

Không ai trong số đó là những hướng dẫn thực tế về cách thực hiện phương pháp X (ngoại trừ Dự toán phần mềm, cuốn sách này giúp bạn chọn một quy trình ước tính phù hợp). Tất nhiên, những cuốn sách tập trung hơn vào chính chương trình như Code Complete cũng rất phong phú.

Tôi sẽ nói từ kinh nghiệm, nhưng hãy nhớ rằng mọi người đều khác nhau. Những điều này không phải là phổ quát.

Một điều là để cho nó đi cá nhân. Dự án này là thứ bạn đã sống và sống trong 18 tháng - bạn tự nhiên muốn mọi thay đổi sẽ giống như bạn sẽ làm. Đưa ra một bộ đệm cho một đồng nghiệp để phạm sai lầm, để học hỏi. Tạo một căn phòng cho chúng hữu ích. Và hãy nhớ rằng nó có thể không xảy ra ngay lập tức. Ngoài ra, sẽ thật tuyệt nếu có một cái gì đó, một phần của mã mà họ có thể cảm thấy họ thành công trong việc cải thiện hoặc tạo ra, cảm giác đó là thành công trong một khoảng thời gian ngắn. Kiên nhẫn và chịu đựng có một tỷ lệ hoàn trả tốt ở đây. Đừng cố gắng vi mô, và nếu bạn muốn chỉ trích, nói "bạn sai", hãy chắc chắn rằng bạn có công đức, bạn có thể chứng minh điều đó, đó không phải là một cuộc chiến "tôn giáo".

Một vấn đề quan trọng khác là tìm người phù hợp với bạn. Lý tưởng hơn là tìm một người thông minh hơn mình. Đó là chủ quan và tương đối, nhưng nếu bạn cảm thấy một người có một số kiến ​​thức và kỹ năng bạn không có, thì đó là điều tốt nhất. Nó sẽ là một sự hợp tác bổ ích lẫn nhau.

Có hai cách nó có thể đi - đồng nghiệp sẽ là một lực cản và cuối cùng bạn sẽ làm lại những gì anh ấy hoặc cô ấy đã làm, hoặc các kỹ năng của hai bạn sẽ nhân lên, không chỉ là cộng lại, và bạn sẽ thực sự đánh giá cao việc làm việc cùng nhau.

Về một chủ đề "mã sạch, nhanh, có thể tái sử dụng" - Tôi đề nghị về một cuộc phỏng vấn, yêu cầu viết một trình quản lý dịch vụ / hạt nhân nhỏ và / hoặc người thực thi công việc. Xem cách các thành phần cắm được chỉ định và cấu hình. Không cần phải kết thúc, đó là một suy nghĩ đáng kể. Và bạn cũng sẽ nhanh chóng học được những người biết cách làm nó sẽ muốn có tiền kha khá ;-) Chúc may mắn!

Của tôi: Bắt đầu với tài liệu kiến ​​trúc dự án nội bộ của bạn cho một người ... không biết về nó. Cố gắng giải thích những giả định nào được đặt ra và khi nào / nơi bạn chuyển hướng từ thực tiễn phổ biến và tại sao.

Xây dựng tự động hóa: Ý tưởng tuyệt vời, tôi có thể thêm tự động hóa cấu hình cho máy dev. Cách đơn giản nhất là xây dựng càng nhiều (sẽ triển khai thử nghiệm nhiều hơn / nhanh hơn).

Một ý tưởng khác (nó đã giúp tôi rất nhiều lần): Yêu cầu nhà phát triển mới thực hiện một số nhiệm vụ quy mô nhỏ trong các khu vực khác nhau của cơ sở mã của bạn, để anh ta quen với các công cụ bố trí, v.v. Một ý tưởng hay là xóa Các khu vực tối nghĩa có thể gây nhầm lẫn sau này (ví dụ: nếu bạn đã sử dụng emmm python cho hai dòng script shell ở đâu đó và dự án của bạn dựa trên java, hãy yêu cầu hai dòng đó được viết lại trong java để nhà phát triển # 3 sẽ cần biết ít hơn để làm việc)

Tôi sẽ tập trung vào việc tự động hóa mọi thứ đòi hỏi công việc thủ công, do đó có thể bị làm hỏng bởi một người thiếu kinh nghiệm . Mà, dựa trên nhận xét ngắn gọn của bạn ở trên, bao gồm những điều sau đây:

• cài đặt kiểm soát phiên bản và thay thế các bản sao lưu thủ công bằng các bản sao lưu tự động,
• thiết lập triển khai tự động càng nhiều càng tốt (tối thiểu, hãy viết một tập lệnh để triển khai qua FTP thay vì thực hiện bằng tay.

Nếu bạn không thực hiện những điều này, hoặc bạn sẽ bị xiềng xích để thực hiện những nhiệm vụ này mãi mãi, hoặc (một số) anh chàng mới chắc chắn sẽ làm hỏng điều gì đó sớm hay muộn.

Nhiệm vụ quan trọng khác là, như @dimitris lưu ý, tài liệu. @S. Lott đã thêm nhiều chi tiết hơn về điều này, vì vậy chỉ cần +1 cho anh ta thay vì lặp lại :-)

Dưới đây là một số suy nghĩ, một phần dựa trên kinh nghiệm cá nhân:

• Tài liệu dự án của bạn. Thiết kế thông số kỹ thuật, sơ đồ, hướng dẫn và nhận xét sẽ giúp nhân viên mới bắt kịp tốc độ. Giải thích một hệ thống phức tạp chỉ bằng lời nói có thể chứng minh sự chậm chạp và bực bội. Tài liệu thường bị bỏ quên trong các dự án một người đàn ông. Hãy chắc chắn rằng bạn là một ngoại lệ.

• Đầu tiên, hãy tập trung vào mã cấp API / / lõi, đồng thời cung cấp cho nhân viên mới một số "lớp ứng dụng" hoặc sửa lỗi để dần dần làm quen với mã. Nói chung, bắt đầu với các nhiệm vụ dễ dàng hơn , nhưng có ý nghĩa và do đó bổ ích .

• Truyền thông là quan trọng. Hãy phản ứng với các câu hỏi, nhận xét và ý tưởng của nhân viên mới. Giải thích lý do tại sao bạn nghĩ rằng một ý tưởng là không tốt nếu bạn làm. Một đôi mắt mới có thể phát hiện ra căn phòng để cải thiện đáng ngạc nhiên. Nếu nhân viên mới của bạn là một người đàng hoàng, anh ta có thể xem lại mã của bạn và cuối cùng tham gia vào các quyết định kiến ​​trúc. Thảo luận, nảy ý tưởng lẫn nhau. Đó là một trong những lợi ích lớn nhất của việc có một đồng nghiệp trong dự án của bạn.

• Xác định trách nhiệm rõ ràng , một khi bạn biết loại nhiệm vụ nào mà thành viên nhóm mới của bạn sẽ làm. Thiết lập thực hành tài liệu và quy ước mã hóa để giữ cho mọi thứ trơn tru.

• Sử dụng một hệ thống kiểm soát sửa đổi . Duy trì bố trí tệp nguồn hợp lý và xây dựng kỷ luật .

Đối với cuộc phỏng vấn - Tôi không phải là một fan hâm mộ lớn của các bài kiểm tra mã hóa nhân tạo hoặc các câu hỏi mẹo, trừ khi bạn muốn thử khả năng chịu đựng căng thẳng của ứng viên. Ngay cả những người giải quyết vấn đề thông minh nhất cũng có thể bị khóa trong tình huống như vậy. Những phẩm chất bạn sẽ tìm kiếm, trong số những người khác là: trung thực , năng lực chuyên môn , kiến thức / hiểu biết về công nghệ , sự nhiệt tình và khả năng tương thích lẫn nhau . Không khí làm việc có thể có nghĩa là rất nhiều; Thật không thể chọn một đồng đội mà bạn không thích. Đặt câu hỏi của bạn đúng và làm một số cuộc thảo luận không chính thức để có được một bức tranh tốt về ứng cử viên của bạn. Chúc may mắn!

Công nghệ

Nếu bạn đang mời người khác làm nhà phát triển, có ba điều quan trọng tôi khuyên bạn nên có và chạy trước khi họ bắt đầu.

1. Kiểm soát nguồn
2. Theo dõi vấn đề
3. Hội nhập liên tục

Nếu ba điều này hoạt động bình thường, bạn sẽ loại bỏ được khoảng 75% vấn đề phổ biến xảy ra khi bạn mang thành viên nhóm mới. Điểm quan trọng của những công nghệ này là lấy rất nhiều thứ chỉ xảy ra trong đầu bạn và đưa nó ra ngoài nơi thành viên trong nhóm của bạn có thể tương tác với nó.

Kiểm soát nguồn đảm bảo rằng cả hai bạn đều làm việc trên cùng một thứ. Theo dõi vấn đề giúp cả hai bạn theo dõi những gì cần phải làm và sẽ giúp bạn dễ dàng biết những gì họ đang làm và hoàn thành. Tích hợp và kiểm tra liên tục sẽ giúp đảm bảo rằng bạn có quy trình xây dựng lặp lại và các cải tiến mới không phá vỡ các phần khác của mã.

Lập trình viên thực dụng có một số cuốn sách khá hay về điều này. Dưới đây là một vài điều tôi muốn giới thiệu. Họ có các tiêu đề tương tự khác dựa trên ngôn ngữ lập trình bạn đang sử dụng hoặc phiên bản nào bạn muốn sử dụng:

http://www.pragprog.com/title/tpp/the-pigateatic-programmer http://www.pragprog.com/title/tsgit/pigateation-version-control-USE-git http: //www.pragprog. com / title / auto / thực dụng-dự án tự động hóa

Cá nhân

Thường thì những khó khăn bạn sẽ gặp phải ít hơn về mặt kỹ thuật của mọi thứ và nhiều hơn về việc học cách buông tay. Có thể khó để cung cấp cho người khác quyền kiểm soát các khía cạnh của dự án - đặc biệt nếu bạn đang sử dụng để tự làm tất cả và đưa ra mọi quyết định. Bạn sẽ tiết kiệm cho mình một số đau buồn nếu bạn có thể tìm thấy một khu vực nơi bạn có thể có người mới làm việc với một lượng tự do hợp lý ngay từ đầu để bạn có thể phát triển một nền tảng của niềm tin. Nếu bạn thuê một người tốt, điều chính có lẽ bạn sẽ học được là làm thế nào để tin tưởng người khác làm việc tốt ngay cả khi tất cả các quyết định cá nhân của họ không giống như những gì bạn đã làm.

Bạn muốn cho người thuê mới của bạn tự do giải quyết các vấn đề theo cách phù hợp với họ trong khi vẫn giữ các biện pháp bảo vệ để bạn có thể sớm nắm bắt được vấn đề.

Những điểm này là quan trọng nhất theo ý kiến ​​của tôi:

1. Đọc qua các phần quan trọng của mã của bạn và đảm bảo chúng dễ hiểu. Sử dụng ý kiến ​​hoặc chức năng trực quan và tên biến.
2. Giúp người mới dễ dàng gửi mã.
3. Nếu nó không tầm thường, hãy tạo một tệp README giải thích tất cả các bước cần thiết cho nhà phát triển mới về cách thiết lập môi trường phát triển. Hoặc hỗ trợ chặt chẽ trong việc thiết lập môi trường này.
4. Cung cấp cho nhà phát triển mới các nhiệm vụ được xác định rất rõ ràng khi làm việc với dự án mới này. Theo tôi những nhiệm vụ này nên liên quan đến chức năng mới nhưng đơn giản. Theo tôi, các nhiệm vụ dọn dẹp không có ý nghĩa nhiều vì nhà phát triển mới trước tiên phải làm quen với phong cách mã hóa của bạn và những thói quen trong đó, ngay cả khi chúng không tốt. Dọn dẹp hoặc thậm chí tái cấu trúc là những công việc cần được thực hiện bởi những người biết mã.
5. Làm rõ những gì quá trình để gửi mã. (Ví dụ: chỉ gửi nội dung biên dịch.) Nhưng đừng quá nghiêm ngặt, điều này có thể gây khó chịu ngay từ đầu.
6. Có một tài liệu với các quy ước mã hóa đã sẵn sàng. Có thể thực sự bực bội khi đoán những quy ước mã hóa khác là gì.
7. Nếu ứng dụng phức tạp, hãy chuẩn bị sẵn một số tài liệu để giải thích kiến ​​trúc. Hoặc giải thích kiến ​​trúc cho người mới bằng biểu đồ dòng chảy hoặc một cái gì đó tương tự. Bạn không muốn nhà phát triển mới lãng phí quá nhiều thời gian cho kỹ thuật đảo ngược dự án của bạn.
8. Nếu nhà phát triển mới được cho là tự thực hiện triển khai, hãy chuẩn bị sẵn một danh sách kiểm tra để giải thích tất cả các bước cần thiết để triển khai.

Và cuối cùng nhưng không kém phần quan trọng: có được một hệ thống kiểm soát phiên bản. Lật đổ là tốt Nhưng hãy chắc chắn không thêm các tệp Eclipse đó (hoặc bất cứ thứ gì) dành riêng cho người dùng và do đó liên tục hoạt động. Họ làm bạn lãng phí hàng giờ. Đừng ngần ngại hỏi về Stackoverflow nếu bạn gặp vấn đề với nó.