Làm cách nào để tôi chịu trách nhiệm về mã của mình khi đồng nghiệp thực hiện các cải tiến không cần thiết mà không cần thông báo?


71

Một trong những đồng đội của tôi là người nắm giữ tất cả các giao dịch trong cửa hàng CNTT của chúng tôi và tôi tôn trọng sự sáng suốt của anh ấy.

Tuy nhiên, đôi khi anh ta xem lại mã của tôi (anh ta chỉ huy thứ hai cho trưởng nhóm của chúng tôi, vì vậy điều đó được mong đợi) mà không cần phải đề phòng. Vì vậy, đôi khi anh ấy xem xét các thay đổi của tôi trước khi chúng hoàn thành mục tiêu cuối cùng và thực hiện thay đổi ngay lập tức ... và thậm chí đã phá vỡ công việc của tôi một lần.

Lần khác, anh ấy đã thực hiện những cải tiến không cần thiết đối với một số mã của tôi đã hơn 3 tháng tuổi.

Điều này làm tôi khó chịu vì một vài lý do:

  1. Không phải lúc nào tôi cũng có cơ hội sửa chữa lỗi lầm của mình
  2. Anh ấy đã không dành thời gian để hỏi tôi những gì tôi đã cố gắng thực hiện khi anh ấy bối rối, điều này có thể ảnh hưởng đến thử nghiệm hoặc thay đổi của anh ấy
  3. Tôi không luôn nghĩ rằng mã của anh ấy có thể đọc được
  4. Thời hạn không phải là một vấn đề và khối lượng công việc hiện tại của anh ấy không yêu cầu bất kỳ công việc nào trong các dự án của tôi ngoài việc xem xét các thay đổi mã của tôi.

Dù sao, tôi đã nói với anh ấy trong quá khứ làm ơn giữ cho tôi được đăng nếu anh ấy thấy điều gì đó trong công việc của tôi mà anh ấy muốn thay đổi để tôi có thể sở hữu mã của mình (có lẽ tôi nên nói "thiếu sót") và anh ấy đã không phản hồi .

Tôi sợ rằng tôi có thể trở nên hung hăng khi tôi yêu cầu anh ấy giải thích những thay đổi của anh ấy với tôi.

Anh ta chỉ là một người im lặng giữ mình, nhưng hành động của anh ta vẫn tiếp tục. Tôi không muốn trục xuất anh ấy thực hiện thay đổi mã (không như tôi có thể), bởi vì chúng tôi là một đội - nhưng tôi muốn làm phần của mình để giúp đội của chúng tôi.

Đã làm rõ thêm:

  • Chúng tôi chia sẻ 1 chi nhánh phát triển. Tôi không đợi cho đến khi tất cả các thay đổi của mình hoàn thành một nhiệm vụ vì tôi có nguy cơ mất một số công việc quan trọng - vì vậy tôi đảm bảo các thay đổi của mình được xây dựng và không phá vỡ bất cứ điều gì.
  • Mối quan tâm của tôi là đồng đội của tôi không giải thích lý do hoặc mục đích đằng sau những thay đổi của anh ấy. Tôi không nghĩ anh ấy cần sự phù hộ của tôi, nhưng nếu chúng tôi không đồng ý với cách tiếp cận tôi nghĩ tốt nhất nên thảo luận về ưu và nhược điểm và đưa ra quyết định một khi cả hai chúng tôi hiểu chuyện gì đang xảy ra.
  • Tôi chưa thảo luận điều này với trưởng nhóm của chúng tôi vì tôi muốn giải quyết các bất đồng cá nhân mà không cần quản lý tham gia trừ khi cần thiết. Vì mối quan tâm của tôi dường như là vấn đề cá nhân nhiều hơn là mối đe dọa đối với công việc của chúng tôi, tôi đã chọn không làm phiền nhóm trưởng. Tôi đang làm việc trên các ý tưởng quy trình xem xét mã - để giúp thúc đẩy lợi ích của các đánh giá mã có tổ chức hơn mà không làm cho tất cả về những con thú cưng của tôi.

20
Bạn có sử dụng git, CVS hoặc TFS cho repo mã của mình không? Chỉ cần quay lại cam kết của mình. Cuối cùng anh ta sẽ hiểu được :)

6
Trong org của tôi, tất cả các thay đổi mã được cho là phải trải qua đánh giá một loại nào đó và nó được coi là hình thức kém để kiểm tra thay đổi mà không chú ý đến mô tả thay đổi người đánh giá là ai. Giới thiệu nguyên tắc đó trong tổ chức của bạn có thể là một giải pháp lâu dài cho vấn đề đồng nghiệp kiểm tra các thay đổi đối với mã bạn đã viết mà không cần xem xét.
Carolyn

13
Tại sao bạn có những thay đổi chưa hoàn thành trong một nhánh được chia sẻ? Đó là một ý tưởng tồi, và không chỉ vì lý do bạn gặp phải.
hyde

15
Tất nhiên điều này phụ thuộc vào những gì bạn sử dụng VCS, nhưng đó có thể là điều cần xem xét, bắt đầu sử dụng các chi nhánh nhiều hơn. Với chi nhánh cá nhân, IMO thật tuyệt vời khi bạn có thể cam kết (và đẩy bằng DVCS) bất cứ khi nào bạn cảm thấy thích mà không phải lo lắng và chỉ hợp nhất khi thực hiện với một phần hoặc chỉ hợp nhất một phần khi cần thiết (một DVCS tốt giúp việc này khá dễ dàng). Cũng hoạt động tuyệt vời với đánh giá mã, có thể tự nhiên làm điều đó và khắc phục các sự cố trước khi hợp nhất.
hyde

4
@Jesslyn - Có phải tất cả các nhóm của bạn đều lo ngại rằng đồng đội của bạn đang dành thời gian để thực hiện các cải tiến không cần thiết cho mã cũ? Ít nhất, có vẻ như không hiệu quả đối với đồng đội của bạn khi dành thời gian để thực hiện các thay đổi không cần thiết thay vì làm các nhiệm vụ ưu tiên cao hơn. Ngoài ra, nếu đồng đội của bạn thích dành thời gian "sửa" mã cho bạn hơn là trao quyền cho bạn tự làm điều đó, điều đó có vẻ khá kém hiệu quả. Bạn đã thảo luận về bất kỳ mối quan tâm trong số này với trưởng nhóm của bạn?
Vách đá

Câu trả lời:


81

Tôi nghĩ rằng hầu hết các nhà phát triển đều thấy mình ở vị trí này vào một lúc nào đó và tôi hy vọng rằng mọi nhà phát triển cảm thấy nạn nhân sẽ nhận ra sự bực bội của mình khi trở thành đàn anh và cảm thấy bắt buộc phải làm sạch mã được viết bởi đàn em.

Đối với tôi, tránh xung đột trong tình huống này có hai điều:

  1. Phép lịch sự . Nói chuyện với ai đó về mã của anh ấy / cô ấy cho phép một nhà phát triển biết rằng bạn quan tâm và bạn có thể thảo luận về nó như những chuyên gia trưởng thành.

  2. Quên về "quyền sở hữu mã" - nhóm sở hữu mã . Những người khác muốn thực hiện các thay đổi là một điều tốt. Nếu một nhà phát triển cấp cao thực hiện các thay đổi "không thể đọc được" hoặc tệ hơn, thì hãy sao lưu chúng. Bạn không cần phải gây hấn, chỉ cần cho một biên tập viên biết rằng những thay đổi của anh ấy / cô ấy không hiệu quả, và bạn rất vui khi thảo luận về sự đảo ngược của bạn.

Hãy nhớ rằng, quyền sở hữu nhóm của mã là tuyệt vời và nó cắt giảm cả hai cách. Nếu bạn thấy một cái gì đó không có ý nghĩa trong mã của người khác, thì hãy sửa nó. Sở hữu quá nhiều và giao tiếp không đầy đủ là một cách chắc chắn để tạo ra một môi trường phát triển độc hại.


4
Tôi nghĩ rằng điều đó đã đi xuống Điểm 1 - hãy thảo luận với anh ta. Đếm thực tế là các thay đổi mã so với nhà phát triển ban đầu là quản lý khủng khiếp (tôi không nói là nó không xảy ra) và tôi cho rằng bạn cần kiến ​​nghị để có số liệu tốt hơn. Băng qua cây cầu đó nếu và khi nó xảy ra mặc dù.
Michael

2
Tôi nghĩ đó là những gì tất cả chúng ta nên tập trung vào - nói chung, các đồng đội của bạn không làm bạn xấu đi - đừng dành thời gian để phân tích, hãy trở nên tốt hơn và là một thành viên có giá trị hơn trong nhóm (Tôi biết rằng nói dễ hơn hơn là hoàn thành!)
Michael

7
@Jesslyn, Nếu anh ấy làm điều đó với bạn, rất có thể anh ấy đang làm điều đó với mọi người. Tôi nghi ngờ bất cứ ai đang đếm điều đó chống lại bạn. (Nếu anh ấy không làm điều đó với mọi người, bạn có thể gặp vấn đề khác)
user606723

3
@tgkprog: (1) Tất nhiên, nhận phản hồi từ người khác là rất quan trọng và tôi đã học được một số điều từ việc xem mã của người khác nhưng (2) nếu bạn muốn tìm hiểu lẫn nhau, bạn nên đề xuất thay đổi và thảo luận cùng nhau . Chỉ thay đổi công cụ ngẫu nhiên vì bạn nghĩ rằng mã tốt hơn sau khi thay đổi không phải là phương pháp phù hợp. Có những cách tiếp cận tốt hơn như đánh giá mã bằng các công cụ đánh giá.
Giorgio

2
vâng, tôi đã nghĩ đến những lần tôi đã sửa mã người khác trước hạn chót vào lúc 11 giờ tối nhưng thậm chí sau đó sẽ gửi thư cho nhóm để họ cũng có thể kiểm tra nó, bao gồm cả QA của chúng tôi ....
tgkprog

86

Bạn và hầu hết những người trả lời tiếp cận vấn đề này như một vấn đề giao tiếp giữa hai đồng nghiệp, nhưng tôi thực sự không nghĩ vậy. Những gì bạn mô tả nghe có vẻ giống như một quy trình xem xét mã bị hỏng khủng khiếp hơn bất cứ điều gì khác.

Đầu tiên, bạn đề cập rằng đồng nghiệp của bạn là người chỉ huy thứ hai và dự kiến ​​anh ta sẽ xem lại mã của bạn. Thật tồi tệ. Theo định nghĩa, đánh giá mã ngang hàng không phân cấp và chắc chắn chúng không chỉ là tìm lỗi. Họ cũng có thể cung cấp kinh nghiệm học tập (cho mọi người tham gia), một cơ hội để tương tác xã hội và chứng minh một công cụ có giá trị để xây dựng quyền sở hữu mã tập thể. Thỉnh thoảng bạn cũng nên xem lại mã của anh ấy, học hỏi từ anh ấy và sửa lỗi cho anh ấy khi anh ấy sai (không ai hiểu đúng mọi lúc).

Hơn nữa, bạn đề cập rằng đồng nghiệp của bạn thực hiện thay đổi ngay lập tức. Điều đó cũng sai, nhưng tất nhiên bạn đã biết điều đó; bạn sẽ không hỏi câu hỏi này nếu cách tiếp cận gung ho của anh ấy không phải là vấn đề. Tuy nhiên tôi nghĩ rằng bạn đang tìm kiếm một giải pháp không đúng chỗ. Thành thật mà nói, đồng nghiệp của bạn nhắc nhở tôi một chút về ... tôi, và điều làm việc cho tôi trong những tình huống tương tự là một quy trình đánh giá rõ ràng và vững chắc và một bộ công cụ tuyệt vời. Bạn không thực sự muốn ngăn đồng nghiệp xem lại mã của mình và yêu cầu anh ta dừng lại và nói chuyện với bạn trước khi mọi thay đổi nhỏ không thực sự có hiệu quả. Nó có thể, trong một thời gian, nhưng anh ấy sẽ sớm đạt đến một điểm mà nó sẽ trở nên quá khó chịu và bạn sẽ quay lại nơi bạn bắt đầu, hoặc tệ hơn: anh ấy sẽ ngừng xem lại mã của bạn.

Chìa khóa để giải quyết ở đây có thể là một công cụ đánh giá mã ngang hàng. Tôi thường tránh các đề xuất sản phẩm, nhưng để đánh giá mã Atlassian's Cruciblethực sự là một cứu tinh Những gì nó có vẻ rất đơn giản, và nó là, nhưng điều đó không có nghĩa là nó không tuyệt vời đáng kinh ngạc. Nó kết nối với kho lưu trữ của bạn và cung cấp cho bạn cơ hội để xem xét các thay đổi, tệp hoặc nhóm tệp riêng lẻ. Bạn không được thay đổi bất kỳ mã nào, thay vào đó bạn nhận xét về mọi thứ không hoàn toàn đúng. Và nếu bạn hoàn toàn phải thay đổi mã của người khác, bạn chỉ cần để lại nhận xét với bộ thay đổi giải thích các thay đổi của bạn. Video giới thiệu tại trang sản phẩm của Crucible rất đáng xem nếu bạn muốn biết thêm chi tiết. Giá của Crucible không dành cho tất cả mọi người, nhưng có rất nhiều công cụ đánh giá ngang hàng có sẵn miễn phí. Một người tôi đã làm việc cùng và rất thích là Hội đồng Đánh giá và tôi chắc chắn bạn sẽ tìm thấy nhiều người khác chỉ với một tìm kiếm Google đơn giản.

Dù bạn chọn công cụ nào, nó sẽ thay đổi hoàn toàn quy trình của bạn. Không cần dừng lại, rời khỏi ghế của bạn, ngắt lời người khác và thảo luận về những thay đổi; tất cả những gì bạn cần làm là dành thời gian nghỉ mỗi tuần và xem qua các bình luận (mỗi tuần một lần chỉ là một gợi ý. Bạn biết lịch trình và thói quen hàng ngày của mình tốt hơn tôi). Quan trọng hơn các đánh giá cốt lõi được lưu trữ trong cơ sở dữ liệu ở đâu đó và bạn có thể truy xuất chúng bất cứ lúc nào. Họ không thảo luận sôi nổi xung quanh máy làm mát nước. Trường hợp sử dụng yêu thích của tôi cho các đánh giá cũ là khi giới thiệu một thành viên nhóm mới cho cơ sở mã của chúng tôi. Thật tuyệt khi tôi có thể dẫn một người mới qua codebase chỉ ra chính xác nơi chúng tôi bị mắc kẹt, nơi chúng tôi có ý kiến ​​khác nhau, v.v.

Tiếp tục, bạn đề cập rằng bạn không phải lúc nào cũng tìm thấy mã của đồng nghiệp này có thể đọc được. Điều đó cho tôi biết rằng bạn không có một bộ tiêu chuẩn mã hóa chung và đó là một điều tồi tệ. Một lần nữa bạn có thể tiếp cận vấn đề này như một vấn đề của mọi người hoặc bạn có thể tiếp cận vấn đề này như một vấn đề quy trình, và một lần nữa tôi sẽ đề nghị mạnh mẽ vấn đề sau. Kết hợp nhóm của bạn và áp dụng một phong cách mã hóa chung và thiết lập các tiêu chuẩn càng sớm càng tốt. Sẽ không có vấn đề gì nếu bạn chọn một bộ tiêu chuẩn phổ biến trong hệ sinh thái phát triển của bạn hoặc bạn tự đưa ra. Điều thực sự quan trọng là các tiêu chuẩn của bạn phải nhất quán và bạn tuân thủ chúng. Có rất nhiều công cụ có thể giúp bạn, nhưng đó là một cuộc thảo luận hoàn toàn khác. Chỉ để bạn bắt đầu, một điều rất đơn giản để làm là có một hook pre-commit chạy một số loại định dạng kiểu trên mã của bạn. Bạn có thể tiếp tục viết mã theo cách bạn muốn và để công cụ "sửa lỗi" tự động trước khi bất kỳ ai khác nhìn thấy mã đó.

Cuối cùng, bạn đề cập đến trong một bình luận rằng quản lý không tin rằng các nhánh dev riêng lẻ là cần thiết. Chà, có một lý do chúng tôi gọi chúng là "nhánh dev" chứ không phải "nhánh quản lý". Tôi sẽ dừng lại ở đây vì không có lý do gì để cơn thịnh nộ hình thành trong đầu tôi thoát ra.

Tất cả những gì đã nói, hãy biết rằng tôi không nghi ngờ đồng nghiệp của bạn là (một chút) có lỗi ở đây. Đó không phải là quan điểm của tôi, quan điểm của tôi là toàn bộ quá trình phát triển của bạn cũng có lỗi và đó là điều dễ khắc phục hơn. Trang bị cho mình các công cụ thích hợp, khám phá nhiều quy trình chính thức và không chính thức và chọn những quy trình phù hợp với nhóm của bạn. Bạn sẽ sớm đạt đến một điểm mà bạn sẽ nhận ra rằng hầu hết "vấn đề con người" của bạn không còn tồn tại nữa. Và xin đừng nghe bất cứ ai (kể cả chính bạn) đưa ra lý do "chúng tôi là một nhóm nhỏ, chúng tôi không cần tất cả những điều đó". Một nhóm các nhà phát triển có thẩm quyền có thể thiết lập các công cụ cần thiết trong vòng chưa đầy một tuần, tự động hóa mọi thứ có thể được tự động hóa và không bao giờ nhìn lại.

Tái bút "Quyền sở hữu mã" là một thuật ngữ mơ hồ, liên tục được tranh luận và nó có nghĩa là những điều khác nhau đối với những người khác nhau. Bạn có thể tìm thấy một bộ sưu tập tuyệt vời của hầu hết các ý kiến ​​khác nhau (và đôi khi phản đối) về C2 .


7
+1 và hơn thế nữa nếu tôi có thể. Câu trả lời tuyệt vời giải quyết những cách tốt nhất để cải thiện một quá trình như vậy.
Waldfee

2
Có, OP cần một công cụ đánh giá mã, theo cách đó bạn có thể cùng nhau xem lại mã, đó không chỉ là ai đó thay đổi mã bởi vì họ cảm thấy thích nó. Chúng tôi mới bắt đầu sử dụng smartbear.com/products/software-development/code-review tại nơi làm việc
Juan Mendes

19

Quy trình khiến bạn muốn chịu trách nhiệm về "mã của bạn" là gì? Bạn có trách nhiệm duy nhất để giữ cho các tính năng nhất định hoạt động? Có phải người dẫn đầu đã nói "Michael, tôi muốn bạn chịu trách nhiệm cho ..."? Hoặc là trách nhiệm của bạn tiềm ẩn, trong đó người dẫn đầu và phần còn lại của nhóm tìm đến bạn mỗi khi một số tính năng nhất định bị hỏng?

Dù bằng cách nào, nếu bạn có trách nhiệm, thì bạn cần có thẩm quyền đối với mã. Lần tới khi đồng nghiệp khác thực hiện các thay đổi đơn phương và người dẫn đầu quay lại với bạn để sửa chúng, bạn nên ngồi xuống với người dẫn đầu và yêu cầu căn chỉnh thẩm quyền và trách nhiệm của bạn.


5
+1 Để chỉ ra một thực tế quan trọng: Có quyền sở hữu nhóm và (1) tất cả đều chịu trách nhiệm (2) mọi người đều có thể thay đổi mã hoặc có quyền sở hữu cá nhân và (1) chủ sở hữu mô-đun chịu trách nhiệm (2) mọi thay đổi phải được sự chấp thuận của chủ sở hữu mô-đun. Thông thường sự nhầm lẫn xuất hiện khi một thành viên trong nhóm dự kiến ​​sẽ chịu trách nhiệm cho một mô-đun, nhưng một thành viên cấp cao cảm thấy có quyền thực hiện các thay đổi ngẫu nhiên cho mã. Nói cách khác, người ta phải tránh tình trạng "trách nhiệm mà không có thẩm quyền".
Giorgio

4

Không phải điều này sẽ giải quyết toàn bộ tình huống, nhưng bạn có thể thử thêm nhiều bình luận vào mã nguồn của mình.

  1. Nếu mã không đầy đủ, nó có thể được đánh dấu như vậy.
  2. Nếu mục đích của một khối mã không phải là tài liệu tự, thì bạn nên ghi lại nó.

Tất cả và tất cả, cố gắng làm nước chanh thay vì lãng phí thời gian hút chanh. Như Michael đã nói, nói chung, đồng đội không làm bạn xấu đi. Cố gắng học hỏi từ những sai lầm của bạn và áp dụng chúng cho các phiên bản trong tương lai.

Nếu bạn tin rằng những thay đổi của anh ấy đang có tác động tiêu cực, xin vui lòng nói điều này (về mặt ngoại giao). Nếu là tôi, tôi chỉ cần hỏi tại sao những thay đổi cụ thể được thực hiện và xem liệu bạn có thể bảo vệ những thay đổi ban đầu của mình không. Đồng nghiệp cao cấp của bạn cũng là con người. Rất có thể anh ta đã bỏ lỡ điều gì đó và / hoặc không biết về bất kỳ tác động tiêu cực nào mà anh ta đang cung cấp.


3
Cậu bé có thể gây nhầm lẫn. Hãy tưởng tượng - thêm một nhận xét cho biết, "Mã này chưa hoàn thành" và sau đó quên xóa nó sau khi bạn hoàn thành mã.
riwalk

1
@ Stargazer712, Khó hiểu hơn là có mã không đầy đủ trong chi nhánh?
user606723

Đó là những gì kệ dành cho. Đừng kiểm tra mã không đầy đủ.
riwalk

2
Không. Nếu bạn kiểm tra mã không đầy đủ cần một nhận xét để gắn nhãn như vậy, thì bạn đã ở trong địa ngục. Bình luận chỉ đưa bạn đến một góc khác của địa ngục.
riwalk

1
Chúng được gọi là TODO, chúng luôn bị bỏ lại trong mã làm việc
Juan Mendes

4

Mọi người đều mặc nhiên 'sở hữu mã riêng của họ', bất kể chính trị, pháp lý hoặc kinh tế - đó là 'bản chất của mọi thứ' - bạn tự nhiên cảm thấy có mối liên hệ cá nhân với công việc của chính bạn.

Nếu đồng nghiệp của bạn đang tham gia vào hành vi mà bạn mô tả và vẫn không phản hồi khi bạn yêu cầu một người đứng đầu , thì đồng nghiệp đó là người bất lịch sự, nói ít nhất, và có thể đang cố làm suy yếu bạn (để nói điều tồi tệ nhất .. .) - KHÔNG giống như một người chơi nhóm.

Một đồng nghiệp tốt sẽ liên lạc với bạn và chỉ ra vấn đề với mã của bạn cho bạn - và cho phép bạn sửa / thay đổi nó, hoặc trả lời thích hợp. Tôi rất biết ơn rằng ngay cả khi tôi là một người mới, những người cố vấn của tôi luôn chỉ cho tôi những gì tôi đã làm sai, giải thích lý do và để (hoặc thực hiện ) tôi sửa chữa nó. Điều đó làm cho tôi trở thành một lập trình viên tốt hơn và mọi người đều được hưởng lợi. Và đó là những gì tôi đã luôn luôn làm khi xem xét công việc được thực hiện bởi những người khác. Sau đó, bạn, (hoặc bất cứ ai) thực sự học được điều gì đó từ 'tất cả các giao dịch' của bạn, và mã và nhóm đều trở nên tốt hơn, bao gồm cả giáo viên của bạn: Dạy giúp hiểu.

Nếu có thể, tôi sẽ thảo luận vấn đề riêng tư với Trưởng nhóm. Dựa trên mô tả của bạn về tình huống, một người lãnh đạo nhóm tốt sẽ đứng về phía bạn - một người xấu sẽ không .... Rõ ràng điều này đòi hỏi sự thận trọng - bạn sẽ phải tự đánh giá điều đó.


1
Ngoài tuyên bố ban đầu (có những nhóm chấp nhận quyền sở hữu nhóm và các nhóm khác áp dụng quyền sở hữu cá nhân), tôi thấy các quan sát trong câu trả lời này OK (+1 cho điều này): Tôi cũng đã quan sát thấy quyền sở hữu mã được chia sẻ được sử dụng để phá hoại một nhóm vị trí của thành viên trong nhóm bằng cách tự ý sửa đổi mã của họ. Vì vậy, tôi không hiểu các downvote. Sẽ là tốt nếu các downvoters quan tâm để giải thích.
Giorgio

1
Tôi nghĩ câu trả lời của Mike là lời giải thích tốt về cách tôi ở lại một cầu thủ đội. Có lẽ đây là quá tập trung mọi người? Giống như Yannis đề xuất, quá trình phát triển nhóm của tôi có vẻ là vấn đề thực sự. Bất kể tôi tò mò về lý do tại sao điều này đã bị hạ thấp.
Jesslyn

1
@Jesslyn - Tôi phỏng đoán tôi đã bị hạ thấp vì câu nói của tôi "Mọi người đều ngầm 'sở hữu mã riêng của họ'". Đây là một câu hỏi triết học, không phải là một câu hỏi chính sách. :-)
Vector

1
@Mikey: "Tất cả mọi người đều 'sở hữu mã riêng của họ'" Tất nhiên đây có thể là vấn đề tranh luận. Các lập trình viên không tự làm chủ thường ký hợp đồng nói rằng họ không sở hữu mã nguồn. Ngoài ra, tôi nghĩ rằng tác giả của mã là người hiểu mã tốt nhất và nếu người khác thay đổi mã, thì cả tác giả lẫn nhà phát triển thứ hai đều không thực sự hiểu mã 100%.
Giorgio

1
@Mikey: Quyền sở hữu mã được chia sẻ cố gắng đảm bảo rằng các thành viên trong nhóm đủ hiểu mã đủ tốt (trong khi không ai thực sự hiểu nó thực sự tốt). Điều này tốt hơn cho quyền sở hữu mã riêng lẻ, trong đó mỗi mô-đun (ít nhất là về nguyên tắc) được hiểu bởi một lập trình viên, nhưng có nguy cơ kiến ​​thức này bị mất nếu lập trình viên đó thoát ra.
Giorgio

1

Nếu bạn viết mã, thì tôi nên xem lại.

Nếu tôi thay đổi mã của bạn trong quá trình đánh giá, thì mã đó không còn là mã mà tôi đã xem xét mà là mã mà tôi đã thay đổi. Do đó nó cần được xem xét. Có lẽ là do bạn.

Nếu tôi cam kết mã mới của bạn với các thay đổi của tôi mà không có ai xem xét các thay đổi của tôi, thì tôi đã cam kết (1) thay đổi chưa được xem xét và (2) tội lỗi tồi tệ nhất có thể xảy ra nếu đánh giá mã được thực hiện nghiêm túc.


0

Tôi nghĩ rằng bạn đang xử lý nó đúng cách ngay bây giờ - nhưng sẽ sớm có một điểm bùng phát trong đó nó làm bạn mất tập trung đến mức bạn có thể không hài lòng khi viết mã theo cách này.

Nếu tôi là bạn, tôi sẽ yêu cầu một người nhanh chóng với người này và giải thích PoV của tôi một cách bình tĩnh nhưng chắc chắn. Đội ngũ sở hữu mã, v.v ... đều ổn nhưng trừ khi bạn cung cấp cho mọi nhà phát triển đủ không gian để đưa công việc của mình ra, phạm sai lầm và cải thiện, bạn sẽ không bao giờ xây dựng mã tốt. Đây có thể là một khu vực ma sát sớm hơn là sau này.

(Có một câu trả lời hoàn toàn khác nếu đây là ở nơi làm việc.stackexchange. Tìm ra cách chính xác để thực hiện đánh giá mã là một chút dễ dàng. Thuyết phục đồng nghiệp của bạn tuân thủ điều này khó hơn rất nhiều).

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.