* Chủ sở hữu mã * hệ thống: đó có phải là một cách hiệu quả? [đóng cửa]

Có một nhà phát triển mới trong nhóm của chúng tôi. Một phương pháp nhanh được sử dụng tại công ty chúng tôi. Nhưng nhà phát triển có một kinh nghiệm khác: anh ta cho rằng các phần cụ thể của mã phải được gán cho các nhà phát triển cụ thể. Vì vậy, nếu một nhà phát triển đã tạo ra một thủ tục chương trình hoặc mô-đun, điều đó sẽ được coi là bình thường rằng tất cả các thay đổi của thủ tục / mô-đun sẽ chỉ do anh ta thực hiện.

Về mặt tích cực, được cho là với phương pháp đề xuất, chúng tôi tiết kiệm thời gian phát triển chung, bởi vì mỗi nhà phát triển biết rõ phần mã của mình và sửa lỗi nhanh. Nhược điểm là các nhà phát triển không biết hệ thống hoàn toàn.

Bạn có nghĩ rằng cách tiếp cận sẽ hoạt động tốt cho một hệ thống kích thước trung bình (phát triển một trang web mạng xã hội)?

Giống như rất nhiều câu hỏi trong số này, tôi nghĩ câu trả lời là:

Nó phụ thuộc

Có lý do để tin rằng việc đảm nhận vị trí mà mọi lập trình viên nên biết mọi dòng mã là sai lầm.

Nếu chúng ta giả định rằng một người nào đó có hiểu biết sâu sắc về một đoạn mã sẽ thực hiện thay đổi nhanh hơn 5 lần so với người không biết gì về nó (không phải là một bước nhảy vọt về kinh nghiệm của tôi) và mất khoảng một tháng về kinh nghiệm mã hóa để có được sự hiểu biết thực sự tốt về một mô-đun có kích thước đáng kể (cũng không phải là không hợp lý), sau đó chúng ta có thể chạy một số số (hoàn toàn không có thật và hư cấu):

• Lập trình viên A: có hiểu biết sâu sắc
• Lập trình viên B: không có

Hãy nói rằng lập trình viên A nhận được 1 đơn vị công việc được thực hiện mỗi ngày. Trong 4 tuần của 5 ngày làm việc, anh ấy / cô ấy có thể hoàn thành 20 đơn vị công việc.

Vì vậy, lập trình viên B, bắt đầu với 0,2 đơn vị công việc mỗi ngày và kết thúc với 0,96 đơn vị công việc vào ngày thứ 20 của mình (vào ngày 21, họ cũng giỏi như lập trình viên A), sẽ hoàn thành 11,6 đơn vị công việc trong cùng một Thời hạn 20 ngày. Trong tháng đó, lập trình viên B đã đạt được hiệu quả 58% so với lập trình viên A. Tuy nhiên, bây giờ bạn có một lập trình viên khác biết mô-đun đó cũng như mô-đun đầu tiên.

Tất nhiên, trong một dự án có quy mô khá, bạn có thể có ... 50 mô-đun? Vì vậy, làm quen với tất cả trong số họ mất khoảng 4 năm và điều đó có nghĩa là trung bình, lập trình viên học tập, làm việc với hiệu suất 58% so với lập trình viên A ... hmmm.

Vì vậy, hãy xem xét kịch bản này: cùng các lập trình viên, cùng một dự án (A biết tất cả và B không biết gì về nó.) Hãy nói rằng có 250 ngày làm việc trong năm. Giả sử rằng khối lượng công việc được phân phối ngẫu nhiên trên 50 mô-đun. Nếu chúng ta chia đều cả hai lập trình viên, cả A và B đều có 5 ngày làm việc trên mỗi mô-đun. A có thể thực hiện 5 đơn vị công việc trên mỗi mô-đun, nhưng B chỉ nhận được, theo mô phỏng Excel nhỏ của tôi, 1,4 đơn vị công việc được thực hiện trên mỗi mô-đun. Tổng (A + B) là 6,4 đơn vị công việc trên mỗi mô-đun. Đó là bởi vì B dành phần lớn thời gian của họ mà không có bất kỳ kỹ năng nào với mô-đun họ đang làm việc.

Trong tình huống này, sẽ tối ưu hơn khi B tập trung vào một tập hợp con mô-đun nhỏ hơn. Nếu B chỉ tập trung vào 25 mô-đun, họ nhận được 10 ngày cho mỗi mô-đun, tổng cộng 3,8 đơn vị công việc trên mỗi mô-đun. Lập trình viên A sau đó có thể dành 7 ngày cho mỗi mô-đun mà B không hoạt động và 3 ngày mỗi mô-đun làm việc trên cùng một mô-đun B. Tổng năng suất dao động từ 6,8 đến 7 đơn vị trên mỗi mô-đun, trung bình 6,9 và cao hơn đáng kể hơn 6,4 đơn vị trên mỗi mô-đun, chúng tôi đã hoàn thành khi A và B trải đều công việc.

Khi chúng tôi thu hẹp phạm vi của các mô-đun mà B hoạt động, chúng tôi thậm chí còn đạt được hiệu quả cao hơn (tới một điểm).

Đào tạo

Tôi cũng sẽ tranh luận rằng ai đó không biết nhiều về một mô-đun sẽ làm gián đoạn người làm nhiều hơn một người có nhiều kinh nghiệm hơn. Vì vậy, những con số trên không tính đến việc B càng dành nhiều thời gian cho mã mà họ không hiểu, họ càng mất nhiều thời gian hơn bằng cách đặt câu hỏi và đôi khi A phải giúp khắc phục hoặc khắc phục những gì B đã làm. Đào tạo ai đó lên là một hoạt động tốn thời gian.

Giải pháp tối ưu

Đó là lý do tại sao tôi nghĩ rằng giải pháp tối ưu phải dựa trên các câu hỏi như:

• Đội của bạn lớn cỡ nào? Liệu có ý nghĩa khi tất cả mọi người được đào tạo chéo trên mỗi phần, hoặc nếu chúng tôi có một nhóm 10 người, chúng tôi có thể đảm bảo mỗi mô-đun được ít nhất 3 người biết đến không? (Với 10 lập trình viên và 50 mô-đun, mỗi lập trình viên phải biết 15 mô-đun để có phạm vi bao phủ 3x.)
• Doanh thu nhân viên của bạn thế nào? Nếu bạn chuyển qua nhân viên trung bình 3 năm một lần và mất nhiều thời gian hơn để thực sự biết mọi ngóc ngách của hệ thống, thì họ sẽ không đủ thời gian để đào tạo tự hoàn vốn.
• Bạn có thực sự cần một chuyên gia để chẩn đoán một vấn đề? Rất nhiều người sử dụng cái cớ, "nếu người đó đi nghỉ", nhưng tôi đã được gọi nhiều lần để chẩn đoán vấn đề trong một hệ thống mà tôi không có kinh nghiệm. Có thể đúng là người có kinh nghiệm có thể tìm thấy nó nhanh hơn rất nhiều, nhưng điều đó không có nghĩa là bạn không thể sống thiếu họ trong một hoặc hai tuần. Rất ít hệ thống phần mềm có nhiệm vụ quan trọng đến mức vấn đề phải được chẩn đoán trong 1 giờ thay vì 5 giờ nếu không thế giới sẽ kết thúc. Bạn phải cân nhắc những rủi ro này.

Đó là lý do tại sao tôi nghĩ rằng "nó phụ thuộc". Bạn không muốn phân chia 20 mô-đun giữa hai lập trình viên ở giữa (10 mỗi mô-đun), vì sau đó bạn không có sự linh hoạt, nhưng bạn cũng không muốn đào tạo 10 lập trình viên trên tất cả 50 mô-đun vì bạn mất rất nhiều hiệu quả và bạn không cần nhiều dư thừa đó.

Đó là một ý tưởng khủng khiếp . Nó có thể nhanh hơn trong thời gian ngắn, nhưng nó khuyến khích mã khó hiểu được tài liệu khó hiểu vì chỉ có người viết mã đã viết nó chịu trách nhiệm duy trì nó. Khi ai đó rời công ty hoặc đi nghỉ, toàn bộ kế hoạch trở nên tồi tệ. Nó cũng làm cho việc phân bổ khối lượng công việc rất khó khăn; Điều gì xảy ra khi hai lỗi khẩn cấp xuất hiện với mã mà một lập trình viên "sở hữu"?

Bạn nên viết mã theo nhóm . Mọi người sẽ tự nhiên được phân bổ nhiệm vụ và tập trung vào một số lĩnh vực nhất định nhưng chia sẻ khối lượng công việc và làm việc cùng nhau nên được khuyến khích, không được khuyến khích.

Nó phụ thuộc vào miền của vấn đề là gì.

Nếu đó là công cụ chung (nghĩa là các hành động CRUD đơn giản, v.v.), thì tôi đồng ý với Tom Squires (bất kỳ ai cũng có thể làm việc với nó và chỉnh sửa nó).

Tuy nhiên ...

Nếu giải pháp trong câu hỏi yêu cầu chuyên môn về miền (nhiều thời gian đã được đầu tư trong quá khứ hoặc rất nhiều nghiên cứu cần được thực hiện trước khi thực hiện, vì đây là điều mà bạn liệt kê trong một yêu cầu công việc là kiến ​​thức chuyên ngành mà không phải tất cả mọi người trong dự án đều có), sau đó một chủ sở hữu chắc chắn nên được gán cho phần đó của mã. Đã nói rằng, bất cứ ai cũng có thể sửa đổi nó khi cần thiết, nhưng họ phải luôn được xem xét bởi người sở hữu khu vực đó của dự án.

Bạn không muốn để toàn bộ nhóm của mình (hoặc một số người trong nhóm) nghiên cứu và học cùng một chủ đề (các chu kỳ lãng phí). Chỉ định một chủ sở hữu, nhưng yêu cầu họ ghi lại các kiến ​​thức và thiết kế của họ và có thể yêu cầu họ thực hiện các buổi đào tạo không chính thức (hoặc chính thức, không thực sự quan trọng) về công nghệ.

Đây là một ý tưởng khủng khiếp . Tôi đã làm việc tại một công ty đã sử dụng phương pháp này và nó gần như là một công thức cho hàng đống nợ kỹ thuật . Điểm mấu chốt là hai đầu hầu như luôn luôn tốt hơn một. Tại sao? Bởi vì trừ khi bạn là một thằng ngốc, bạn biết bạn không phải là một lập trình viên hoàn hảo và bạn sẽ không nắm bắt mọi lỗi lầm bạn mắc phải. Đây là lý do tại sao bạn cần một nhóm - nhiều mắt hơn nhìn vào cùng một mã từ các quan điểm khác nhau.

Nó sôi sùng sục xuống một điều: kỷ luật . Có bao nhiêu lập trình viên đơn độc mà bạn biết ai thực sự kỷ luật trong phong cách mã hóa của họ? Khi bạn không viết mã theo kỷ luật, bạn sẽ sử dụng các phím tắt (vì bạn sẽ "sửa lỗi sau") và khả năng duy trì của mã bị ảnh hưởng. Chúng ta đều biết "sau này" không bao giờ đến. Sự thật : Khó thực hiện các phím tắt hơn khi bạn có trách nhiệm ngay lập tức với các đồng nghiệp trong nhóm. Tại sao? Bởi vì các quyết định của bạn sẽ được đặt câu hỏi và luôn khó khăn hơn để biện minh cho các phím tắt. Kết quả cuối cùng? Bạn sản xuất mã tốt hơn, dễ bảo trì hơn mà cũng mạnh mẽ hơn.

Ưu điểm là không phải ai cũng cần nghiên cứu và hiểu mọi thứ. Nhược điểm là điều đó làm cho mỗi người cần thiết cho khu vực mã riêng của họ và không ai biết cách duy trì nó.

Một thỏa hiệp sẽ có ít nhất 2 chủ sở hữu cho mỗi khu vực mã. Sau đó, một người nào đó có thể đi nghỉ mát, nhận một công việc mới hoặc nghỉ hưu và vẫn còn một người biết mã (và có thể đào tạo người thứ hai mới). Không phải ai cũng cần học mọi thứ, hiệu quả hơn một chút.

Đừng có cùng 2 (hoặc 3) người làm việc cùng nhau mọi lúc. Chuyển đổi cặp cho các khu vực khác nhau, vì vậy kiến ​​thức cũng được chia sẻ vô tình khi làm việc với một người khác trên một khu vực chương trình liên quan.

Vâng, nó là hiệu quả hơn một chút, trong ngắn hạn. Và kết thúc những lợi ích. Điều đó thậm chí không đến gần để vượt xa chi phí.

Điều gì xảy ra khi anh ấy đi nghỉ, hoặc bị ốm bất ngờ, hoặc rời khỏi, hoặc bị xe buýt hoạt động? Điều gì xảy ra khi bạn muốn uốn cong tài nguyên để có được một công việc nhanh hơn công việc khác? Làm thế nào hiệu quả có thể đánh giá mã? Làm thế nào một người quản lý, đặc biệt là một người không ở trong cơ sở mã, có thể biết liệu nhà phát triển đang làm việc chăm chỉ hay kéo len qua mắt anh ta? Ai sẽ thông báo nếu nợ kỹ thuật bắt đầu tăng lên?

Theo kinh nghiệm của tôi, những người thích làm việc theo cách này là những người săn vinh quang giỏi nhất, lười biếng nhất. Họ thích là người duy nhất bạn có thể gặp phải một vấn đề nhất định và họ thích mã của họ được giữ kín. Và họ thường thích viết mã nhanh, không quan tâm đến khả năng đọc.

Điều đó không có nghĩa là, trong một nhóm gồm 50 nhà phát triển, mọi người nên biết tất cả các mã, nhưng một nhóm 5-7 nên sở hữu một mô-đun đủ lớn để giữ cho những người đó làm việc. Không có cá nhân nên sở hữu bất cứ điều gì.

Có ít nhất ba vấn đề mà các câu trả lời khác chỉ ra; nhưng tôi muốn thử và đối xử với cả hai cùng nhau. Hai vấn đề là:

• chuyên môn : Ai đó trong nhóm có kiến ​​thức chi tiết về một lĩnh vực cụ thể; kiến thức này độc lập với việc triển khai cụ thể của miền đó trong dự án
• lãnh đạo : Mặc dù công việc xây dựng dự án có thể được chia sẻ trên nhiều nhà phát triển; lộ trình, cũng như các quyết định ngay lập tức về các chi tiết thực hiện quan trọng nằm trong tay của một thành viên nhóm cụ thể hoặc chỉ một vài thành viên của nhóm.
• mã egoless : Cách thức cụ thể mà dự án được thực hiện không phụ thuộc vào phong cách mã hóa, thực tiễn hoặc kiến ​​thức của bất kỳ nhà phát triển cụ thể nào trong nhóm; và bằng cách tuân thủ nghiêm ngặt một phong cách mã hóa nổi tiếng hoặc một đặc điểm kỹ thuật được bảo đảm tốt, bất kỳ thành viên nhóm mới nào cũng có cơ hội bình đẳng trong việc tìm hiểu các vấn đề của các dự án như các nhà phát triển có kinh nghiệm.

Khi chủ đề hoàn toàn là một chuyên môn, thành công của dự án có thể phụ thuộc vào mức độ hiểu biết cao về tên miền; nhưng nó không phụ thuộc vào kiến ​​thức của một chuyên gia cụ thể về miền đó. Các chuyên gia, mặc dù có lẽ hiếm và có giá trị, về cơ bản vẫn có thể thay thế cho nhau; một kế toán thuế có kinh nghiệm cũng hữu ích cho một dự án phần mềm lập kế hoạch thuế như một dự án khác, từ quan điểm về kiến ​​thức tên miền của họ. Vấn đề trở thành một trong những chuyên gia có thể chuyển kiến ​​thức của cô ấy đến dự án tốt như thế nào.

Khi chủ đề hoàn toàn là một trong những người lãnh đạo, thành công của dự án phụ thuộc chủ yếu vào tính nhất quán và hiểu biết sâu sắc về các quyết định của người lãnh đạo dự án; mặc dù chúng tôi có xu hướng ủng hộ các nhà lãnh đạo dự án có kinh nghiệm trong lĩnh vực này hoặc được chứng minh là người lãnh đạo dự án, điều này đôi khi chỉ là thứ yếu đối với vai trò. "Người lãnh đạo" có thể thay đổi từ ngày này sang ngày khác nếu các quyết định được đưa ra nhất quán từ trường hợp này sang trường hợp tiếp theo và mỗi quyết định được nhóm thực hiện nhanh chóng. Nếu điều này là làm việc đúng; nhiều quyết định không phải được "đưa ra" bởi người lãnh đạo dự án vì nhóm đã hiểu những quyết định nào sẽ được đưa ra.

Tôi không nghĩ câu hỏi thực sự là về mã vô ngã, nhưng thật khó để nói về quyền sở hữu mã mà không thảo luận về vấn đề này quan trọng như thế nào. Duy trì một dự án có lẽ là phần lớn hơn của chu kỳ phát triển. Cách để hiểu vấn đề này là tự hỏi điều gì sẽ xảy ra nếu một số nhà phát triển phải rời bỏ nó ngay lập tức. Điều gì sẽ xảy ra nếu toàn bộ đội phải được thay thế? Nếu dự án bị bỏ qua vì nghi ngờ phụ thuộc vào một số người chơi chính, thì bạn có nguy cơ thất bại cao. Ngay cả khi bạn không bao giờ mất một thành viên trong nhóm, thực tế đơn giản là cần một hoặc một vài nhà phát triển để thúc đẩy dự án có nghĩa là bạn có thể không làm việc hiệu quả như bạn có thể nếu có nhiều nhà phát triển hơn tham gia.

Quyền sở hữu mã có xu hướng ngăn chặn tái cấu trúc, tạo ra các nút thắt phát triển và gây ra các vấn đề về bản ngã khi mã có vấn đề cần được xử lý.

Tôi khuyên bạn nên tham khảo ý kiến ​​của các tác giả mã trước khi thay đổi, mặc dù mã tiêu chuẩn cao phải đủ tài liệu, thử nghiệm đơn vị, thử nghiệm tích hợp và thử nghiệm hệ thống để tạo ra sự dư thừa này, nhưng vẫn không thể có ý kiến ​​khác.

Điều này là xấu vì rất nhiều lý do, tôi đã làm việc trong một cửa hàng nơi họ cố gắng thay đổi từ điều này sang một cái gì đó hợp lý hơn và nó thật xấu xí.

Những lý do tại sao điều này là xấu:

• Nếu chủ sở hữu mã nghỉ phép và một số lỗi lớn xuất hiện trong nội dung của họ, sẽ rất khó khăn và tốn thời gian để cố gắng tìm hiểu mã VÀ sửa lỗi
• Nếu chủ sở hữu mã rời khỏi công ty, các dự án của họ sẽ bị đặt lại nghiêm trọng vì tất cả các kiến ​​thức về di sản và bộ lạc chỉ cần bước ra khỏi cửa
• Tài liệu kém. Nếu tôi là người duy nhất viết mã trong đó, tại sao tôi lại làm tài liệu đó? Liên quan là vấn đề mà bất kỳ tài liệu nào bị buộc phải tạo cũng có thể sẽ kém vì không ai biết đủ về mã để thực sự nói nếu tài liệu đó hoàn thành hoặc thậm chí chính xác.
• Cuộc chiến thánh mã có thể dễ dàng bùng cháy khi mọi người đều có hộp cát nhỏ của riêng mình, vì những người khác đã đề cập điều này có thể trở nên thực sự ngu ngốc thực sự nhanh chóng. Đây là một vấn đề là khi hai người phải làm việc cùng nhau, cả hai đều không quen thỏa hiệp với bất cứ điều gì.
• Vì quan điểm trên, các kỹ năng làm việc nhóm không bao giờ hình thành - mọi người không bao giờ phải làm việc với người khác.
• Fiefdoms có thể dễ dàng hình thành, những vương quốc nhỏ được tạo ra từ những túi rác không mua cho công ty bất cứ thứ gì. Bạn không biết những điều này xảy ra cho đến khi quá muộn vì mô-đun hoặc công cụ X là trách nhiệm của Bob và khốn cho bạn, người thậm chí sẽ hỏi về những gì Bob đang làm trong mã của mình .
• Đánh giá mã và đánh giá ngang hàng phải chịu vì không ai biết gì về mã. Nếu bạn không biết mã, bạn không thể phát hiện ra những địa điểm không phù hợp và chỉ giới hạn nhận xét về định dạng văn bản và quy ước đặt tên.
• Và nếu bạn làm việc cho tôi ... công ty sở hữu mã, không phải bạn. Chúng tôi tự hào về những gì chúng tôi làm và những gì chúng tôi đạt được, và trong những gì chúng tôi viết, nhưng đó là một điều nhóm, giống như khi đội của bạn thắng một trận đấu khó khăn. Bất kỳ nhân viên nào làm việc cho công ty đều sở hữu mã như nhau và trong quá trình thực hiện công việc của họ được phép chỉnh sửa nó theo bất kỳ cách nào họ muốn thực hiện công việc của mình nhằm chuyển tiếp các mục tiêu của công ty.

Những vấn đề lớn nhất thực sự là vấn đề nhân sự và tài liệu. Người đó sẽ rời đi một ngày nào đó, và chàng trai bạn sẽ đẩy lịch trình sang trái trong vài tuần.

Cách tiếp cận tốt hơn là làm cho mọi người quen thuộc với mọi phần của cơ sở mã (hoặc nửa tá phần hoặc nếu nó thực sự lớn và đa dạng) đến mức họ có thể

• Khắc phục mọi khiếm khuyết trong khu vực đó
• Thêm các tính năng hoặc cải tiến mới nhỏ hoặc vừa phải

Mỗi người có xu hướng biết nhiều hơn một chút về một số thứ so với những thứ khác, vì vậy đối với các vấn đề khó khăn, hai hoặc ba có thể liên kết với nhau, hoặc chuyên gia defacto có thể giải quyết nó. Tôi đã làm việc trong các nhóm trong trường hợp này và nó đã hoạt động rất tốt. Không chỉ không có bất kỳ khuyết điểm nào được liệt kê ở trên, việc bố trí nhân sự còn dễ đoán hơn nhiều vì chúng tôi không săn lùng các chuyên gia.

Quyền sở hữu mã duy nhất là "chủ sở hữu mã" có thể thực hiện mọi việc nhanh hơn những người khác, nhưng điều này chỉ đúng nếu mọi người là "chủ sở hữu mã" trong các dự án không chồng chéo. Nói cách khác, nếu mọi người xoay quanh lợi thế của "chủ sở hữu mã duy nhất" sẽ biến mất.

Xem số xe tải hay còn gọi là yếu tố xe buýt

hệ số xe buýt (còn được gọi là hệ số xe tải , hoặc số xe buýt / xe tải ) là thước đo nồng độ thông tin trong từng thành viên trong nhóm. Yếu tố xe buýt là tổng số nhà phát triển chính, những người sẽ cần phải mất khả năng (như bị xe buýt / xe tải đâm) để đưa dự án vào tình trạng hỗn loạn đến mức không thể tiến hành; dự án sẽ giữ lại thông tin (chẳng hạn như mã nguồn ) mà không có thành viên nhóm nào còn lại quen thuộc. Một yếu tố xe buýt cao có nghĩa là nhiều nhà phát triển sẽ cần phải được gỡ bỏ trước khi dự án nhất thiết phải thất bại.

"Bị xe buýt đâm" có thể có nhiều hình thức khác nhau. Đây có thể là một người nhận một công việc mới, sinh con, thay đổi lối sống hoặc tình trạng cuộc sống của họ, hoặc bị xe buýt đâm vào: nghĩa là ...

Như với nhiều thứ, đó là một "phụ thuộc" lớn. Nếu đó là một quy tắc nghiêm ngặt "không ai khác có thể làm việc với mã", thì có lẽ đó là lỗi xấu. Nếu đó là "chủ sở hữu phải thực hiện đánh giá mã trước khi chấp nhận thay đổi", thì điều đó có nghĩa là tốt, tùy thuộc vào việc chủ sở hữu sẵn sàng chấp nhận thay đổi bên ngoài như thế nào.

Nhược điểm là nghiêm trọng; "số xe tải" của đội bạn gần như trở thành 1.

Để xem xét, "số xe tải" được định nghĩa đơn giản là "có bao nhiêu thành viên của đội, trong trường hợp xấu nhất, có thể bị xe tải đâm trước khi kiến ​​thức cần thiết để thực hiện một số nhiệm vụ quan trọng bị mất cho đội."

Đó là điều tự nhiên, và phần nào được khuyến khích, cho các nhà phát triển tập trung vào các ngành học phụ; nếu mọi người phải biết mọi thứ phải làm với dự án, sẽ không có gì được thực hiện bởi vì mọi người sẽ học những gì người khác đã làm, tại sao nó hoạt động và làm thế nào để thay đổi mà không phá vỡ nó. Ngoài ra, nếu các nhà phát triển ngừng làm những việc khác nhau cho các khu vực khác nhau thì ít có khả năng những thay đổi đó sẽ va chạm. Vì vậy, nói chung là tốt khi có hai hoặc ba cặp nhà phát triển hoặc nhà phát triển hoạt động chủ yếu trong một hệ thống con cụ thể của dự án và biết rõ về nó.

Tuy nhiên, nếu chỉ có một người được cho là chạm vào một dòng mã cụ thể, thì khi anh chàng đó bỏ cuộc, bị đuổi việc, đi nghỉ hoặc kết thúc trong bệnh viện và dòng mã đó được chứng minh là nguyên nhân gây ra lỗi. phải sửa, người khác phải vào và hiểu mã. Nếu không ai khác ngoài anh chàng đã viết nó đã từng thấy nó, điều đó sẽ mất thời gian để đạt đến một mức độ hiểu biết cho phép nhà phát triển thực hiện thay đổi sửa lỗi mà không cần thực hiện thêm. TDD có thể giúp đỡ, nhưng chỉ bằng cách nói với nhà phát triển họ đã thực hiện thay đổi "sai"; một lần nữa, nhà phát triển phải hiểu các thử nghiệm nào đang thực hiện mã nào để đảm bảo rằng các thử nghiệm thất bại không cố gắng đưa ra các xác nhận sai.

Tôi không đưa nó đến mức cực đoan, nhưng tôi thích trách nhiệm mã hơn . Bạn viết mã bị hỏng, bạn nên sửa nó. Điều này có thể được thực hiện ở cấp độ cá nhân, cặp hoặc nhóm. Nó ngăn chặn việc chuyển mớ hỗn độn của bạn cho người khác để dọn dẹp. Điều này đi cho những thay đổi là tốt.

Khối lượng công việc và lịch trình các vấn đề sẽ ghi đè lên điều này. Sẽ thật ngu ngốc khi giữ việc sửa một lỗi lớn vì thủ phạm đang trong kỳ nghỉ hai tuần.

Mục tiêu không phải là để nhóm của bạn chơi "trò chơi đổ lỗi" hoặc tính số lỗi quá xa (Dù sao chúng cũng không bằng nhau.). Dựa vào người đã kiểm tra mã cuối cùng hoặc nhờ người giám sát đưa ra quyết định và giao nó cho ai đó thay vì đi qua từng phần của mỗi dòng mã.

Các lập trình viên giỏi hơn có thể sẽ sửa rất nhiều mã của người khác cho dù bạn gán nó như thế nào.