Lập trình cặp / hợp tác trong một công ty nhỏ

Tôi làm việc tại một công ty phát triển nhỏ với tư cách là nhà phát triển chính. Chúng tôi có hai nhà phát triển khác, cũng như ông chủ của tôi là một nhà phát triển, nhưng thực sự không còn thực hiện nhiều mã hóa thực tế nữa.

Vấn đề tôi đang cố gắng khắc phục là nhiều mặt. Chúng tôi có xu hướng làm việc trên các dự án của riêng mình mà không có nhiều sự hợp tác giữa chúng tôi. Thực tế, tôi (với tư cách là nhà phát triển tiên tiến nhất) yêu cầu ý kiến ​​/ giúp đỡ của người khác nhiều hơn họ, vì tôi coi trọng đầu vào của một con mắt bên ngoài.

Tôi muốn tăng sự hợp tác của chúng tôi và đã bày tỏ điều đó với họ. Phần lớn bởi vì tôi muốn cho họ thấy một số điều về cách trở thành nhà phát triển tốt hơn và làm theo các thực tiễn tốt hơn. Nhưng với các kiểu tính cách của các nhà phát triển khác của chúng tôi, tôi nghĩ họ thoải mái hơn khi làm việc một mình.

Tôi đã đọc về lập trình cặp và tôi đã đọc (trong một số diễn đàn) rằng nó không hoạt động tốt khi bạn có một nhà phát triển tiến bộ hơn những người khác (mà tôi). Tuy nhiên, tôi cảm thấy bắt buộc phải bắt đầu hợp tác để công việc của chúng tôi không quá khác biệt.

Câu hỏi của tôi là liệu có ai đã từng ở trong một tình huống tương tự, và điều gì đã làm việc cho họ?

Tôi nhận ra đây không phải là tình huống một kích cỡ phù hợp với tất cả, nhưng tôi sẵn sàng đưa ra nhiều cách tiếp cận.

Tất cả chúng ta đều làm việc trong một khu vực chung, các nhà phát triển không có văn phòng / tủ riêng lẻ.

Vì nó đã được thảo luận trong các câu trả lời khác tại sao lập trình cặp không phải là giải pháp cho bạn , tôi sẽ thảo luận về những gì chúng tôi hiện đang thử nghiệm và hài lòng với kết quả.

Theo quan điểm của tôi, những gì bạn có thể làm để tăng sự hợp tác là có hai người cùng tham gia vào mỗi dự án. Mỗi người trong số họ làm việc trên một phần khác nhau của dự án, nhưng vì những phần này phải được tích hợp nên hai nhà phát triển phải hợp tác. Điều này cũng yêu cầu hai lập trình viên thảo luận về kiến ​​trúc (lớp và giao diện) của dự án, và sau đó quyết định đảm nhận các vai trò khác nhau.

Và, nếu cách tiếp cận này, giới hạn số lượng dự án mà công ty bạn có thể xử lý tại một thời điểm, bạn có thể chỉ định đồng thời hai dự án hợp tác này.

Gần đây chúng tôi đã thử nghiệm phương pháp này, có một trong số họ phát triển các mô hình + tích hợp với apis và các lập trình viên khác xử lý các quan điểm và bộ điều khiển . Chúng tôi đã tìm thấy những lợi thế sau của cài đặt này:

1. Cấu trúc mã cho kết quả theo cách tốt hơn nhiều so với việc chỉ có một người đang làm việc trên tất cả các khía cạnh của dự án.
2. Chúng tôi không phải nhắc họ về việc cam kết mã vào kho lưu trữ, v.v.
3. Họ phải nỗ lực để kiểm tra mã của nhau, thay vì chỉ dựa vào QA chuyên dụng của chúng tôi cho nó.

Theo tôi, lập trình cặp không phải là giải pháp cho vấn đề bạn nêu ra.

Có hai vai trò riêng biệt trong một chương trình cặp. Người quan sát có mặt để xem xét và phản hồi về mã được viết bởi trình điều khiển . Nếu bạn đang cố gắng truyền đạt ý tưởng để cải thiện các quyết định mà các lập trình viên cơ sở của bạn đang đưa ra, tôi đặt câu hỏi về việc bạn có thể thấy khả năng của họ như thế nào để xem xét nghiêm túc mã bạn đang viết khi bạn thực hiện vai trò của người lái xe.

Không có động lực này, lợi ích của lập trình cặp sẽ bị mất.

Là lập trình viên cao cấp, tôi sẽ đề nghị bạn xem xét một chương trình đào tạo và phát triển nhân viên mạnh mẽ hơn với sếp của bạn. Lập trình viên cơ sở của bạn nên được cung cấp một khuôn khổ để cải thiện kỹ năng của họ. Thông thường, bạn có thể sử dụng các phương pháp như khai sáng, viết tài liệu tiêu chuẩn mã hóa, tách các tác vụ độc lập khỏi công việc của chính bạn và đảm bảo các quy trình xem xét mã phù hợp được thực hiện.

TL; DR : Tôi không nghĩ lập trình cặp sẽ phù hợp với bạn. Thay vào đó, bạn nên cố gắng khiến mọi người quan tâm về chất lượng lâu dài của mã của họ và khiến họ muốn tìm câu trả lời. Điều này phải được thực hiện không chính thức.

Về văn hóa và chất lượng

Tôi cảm thấy vấn đề này không phải là về phương pháp lập trình mà là về văn hóa . Theo kinh nghiệm của tôi, văn hóa có thể chỉ đạo, nhưng hiếm khi bằng cách nói với mọi người về nó. Đó là, cố gắng tạo ra một quy trình công việc nhất định đối với những người không tiến hóa tự nhiên hoặc quá xa với thực tiễn hiện tại chắc chắn sẽ có những hậu quả tiêu cực.

Nói cách khác, bạn không muốn trông giống như người phù hợp với những từ thông dụng mới nhất, ngay cả khi cuối cùng bạn cũng vậy. Hầu hết các lập trình viên mà tôi biết sẽ đánh dấu bạn là tiếng ồn nền. Đừng là một con ong công ty.

Theo tôi, câu hỏi chính bạn nên tự hỏi mình là "tôi có hài lòng với chất lượng và giá trị kinh doanh của mã mà tổ chức của tôi đưa ra không?" và nếu câu trả lời là tiêu cực, bạn nên hỏi "làm thế nào để tôi xoay cái này?".

Cuối cùng, chất lượng và giá trị là định nghĩa của con người mà chỉ bạn hoặc người khác trong tổ chức của bạn có thể (và nên) nghĩ đến.

Lập trình cặp và quản lý vi mô

Vì vậy, có nguy cơ nghe có vẻ hơi khó khăn và gay gắt, đối với tôi, việc đọc về lập trình cặp thực sự khiến bạn phải suy nghĩ về một số hình thức quản lý vi mô , hoặc ngược lại. MM là một công thức chắc chắn để xa lánh hầu hết mọi người.

Để bảo vệ lập trình cặp: lập trình cặp không phải là về một người nào đó nhìn qua vai của người khác. Đó là vi mô như quản lý được. PP là về việc sử dụng hai tâm trí để suy nghĩ về hai cấp độ cùng một lúc - một người xử lý các vấn đề hình ảnh lớn , cấp độ cao trong khi người còn lại quan tâm đến các loại hạt và bu lông cần thiết để sản xuất mã làm việc. Và theo ý kiến ​​khiêm tốn của tôi, nó hiếm khi hoạt động tốt nếu hai người tham gia không ở vị trí để chuyển đổi địa điểm. Họ phải có đủ kinh nghiệm tương tự để có một kho khái niệm chuyên nghiệp tương tự và một từ vựng chuyên nghiệp được chia sẻ (chúng tôi không liên quan đến tâm trí - tuy nhiên , muhahaha).

Đối với tình huống của bạn, tôi sẽ nói vì bạn là một nhóm nhỏ và bạn là người duy nhất có kinh nghiệm thực sự (đó là những gì bài đăng của bạn giống với tôi), lập trình cặp hoặc xem lại hầu hết các mã trong hầu hết thời gian 't làm việc. Bạn chỉ có 24 giờ một ngày. Thay vào đó, một số giải pháp bạn có thể xem xét:

• Khuyến khích họ tham gia SO theo thẻ ngôn ngữ phù hợp hoặc đăng một số đoạn mã để xem xét trên Code Review SE. Bắt đầu một cuộc thi không chính thức về việc ai có thể đạt được nhiều điểm đại diện SO nhất mỗi tuần.

  SO có thể làm nên điều kỳ diệu cho các nhà phát triển newbie vì nó cung cấp phản hồi liên tục và theo nhịp đập của cộng đồng.

• Hãy xem một số mã họ đăng ký và thách thức chúng một cách không chính thức với một số câu hỏi liên quan đến sự phát triển lâu dài của nó. Hầu hết các lập trình viên mới bắt đầu chỉ đơn giản là không quen với việc nghĩ về việc làm cho mã của họ có thể đọc và duy trì được. Khi bạn đưa những vấn đề đó vào đầu họ, họ sẽ tự tìm kiếm thêm thông tin, từ bạn hoặc các nguồn khác.

Tôi không nghĩ rằng lập trình cặp là thứ sẽ giúp bạn trong môi trường của bạn. Không phải là nó sẽ không giúp nâng cao các nhà phát triển ít kinh nghiệm về kỹ năng - thậm chí còn có một câu hỏi của các lập trình viên về lập trình cặp với các kỹ sư ở các cấp độ kỹ năng khác nhau . Mặc dù có những lợi ích như chia sẻ kiến ​​thức và ít lỗi hơn, lập trình cặp đòi hỏi đầu tư thời gian lớn hơn. Với một nhóm gồm ba nhà phát triển và chỉ có bốn người có nền tảng / kinh nghiệm phát triển, việc duy trì thói quen lập trình cặp có vẻ như sẽ khó khăn.

Tôi nghĩ rằng một sự thay thế tốt hơn trong tình huống của bạn là đánh giá mã, đặc biệt nếu bạn điều chỉnh chúng phù hợp. Đánh giá mã có thể bao gồm bất cứ điều gì từ một người nhìn qua một chút mã và cung cấp phản hồi cho nhiều người (thậm chí cả nhóm) trong một phòng trong một hoặc hai giờ để xem qua toàn bộ thiết kế và triển khai của một thành phần. Chúng có thể được thay đổi khi thích hợp cho công việc đang được thực hiện, đặc biệt là dựa trên kiến ​​thức, kinh nghiệm và nhu cầu của nhóm. Bạn vẫn có thể có được khía cạnh chia sẻ kiến ​​thức bằng cách cho nhiều người tham gia đánh giá cho các mục đích tìm kiếm vấn đề, đưa ra đề xuất và thu thập kiến ​​thức bằng cách đọc kết quả đánh giá để kết hợp các nhận xét vào công việc của họ, trước khi họ xem xét .

Câu hỏi của tôi là liệu có ai từng gặp phải trường hợp tương tự không, và điều gì đã làm việc cho họ.

Vì bạn đang mời trải nghiệm đây là những gì tôi đã làm. Tôi chọn cách tiếp cận rủi ro thấp và yêu cầu một người trẻ hơn tôi hàng chục tuổi dành thời gian làm việc cùng nhau. Chúng tôi không dán nhãn cho hoạt động. Không ai, ngoại trừ tôi, biết chúng tôi đang thử một kỹ thuật mới.

Tôi không biết chính xác những chi tiết liên quan, nhưng quá trình này hoạt động rất tốt. Anh ấy muốn được cố vấn, đó là điều mà tôi không có gợi ý trước. Vì vậy, nó đã mở giao tiếp theo cả hai hướng theo một cách rất tích cực.

Thực tế, tôi (với tư cách là nhà phát triển tiên tiến nhất) yêu cầu ý kiến ​​/ giúp đỡ của người khác nhiều hơn họ, vì tôi coi trọng đầu vào của một con mắt bên ngoài.

Có vẻ như bạn có thể đóng khung này là sự tiến triển hợp lý của những gì bạn đang làm.

Vài tháng sau khi nêu câu hỏi này, tôi phải nói rằng tôi hài lòng với kết quả của chúng tôi. Nhưng nó không chính xác là cái tôi đã chấp nhận lúc đầu. Hãy nhớ rằng đây là nhóm nhỏ, vì vậy giải pháp này sẽ không phù hợp với tất cả mọi người.

Tôi thấy tốt nhất là để mọi người tự làm việc. Và theo thời gian, chúng tôi đã phát triển niềm tin vào nhau, nếu chúng tôi gặp phải vấn đề, chúng tôi gọi những người khác đến trợ giúp. Tôi không nghĩ có ai muốn làm việc với ai đó đang trông chừng vai họ. Thỉnh thoảng tôi ngồi sau một ai đó và đôi khi giúp họ vượt qua một vấn đề mà không được mời. Đôi khi tôi không có gì để thêm, và tôi có thể làm phiền họ một chút. Nhưng họ hiểu rằng tôi không ở đó để đàn áp họ. Tôi chủ yếu ở đó để nghỉ ngơi từ những gì tôi đang làm và giới thiệu một chút về sự hợp tác.

Những gì tôi đã tìm thấy là những người ĐÚNG theo thời gian (trong một nhóm nhỏ) nhận và đồng bộ hóa với những người khác đang làm. Không cần phải quản lý vi mô hoặc nói với ai đó những gì họ đang làm sai mọi lúc.

Thỉnh thoảng, ngồi xuống với ai đó và giải quyết vấn đề, dù bạn là chuyên gia hay ai đó đang học, hoặc cả hai. Giải thích lý do tại sao bạn sẽ hoặc không làm điều gì đó trái ngược với cách khác. Ý tưởng tốt thường bắt kịp, trong khi những người khác bị bỏ lại phía sau. Và vào cuối ngày, bạn có một nhóm người làm việc hiệu quả, gắn kết, những người có thể đang làm việc trên những thứ khác nhau nhưng chia sẻ một mục đích chung.