Đang chuẩn bị cho một đánh giá mã như một nhà phát triển?

Tôi đang tìm kiếm một số ý tưởng ở đây.

Tôi đã đọc bài viết Làm thế nào để đánh giá mã được thực hiện và Đánh giá mã, những lợi thế là gì? đó là rất nhiều thông tin nhưng tôi vẫn cần rõ ràng hơn về câu hỏi dưới đây.

Câu hỏi của tôi là,

1. Là nhà phát triển mục tiêu, bạn có thể đề xuất một số thực tiễn tốt nhất mà nhà phát triển có thể kết hợp trước khi mã của anh ấy được xem xét.

   • Hiện tại tôi đang thực hành các phương pháp sau

     • PPT cho một luồng logic
     • Nhận xét chi tiết.

Vấn đề: Mặc dù tôi đã thực hiện các thực tiễn trên, chúng không giúp đánh giá. Vấn đề tôi gặp phải là, khi logic nhất định được đề cập, tôi tiếp tục tìm kiếm việc thực hiện và dòng chảy và quá nhiều thời gian bị lãng phí trong quá trình và tôi cảm thấy lo lắng.

Tôi nghĩ rằng rất nhiều nhà phát triển cũng sẽ trải qua những gì tôi đang trải qua.

Vì vậy, dựa trên các chi tiết mà OP cung cấp, có vẻ như câu hỏi là "làm thế nào để tôi học được mã của riêng mình để khi được yêu cầu tìm X hoặc giải thích Y, tôi có thể trả lời nhanh chóng".

Một số gợi ý mà tôi có thể nghĩ ra:

• Khi viết mã, bạn cần dành thời gian để tìm hiểu và hiểu mã của chính mình. Đây có thể là những gì TL của bạn đang cố gắng vượt qua bạn trong không quá nhiều từ. Là một TL trong dự án hiện tại, tôi đã thực hiện rất nhiều đánh giá mã trong 11 tháng qua và tôi nhận thấy một thực tế của một số nhà phát triển để tìm kiếm "mã ví dụ" trong cơ sở mã của chúng tôi hoặc ở một nơi khác (google , v.v ...) và sao chép / dán nó vào. Cá nhân tôi không thể chịu đựng được vì trong khi mã của họ vượt qua các bài kiểm tra đơn vị đơn giản, họ không hiểu nó thực sự đang làm gì, vì vậy chúng tôi không bao giờ được đảm bảo rằng không có ' t một số trường hợp ranh giới hoặc một điều kiện thất bại dự kiến ​​có thể xảy ra.

• Như một hệ quả của tuyên bố trước đó, nếu bạn phải sao chép / dán, hãy cố gắng chỉ sao chép / dán mã BẠN đã viết trước đó và bạn hiểu. Chắc chắn bạn có thể "mượn" ý tưởng của người khác nhưng trong trường hợp đó, hãy viết lại từng dòng mã của họ bởi vì khi bạn viết nó, bạn sẽ hiểu rõ hơn về những gì nó làm. Nếu bạn đang sử dụng các API bên ngoài, ngay cả khi bạn có một ví dụ sử dụng API đó, hãy dành vài phút để tìm tài liệu tham khảo và tìm hiểu cách API đó hoạt động. Đừng chỉ cho rằng nếu nó hoạt động trước đó, nó cũng sẽ hoạt động trong tình huống của bạn.

• Đọc và học cách yêu nguyên tắc DRY . Rất nhiều lần những gì bạn muốn sao chép / dán có thể được đặt ở một vị trí chung (chức năng riêng, lớp riêng, thư viện riêng ...)

• Đọc và học cách yêu thích các nguyên tắc RẮN và trong khi bạn đang ở đó, hãy xem lại KISS đã được đề cập bởi mouviciel. Những nguyên tắc này đều được định hướng để sản xuất mã rất súc tích, sạch sẽ và mô-đun. Nếu bạn có các lớp lớn và các hàm lớn trong các lớp đó, rõ ràng sẽ khó khăn hơn nhiều để tìm thấy mọi thứ và trên hết là cố gắng giải thích những gì mã làm. Mặt khác, nếu bạn theo dõi (hoặc ít nhất là cố gắng theo dõi) SRP và làm cho mỗi lớp / chức năng chỉ chịu trách nhiệm cho một điều duy nhất, mã của bạn sẽ nhỏ và rất dễ đọc.

• Chọn một bản sao của Clean Code . Cuốn sách rất tốt Nó nói về việc viết mã tự giải thích và dễ đọc, duy trì và mở rộng. Nếu bạn thực hành viết mã dễ đọc, bạn không nên gặp vấn đề khi đọc mã của riêng mình trong phần đánh giá mã. Và đây là phần thú vị, tôi đã yêu cầu mọi người đọc mã của riêng họ hoặc chỉ đơn giản là cho tôi biết các biến đang biểu thị điều gì và họ không thể trả lời mặc dù họ đã viết mã đó (các lớp hoàn toàn mới, không phải là di sản) chỉ một tuần trước . Đặt tên tốt đi một chặng đường dài.

• Nếu sau khi đơn giản hóa và tái cấu trúc, bạn vẫn có một hàm phải thực hiện một số loại thuật toán không rõ ràng, hãy dành thời gian và viết một khối nhận xét trong hàm đó giải thích thuật toán. Nó không chỉ hữu ích khi bạn phải sửa đổi chức năng đó 2 tháng kể từ bây giờ, mà nếu bạn bị phục kích trong đánh giá mã, bạn có thể chỉ cần đọc lại những gì bạn đã viết.

• Nếu sau tất cả các mục trên, bạn vẫn thấy mình gặp rắc rối? Bạn mới tham gia nhóm và được yêu cầu làm việc với rất nhiều mã kế thừa? Trong trường hợp đó, có thể là TL của bạn là A $$ và bạn có thể chủ động bằng cách hỏi anh ấy trước cuộc họp để dễ dàng và không lãng phí thời gian của mọi người liên quan. Khi những người mới tham gia vào một nhóm, TL cần có đủ kiên nhẫn vì làm việc trong một nền tảng mới, sản phẩm mới, con người mới, môi trường mới cần rất nhiều sự tập trung từ một người mới và người đó sẽ thiếu một số chi tiết ngay từ đầu. Hoạt động như Thiết kế và TL của bạn chỉ nên chấp nhận điều đó.

• Nếu sau tất cả các mục ở trên, bạn vẫn cảm thấy rằng bạn có các đánh giá mã khủng khiếp. Nói chuyện với TL của bạn. Đôi khi mọi người cảm thấy tồi tệ vì bản chất của các cuộc họp xem xét mã khi trên thực tế TL hoàn toàn hài lòng với bạn. Khi tôi thực hiện đánh giá mã, mục tiêu của tôi là làm nổi bật những gì cần thay đổi, đảm bảo bạn hiểu các thay đổi và tiếp tục. Rất nhiều lần tôi không có thời gian để lịch sự và một số người phòng thủ và cố gắng trả lời từng ý kiến ​​của tôi. Trong những tình huống đó, cuộc họp xem xét mã bị đình trệ nên tôi có xu hướng làm gián đoạn chúng và tiếp tục. Nói chung, sau cuộc họp tôi sẽ nói chuyện với những người mới để đảm bảo họ hiểu quy trình và đó không phải là chuyện cá nhân. Sau vài mã đánh giá mọi người thường thoải mái hơn nhiều.

Thực tiễn khác nhau, nhưng theo kinh nghiệm của tôi:

• Đừng làm bất cứ điều gì đặc biệt cho mã. Sẽ rất tự nhiên khi làm tăng mã của bạn thêm một chút khi bạn biết rằng nó sẽ được xem xét và không có hại trong việc sửa những thứ rõ ràng như lỗi chính tả và những thứ tương tự. Nhưng đừng đi vào và thêm nhiều bình luận chi tiết hoặc thay đổi mã chỉ vì nó được lên lịch để xem xét.

• Mã được chuẩn bị và phân phối cho người đánh giá tốt trước khi xem xét. Điều này thường được thực hiện bởi một bên thứ ba trung lập, có thể là người hỗ trợ xem xét mã. Nếu được in ra, mã phải đủ nhỏ để các dòng không được gói quá thường xuyên, nhưng đủ lớn để mọi người có thể đọc nó dễ dàng. In nó ở định dạng ngang nếu đó là những gì nó cần.

• Mã phải được in hoặc hiển thị với số dòng . Tốt hơn là, số nên tiếp tục từ tập tin này sang tập tin tiếp theo. Việc tham khảo "dòng 3502" dễ dàng hơn nhiều so với "dòng 238 của foo.c" và việc có các số cho phép mọi người nói về các dòng cụ thể mà không mất thời gian tìm các dòng đó.

• Chắc chắn nên có người hướng dẫn , btw. Công việc của anh ấy hoặc cô ấy là giữ cho bài đánh giá không bị sa lầy vào những chi tiết vụn vặt, ngăn không cho nó bị cá nhân hoặc nổi nóng, và hạn chế nghiêm ngặt thời lượng của bài đánh giá.

• Là tác giả, bạn nên tự xem lại mã trước cuộc họp đánh giá. Viết ra những thay đổi bạn đề xuất nếu đây là mã của người khác. Điều này giúp bộ nhớ mã của bạn mà bạn có thể không nhìn thấy trong một vài ngày và nó cũng giúp bạn thực hành nhìn mã của chính mình bằng con mắt quan trọng. Sau khi bạn đã trải qua một vài đánh giá, cả với tư cách là người đánh giá và là tác giả, bạn sẽ thấy rằng các ghi chú của riêng bạn sẽ phù hợp chặt chẽ hơn với các ghi chú của nhóm.

• Hãy chuẩn bị để ghi chú trong quá trình xem xét. Đây không phải là mối quan tâm chính của bạn - người khác nên ghi lại các mục hành động mà nhóm đồng ý để bạn có thể tập trung giải thích mã và lắng nghe phản hồi. Nhưng sẽ có lúc bạn nhận được một số phản hồi có giá trị không phải là một mục hành động và bạn nên xử lý ngay những điều đó khi chúng xảy ra.

• Hãy nhớ rằng đó không phải là cá nhân. Thật khó để tránh cảm giác (và hành động) phòng thủ trong khi xem xét. Sẽ tốt để giải thích mã của bạn nếu bạn nghĩ rằng nó bị hiểu sai, nhưng hơn bất cứ điều gì khác chỉ cố gắng lắng nghe.

Một điều nữa để thêm vào các câu trả lời khác: để làm cho người đánh giá mã chính thức dễ dàng hơn, hãy tiến hành RẤT NHIỀU đánh giá mã không chính thức ! Ví dụ:

"Này Bob, tôi có thể chỉ cho bạn cách tôi triển khai hàm foo () không?" "Này Steve, bạn có thể xem sơ đồ lớp này và cho tôi biết bạn nghĩ gì không?" "Này Karen, bạn có thể giúp tôi suy nghĩ vấn đề này không? Tôi nghĩ rằng tôi đã có một giải pháp tốt, nhưng tôi có thể sử dụng sự giúp đỡ của bạn ..."

Hãy biến điều này thành thói quen thường xuyên. Khi bạn liên quan đến đồng nghiệp sớm trong quá trình thiết kế, bạn:

• Xây dựng mối quan hệ
• Có được những hiểu biết mới về vấn đề
• Cải thiện khả năng của bạn để giải thích vấn đề / giải pháp trong tầm tay
• Tiết kiệm thời gian sau đó trong đánh giá mã chính thức