Bạn nói gì trong một đánh giá mã khi người khác xây dựng một giải pháp quá phức tạp? [đóng cửa]

Hôm nọ tôi đã xem lại mã ai đó trong nhóm của tôi đã viết. Giải pháp không đầy đủ chức năng và thiết kế đã quá phức tạp - nghĩa là lưu trữ thông tin không cần thiết, xây dựng các tính năng không cần thiết và về cơ bản mã có nhiều phức tạp không cần thiết như mạ vàng và nó đã cố gắng giải quyết các vấn đề không tồn tại.

Trong tình huống này tôi hỏi "tại sao nó được thực hiện theo cách này?"

Câu trả lời là người khác cảm thấy muốn làm theo cách đó.

Sau đó, tôi hỏi liệu bất kỳ tính năng nào trong số này là một phần của thông số dự án, hoặc liệu chúng có sử dụng cho người dùng cuối hay không, nếu có bất kỳ dữ liệu bổ sung nào sẽ được trình bày cho người dùng cuối.

Câu trả lời là không.

Vì vậy, sau đó tôi đề nghị anh ta xóa tất cả sự phức tạp không cần thiết. Câu trả lời tôi thường nhận được là "nó đã được thực hiện".

Quan điểm của tôi là nó không được thực hiện, nó có lỗi, nó không làm những gì người dùng muốn và chi phí bảo trì sẽ cao hơn nếu nó được thực hiện theo cách đơn giản hơn tôi đề xuất.

Một kịch bản tương đương là:
Đồng nghiệp dành 8 giờ để tái cấu trúc mã bằng tay, có thể được thực hiện tự động trong Resharper sau 10 giây. Đương nhiên, tôi không tin tưởng vào việc tái cấu trúc bằng tay vì nó có chất lượng đáng ngờ và chưa được kiểm tra đầy đủ.
Một lần nữa, phản hồi tôi nhận được là "nó đã được thực hiện."

Một phản ứng thích hợp cho thái độ này là gì?

Tâm trạng / thái độ

• Dẫn bằng ví dụ
• Khuyên bảo riêng tư (một đối một, ngoài đánh giá mã)
• Khuyến khích một tâm lý đơn giản giữa các thành viên trong nhóm

Quản lý đội

• Dành nhiều thời gian hơn cho đặc tả của một mục công việc (như kiến ​​trúc, phác thảo thuật toán, khung dây UI, v.v.)
• Khuyến khích các thành viên trong nhóm tìm kiếm làm rõ về phạm vi của một mục công việc
• Khuyến khích các thành viên trong nhóm thảo luận về cách thực hiện một mục công việc
• Ước tính hợp lý cho từng hạng mục công việc trước khi bắt đầu và nỗ lực hết sức để đáp ứng chúng
• Theo dõi sự "cải thiện" của các thành viên trong nhóm.
  • Sau khi được khuyên răn hoặc được chỉ dẫn cách làm việc đúng đắn, hãy xem thành viên trong nhóm có tiến bộ không.

Cấp độ kỹ năng

• Phân bổ thời gian cho các phiên lập trình cặp hoặc các buổi đào tạo một-một để sử dụng tốt nhất các công cụ dành cho nhà phát triển (tái cấu trúc, xem lại mã)

Quản lý dự án (rủi ro)

• Tiến hành xem xét mã thường xuyên hơn, không đồng bộ (Lưu ý)
  • Lưu ý về "không đồng bộ"
    • Người đánh giá mã sẽ nhận được thông báo / lời mời để xem xét các thay đổi ngay khi được cam kết
    • Người đánh giá mã nên có cơ hội xem lại mã trước bất kỳ cuộc họp nào với nhà phát triển.
    • Nếu cần làm rõ từ nhà phát triển, hãy thực hiện một cách không chính thức trên IM / email mà không đưa ra ý kiến ​​tiêu cực

Bạn nói gì trong một đánh giá mã khi người khác xây dựng một giải pháp quá phức tạp?

Bạn nói: "bạn đã xây dựng một giải pháp quá phức tạp."

Vì vậy, sau đó tôi đề nghị anh ta xóa tất cả sự phức tạp không cần thiết. Câu trả lời tôi thường nhận được là "nó đã được thực hiện."

Nếu quá muộn để thay đổi bất cứ điều gì, tại sao bạn lại thực hiện đánh giá mã?

"Nó đã được thực hiện" không phải là một câu trả lời thỏa mãn. Xong có nghĩa là thử nghiệm và làm việc. Mỗi mã bổ sung không làm gì hữu ích nên được duy trì đúng cách (đã xóa).

Giao cho anh ta nhiệm vụ này một lần nữa yêu cầu tái cấu trúc và tối ưu hóa giải pháp của anh ta. Nếu anh ta không làm điều đó, chỉ định cho anh ta một lập trình viên cặp và hy vọng anh ta sẽ học được điều gì đó từ đồng nghiệp.

Vì vậy, sau đó tôi đề nghị anh ta xóa tất cả sự phức tạp không cần thiết. Câu trả lời tôi thường nhận được là "nó đã được thực hiện".

Đó không phải là một câu trả lời chấp nhận được:

• Nếu thực sự quá muộn để thay đổi, thì việc xem xét mã sẽ gây lãng phí thời gian và ban quản lý cần phải biết điều này.

• Nếu đó thực sự là một cách để nói "Tôi không muốn thay đổi", thì bạn cần phải đảm bảo rằng sự phức tạp thêm là BAD cho codebase BECAUSE của các vấn đề / chi phí sẽ xảy ra sau này. Và giảm tiềm năng cho các vấn đề trong tương lai, lý do thực sự khiến bạn thực hiện đánh giá mã ngay từ đầu.

Và ...

... giải pháp không đầy đủ chức năng ...

Đó hoàn toàn có thể là kết quả trực tiếp của sự phức tạp không cần thiết. Lập trình viên đã làm cho nó phức tạp đến mức anh ta không còn hiểu đầy đủ về nó và / hoặc anh ta đã lãng phí thời gian để thực hiện sự phức tạp của mình hơn là các điểm chức năng. Sẽ đáng để chỉ ra cho các lập trình viên rằng việc cắt bỏ sự phức tạp thực sự có thể đưa anh ta đến một chương trình làm việc nhanh hơn.

Bây giờ, có vẻ như bạn không có sức mạnh (hoặc có thể tự tin) để "đẩy lùi khó khăn" về điều này. Nhưng ngay cả như vậy, cũng đáng để gây ồn ào về việc này (mà không cá nhân hóa nó) với hy vọng rằng lập trình viên vi phạm sẽ làm việc tốt hơn ... vào lần tới.

Một phản ứng thích hợp cho thái độ này là gì?

Cuối cùng, hãy chú ý đến quản lý ... trừ khi bạn có quyền tự sửa nó. (Tất nhiên, điều này sẽ không khiến bạn nổi tiếng.)

Bạn đã đúng, họ đã sai:

• nguyên tắc YAGNI bị hỏng
• nguyên tắc KISS bị phá vỡ
• mã đã được kiểm tra đầy đủ chưa? Nếu không, thì nó không được thực hiện

Một phản ứng thích hợp cho thái độ này là gì?

Làm mã xem xét thích hợp. Nếu họ từ chối thực hiện các thay đổi được đề xuất mà không có lý do, thì hãy ngừng lãng phí thời gian của bạn để đánh giá mã. Bạn cũng có thể leo thang vấn đề với ông chủ của họ .

Một hành động mà nhóm của chúng tôi đã thực hiện, cải thiện đáng kể tình hình trong những trường hợp như vậy, là chuyển sang các thay đổi nhỏ hơn nhiều .

Thay vì làm một nhiệm vụ trong một ngày hoặc hơn và sau đó xem xét mã (lớn), chúng tôi cố gắng kiểm tra thường xuyên hơn (tối đa 10 lần một ngày). Tất nhiên điều này cũng có một số nhược điểm, ví dụ người đánh giá cần rất nhạy, điều này làm giảm đầu ra của chính nó (do bị gián đoạn thường xuyên).

Ưu điểm là, các vấn đề được phát hiện và có thể được giải quyết sớm, trước khi một lượng lớn công việc sai cách được thực hiện.

Bạn nên tập trung vào nguyên nhân gốc rễ của vấn đề:

1. Giáo dục lập trình viên tập trung vào việc tăng độ phức tạp cho các lập trình viên. Khả năng để làm điều này đã được thử nghiệm bởi các trường học. Do đó, nhiều lập trình viên sẽ nghĩ rằng nếu họ thực hiện giải pháp đơn giản, họ đã không thực hiện đúng công việc của mình.
2. Nếu lập trình viên theo mô hình tương tự mà anh ta đã thực hiện hàng trăm lần khi còn ở trường đại học, thì đó chỉ là cách các lập trình viên nghĩ - sự phức tạp hơn sẽ khó khăn hơn và do đó tốt hơn.
3. Vì vậy, để khắc phục điều này, bạn sẽ cần phải phân tách chặt chẽ những gì yêu cầu của công ty bạn liên quan đến sự phức tạp so với những gì thường được yêu cầu trong giáo dục lập trình viên. Kế hoạch tốt là một quy tắc như "mức độ phức tạp cao nhất chỉ nên dành riêng cho các nhiệm vụ được thiết kế để cải thiện kỹ năng của bạn - và không nên sử dụng nó trong mã sản xuất".
4. Nó sẽ trở thành một bất ngờ đối với nhiều lập trình viên rằng họ không được phép thực hiện các thiết kế điên rồ nhất của họ trong môi trường mã sản xuất quan trọng. Chỉ cần dành thời gian cho các lập trình viên thực hiện các thiết kế thử nghiệm, và sau đó giữ tất cả sự phức tạp ở phía bên kia của hàng rào.

(trong phần đánh giá mã đã quá muộn để thay đổi nó)

Tôi không biết bất cứ điều gì hoạt động sau khi mã được viết.

Trước khi mã được viết, mọi người có thể thảo luận về các cách khác để làm điều đó. Chìa khóa là đóng góp ý tưởng cho nhau, vì vậy hy vọng một ý tưởng hợp lý sẽ được chọn.

Có một cách tiếp cận khác làm việc với các nhà thầu - hợp đồng giá cố định. Giải pháp càng đơn giản, lập trình viên $$ càng được giữ.

Bạn không thể sửa chữa thế giới.

Bạn thậm chí không thể sửa tất cả các mã trong dự án của bạn. Bạn có thể không thể sửa các thực tiễn phát triển trong dự án của mình, ít nhất là không phải trong tháng này.

Đáng buồn thay, những gì bạn đang trải nghiệm trong đánh giá mã là quá phổ biến. Tôi đã làm việc tại một vài tổ chức nơi tôi thấy thường thấy mình đang xem xét 100 dòng mã có thể được viết thành mười và tôi nhận được câu trả lời giống như bạn đã làm: "Nó đã được viết và thử nghiệm" hoặc "Chúng tôi đang tìm kiếm lỗi, không phải là thiết kế lại. "

Thực tế là một số đồng nghiệp của bạn không thể lập trình tốt như bạn có thể. Một số trong số họ có thể là khá xấu về nó. Đừng lo lắng về điều đó. Một vài lớp có thực hiện xấu sẽ không làm giảm dự án. Thay vào đó, tập trung vào các phần công việc của họ sẽ ảnh hưởng đến người khác. Các bài kiểm tra đơn vị có đầy đủ (nếu bạn có chúng)? Giao diện có sử dụng được không? Nó được ghi nhận?

Nếu giao diện cho mã xấu vẫn ổn, đừng lo lắng về nó cho đến khi bạn phải duy trì nó, sau đó viết lại. Nếu bất kỳ ai phàn nàn, chỉ cần gọi nó là tái cấu trúc. Nếu họ vẫn phàn nàn, hãy tìm một vị trí trong một tổ chức tinh vi hơn.

Cần có một chính sách tiêu chuẩn trong dự án kiểm soát các quy trình và công cụ kiểm tra chất lượng có thể cung cấp được sử dụng.

Mọi người nên biết những gì họ nên làm và những công cụ nào được chấp nhận để sử dụng trong dự án này.

Nếu bạn chưa làm điều này, hãy sắp xếp suy nghĩ của bạn và thực hiện nó.

Đánh giá mã nên có một danh sách kiểm tra các mặt hàng tiêu chuẩn. Nếu bạn nhận được "nó đã được thực hiện" và nó thì không, cá nhân tôi sẽ không muốn chịu trách nhiệm cho công việc của nhà phát triển này với tư cách là người quản lý dự án hoặc nhà phát triển cao cấp. Thái độ này không được dung thứ. Tôi có thể hiểu tranh luận về cách làm một cái gì đó hoặc thậm chí mọi thứ, nhưng một khi giải pháp được chấp nhận, nói dối không nên được dung thứ và điều đó nên được nêu rõ.

Cửa hàng của bạn cần phải thực thi một số phương pháp thiết kế.

• Yêu cầu cần được xác định rõ ràng.
• Bạn cần phát triển các trường hợp sử dụng hỗ trợ các yêu cầu.
• Bạn cần chỉ định các chức năng cần thiết để thực hiện các trường hợp sử dụng.
• Bạn cần chỉ định bất kỳ yêu cầu phi chức năng nào (thời gian đáp ứng, tính khả dụng, v.v.)
• Bạn cần một RTM (Yêu cầu Tracabilty Matrix) để ánh xạ từng chức năng hệ thống trở lại trường hợp sử dụng và yêu cầu thực tế.
• Bỏ bất kỳ chức năng nào không hỗ trợ một yêu cầu thực tế.
• Cuối cùng, trong mã đánh giá mã của bạn, bất kỳ mã nào không trực tiếp triển khai hoặc hỗ trợ các hàm được xác định.

Có lẽ không phải là nó quá phức tạp vì điều đó khiến hầu hết mọi người cảm thấy tồi tệ sau đó. Tôi giả sử rằng khi điều này xảy ra, rất nhiều mã đã được viết mà không nói một từ nào về nó. (Tại sao lại như vậy? Bởi vì người đó có đủ thẩm quyền nên mã của anh ta không phải được xem xét trong thực tế?)

Nếu không, tôi đoán để làm cho mã đánh giá ít chính thức hơn nhưng thường xuyên hơn. Và trước khi viết các mô-đun lớn, có lẽ bạn nên nhanh chóng thảo luận về cách tiếp cận.

Nói "điều này quá phức tạp" sẽ không đưa bạn đến đâu cả.

Thật không may, nhưng Code Reviews, rất nhiều lần, cho tương lai nhiều hơn là cho hiện tại. Đặc biệt trong môi trường doanh nghiệp / doanh nghiệp, mã vận chuyển luôn có giá trị hơn mã không được chuyển.

Tất nhiên, điều này phụ thuộc vào thời điểm đánh giá mã được hoàn thành. Nếu đó là một phần của quá trình phát triển, thì bạn có thể đạt được một số lợi ích ngay bây giờ. Nhưng nếu CR được coi là nhiều hơn sau khi chết, thì tốt nhất bạn nên chỉ ra những gì có thể làm tốt hơn trong tương lai. Trong trường hợp của bạn (như những người khác đã nói), hãy chỉ ra YAGNI và KISS nói chung, và có lẽ một số lĩnh vực cụ thể nơi các nguyên tắc này có thể được áp dụng.

Không quá phức tạp có nghĩa là gì? Bạn đưa ra một tuyên bố mơ hồ sau đó bạn sẽ nhận được một câu trả lời mơ hồ / không thỏa mãn trong phản ứng. Những gì quá phức tạp với một người là hoàn hảo cho người khác.

Mục đích của đánh giá là chỉ ra các vấn đề và lỗi cụ thể, không nói rằng bạn không thích nó, đó là điều mà tuyên bố "quá phức tạp" ngụ ý.

Nếu bạn thấy một vấn đề (quá phức tạp) thì hãy nói điều gì đó cụ thể hơn như:

• Sẽ không thay đổi phần X thành Y để đơn giản hóa mã hoặc làm cho nó dễ hiểu hơn?
• Tôi không hiểu những gì bạn đang làm ở đây trong phần X, tôi nghĩ những gì bạn đang cố gắng làm là đây. Trình bày một cách sạch hơn để làm điều đó.
• Làm thế nào bạn kiểm tra điều này? Bạn đã kiểm tra điều này? Nếu nó quá phức tạp, điều này thường sẽ dẫn đến những cái nhìn trống rỗng. Yêu cầu kiểm tra sau đó sẽ thường xuyên khiến người đó tự đơn giản hóa mã của họ khi họ không thể tìm ra cách kiểm tra mã gốc.
• Dường như có một lỗi ở đây, việc thay đổi mã thành điều này sẽ khắc phục vấn đề.

Bất cứ ai cũng có thể chỉ ra vấn đề, đặc biệt là những vấn đề mơ hồ. Có một tập hợp con nhỏ hơn nhiều có thể trình bày các giải pháp. Nhận xét đánh giá của bạn nên càng cụ thể càng tốt. Nói điều gì đó quá phức tạp không có nghĩa gì nhiều, thậm chí có thể khiến người khác nghĩ rằng BẠN không đủ năng lực vì không thể hiểu được mã. Hãy nhớ rằng hầu hết các nhà phát triển không có manh mối về sự khác biệt giữa thiết kế tốt hay xấu.

Đôi khi nó đáng để tập trung vào một số nguyên tắc "Nhanh nhẹn" - chúng có thể giúp một nhóm hoặc cá nhân dường như hơi lạc lõng.

Tập trung không có nghĩa là một số hoạt động lớn tuyệt vời của nhóm của bạn, nhưng tất cả bạn nên ngồi xuống và thảo luận về những thực tiễn nào được nhập khẩu nhiều nhất cho bạn với tư cách là một nhóm. Tôi muốn đề xuất thảo luận ít nhất về những điều này (và có lẽ khá nhiều nữa):

• Làm điều đơn giản nhất có thể có thể làm việc?
• Bạn sẽ không cần nó (bạn đang giải quyết vấn đề không có trong thông số kỹ thuật)
• Viết bài kiểm tra trước khi mã hóa (Giúp bạn tập trung mã của mình)
• Đừng lặp lại chính mình

Ngoài ra, thỉnh thoảng (Hàng tuần?) Đánh giá về những gì hoạt động, những gì không và những gì vẫn cần thiết có thể thực sự hữu ích ... Nếu không có gì khác, tại sao không cam kết một giờ mỗi tuần để thảo luận về giá trị và thực tiễn của nhóm?

Nâng cao, nếu bạn có một người quản lý có đầu óc kỹ thuật. Điều này nghe có vẻ như một thói quen cần phải được phá vỡ.

Nếu mã không được xây dựng để đặc tả, thì theo định nghĩa, nó sẽ không xem lại mã. Tôi không hiểu khái niệm "chúng tôi đã làm một cái gì đó mà không ai yêu cầu, và nó không hoạt động nên chúng tôi sẽ để nó ở đó thay vì làm một cái gì đó mà ai đó yêu cầu làm việc đó".

Đây là một thói quen xấu cho bất kỳ nhà phát triển nào. Nếu anh ấy / cô ấy đang làm việc với một thông số thiết kế thì không phù hợp với nó mà không có lý do chính đáng là không.

Một từ: nhanh nhẹn

Nó chắc chắn không giải quyết mọi thứ. Nhưng bằng cách trị vì trong các lần lặp của bạn (ví dụ 1-2 tuần), hạn chế công việc đang tiến triển và tận dụng kế hoạch / đánh giá nước rút, bạn nên tránh những sai lầm giống như thác nước này. Bạn cần có tầm nhìn tốt hơn về những gì thực sự được thực hiện - trong khi nó đang được thực hiện.

Để phát triển dựa trên dự án bình thường, tôi khuyên bạn nên áp dụng phương pháp Scrum . Đối với môi trường phát triển / tích hợp liên tục, và đặc biệt là nếu bạn có nhiều nhà phát triển làm việc trên các dự án tương tự hoặc có liên quan, xem xét kết hợp các yếu tố của Kanban . Một cách tiếp cận hiệu quả khác là tận dụng lập trình cặp , một thực tiễn được xác định của lập trình Extreme .

Tình huống của bạn hầu như không phải là duy nhất. Và ngay cả với các nhóm nhỏ, quá trình có thể đi một chặng đường dài để giúp tránh tình trạng hiện tại của bạn. Với tầm nhìn phù hợp và tồn đọng hợp lý, các câu hỏi như thế này trở thành quyết định lập kế hoạch nước rút - giúp bạn tiết kiệm quản lý nợ kỹ thuật .

Điều tôi đã nói trong quá khứ là "mã này rất phức tạp và tôi không tự tin vào những gì nó đang cố gắng làm, liệu có thể đơn giản hóa nó hoặc viết nó rõ ràng hơn?"

Bạn mã hóa sau khi xóa / khôi phục mã của họ: "Rất tiếc, mã của bạn đã biến mất. Vui lòng viết lại. Vì bạn đã viết nó một lần, bạn sẽ cần ít hơn hai mươi phút để cung cấp CHỈ mã theo yêu cầu của thông số kỹ thuật.

"Đánh giá tiếp theo của tôi là trong 20 phút.

"Ngày tốt."

KHÔNG chấp nhận bất kỳ đối số!

Xong, IMHO

Chris