Là sở hữu mã cá nhân quan trọng? [đóng cửa]

Tôi đang ở giữa một cuộc tranh luận với một số đồng nghiệp về việc liệu quyền sở hữu nhóm của toàn bộ cơ sở mã có tốt hơn quyền sở hữu cá nhân đối với các thành phần của nó hay không.

Tôi là một người ủng hộ rất lớn trong việc chỉ định cho mọi thành viên trong nhóm một phần gần bằng nhau của codebase. Nó cho phép mọi người tự hào về sự sáng tạo của họ, cung cấp cho các trình sàng lọc lỗi một vị trí đầu tiên rõ ràng để gán vé đến và giúp giảm bớt "hội chứng cửa sổ bị vỡ".

Nó cũng tập trung kiến ​​thức về chức năng cụ thể với một (hoặc hai) thành viên trong nhóm để việc sửa lỗi dễ dàng hơn nhiều.

Trên hết, nó đưa ra tiếng nói cuối cùng về các quyết định lớn với một người có nhiều đầu vào thay vì với một ủy ban.

Tôi không ủng hộ việc yêu cầu sự cho phép nếu ai đó muốn thay đổi mã của bạn; Có thể có mã xem lại luôn cho chủ sở hữu, chắc chắn. Tôi cũng không đề xuất xây dựng silo kiến ​​thức: không nên có gì độc quyền về quyền sở hữu này.

Nhưng khi đề xuất điều này với đồng nghiệp của tôi, tôi đã nhận được rất nhiều phản hồi, chắc chắn là nhiều hơn tôi mong đợi.

Vì vậy, tôi hỏi cộng đồng: ý kiến ​​của bạn khi làm việc với một nhóm trên một cơ sở mã lớn là gì? Có điều gì tôi đang thiếu về việc duy trì cảnh giác sở hữu tập thể không?

Tôi tin rằng Quyền sở hữu Đội có lợi hơn nhiều trong dài hạn.

Bạn chỉ cần nhìn vào 2 kịch bản sau đây để hiểu tại sao việc tập trung kiến ​​thức vào số lượng người tối thiểu ít hơn lý tưởng:

• Thành viên đội gặp tai nạn đáng tiếc
• Thành viên nhóm đáp ứng cơ hội việc làm tốt hơn

Đương nhiên, người / người viết các phần cụ thể sẽ có kiến ​​thức lớn hơn về nó, nhưng đừng từ bỏ cám dỗ để biến họ thành silo kiến thức duy nhất . Silo sẽ mang lại cho bạn những chiến thắng ngắn hạn bằng những cơn đau dài hạn.

Chỉ vì bạn không có quyền sở hữu cá nhân đối với các phần mã, vì bạn đã viết nó, không có nghĩa là bạn sẽ vẫn không có các khía cạnh của "niềm tự hào về sáng tạo của bạn", v.v. Tôi không tin rằng việc sở hữu nhóm sẽ rất lớn làm giảm bất kỳ cảm giác cá nhân của quyền sở hữu mã được viết.

Cuối cùng, nhóm sở hữu mã. Nhưng vì tất cả các lý do bạn đã đề cập, chúng tôi đã chỉ định các tác giả riêng lẻ cho các phần cụ thể của mã. Mỗi tác giả có trách nhiệm chính đối với phần mã của họ và trách nhiệm phụ đối với toàn bộ cơ sở mã.

Nếu một vấn đề với một phần của cơ sở mã xuất hiện, tôi cố gắng quay lại với người ban đầu đã viết mã để sửa lỗi. Tất nhiên, không có gì ngăn cản các thành viên khác trong nhóm áp dụng bản sửa lỗi; tất cả các thành viên trong nhóm dự kiến ​​sẽ quen thuộc với mã của mọi người khác. Nhưng chúng tôi luôn cố gắng để có được một bản sửa lỗi từ tác giả ban đầu. Rốt cuộc, họ đã viết mã; họ là người quen thuộc nhất với nó

Tôi đã làm việc trong môi trường nhóm, bởi vì mọi người không cảm thấy quyền sở hữu trong những gì họ viết, họ không bị buộc phải viết mã xuất sắc, mà chỉ là mã trung bình.

Trong khi tôi đồng ý từ lập trường kinh doanh về lý do để truyền bá kiến ​​thức về sản phẩm; thực tế là một cá nhân tập trung nỗ lực của họ vào một lĩnh vực nhất định, theo thời gian, sẽ trở nên thông thạo hơn nhiều trong khu vực nhất định.

Bỏ qua điều này là bỏ qua khoa học. Bộ não không may không thể giữ lại mọi thứ nó gặp phải. Nó nhớ lại những gì là hợp lệ và có giá trị tại một thời điểm nhất định ngay cả khi lưu trữ giảm dần theo thời gian.

Tôi có xu hướng đồng ý với bạn rằng quyền sở hữu đối với một mô-đun hoặc ngăn cụ thể trong cơ sở mã lớn hơn thường sẽ mang lại kết quả tốt hơn. Ai đó sẽ rời đi mà không có bất kỳ thông báo nào cản trở sự thành công? Chắc chắn rồi. Nhưng giả vờ rằng tất cả mọi người trong nhóm nên có cùng lượng kiến ​​thức liên quan đến cơ sở mã là ngây thơ và không làm gì để cải thiện mã; nó cố gắng bảo vệ mã. Bảo vệ mã là vai trò của doanh nghiệp vì những lý do rõ ràng. Thời gian nỗ lực mà một doanh nghiệp sẽ đạt được trong việc bảo vệ mã thường có thể trở nên bất lợi giống nhau.

Bạn không chắc chắn rằng mọi người chơi trong đội của bạn đều có thể chơi vị trí tiền vệ phải không? Tôi sẽ lập luận rằng việc đảm bảo rằng mọi thành viên trong nhóm đều có cổ phần trên cơ sở mã cùng một lúc với việc cố gắng để mọi người chơi trong đội của bạn chơi trận tứ kết ở mức độ thỏa đáng ... điều đó không tăng thêm. Bạn có bản sao lưu? Chắc chắn bạn làm ... nhưng các thành viên trong nhóm nên có một bản sắc trong nhóm. Tin rằng tất cả mọi người đều giống nhau là yêu cầu nỗi đau của một loại khác ...

Tôi không biết rằng quyền sở hữu mã cá nhân là một ý tưởng tốt. Ít nhất không phải theo nghĩa là mọi người có thể nói "Đây là mã của tôi và tôi sẽ làm những gì tôi muốn với nó". Có lẽ tốt hơn là bạn nên có quyền quản lý mã riêng lẻ : mã phải thuộc sở hữu của nhóm, nhưng có một người cụ thể mà nhóm ủy thác trách nhiệm và quyền hạn đối với nó.

Lý do cho điều này là nếu đó là trách nhiệm của mọi người, thì đó không phải là trách nhiệm của một người.

Tôi sẽ tán thành quyền sở hữu nhóm đối với cá nhân vì những lý do sau:

• Mã thống nhất trên toàn bộ dự án
• Thúc đẩy thảo luận về mã, luôn luôn dẫn đến các giải pháp tốt hơn, được hiệu đính hơn
• Nếu một thành viên trong nhóm bị ốm (hoặc tệ hơn), toàn bộ phần mã không bị trì hoãn
• Các thành viên trong nhóm có thể làm việc trên tất cả các phần của dự án, phục vụ cho việc xem xét mã được xây dựng trong quy trình phát triển

Chuyên môn hóa là tốt - đối với một cơ sở mã lớn, điều này về lâu dài có thể tiết kiệm khá nhiều thời gian giao tiếp - nhưng quyền sở hữu thì không.

Ý tôi là, thái độ của đội nên có lỗi và không ai nên nói rằng "ồ, chỉ X mới có thể chạm vào mã đó, vì vậy đó không phải là vấn đề của tôi". Nếu bạn là thành viên của nhóm, bạn cũng có trách nhiệm sửa các lỗi trong toàn bộ cơ sở mã nếu bạn có thể và thực hiện đúng cách. Người X có thể là lựa chọn tốt nhất để làm điều đó, nhưng bất kỳ ai cũng nên làm như vậy nếu họ phải làm điều đó. Điều này tự nhiên đòi hỏi mã phải được viết theo cách cho phép và mời các thành viên trong nhóm làm việc với nó. Có mã sởn gai ốc sẽ ngăn cấm điều này, vì vậy hãy phấn đấu để có mã đơn giản, rõ ràng, vì điều đó cho phép hầu hết các nhà phát triển làm việc với nó. Bạn có thể muốn đi với đánh giá ngang hàng để giữ nó theo cách đó.

Tôi phải không đồng ý với bạn: quyền sở hữu nhóm của một cơ sở mã là một lựa chọn tốt hơn nhiều so với quyền sở hữu cá nhân.

Nhược điểm rõ ràng của quyền sở hữu cá nhân là nếu có điều gì đó xảy ra với một nhân viên (bị sa thải, nghỉ hưu, bị ốm, v.v.) thì trừ khi anh ta / cô ta viết mã thực sự sạch sẽ, sẽ phải mất một thời gian để người khác chấp nhận người đó mã, đặc biệt là nếu họ cũng phải quản lý mã của riêng họ.

Họ cũng chỉ là quá nhiều công cụ giúp sở hữu đội dễ dàng hơn. Đánh giá mã, kiểm soát nguồn - đây là những điều khuyến khích sự tham gia của nhóm trong toàn bộ cơ sở mã. Ngoài ra, làm thế nào để bạn chỉ định một phần cụ thể của một cơ sở mã cho chỉ một người? Bạn chỉ nói rằng chỉ người này có thể sửa đổi tập tin này?

Cuối cùng, tôi nghĩ rằng nếu một phần của cơ sở mã bị hỏng, quá dễ để đổ lỗi cho người chịu trách nhiệm về nó và điều đó chỉ gây ra nhiều vấn đề hơn.

Tôi nghĩ bạn cần cả hai, bởi vì có một sự căng thẳng giữa cả hai cách tiếp cận.

Nếu đối với bất kỳ đoạn mã nào chỉ có một người có thể làm việc với nó, thì điều đó thực sự tồi tệ về lâu dài cho công ty, đặc biệt là / nếu nó phát triển, bởi vì mỗi nhà phát triển trở thành một điểm thất bại. Mặt khác, quyền sở hữu mã riêng lẻ (hy vọng) cho phép thời gian giao hàng nhanh hơn, bởi vì nhà phát triển thường thích cách tiếp cận đó (khuyến khích), bởi vì nhà phát triển biết rất rõ mã, v.v ... Ngoài ra còn có một vấn đề về thời gian: nên có thể để phân bổ lại các nhà phát triển cho các dự án cụ thể tùy thuộc vào nhu cầu kinh doanh, nhưng nếu bạn thực hiện nó hàng ngày, điều đó thật kinh khủng (nếu chỉ vì các nhà phát triển ghét nó, mà còn vì chi phí chuyển đổi quá nặng và bạn dành phần lớn thời gian để làm không có gì).

IMO, một vai trò của người quản lý là tìm sự cân bằng tốt giữa cả hai. Đánh giá mã, tiêu chuẩn mã hóa, tiêu chuẩn hóa trên một bộ công cụ cũng sẽ giúp làm giảm sự nguy hiểm của vấn đề thất bại. Rốt cuộc, điểm chính của mã duy trì là giải quyết vấn đề này.

Tôi nghĩ rằng quyền sở hữu mã tập thể tốt hơn so với quyền sở hữu mã cá nhân.

Tôi không bận tâm đến tranh luận về xe tải - trong mô hình sở hữu cá nhân, việc mất chủ sở hữu là tốn kém về thời gian cần thiết để người khác tiếp quản, nhưng sự kiện này hiếm khi chi phí khấu hao thấp.

Thay vào đó, tôi nghĩ rằng quyền sở hữu mã tập thể dẫn trực tiếp đến mã chất lượng cao. Đây là vì hai lý do rất đơn giản. Thứ nhất, vì sự thật đau lòng là một số lập trình viên của bạn không giỏi như những người khác, và nếu họ sở hữu mã, mã đó sẽ kém; cung cấp cho các lập trình viên tốt hơn của bạn truy cập vào nó sẽ cải thiện nó. Thứ hai, xem xét mã: nếu mọi người sở hữu mã, mọi người đều có thể xem lại và cải thiện mã; ngay cả những lập trình viên giỏi cũng viết mã phụ nếu để lại cho thiết bị của họ.

Tôi nói điều này dựa trên kinh nghiệm trong dự án hiện tại của tôi. Chúng tôi hướng đến thực hành quyền sở hữu tập thể, nhưng có một số phần của hệ thống đã trở nên chuyên biệt - tôi và một người khác là chủ sở hữu thực tế của hệ thống xây dựng, ví dụ, có một người làm hầu hết công việc trên các nguồn cấp dữ liệu đến , một anh chàng khác làm việc về nhập khẩu hình ảnh, vân vân. Trong một số lĩnh vực đó (đặc biệt, tôi phải thú nhận, trong khu vực của tôi!), Chất lượng mã đã bị ảnh hưởng nghiêm trọng - có những sai lầm, quan niệm sai lầm, loại bỏ và hack đơn giản là không thể tồn tại sự chú ý của những người khác trong nhóm.

Tôi lưu ý rằng bạn có thể đạt được một số lợi ích của quyền sở hữu mã tập thể bằng cách sở hữu mã riêng lẻ trong đó quyền sở hữu một đoạn mã cụ thể di chuyển giữa các lập trình viên khác nhau thường xuyên (giả sử, cứ sau ba tháng, hoặc mỗi lần phát hành - thậm chí mỗi lần lặp lại?) . Một chương trình tương đương với luân canh cây trồng. Đó có thể là niềm vui. Tôi sẽ không thử bản thân mình, mặc dù.

Tôi không nghĩ quyền sở hữu mã nhóm cũng quan trọng như việc có nhiều người đóng góp hiểu kiến ​​trúc cơ bản của các hệ thống con hiện hành.

Ví dụ: chúng tôi có một vài người trong nhóm của chúng tôi tạo các trang web quản trị cho các sản phẩm máy chủ của chúng tôi. Chúng tôi đã xây dựng một công cụ kịch bản phía máy chủ tùy chỉnh để chúng tôi có thể gọi các hàm C trên máy chủ ngay từ các tập lệnh java hoặc html của chúng tôi. Tôi nghĩ rằng điều quan trọng hơn là các anh chàng "web" của chúng tôi hiểu cách sử dụng công cụ này thay vì là đồng sở hữu của các ứng dụng trang web khác.

Tôi nghĩ rằng bạn có quyền sở hữu cá nhân của mã tại thời điểm bạn viết nó và sau đó chuyển nó cho nhóm. Bằng cách này, mọi người đều có trách nhiệm và đóng góp. Mọi người nên muốn sửa một lỗi mã hóa mà họ tạo ra. Cùng với việc xem xét mã này tạo ra các tiêu chuẩn cao hơn. Không ai muốn công việc dọn dẹp sau khi người khác.

Suy nghĩ nhiều trách nhiệm hơn và ít sở hữu hơn. Rốt cuộc, bất cứ ai đang viết séc đều là chủ sở hữu thực sự.

Jim, tôi với bạn về điều đó 100%. Tôi đang ở giữa trận chiến chính xác ở nơi làm việc của mình - đó là lý do tại sao tôi tình cờ gặp câu hỏi của bạn.

Theo cách tôi thấy là: "khi mọi người sở hữu nó, không ai sở hữu nó".

Đối với tôi, không có yếu tố quan trọng nào đối với chất lượng mã hơn quyền sở hữu và trách nhiệm.

Ví dụ từ cuộc sống thực minh họa điều này tốt. bạn sẽ chăm sóc tốt hơn: bãi cỏ riêng hay công viên của cộng đồng? Khá rõ ràng.

Tuy nhiên, điều đó không nhất thiết phải được đánh đổi vì "tính linh hoạt của nhóm". Nó chỉ có nghĩa là khi một người sở hữu một cái gì đó, anh ta sở hữu nó - và nếu chỉ trong ngày.

Đối với tôi nó phụ thuộc vào sự năng động của nhóm của bạn.

Ví dụ: nếu bạn có một nhóm không thống nhất theo tiêu chuẩn, đánh giá ngang hàng, kiểm tra phương pháp hoặc nếu bạn có một nhóm có mức độ năng lực khác nhau giữa các thành viên, thì có thể tìm kiếm một khái niệm mạnh mẽ hơn về quyền sở hữu mã với một tư duy mô-đun hộp đen hơn.

Ví dụ, việc thiếu giao diện được thiết kế cẩn thận theo các nguyên tắc RẮN của bạn có thể nhanh chóng bị phá hỏng bởi một người thậm chí không biết "RẮN" có nghĩa là và muốn thêm các chức năng chiết trung mới vào giao diện để "thuận tiện", ví dụ: Đây là, tồi tệ nhất.

Bạn cũng có thể đối phó với các đồng nghiệp cẩu thả, người có ý tưởng sửa lỗi đang khắc phục triệu chứng mà không hiểu vấn đề gốc (ví dụ: cố gắng phản hồi báo cáo sự cố bằng cách chỉ đưa mã khắc phục vào mã để ẩn lỗi và chuyển lỗi chết người tác dụng phụ cho người khác). Trong trường hợp đó, nó không hoàn toàn xấu như phá hoại thiết kế giao diện và bạn có thể bảo vệ ý định của mình bằng các bài kiểm tra đơn vị được xây dựng cẩn thận.

Giải pháp lý tưởng là thắt chặt đội ngũ của bạn mặc dù đến thời điểm mà khái niệm về quyền tác giả và quyền sở hữu không còn trở nên quá quan trọng. Đánh giá ngang hàng không chỉ là cải thiện chất lượng mã, mà còn là cải thiện tinh thần đồng đội. Các tiêu chuẩn không chỉ là về tính nhất quán, chúng cải thiện tinh thần đồng đội.

Tuy nhiên, có những kịch bản trong đó đánh giá ngang hàng và thực sự có tất cả mọi người tuân thủ một tiêu chuẩn chỉ là vô vọng và sẽ mang lại nhiều lời phê bình thiếu kinh nghiệm vô vọng vào hỗn hợp. Tôi muốn nói rất nhiều về việc quyền sở hữu mã hay quyền sở hữu nhóm có ưu tiên mạnh hơn sẽ dựa trên khả năng của nhóm bạn để thực hiện đánh giá ngang hàng hiệu quả và thực sự khiến mọi người thoát ra như họ được hưởng lợi từ đó (cả về mặt đánh giá và kết quả là trở nên gần nhau hơn trong suy nghĩ và tiêu chuẩn. Trong các đội lớn, lỏng lẻo và / hoặc khác biệt, điều này có vẻ vô vọng. Nếu nhóm của bạn có thể hoạt động như một "đội", nơi bạn thậm chí không thể biết ai đã viết gì, thì quyền sở hữu duy nhất sẽ bắt đầu giống như một khái niệm ngớ ngẩn.

Trong các loại kịch bản xa lý tưởng này, khái niệm quyền sở hữu mã này thực sự có thể giúp ích. Nó đang cố gắng làm tốt một tình huống xấu nhất, nhưng nó có thể giúp ích nếu làm việc theo nhóm nói chung là vô vọng để đặt một hàng rào xung quanh mã của tác giả. Trong trường hợp đó, nó làm giảm tinh thần đồng đội nhưng điều đó có thể tốt hơn nếu "làm việc theo nhóm" chỉ dẫn đến bước chân.