Thực hành tốt nhất để làm việc với nhiều lập trình viên


9

Tôi nghĩ rằng hầu hết các lập trình viên thích làm việc solo trong các dự án, ngay cả khi điều đó không khả thi. Tôi thích làm việc một mình, thậm chí bên ngoài các dự án lập trình. Khi làm việc với các nhà phát triển khác, tôi thường thấy rằng

  • Tôi không thích định dạng hoặc quy ước của họ (chẳng hạn như tên biến hoặc phương thức)
  • Tôi không hiểu rõ về cách họ viết mã hoạt động, mà tôi sẽ có nếu tôi tự viết nó
  • Tôi nghĩ có một cách tốt hơn hoặc hiệu quả hơn để thực hiện một cái gì đó họ đã viết

Các cách tốt nhất để khắc phục các vấn đề này và bất kỳ vấn đề nhóm tương tự nào khác cho một dự án với 4-5 lập trình viên là gì?


Câu hỏi rất hay. Tôi đã suy nghĩ điều tương tự; đặc biệt là khi bạn có ai đó ở trên bạn, vì thiếu nhiều điều khoản khác, là không đủ năng lực.

"tốt hơn hoặc hiệu quả hơn" - có lẽ, nhưng tại sao bạn không tìm ra trước khi họ bắt đầu thực hiện kém hơn, kém hiệu quả hơn?

-1: Câu hỏi này rất rộng.
Jim G.

Cũng lưu ý, đó là BẠN trách nhiệm để thực hiện một nỗ lực để hiểu người khác mã.

Câu trả lời:


20

Chỉ có một cách khắc phục những vấn đề đó. Đó là "Truyền thông". Các vấn đề bạn mô tả là do các lập trình viên không nói chuyện với nhau. Nếu bạn đã thảo luận điều gì sẽ là cách tốt nhất hoặc hiệu quả nhất để giải quyết một nhiệm vụ thì nó sẽ được thực hiện theo cách bạn muốn. Hơn nữa bạn có thể đồng ý về định dạng và quy ước.

Để hiểu được phần mã của họ, bạn cần có các đánh giá mã hàng tuần, nơi bạn thảo luận về mã của mọi người. Sau đó, bạn có thể đặt câu hỏi trong khi họ trình bày công việc của mình và điều này giúp ích rất nhiều với việc tăng chất lượng mã của mọi người.


2
+1 để liên lạc. Rất nhiều câu hỏi ở đây có thể được trả lời bằng một câu đơn giản "Hãy nói với họ về điều đó"
Ian

Đối với tôi, OP dường như không chỉ gặp vấn đề về giao tiếp mà dường như không có khả năng chấp nhận có nhiều cách khác để làm những việc khác ngoài cách anh ấy thích và từ chối làm việc với bất kỳ hệ thống nào khác ngoài hệ thống ưa thích của anh ấy.
năm11

Lập trình +1 (hoặc bất kỳ công việc trí óc nào) là khoảng 5% sản xuất thực tế, 35% giải quyết vấn đề logic và 60% giải quyết vấn đề xã hội.
JF Dion

9

Tôi thích làm việc với một nhóm. Khó khăn là để làm việc hiệu quả với một nhóm, tất cả các thành viên trong nhóm phải thực sự làm việc cùng nhau, không chỉ làm việc riêng trên cùng một dự án.

Bạn cần thảo luận về những lý do tại sao bạn thích một quy ước mã hóa hơn một quy ước khác, và sau đó tất cả đồng ý về một bộ quy ước, cho dù chúng có phải là sở thích cá nhân của bạn hay không. Dù chúng là gì, bạn sẽ quen với chúng và đánh giá cao sự nhất quán.

Bạn nên xem xét và phê bình mã của nhau. Trên thực tế, có lẽ bạn nên lập trình theo cặp hầu hết thời gian, nhưng tôi nghi ngờ bạn sẽ tin tôi về điều đó, vì vậy chỉ cần xem lại mã của nhau. Không có đoạn mã nào được coi là "hoàn thành" cho đến khi một lập trình viên khác đã xem xét nó và đảm bảo rằng nó sẽ dễ hiểu đối với người tiếp theo cần duy trì nó.

Tìm kiếm lời bào chữa nói chuyện với nhau và đặt câu hỏi khi bạn đang viết mã. Nếu bạn thấy mình đang cố gắng chọn giữa 2 hoặc nhiều cách để tấn công một vấn đề, ngay cả khi bạn nghĩ rằng bạn biết câu trả lời tốt nhất có thể, hãy kiểm tra sự tỉnh táo từ một trong những nhà phát triển khác. Cả hai bạn sẽ học được điều gì đó từ cuộc trò chuyện và bạn sẽ hiểu thêm về khái niệm được chia sẻ về cách mã được kết hợp với nhau.

Có một cuộc họp ngắn mỗi ngày, vì vậy mọi người có thể nói những gì họ đã và đang diễn ra. Bằng cách đó, mọi người sẽ có ý thức tốt hơn về tình trạng của tất cả các bit công việc đang diễn ra và cách nó được tiếp cận.


7

Bạn không sở hữu mã - với tư cách là một nhóm bạn có thể chọn quy ước mã hóa hay không. Bạn sẽ không luôn luôn theo cách của bạn, chỉ cần học cách thích nghi.

Bạn sẽ không bao giờ cảm thấy thoải mái với mã người khác. Trong XP đây là lý do lập trình cặp đẩy. Nhưng thông thường cách tốt nhất (như với mọi thứ khác) là đào sâu và tìm hiểu nó.

Nếu bạn có một mã hiệu quả hơn hoặc tốt hơn (Có thể đọc là CÁCH quan trọng hơn hiệu quả - xem điểm trước đó) thì bạn nên thảo luận với họ.

Đây là một nghề nghiệp và bạn không sở hữu những gì bạn làm. Bạn sẽ phải làm việc với nhiều người, làm quen với nó hoặc giỏi đến mức bạn có thể tự làm tất cả và tài trợ cho các dự án của riêng bạn.

Đó là một nghề nghiệp, không vui vẻ gì - nếu công việc của bạn là sửa chữa mái nhà vào giữa mùa hè và họ bảo bạn làm điều đó theo cách bạn không thích bởi vì làm việc đó theo cách dễ dàng hơn như một phi hành đoàn, bạn chỉ cần làm nó Giai đoạn = Stage.


Tôi đồng ý với tất cả mọi thứ ngoại trừ "Có thể đọc là CÁCH quan trọng hơn hiệu quả", điều này KHÔNG đúng với mã sql cơ sở dữ liệu, hiệu quả trong cơ sở dữ liệu là rất quan trọng. Nếu bạn quen viết mã hiệu quả, nó sẽ trở nên dễ đọc hơn rất nhanh.
HLGEM

@HLGEM Mã DB không hiệu quả là khủng khiếp, nhưng mã phải không thể đọc được để có hiệu quả hay bạn có thể làm cho nó vừa dễ đọc vừa hiệu quả? Tôi đã không nói bỏ qua hiệu quả trong mọi trường hợp và tôi cũng không nói là một lập trình viên ngu ngốc (Giống như sử dụng một mảng cho một loại chèn).
Bill K

Tôi không nói là không thể đọc được nhưng hầu hết các cách hiệu quả nhất để viết truy vấn thường có vẻ phức tạp hơn đối với những người không phải là chuyên gia cơ sở dữ liệu, vì vậy họ có xu hướng viết mã trông "thanh lịch" hơn và gặp rắc rối với hiệu suất.
HLGEM

@HLGEM Tôi không thích cụm từ "Elegant" bởi vì nó thường có nghĩa là ngắn gọn mà hoàn toàn không liên quan đến việc có thể đọc được. Tôi cho rằng tốt nhất nên nói đó là "Giải pháp dễ đọc nhất phù hợp với yêu cầu của vấn đề" trong đó hiệu suất có thể được bao gồm trong các yêu cầu. Quan điểm của tôi là nếu hiệu suất không nằm trong các yêu cầu (nếu nó đáp ứng các yêu cầu) thì khả năng đọc sẽ được ưu tiên hơn bất cứ thứ gì khác, nhưng tất nhiên, nó phải đáp ứng các yêu cầu.
Bill K

Buồn cười tôi không thích thuật ngữ tao nhã quá. Tôi nghĩ rằng tất cả chúng ta quá thường xuyên hy sinh hiệu quả và hiệu quả của người dùng để đáp ứng tầm nhìn của ai đó về mức độ đẹp của mã. Thanh lịch không nên hiệu quả và hiệu quả. Nhà phát triển xem mã đó có thể là bảy giờ trong năm, người dùng chạy mã đó mỗi ngày nhiều lần trong ngày. Chúng ta không nên viết chỉ cho các giá trị thẩm mỹ của nhà phát triển. Tôi thích định nghĩa của bạn tốt hơn nhiều. Với lời giải thích thêm của bạn, tôi hoàn toàn đồng ý với bạn.
HLGEM

5

Hỏi họ "tại sao" , nhưng lịch sự. Các lập trình viên thường rất vui khi giải thích lý lẽ của họ và trừ khi câu trả lời là "Đó là cách tôi luôn làm", bạn có khả năng sẽ học được điều gì đó hữu ích. Ví dụ, sự khác biệt giữa ký hiệu Hungary "tốt" và "xấu", ưu điểm của các quy ước đặt tên khác nhau và tại sao thuật toán được chọn là đủ tốt cho nhiệm vụ trong tay.


3

Tôi chỉ có một vài suy nghĩ. Hầu hết các câu trả lời khác dường như đã đề cập đến khía cạnh giao tiếp của vấn đề này khá tốt, nhưng tôi muốn giải quyết từng điểm đạn bạn thực hiện với một ý nghĩ hoặc 2 của riêng tôi:

Tôi không thích định dạng hoặc quy ước của họ (chẳng hạn như tên biến hoặc phương thức)

Đây là một sự tự phụ mà bạn không thể thực sự có được. Có lẽ có 20 người không thích định dạng hoặc quy ước của bạn. Nếu bạn không phải là một phần của quá trình quyết định những điều này, thì bạn cần phải vượt qua nó và học cách thích nghi. Nếu bạn là một phần của quy trình (hoặc có thể trong tương lai), thì hãy đưa mối quan tâm của bạn đến các nhà phát triển khác. Đừng chỉ phàn nàn, mặc dù. Có giải pháp / giải pháp thay thế đã được vạch ra và sẵn sàng để đi.

Tôi không hiểu rõ về cách họ viết mã hoạt động, mà tôi sẽ có nếu tôi tự viết nó

Không, bạn sẽ không. Nếu bạn đang đưa ra yêu cầu này thì bạn đã không làm việc trong một môi trường thay đổi nhiều nhịp độ. Tôi đã nhận được mã mà tôi đã viết 6 tháng trước mà tôi không thể hiểu chỉ bằng cách liếc nhìn nó. Nếu không phải vì nó được viết với một vài câu nói cá nhân thì tôi thậm chí sẽ không thực sự biết nó là của tôi. Nó có thể đòi hỏi nhiều nỗ lực hơn để tái thiết kế công việc của người khác, nhưng đừng nhầm lẫn, bạn sẽ tái thiết kế nó để hiểu nó sau này bất kể ai đã viết nó.

Tôi nghĩ có một cách tốt hơn hoặc hiệu quả hơn để thực hiện một cái gì đó họ đã viết

Tuyệt vời. Mọi đội đều yêu thích sự cải tiến và hiệu quả. Đưa nó lên cho các nhà phát triển đồng bào của bạn. Nếu có một nhà phát triển hoặc kiến ​​trúc sư cao cấp được chỉ định ở trên bạn, hãy cho anh ta biết. Chia sẻ ý tưởng của bạn với nhóm một cách cởi mở và tự do. Hãy chuẩn bị để chấp nhận ý tưởng của người khác là tốt. Tôi thấy rất nhiều người nói những điều tương tự như bạn đang nói ở đây, nhưng ý nghĩa thực sự của họ là "Cách của tôi tốt hơn và tất cả bạn chỉ có thể mút nó. Làm theo cách của tôi hoặc bạn đều là những cái đầu khó hiểu". Đừng là anh chàng đó. Hãy sẵn sàng thay đổi như bạn mong đợi ở người khác.


1

Bây giờ tôi đã nghĩ về những câu hỏi này. Tôi là trưởng nhóm và đang làm việc với 2 lập trình viên khác. Một trong những lập trình viên có phong cách rất giống tôi - không giống nhau, nhưng đủ gần. Tôi không cảm thấy nó đảm bảo bất kỳ thay đổi nào từ phía anh ấy. Điểm bắt đầu một cái gì đó vì lợi ích của các quy ước lập bảng khác nhau hoặc tên biến.

Nhà phát triển khác là lập trình viên ac (chúng tôi là lập trình viên vb.net làm việc trong một dự án .net). Anh ta viết mã vb như thể đó là mã c (tôi cho rằng nếu các vai trò bị đảo ngược, chúng ta sẽ viết mã c như thể đó là vb). Tôi đã có một số vấn đề với điều này. Nhưng sau khi tôi nghĩ về nó một lúc. Các vấn đề tôi gặp phải thực sự chỉ là một cảm giác không thoải mái mà mã trông lạ lùng mang lại cho tôi. Thực sự không có gì sai với mã của anh ấy. Mã của anh ấy sạch sẽ và hoạt động rất tốt. Bên cạnh đó, mã sẽ được trừu tượng hóa đằng sau giao diện lớp mà anh ta tiếp xúc với phần còn lại của chương trình. Vì vậy, cuối cùng, phong cách mã hóa không thực sự quan trọng đối với chúng tôi. Miễn là chương trình là chính xác và các ý kiến ​​là hợp lý. Tất cả chúng ta đều đủ thông minh (ít nhất là tôi hy vọng), việc gỡ lỗi không quá khó khăn.

Bây giờ sẽ là một câu chuyện khác nếu anh ấy viết mã trong c # và chúng tôi đã viết mã trên vb.net. Chúng tôi vẫn có thể quản lý, nhưng nó sẽ khó khăn hơn.

Cá nhân tôi nghĩ rằng điều quan trọng hơn nhiều là các thành viên trong nhóm sử dụng một quy ước mã hóa mà họ hài lòng và thoải mái. Điều này sẽ có nghĩa là chúng được mã hóa một cách hiệu quả thay vì tham khảo một số hướng dẫn về phong cách cho chúng biết có bao nhiêu tab chúng cần để thụt một hàm.

Điều đó không có nghĩa là họ được tự do làm theo ý muốn với các trường hợp hoặc yêu cầu sử dụng ứng dụng - chúng được đặt bởi khách hàng.


1

Ôi làm ơn! Các tiêu chuẩn mã hóa giống như các đối số phá thai: mọi người đều có một (ngoại trừ tôi, tôi không có ý kiến ​​thực sự nào về việc phá thai ngoài việc bạn không muốn, không có nó), mọi người đều nghĩ rằng họ là hoàn toàn chính xác và mọi người đều nghĩ mọi người khác bốc mùi.

Tôi sử dụng các phương pháp khác nhau vì tôi thấy chúng dễ đọc hơn. Ví dụ: một khối kiểm tra trong PHP tôi sẽ viết như thế này:

if (điều kiện) {
  câu lệnh;
} [tùy chọn khác hoặc khác]

Nhưng nếu tôi viết một khối trong Pascal thì tôi sẽ làm điều này:

nếu (điều kiện)
  bắt đầu

  kết thúc;

Nó phụ thuộc vào ngôn ngữ, đối với tôi, việc đọc theo cách này cho cả hai dễ dàng hơn. Nhưng nếu ai đó muốn đặt {trên dòng sau nếu trong PHP tôi thực sự không có vấn đề gì.


1
Bạn muốn mọi người trong nhóm của mình sử dụng cùng một tiêu chuẩn để tránh gây ô nhiễm cho điều khiển phiên bản khác với dấu ngoặc nhảy giữa các dòng.

0

Mặc dù tôi có thể hiểu sự thất vọng liên quan đến việc có mã "nước ngoài", nhưng có hai cơ hội để bạn trưởng thành với "chướng ngại vật" này

  1. Mọi nhà phát triển đều phải học cách trải qua "cuộc chiến giằng co", và ý tôi là tìm cách để có được một tiêu chuẩn mã hóa chung. Học cách nói rõ tại sao bạn thích một số kỹ thuật nhất định, nhưng quan trọng hơn là học cách lắng nghe lý do tại sao người khác có quan điểm khác. Sau đó học cách đặt một số của bạn xuống vì lợi ích của nhóm / dự án.

  2. Tuy nhiên, điều gì sẽ có giá trị lớn hơn nhiều đối với bạn về lâu dài sẽ là việc học cách đọc mã người khác. Đối với điều này, bạn chỉ cần vượt qua nó và không tránh nó. Bạn thậm chí có thể thấy rằng bạn học được rất nhiều.


0

Tôi tin rằng một nhóm càng lớn, thử nghiệm đơn vị càng quan trọng.

  • Hãy chắc chắn rằng mã bạn tự viết được bao phủ bởi các bài kiểm tra đơn vị.
  • Cố gắng thuyết phục các thành viên khác trong nhóm viết bài kiểm tra.

Sống với mã (của chính bạn và của người khác) sẽ dễ dàng hơn khi bạn có các bài kiểm tra bao gồm mã. Điều này đúng ngay cả với mã mà bạn không thích.


0

Các tốt nhất câu trả lời là để tìm một đội bóng có quá trình suy nghĩ phù hợp với riêng bạn, vì vậy bạn không cần phải thỏa hiệp.

Một câu trả lời thực tế là để đối phó với nó tốt nhất có thể. Nếu đó chỉ là vấn đề của kiểu mã khác nhau (ví dụ: niềng răng cùng dòng so với dòng tiếp theo) thì đó không phải là vấn đề lớn, mặc dù tôi hiểu rằng thật bực bội nếu mọi người không tuân theo các nguyên tắc cho ngôn ngữ họ đang sử dụng. Nếu đó là một cái gì đó giống như các tiêu chuẩn mã hóa hoàn toàn vô nghĩa mà không có ý nghĩa gì (ví dụ ký hiệu tiếng Hungary không cần thiết, thì SoMeweIrDnAmInGsTyLe, tất cả các biến phải dài không quá 8 ký tự, v.v.) mã không có đầu mối hoặc chỉ là hàng hóa với những gì đã có trước đó thay vì đủ thông minh để muốn cải thiện nó.


-1

Trước hết, điều chỉnh lại phong cách mã hóa của tôi: khoảng trắng. Từ lâu, một số chú hề đã viết một bài báo đùa về các thực tiễn tốt nhất đưa ra các ví dụ mã với như 12 tab đầy đủ của khoảng trắng ở mọi nơi anh ta có thể; làm cho mã không thể đọc được nếu không có màn hình rộng 12 feet hoặc cỡ chữ .0001. Rất nhiều lập trình viên cho rằng nó đáng tin cậy và bắt đầu thực hiện nó - mặc dù nó thực sự rõ ràng là không thực hành tốt. Nó làm tôi điên. Thôi nào các bạn, tôi nói, bạn thông minh hơn thế. Khoảng trắng 50% trở lên trên trang 240 cột không có ý nghĩa gì. Đặt dấu ngoặc nhọn đầu tiên trên cùng một dòng với chữ ký hàm hoặc lớp (có một hoặc hai dấu cách, không phải là một tab hoặc hai ở giữa). Sử dụng 3 khoảng trắng để thụt lề cho các cấp mã (5 nếu bạn có thành viên nhóm mù một phần). Sau đó sử dụng một dòng trống ở đây và ở đó trong mã để đặt mọi thứ trong các khối logic nhỏ hơn.

Đây là một ví dụ khác về một cái gì đó xương đầu. Trước tiên tôi sẽ nói với bạn điều này không đến từ một người dí dỏm thiếu kinh nghiệm. Đó là một số mã rất tốt bởi một anh chàng có thể có được một kỹ thuật rất tiên tiến hoạt động trong khi hầu hết phần còn lại của thế giới vẫn đang gãi đầu về nó. Đây là những gì làm tôi bực bội. Tại sao các lập trình viên giỏi rất quan tâm đến việc định dạng mã của họ?

    for (Iterator<Byte> iterator = collection.iterator(); iterator
            .hasNext();) {
        byteArray[i++] = iterator.next();
    }

Bây giờ chỉ cần nhìn vào định dạng của điều kiện. Nếu bạn thực sự nghĩ về nó, đó không phải là một nơi hoàn toàn phi logic để đặt một ngắt dòng? Đối với một người, tôi có nhiều không gian để xem toàn bộ cho ... {trên một dòng. (May mắn thay, anh chàng này không sử dụng nhiều tab để thụt lề.) Nhưng nếu anh ta hoàn toàn không thể sống mà không phá vỡ nó, tại sao lại có một thông số chức năng? Có một dấu phân cách hoàn toàn tốt ngay trước đó - dấu chấm phẩy - sẽ có ý nghĩa hơn như một điểm dừng. Phiếu bầu của tôi là đặt toàn bộ điều kiện và mở {(đi cùng với for) trên cùng một dòng. Anh ấy cũng kết thúc tốt đẹp - dễ dàng để phù hợp với cú đúp kết thúc với "for" đã mở. (Một số người - và các công cụ (Điều đó có thừa không?) - cũng muốn đặt nó ở những nơi xa lạ.)

Thứ hai - lưu ý về trọng tâm của từng chuyên gia lập trình viên và nếu có sự khác biệt đáng kể, hãy chắc chắn rằng điều đó được phản ánh trong phần nào của mã mà mỗi lập trình viên làm việc. Một chuyên gia về điều khiển công nghiệp về robot, một kỹ sư chủ yếu làm việc trên các bit toán học phức tạp và anh chàng có bằng CS, người gây ấn tượng với việc xây dựng mã hoàn toàn tối nghĩa (dường như càng khó hiểu, càng phức tạp, phải không?) sẽ viết mã khác nhau. Khi có những khác biệt đáng kể này, hãy chia nhỏ công việc để mỗi sức mạnh riêng phù hợp với công việc.

Khi không có sự khác biệt như vậy, hãy đồng ý về phong cách mã hóa và trong mọi trường hợp - xem lại mã, xem lại mã, xem xét mã. Thẳng thắn mà nói, tôi đã trải qua rất nhiều mã spaghetti cẩu thả trong đời (giảm 12 lần trong việc gỡ lỗi và thay đổi bởi nhóm bảo trì, hoặc kết quả của việc tích hợp mắt gà) và tôi đang trên đường trở thành một chuyên gia về mã sau 2 phút nói chuyện với người cuối cùng đã làm việc với nó. (Lưu ý bên lề: Trên thực tế, có một điểm mà tại đó việc viết lại mã tốt hơn là tiếp tục thích ứng.)

Cá nhân, tôi thích làm việc ở nhà một mình là tốt. Tôi chưa bao giờ gặp một lập trình viên thích hoặc làm việc tốt hơn trong một hình khối được bao quanh bởi rất nhiều lập trình viên, các cuộc thảo luận và gián đoạn khác. Nhưng bạn phải làm quen với việc làm việc trong một nhóm và điều đó có nghĩa là dành thời gian để cùng nhau thảo luận (không phải chiến đấu) những gì bạn đang làm. Đó thực sự là một phần của công việc - nó thực sự là. Tốt hơn nhiều để chấp nhận nó và làm nó một cách có hệ thống, hiệu quả và hiệu quả. Và trong khi chúng tôi làm việc đó - đó cũng là một phần của công việc dành thời gian chuyển kiến ​​thức và thông tin cho những người viết tài liệu (một số trong đó bạn có thể cần phải tự viết). Và khi bạn đủ kinh nghiệm để nâng cao trách nhiệm của mình, bạn thậm chí có thể thấy mình trò chuyện thường xuyên hơn với các nhà quản lý và người tiếp thị, v.v.

Viết mã một mình là một sở thích. Kỹ thuật phần mềm chuyên nghiệp là một nghề nghiệp nhiều mặt.


Và điều khác; khi bạn chỉ có một loạt các dấu ngoặc nhọn, sẽ không có ý nghĩa gì khi đặt các dòng trống giữa chúng.
Roger F. Gay

1
"Một loạt các niềng răng đóng cửa" -> ứng cử viên cho bao thanh toán phương pháp được đặt tên.

Tại sao? Rất dễ dàng để kết thúc với 3; giống như khi bit cuối cùng của một phương thức là một điều kiện và sau đó đóng phương thức và lớp của bạn.
Roger F. Gay

@Roger, bạn sẽ đặt tên cho "ba liên tiếp" một loạt?

Vâng, và tôi đã có.
Roger F. Gay
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.