Là mã sở hữu một mùi mã?

Đây là điều mà tôi đã suy nghĩ từ bao giờ kể từ khi tôi đọc câu trả lời này trong chuỗi ý kiến ​​lập trình gây tranh cãi :

Công việc của bạn là đưa mình ra khỏi công việc.

Khi bạn viết phần mềm cho chủ nhân của mình, bất kỳ phần mềm nào bạn tạo sẽ được viết theo cách mà bất kỳ nhà phát triển nào cũng có thể chọn và hiểu với một nỗ lực tối thiểu. Nó được thiết kế tốt, được viết rõ ràng và nhất quán, được định dạng sạch sẽ, được ghi lại ở nơi cần thiết, xây dựng hàng ngày như mong đợi, được kiểm tra vào kho lưu trữ và được phiên bản phù hợp.

Nếu bạn bị xe buýt đâm , bị sa thải, bị sa thải hoặc nghỉ việc, chủ nhân của bạn sẽ có thể thay thế bạn trong một thông báo và anh chàng tiếp theo có thể bước vào vai trò của bạn, nhận mã của bạn và đứng dậy và chạy trong vòng một tuần. Nếu anh ấy hoặc cô ấy không thể làm điều đó, thì bạn đã thất bại thảm hại.

Thật thú vị, tôi đã thấy rằng có mục tiêu đó đã làm cho tôi có giá trị hơn đối với các nhà tuyển dụng của tôi. Tôi càng phấn đấu để được dùng một lần, tôi càng trở nên có giá trị đối với họ.

Và nó đã được thảo luận một chút trong các câu hỏi khác, chẳng hạn như câu hỏi này , nhưng tôi muốn đưa nó lên một lần nữa để thảo luận từ quan điểm trống rỗng hơn " đó là một mùi mã !! " - quan điểm chưa thực sự được đề cập ở độ sâu chưa.

Tôi đã là một nhà phát triển chuyên nghiệp trong mười năm. Tôi đã có một công việc trong đó mã được viết đủ tốt để được chọn bởi một nhà phát triển mới tốt, nhưng trong hầu hết các trường hợp trong ngành, dường như mức độ sở hữu rất cao (cả quyền sở hữu cá nhân và nhóm) là định mức. Hầu hết các cơ sở mã dường như thiếu tài liệu, quy trình và "tính mở" sẽ cho phép nhà phát triển mới chọn chúng và nhanh chóng làm việc với chúng. Dường như luôn có rất nhiều mánh khóe và hack bất thành văn mà chỉ có ai đó biết rõ về cơ sở mã ("sở hữu" nó) mới biết.

Tất nhiên, vấn đề rõ ràng với điều này là: nếu người đó thoát hoặc "bị xe buýt đâm" thì sao? Hoặc ở cấp độ đội: điều gì sẽ xảy ra nếu cả đội bị ngộ độc thực phẩm khi họ ra ngoài ăn trưa trong đội của họ, và tất cả họ đều chết? Bạn có thể thay thế nhóm bằng một nhóm các nhà phát triển ngẫu nhiên mới tương đối không đau đớn không? - Trong một số công việc trước đây của tôi, tôi không thể tưởng tượng điều đó xảy ra. Các hệ thống đầy rẫy những mánh khóe và hack mà bạn " chỉ cần biết ", rằng bất kỳ nhóm mới nào bạn thuê sẽ mất nhiều thời gian hơn chu kỳ kinh doanh có lãi (ví dụ: các bản phát hành ổn định mới) để mọi thứ trở lại. Nói tóm lại, tôi sẽ không ngạc nhiên nếu sản phẩm sẽ phải bị bỏ rơi.

Rõ ràng, mất toàn bộ một đội sẽ rất hiếm. Nhưng tôi nghĩ có một điều tinh tế và độc ác hơn trong tất cả những điều này - đó là điểm khiến tôi suy nghĩ để bắt đầu chủ đề này, vì tôi chưa từng thấy nó được thảo luận trong các điều khoản này trước đây. Về cơ bản: Tôi nghĩ rằng nhu cầu cao về quyền sở hữu mã thường là một chỉ số về nợ kỹ thuật . Nếu thiếu quy trình, giao tiếp, thiết kế tốt, nhiều thủ thuật và hack nhỏ trong hệ thống mà bạn "chỉ cần biết", v.v. - điều đó thường có nghĩa là hệ thống đang dần dần mắc nợ kỹ thuật ngày càng sâu hơn.

Nhưng vấn đề là - quyền sở hữu mã thường được trình bày như một loại "lòng trung thành" đối với một dự án và công ty, như một hình thức tích cực "chịu trách nhiệm" cho công việc của bạn - vì vậy nó không được ưa chuộng để lên án nó. Nhưng đồng thời, khía cạnh nợ kỹ thuật của phương trình thường có nghĩa là cơ sở mã đang ngày càng ít mở hơn và khó làm việc hơn. Và đặc biệt khi mọi người tiến lên và các nhà phát triển mới phải thế chỗ, chi phí nợ kỹ thuật (tức là bảo trì) bắt đầu tăng vọt.

Vì vậy, theo một nghĩa nào đó, tôi thực sự nghĩ rằng đó sẽ là một điều tốt cho nghề nghiệp của chúng ta nếu mức độ cao về nhu cầu sở hữu mã được xem công khai như một mùi công việc (trong trí tưởng tượng lập trình viên phổ biến). Thay vì nó được coi là "nhận trách nhiệm và niềm tự hào" trong công việc, nó nên được xem nhiều hơn là "cố thủ chính mình và tạo ra bảo mật công việc nhân tạo thông qua nợ kỹ thuật".

Và tôi nghĩ rằng thử nghiệm (thử nghiệm suy nghĩ) về cơ bản nên là: nếu người đó (hoặc thực sự là toàn bộ đội) sẽ biến mất khỏi khuôn mặt Trái đất vào ngày mai. Đây sẽ là một tổn thương khổng lồ - có thể gây tử vong - cho dự án, hoặc chúng tôi có thể đưa người mới đến, khiến họ đọc doccos và trợ giúp các tệp và chơi xung quanh với mã trong vài ngày - và sau đó quay lại kinh doanh trong một vài tuần (và trở lại năng suất đầy đủ trong một tháng hoặc lâu hơn)?

Tôi nghĩ rằng chúng ta phải tạo sự khác biệt giữa quyền sở hữu mã:

• từ quan điểm trách nhiệm,
• từ phong cách mã / hack, vv quan điểm.

Người đầu tiên phải được khuyến khích. Nếu không ai chịu trách nhiệm về mã và lỗi chất lượng thấp, điều tồi tệ sẽ xảy ra . Điều đó không có nghĩa là lỗi liên quan đến mã của bạn phải được gán cho bạn mỗi lần: nếu mã được viết chính xác, bất kỳ ai cũng có thể sửa lỗi trong bất kỳ phần nào của mã. Nhưng nếu bạn không có bất kỳ phản hồi nào về các lỗi bạn làm, bạn sẽ tạo ra các lỗi tương tự lặp đi lặp lại .

Quyền sở hữu mã có thể giúp ích rất nhiều cho cả người quản lý và nhà phát triển, đặc biệt là nhà phát triển. Nếu tôi biết rằng 80% lỗi trong sản phẩm nằm trong mã của tôi trong khi chúng tôi là ba nhà phát triển làm việc trong dự án và 75% các lỗi đó có liên quan đến SQL Injection, tôi sẽ cẩn thận hơn khi viết mã vào lần tới và làm thêm một nỗ lực để viết các truy vấn cơ sở dữ liệu chính xác.

Cái thứ hai (quyền sở hữu mã từ kiểu mã / hack, v.v.) chủ yếu là một điều xấu. Nó mang lại điều gì cho sản phẩm? Nó không làm tăng chất lượng sản phẩm, nhưng làm giảm tính đồng nhất của mã nguồn và gây khó khăn cho việc duy trì gần đây .

Đối với nhiều dự án lớn, mọi người không ở lại suốt đời làm việc trên cùng một đoạn mã. Và ở đây, tôi thậm chí không nói về những điều khủng khiếp như nhà phát triển bị xe buýt đâm: Tôi không nghĩ quyền sở hữu mã là mối quan tâm đầu tiên trong trường hợp này. Nhưng nhiều suy nghĩ nhỏ xảy ra: mọi người chuyển từ phát triển sang quản lý hoặc các công việc khác, hoặc chọn các dự án khác, hoặc làm việc trên các công cụ khác hoặc bắt đầu sử dụng ngôn ngữ khác (nếu một số ngôn ngữ được sử dụng trong một dự án), v.v.

Một đoạn mã của một dự án cũng có thể được sử dụng lại trong một dự án khác và nhà phát triển làm việc cho dự án khác này muốn sửa đổi một số phần của mã để phù hợp với nhu cầu mới, mà không cần hỏi lời khuyên của người viết mã trước đây.

Có phải là một mùi mã? Vâng, nó phụ thuộc vào những gì bạn có nghĩa là mùi mã. Đối với tôi, đó là tất cả về sự gắn kết tổng thể của dự án và quản lý chính xác . Trong một dự án tốt,

• hướng dẫn kiểu mã được thi hành để giúp hiểu mã dễ dàng hơn sau này,
• các nhà phát triển có kinh nghiệm hơn không vi phạm nguyên tắc KISS, do đó giúp hiểu được mã nguồn sau này bởi các đồng nghiệp ít kinh nghiệm hơn.

Để kết luận, quyền sở hữu mã phải được theo dõi thông qua kiểm soát phiên bản, nhưng bạn không thể nói rằng một đoạn mã được viết bởi bạn hoặc ai đó trong một nhóm .

Đầu tiên chúng ta cần xác định "quyền sở hữu mã" là gì.

Khi một phần (một phần) mã đang trong quá trình phát triển ban đầu, thường thì cần phải chỉ định một hoặc hai người là "chủ sở hữu" vì:

• Ban đầu, không có thông số kỹ thuật hoặc yêu cầu rõ ràng và (các) nhà phát triển sẽ cần phải tự thu thập thông tin. Có một khoảng cách thời gian giữa bộ sưu tập và tài liệu về những phát hiện đó.
• Tránh các chỉnh sửa xung đột khi đoạn mã đang được tích cực sửa đổi.
• "Chủ sở hữu" là người có thể báo cáo tiến trình phát triển của tính năng.

Thông thường có một chủ sở hữu duy nhất cho mỗi nhiệm vụ. Chủ sở hữu kép có thể với lập trình Cặp. Sẽ không thực tế nếu không có "quyền sở hữu mã" được chỉ định hẹp.

Lưu ý:
Vui lòng xem câu trả lời của @ MainMa cho các vấn đề khác trong quá trình phát triển. Trong những trường hợp đó, "quyền sở hữu mã" là một triệu chứng của các vấn đề lớn hơn, đó là: sự lựa chọn tối ưu về kiến ​​trúc, sự không nhất quán về kiểu mã hóa và nói chung là thiếu chất lượng mã.

Khi một phần được viết và chấp nhận vào cơ sở mã ("đã hoàn thành"), câu hỏi "quyền sở hữu mã" chung hơn sẽ xuất hiện.

• Ai là chuyên gia có thể trả lời tất cả các câu hỏi về đoạn mã này / phần chức năng này?
• Kiến thức này đã được nắm bắt trong các tạo phẩm hữu hình, như tài liệu yêu cầu, kiểm tra đơn vị, kiểm tra chấp nhận, nhật ký thay đổi, wiki dự án, v.v.?

Sẽ luôn có một phần kiến ​​thức về miền (hiểu ngầm về các yêu cầu của khách hàng, các vấn đề tương thích với các hệ thống phức tạp, v.v.) khó có thể chính thức hóa thành các thông số kỹ thuật bằng văn bản. Do đó, khi có một sự kiện thiên tai, một số mất kiến ​​thức tên miền phải được dự kiến.

Cùng với việc mất kiến ​​thức tên miền, bạn cũng sẽ mất những người trả lời chuyên gia có thể giải thích các chi tiết của hệ thống. Trong khía cạnh này, mất chuyên gia là một điều xấu toàn cầu. Các kiến ​​thức nên được nắm bắt trước đó.

Điều này không có nghĩa là sự tồn tại của "chuyên gia" là xấu: Hãy coi các chuyên gia là "bộ đệm" của kiến ​​thức bằng văn bản. Các chuyên gia thường có thể trả lời các câu hỏi nhanh hơn là phải tra cứu và tiêu hóa kiến ​​thức bằng văn bản.

Tuy nhiên, đôi khi "quyền sở hữu mã" đề cập đến các rào cản được thiết lập bởi các nhà phát triển đang hoạt động của dự án để ngăn người ngoài sửa đổi mã.

• Ai có thể thay đổi đoạn mã này?
  • Để sửa lỗi rõ ràng?
  • Để làm cho mã thỏa mãn một số yêu cầu khác?
  • Để viết lại hoàn toàn mã theo sở thích của một người?

Có những rào cản tốt và rào cản xấu:

• Rào cản tốt
  • Kiến thức tên miền - bạn hiểu rõ các yêu cầu và phong cách kiến ​​trúc / mã hóa như thế nào
  • Kỹ năng lập trình và thiết kế - bạn có kỹ năng để cải thiện chất lượng thiết kế và mã của dự án không
• Rào cản xấu
  • Bạn không thuộc nhóm nhà phát triển ban đầu, vì vậy bạn không được phép thay đổi.
  • Chỉ có lỗi được chào đón. Cải tiến tính năng không được chào đón.

Trong trường hợp này, đặc quyền chỉnh sửa mã nguồn của dự án khác không nên dựa trên quyền sở hữu mã, nhưng nó phải dựa trên thành tích.

Cuối cùng, câu trả lời của @Graham Lee chỉ ra sự phân mảnh kiến ​​thức và kiến ​​trúc gây ra bởi sự phân nhánh.

Trong trường hợp này, "quyền sở hữu mã" là một trong những triệu chứng của việc phân nhánh. Một triệu chứng thứ hai là "thiếu quan tâm đến các dự án của nhóm khác". Là một tổ chức, các nhà quản lý sẽ cần thực hiện các bước để khuyến khích chuyển giao kiến ​​thức và cộng tác giữa các nhóm và phòng ban.

Đáng sợ hơn, một số công ty (tôi từng làm việc tại một) tổ chức cấu trúc quản lý của họ xung quanh các nhóm chức năng: bạn quản lý các nhà phát triển máy khách Windows, cô ấy quản lý nhóm cài đặt, anh ta quản lý các nhà phát triển phụ trợ, v.v. Điều này không chỉ dẫn đến quyền sở hữu mã mạnh mà bạn mô tả, nó còn được coi là cách thức hoạt động của doanh nghiệp. Nó biến kiến ​​trúc phần mềm thành một cuộc chiến chính trị.

Đây co phải vân đê? Đó là nếu kiến ​​trúc là - hoặc trở thành - tối ưu. Không thể nói (ví dụ) rằng trình cài đặt sẽ hoạt động tốt hơn hoặc rẻ hơn để phát triển nếu đó chỉ là trường hợp sử dụng của khách hàng, vì đó là sự kiểm soát của một nhóm và người quản lý. Sự phân chia giữa các mô-đun chức năng đã trở thành sự thật về cách thức hoạt động của bộ phận kỹ thuật và phải mất rất nhiều biến động để thay đổi những sự thật đó.

[BTW trong trường hợp cuộc thảo luận ở trên không làm rõ, câu trả lời của tôi cho câu hỏi của bạn là có. Quyền sở hữu mã là một mùi mã, bởi vì nó có thể ngăn chặn những người thông minh có ý tưởng tốt - hoặc thậm chí chỉ những người có sẵn khi bạn cần họ - làm việc với mã. Rõ ràng có các biện pháp kiểm soát để ngăn chặn các thay đổi thất thường là một điều tốt, nhưng nếu bạn có một kỹ sư có thể thấy cách sửa lỗi và có thời gian để làm điều đó, bạn không nên chặn kỹ sư đó chỉ vì ai đó đã viết mã lỗi. ]

Giải quyết câu hỏi của bạn từ một quan điểm hơi khác, quyền sở hữu mã KHÔNG phải là mùi mã. Nó thay vào đó là một quản lý và cung cấp lại mùi .

Hãy suy nghĩ về những gì một mùi mã có nghĩa. Đó là một phép ẩn dụ cho bạn biết khi bạn xem mã của mình, rằng có gì đó không đúng với mã và / hoặc thiết kế của phần mềm, nhưng vấn đề có thể không rõ ràng đến mức không thể đặt ngón tay vào cái gì vấn đề chính xác có thể là nhưng bạn có thể có một ý tưởng tốt bất kể. Trong nhà của bạn, nếu có thứ gì đó có mùi khó chịu, bạn đi theo mũi cho đến khi bạn xác định được nguồn gốc của vấn đề, và sau đó bạn làm gì đó với nó. Theo cùng một cách, nếu mã có vấn đề, bạn điều tra và thay đổi nó cho đến khi nó trở thành ít vấn đề hơn, hoặc như một số người có thể nói, đẹp hoặc được chế tạo tốt .

Mặt khác, quyền sở hữu mã có thể là một vấn đề nghiêm trọng. Nó cho thấy sự thiếu kiểm soát và rủi ro là nếu chủ sở hữu mã rời đi, kiến ​​thức về mã và các vấn đề cụ thể mà nó giải quyết sẽ không còn có sẵn cho công ty. Điều này không có gì để làm với chính mã thực tế. Về cơ bản, nó dẫn đến một tình huống quản lý rủi ro giống như cách chúng ta giữ các bản sao lưu dữ liệu của mình và áp dụng tương tự như quyền sở hữu nhiệm vụ hoặc quyền sở hữu tài liệu trong các lĩnh vực khác của công ty.

Tôi nghĩ rằng thật tốt khi mô tả các vấn đề kinh doanh khác là mùi , nhưng chắc chắn không ngụ ý rằng chỉ vì có mùi , mà nó đặc biệt liên quan đến mã.

Tôi xác định Quyền sở hữu mã là chịu trách nhiệm cá nhân đối với mã mà bạn viết, với sự hiểu rằng những người khác sẽ làm việc trong mã của bạn trong tương lai . Nếu bạn nghĩ về mọi thứ theo cách này, bạn sẽ ít có khả năng viết một bản hack vì một) lỗi trong mô-đun đó có thể được truy ngược lại cho bạn và b) các thành viên trong nhóm có thể sẽ gặp khó khăn trong việc sửa đổi mã trong tương lai .

Tôi đã viết một bài đăng trên blog này vài tháng trước, nơi tôi lập luận rằng không có quyền sở hữu mã, như tôi định nghĩa, một cơ sở mã hóa thường trở thành con mồi của Bi kịch .

Theo định nghĩa của bạn về quyền sở hữu mã, tôi đồng ý rằng thật tệ khi có mã mà chỉ tác giả mới có thể làm việc.