Quy tắc chưa được viết về việc viết lại mã của thành viên nhóm khác [đã đóng]

Chúng tôi đang thực hành quyền sở hữu mã tập thể. Theo hiểu biết của tôi, điều này có nghĩa là bất kỳ nhà phát triển nào cũng có thể thay đổi bất kỳ dòng mã nào để thêm chức năng, để cấu trúc lại, sửa lỗi hoặc cải thiện thiết kế.

Nhưng những gì về việc viết lại mã hoàn chỉnh từ một nhà phát triển vẫn còn trong nhóm? Tôi có nên hỏi anh ấy trước không? Thực hành tốt nhất là gì?

Tôi nghĩ giao tiếp tốt luôn là thực hành tốt nhất. Nói chuyện với nhà phát triển và xem liệu có lý do tại sao nó được mã hóa theo cách đó không. Có thể là họ đã có ý định quay lại và tái cấu trúc nó từ lâu, có thể là họ đã làm theo cách đó vì một lý do rất tốt, hoặc có thể là cả hai bạn có thể học được điều gì đó từ cuộc trò chuyện.

Đi vào và viết lại mà không có giao tiếp trước là một công thức cho ý chí xấu.

Tiền đề của câu hỏi này đặt ra một số lo ngại cho tôi rằng tôi không nghĩ bất kỳ câu trả lời hiện có nào đang cố gắng giải quyết thỏa đáng. Hãy để tôi hỏi một số câu hỏi tiếp theo ở đây:

1. Bạn có chắc chắn, tích cực chắc chắn rằng bạn đang nói về việc viết lại và không tái cấu trúc? Theo định nghĩa, các thay đổi về kiểu hoặc cấu trúc mã dẫn đến việc triển khai được cải thiện (hoặc đơn giản là khác nhau) mà không thay đổi hành vi bên ngoài là một cấu trúc lại, không phải là viết lại. Việc phá vỡ một thói quen 500 dòng nguyên khối thành một bộ 50 chương trình con có thể liên quan đến việc viết khá nhiều mã mới, nhưng nó không phải là viết lại. Thuật ngữ viết lại ngụ ý vứt bỏ toàn bộ sản phẩm hoặc tính năng và bắt đầu lại từ đầu; nó không phải là một cái gì đó để được xem nhẹ.

2. Nếu hành vi của mã ban đầu quá sai hoặc việc triển khai quá lỗi khi yêu cầu viết lại đầy đủ, tại sao nó không bị quá trình của nhóm của bạn bắt gặp và xử lý trong bối cảnh thích hợp của nó (về mặt kỹ thuật chứ không phải về mặt xã hội)? Mã xấu hoặc nghi vấn phải được phơi bày nhanh chóng trên một nhóm khỏe mạnh thông qua các bài kiểm tra, đánh giá mã, đánh giá thiết kế, v.v. Bạn có những thứ này không?

3. Là người quản lý / lãnh đạo công nghệ nhận thức được vấn đề, và nếu không, tại sao không? Cho dù bạn có loại quy trình nào, chất lượng mã thường là trách nhiệm của người quản lý phát triển. Anh ấy hoặc cô ấy là người đầu tiên bạn nên hỏi - rõ ràng không phải trong bối cảnh "vì vậy và viết mã tào lao" mà chỉ đơn giản là "Tôi nghĩ rằng tôi thấy một vấn đề lớn ở đây, chúng ta có thể nói về việc viết lại không?" Nếu nó không đảm bảo loại thảo luận này, thì có lẽ nó cũng không đảm bảo viết lại?

4. Nếu kích thước và phạm vi của mã vi phạm đủ lớn để đảm bảo thảo luận nghiêm túc về việc viết lại, tại sao nó lại thuộc sở hữu độc quyền của một nhà phát triển? Hầu hết nếu không phải tất cả những lần tôi nhìn thấy mã và nghĩ rằng "viết lại", nó đã bị chà đạp bởi hàng tá người khác nhau và tính xấu là kết quả trực tiếp của sự tích lũy các mâu thuẫn về phong cách, các giả định sai lầm hoặc thay đổi, và cũ kỹ hack thời trang. Mã phát triển gai theo thời gian chính xác vì sở hữu chung của nó.

   Quan điểm của tôi ở đây là, thật kỳ lạ khi một người sẽ sở hữu một lượng lớn mã như vậy trong một môi trường được cho là thực hiện quyền sở hữu tập thể. Có phải những người khác sợ chạm vào mã của nhà phát triển này? Họ có sợ đưa ra chủ đề không? Có thể có một vấn đề tiềm ẩn với nhóm động của bạn, hoặc với nhà phát triển này cụ thể; nếu có, đừng bỏ qua nó. Hoặc, thay vào đó, có lẽ đây là lần đầu tiên bạn làm việc trong dự án này, và nếu vậy, tại sao bạn lại nghĩ về việc viết lại quá sớm trong trò chơi? Một cái gì đó về tình huống dường như không bổ sung cho tôi.

5. Câu hỏi nêu, trong đoạn đầu tiên , any developer can change any line of code to add functionality, to refactor, fix bugs or improve designs. Viết lại sẽ không làm những điều này? Hoặc nó sẽ làm một cái gì đó thêm - và nếu vậy, những gì? Về cơ bản, những gì là lý do của bạn về việc muốn làm một viết lại, và làm thế nào chắc chắn là bạn biết rằng họ sẽ được hưởng lợi sản phẩm hoặc nhóm? Bạn không cần phải trả lời cho tôi, nhưng tốt hơn là bạn nên có một số điểm khách quan để thực hiện nếu và khi bạn chọn thảo luận với nhóm.

Tôi thực sự cảm thấy rằng câu hỏi này đòi hỏi một lượng lớn bối cảnh và không nên được trả lời nếu không có sự hiểu biết rất rõ ràng về bối cảnh đó. Câu trả lời "đúng" hoàn toàn phụ thuộc vào nhóm của bạn, sản phẩm của bạn, tổ chức của bạn, tính cách của bạn, quy trình của bạn, phạm vi của mã gốc, phạm vi của các thay đổi, v.v. Đây là, IMO, một vấn đề mà bạn thực sự cần phải giải quyết với nhóm của mình , không phải trên trang web Hỏi & Đáp trực tuyến.

Tại sao bạn chỉnh sửa mã?

Có lỗi hay đó là một lỗ hổng thiết kế cơ bản hơn?

Trong trường hợp trước, tôi lo lắng về việc viết lại để sửa những gì chỉ là lỗi nhỏ trong mã.

Trong trường hợp thứ hai, trong khi tôi mong đợi một mã dự phòng rằng mã "của tôi" có khả năng được viết lại, tôi hoàn toàn vui mừng khi điều đó xảy ra.

Đó là điểm của quyền sở hữu mã tập thể - mã bạn viết sẽ được sửa đổi hoặc thậm chí thay thế nếu có thứ gì đó tốt hơn xuất hiện.

Nói chung, nếu tất cả các bạn đồng ý rằng tất cả các bạn chịu trách nhiệm về mã, thì bạn có thể viết lại bất kỳ mã nào nếu đó là một cải tiến. Thảo luận với nhà phát triển khác trước như một phép lịch sự. Có thể có những lý do hợp lệ nó được viết theo một cách nhất định. Ở cấp độ cá nhân, nhiều nhà phát triển được đầu tư theo cảm xúc vào những gì họ sản xuất và, như những người khác đã nói, bạn không muốn có ý xấu.

Cụ thể nó phụ thuộc phần nào vào sự năng động của đội. Một nhà phát triển cấp cao sắp viết lại mã của nhà phát triển cơ sở có lẽ nên thực hiện đánh giá mã (trang web của tôi) với họ trước khi chỉ cần viết lại mã. Bằng cách đó, nhà phát triển cơ sở có thể học hỏi từ tình huống.

Nó không thực sự quan trọng nếu nhà phát triển ban đầu có trong nhóm hay không, hoặc thậm chí nếu bạn là nhà phát triển ban đầu. Việc viết lại hoàn toàn bất kỳ mã chia sẻ nào sẽ được nhóm của bạn điều hành, vì những lý do sau:

• Phải mất một lượng thời gian đáng kể. Nếu ai đó đang thực hiện một thay đổi liên quan, bạn không muốn lãng phí thời gian của họ.
• Những người khác có một quan điểm khác. Ngay cả khi bạn đã lập trình 20 năm, một người khác có thể biết những điều về tương tác với mã mà bạn hiếm khi chạm vào.
• Các nhà phát triển khác là "khách hàng" của mã nguồn. Mã nguồn được viết cho các nhà phát triển khác để đọc. Họ có thể có các yêu cầu về kiến ​​trúc, đầu vào về kiểu dáng hoặc các yêu cầu tính năng mà họ muốn có trong mã đó, nhưng không có thời gian. Bạn không muốn hoàn thành một bộ tái cấu trúc chỉ để tìm ra một nhà phát triển khác cần nó được tái cấu trúc theo một cách khác.

Như Matthew Flynn đã nói, cần phải nói chuyện với nhà phát triển trước. Nhà phát triển ban đầu có thể nói những điều quan trọng về chức năng và giải thích lý do tại sao giải pháp này hoặc giải pháp đó được đưa ra.

Nhưng trước khi tái cấu trúc hoặc viết lại mã, hãy tạo một bản sao lưu hoặc nhánh chứa mã đó. Nếu mã cũ hoạt động tốt, sẽ vẫn có khả năng nó có thể được phục hồi.

Nếu bạn có một hệ thống kiểm soát nguồn (mà tôi cho là bạn có), thì nếu có thể, hãy cấu trúc lại toàn bộ mã và chỉ sau đó, khi bạn chắc chắn rằng nó hoạt động tốt, hãy kiểm tra xem.

Không xóa mã cũ, ít nhất là trước khi bạn chắc chắn mã mới hoạt động tốt. Nhưng để lại mã cũ ở đó mãi mãi cũng không phải là một điều tốt. Tôi đề nghị bạn xóa mã một thời gian sau, như trong một tháng sau khi nó vượt qua thử nghiệm.

Phạm vi của nó là gì?

• Nếu bạn đang làm lại một vài dòng để hiệu quả hơn, chỉ cần làm điều đó. Có thể hỏi nếu có một số nguy hiểm của bạn khi xóa hành vi tinh vi. Báo cáo sự thay đổi trong scrum hoặc qua email sau khi hoàn thành, trừ khi nó thực sự tầm thường (sửa lỗi chính tả).

• Nếu bạn đang làm lại một lớp có kích thước vừa phải, có lẽ bạn nên yêu cầu đảm bảo rằng bạn hiểu thiết kế / hành vi. Cho mọi người biết trước để mọi người có thể làm việc trong cùng khu vực có thể nhận thức và phối hợp với bạn.

• Nếu bạn đang làm lại một hệ thống lớn hơn, bạn chắc chắn nên làm việc với nhóm của mình để khiến họ biết về những thay đổi và lên kế hoạch thiết kế.

Nếu các nhà văn ban đầu của bạn ở đó, giao tiếp với họ. Không CHỈ cho ettiquette, nhưng để biết thêm thông tin, trong trường hợp có trường hợp hoặc trường hợp mà bạn không biết. Đôi khi, họ sẽ cho bạn biết điều gì đó có giá trị.

Chúng tôi có kiểm soát mã abysmal. Tôi hiện có rất nhiều thứ cần xem xét và bảo trì, và thậm chí không có ai để xem lại mã. Các nhà văn trước đây (ngoài moi) không buồn bình luận bất kỳ mã nào. Và, họ đã rời khỏi công ty. Không có ai để hỏi về mã.

Khi tôi viết lại, tôi nhận xét, với các bình luận mà tôi đã nhận xét, cũng như ngày và tên / tên viết tắt, và tại sao nó được bình luận. Tôi nhận xét mã mới, với tên hoặc tên viết tắt, ngày, lý do đã được thêm vào, v.v.

Nhận xét bổ sung được thực hiện ở đầu gói (er, thường), cho biết chức năng / procs / SQL / vv. đã được thay đổi, với ngày. Nó giúp bạn dễ dàng tra cứu các phần đã được thay đổi và các phần đó có tài liệu đầy đủ.

Nhận xét là giá rẻ. Ngày sẽ là một chỉ báo về những gì đã thay đổi và sau x số (ngày / lần sửa đổi / thuê mới / nghỉ hưu) thì mã có thể được xóa sạch các nhận xét cũ và phần còn lại là đường cơ sở mới.

Theo quan sát của tôi, thực tiễn chung là: Không bao giờ xóa mã. Chỉ cần bình luận ra và giữ nó.

Thực hành của tôi là nhận xét nó trong khi thay thế nó. (Chủ yếu để tham khảo.) Sau đó xóa nó trên cam kết cuối cùng của thay đổi làm việc. (Điều này yêu cầu kiểm soát phiên bản và hiểu cách hoàn nguyên các thay đổi.)

Khi tôi tìm thấy mã nhận xét cũ, tôi cố gắng xóa nó trong một cam kết riêng với các bình luận thích hợp. Điều này giúp dễ dàng hoàn nguyên hoặc kiểm tra sự thay đổi nếu cần.

Đối với tất cả các thay đổi, bạn sẽ có thể sử dụng lịch sử sửa đổi để xác định (các) nhà phát triển đã tạo mã. (Lịch sử sửa đổi được chú thích giúp ở đây.) Liên hệ với họ nếu có thể để biết lý do tại sao mã là như vậy. Trên nhiều dự án, thời gian dọn dẹp không xảy ra và mọi thứ bị bỏ lại phía sau. Kiểm tra trình theo dõi lỗi để xem có bản ghi dọn dẹp cần thiết không. Đôi khi những thay đổi cần được dọn sạch một hoặc hai bản phát hành sau.

Nếu bạn đang thay đổi mã, sẽ có một lý do bạn đang làm việc với mã đó. Kiểm tra với nhà phát triển ban đầu để tìm hiểu lý do tại sao mã giống như vậy. Nếu có một lý do chính đáng để không sửa nó, hãy thêm một bình luận giải thích tại sao nó không được sửa hoặc tại sao không nên thay đổi. Điều này sẽ tiết kiệm thời gian cho nhà phát triển tiếp theo.

Các thẻ như FixMe, ToDo, Bug và Hack có thể được sử dụng để chỉ ra mã có thể được thay đổi sau này. (Có thể chấp nhận gắn thẻ các giới hạn là Bug và không sửa chúng nếu chúng không được kích hoạt theo các điều kiện bắt buộc.) Có thể là lỗi nếu chương trình kế toán tại nhà vượt quá 20 triệu đô la, nhưng tôi sẽ không lãng phí nhiều thời gian để sửa nó

Các thay đổi đánh giá mã phải được thực hiện bởi nhà phát triển ban đầu nếu nó phù hợp để sửa đổi mã.

Nó có thể phụ thuộc vào lý do tại sao viết lại là cần thiết. Nếu đó là vì có vấn đề với những gì được viết và luôn có vấn đề với nó, thì việc nói về nó được kêu gọi, nếu chỉ để giảm thiểu mức độ thường xuyên phải sửa mã trong tương lai.

Đề nghị của tôi trong trường hợp này là ghép nối khi sửa mã. Bằng cách này, nó cung cấp một ví dụ tốt về các trạng thái trung gian và (hy vọng), một số bối cảnh về lý do tại sao mã viết lại là tốt hơn. Ngoài ra (nếu chỉ là một bài tập cá nhân), hãy thử tái cấu trúc mã để tốt hơn mà không cần viết lại toàn bộ. Nó sẽ khó hơn, nhưng nó tốt cho bạn.

Mặt khác, có một số lần khác khi viết lại được gọi cho:

• Nhóm đã học được rất nhiều kể từ khi mã được viết và các nhà phát triển đã viết nó sẽ viết nó khác đi ngay cả khi không có đầu vào của bạn.

• Một yêu cầu tính năng mới thay đổi tình huống sao cho viết lại mini được nhắm mục tiêu là phù hợp.

Trong những trường hợp này, tôi có lẽ sẽ không bận tâm với một cuộc trò chuyện.

Nghĩ về nó, dường như với tôi rằng mã đã ở đó càng lâu thì cuộc trò chuyện càng ít cần thiết.

Tôi nghĩ rằng @aaronaught đã đưa ra một số điểm tốt, điều này thực sự dẫn đến câu trả lời tôi muốn đưa ra, đó là nó thực sự phụ thuộc vào người thực hiện thay đổi (và tại sao) và ai đã viết mã.

Theo kinh nghiệm cá nhân của tôi, mã thường được thay đổi bởi vì nó không hoạt động như dự định hoặc bạn chỉ cần mở rộng những gì nó thực sự làm.

Trong môi trường Team dev, bạn không cần phải (và có thể không thể) nói chuyện với người viết mã gốc, mọi thứ phải rõ ràng từ mã.

Điều đó dẫn đến câu hỏi tiêu tốn phần lớn thời gian của tôi, đó là ý định của lập trình viên ban đầu, và đó là câu hỏi thường dẫn đến việc mã bị xóa, và đó là lý do tại sao chúng ta nên bình luận mọi thứ, và nơi các lập trình viên thiếu kinh nghiệm nhất thường rơi hôi.

Bất kỳ lập trình viên nào đang thay đổi mã của người khác (tái cấu trúc) thực sự nên là một vấn đề lịch sự và thực hành sao chép cùng một kiểu mã hóa của mã đã có, và trước tiên hãy thực hiện các bước để tìm ra cách mã gốc hoạt động và những gì nó đang cố gắng để, và thực sự sẽ đạt được. Thường thì điều này tự xác định lỗi, nhưng chắc chắn nó buộc mọi người phải chịu đựng nỗi đau mà người tiếp theo sẽ nhìn vào mã của bạn.

Trong nhóm của tôi, bất kỳ ai cũng có thể xóa, tái cấu trúc hoặc viết lại bất cứ điều gì và tôi xem 'quyền sở hữu' là một thực tiễn gây ra sự lười biếng, như thể một người chắc chắn sẽ được thông báo về bất kỳ thay đổi nào, tại sao họ cần phải đọc mã.

Vì vậy, trong ngắn hạn, không, bạn không cần phải hỏi tác giả ban đầu của mã và nếu nhìn vào mã bạn làm, thì đó là dấu hiệu cho thấy mã của anh ta không thể đọc được hoặc bạn cần cải thiện kỹ năng của bạn. Tuy nhiên, tôi thấy đây là một hình thức tốt để giữ nguyên mã gốc, nhận xét, cho đến khi bạn hoàn toàn chắc chắn rằng khi viết lại, bạn đã vô tình xóa chức năng cần thiết. Không ai là hoàn hảo cả.

Mã thường được viết một cách nhất định cho một lý do. Truyền đạt sự thay đổi cho tác giả luôn luôn làm việc tốt nhất.