Tải xuống bản tổng hợp miễn phí của chúng tôi gồm hơn 50 slide và mẫu Chiến lược & Chuyển đổi. Các khuôn khổ bao gồm Mô hình chiến lược 7-S của McKinsey, Thẻ điểm cân bằng, Đổi mới đột phá, Đường cong trải nghiệm BCG, v.v.
Tải xuống bản tổng hợp miễn phí của chúng tôi gồm hơn 50 slide và mẫu Chiến lược & Chuyển đổi. Các khuôn khổ bao gồm Mô hình chiến lược 7-S của McKinsey, Thẻ điểm cân bằng, Đổi mới đột phá, Đường cong trải nghiệm BCG, v.v.
Đánh giá mã là cách tốt nhất để duy trì chất lượng mã ở mức cao. Đánh giá mã không chỉ đóng vai trò là người gác cổng cho mã xấu mà còn là động lực để các lập trình viên cải thiện kỹ năng, học hỏi và xem xét kỹ lưỡng công việc của chính họ. Những người khổng lồ về mã như Google sử dụng đánh giá mã trên mọi thứ được thêm vào cơ sở mã
Hầu hết các lập trình viên không sử dụng danh sách kiểm tra. Ít nhất không phải là một chính thức. Và chắc chắn không phải là một danh sách kiểm tra như một công cụ được sản xuất bởi một nhóm hoặc một công ty được sử dụng thống nhất bởi tất cả các lập trình viên và người đánh giá. Họ có thể đang sử dụng một danh sách kiểm tra tinh thần mà họ đã tạo ra cho chính họ. Nhưng danh sách kiểm tra này có thể có những sai sót lớn nếu nó không được thảo luận, thiết kế và duy trì bởi nhiều người. Danh sách kiểm tra bạn có thể tìm thấy trên internet quá dài và quá trừu tượng để bất kỳ ai thực sự sử dụng. Đó là lý do tại sao, nếu định sử dụng danh sách kiểm tra, bạn nên xây dựng danh sách kiểm tra của riêng mình.
Tại sao sử dụng một danh sách kiểm tra?
Đánh giá mã cần tạo ra các thay đổi. Nếu họ không, họ cũng có thể không xảy ra. Điều này có thể dẫn đến một trong những cạm bẫy lớn nhất của đánh giá mã. Rơi vào một phiên soi mói để tìm kiếm thứ gì đó để thay đổi.
Bằng cách sử dụng danh sách kiểm tra, người đánh giá có thể bám vào những gì quan trọng và tìm thấy những thay đổi đó trong những điều quan trọng. Danh sách kiểm tra cũng giúp người đánh giá đảm bảo rằng họ không quên điều gì quan trọng.
Khi nào bạn nên sử dụng danh sách kiểm tra đánh giá mã?
Danh sách kiểm tra có thể là một công cụ bạn xây dựng để cải thiện việc đánh giá mã của mình hoặc nó có thể là một thông lệ được thiết lập trên toàn công ty. Dù bằng cách nào, danh sách kiểm tra có thể được sử dụng bởi cả lập trình viên gửi mã để xem xét và bởi người thực hiện đánh giá
Chuẩn bị mã để đánh giá là một bước quan trọng và danh sách kiểm tra cho phép người viết mã lùi lại một bước và xem xét mã của họ một cách khách quan hơn trước khi chuyển mã cho người đánh giá. Tôi muốn nói rằng một danh sách kiểm tra có thể mang lại lợi ích cho người viết mã hơn là người đánh giá
Các mẹo hàng đầu để xây dựng danh sách kiểm tra đánh giá mã hiệu quả
1. nhớ chiều dài
Khi xây dựng danh sách kiểm tra đánh giá mã, điều quan trọng là phải xem xét độ dài. Nếu một danh sách kiểm tra quá ngắn thì nó không chắc là một danh sách kiểm tra thực sự và bao gồm những điều quan trọng. Nhưng nếu một danh sách kiểm tra quá dài, nó sẽ bị bỏ qua, vì nó sẽ quá tẻ nhạt để sử dụng.
Quy mô phù hợp cho nhóm của bạn có thể không giống với quy mô của nhóm khác. Tuy nhiên, theo nguyên tắc thông thường, 3-5 vấn đề chính và 7-10 mục khác tập trung hơn hoặc các vấn đề nhỏ hơn sẽ là kích thước tôi khuyên dùng
2. Bắt đầu từ những điều cơ bản
Có rất nhiều danh sách kiểm tra đánh giá mã ngoài kia. Một số là một danh sách dài các câu hỏi và một số là các chủ đề rộng mà bạn nên đảm bảo chạm vào. Hầu hết những vấn đề đó chỉ đơn giản là những nguyên tắc thiết kế tốt mà bất kỳ lập trình viên nào cũng nên biết và quản lý trong khi viết mã. Điều hợp lý là những thứ đó sẽ là trọng tâm của danh sách kiểm tra
Tuy nhiên, tôi thấy không hữu ích khi có một mục trong danh sách kiểm tra hỏi xem mã được đề cập có phải là thiết kế tốt không. Thay vào đó, tôi khuyên bạn nên bao gồm các mục khuyến khích tập trung vào lý do mã được viết ngay từ đầu hoặc đưa ra một lăng kính khác để xem xét mã
3. Chuẩn bị mã của bạn
Trước khi bạn nhận được bất kỳ lời giải thích nào từ lập trình viên, hãy tự hỏi bản thân “Mã này có tự giải thích được không?” . Nhưng ngay cả khi phong cách mã hóa của bạn kết hợp với nhận xét, thì mã vẫn có thể đọc được bằng con người.
Việc phải đọc mã mà không có bất kỳ lời giải thích nào buộc người đánh giá phải đảm bảo rằng họ có thể hiểu mã mà không cần ai đó giải thích cho họ. Nếu bất kỳ phần nào của mã yêu cầu giải thích để hiểu, tốt nhất nên chia nó thành các đoạn mã nhỏ hơn hoặc thêm nhận xét. Với mục này trong danh sách kiểm tra, người đánh giá có thể chỉ cần nói với người viết mã rằng họ không hiểu mã. Người lập trình có thể làm rõ, nhưng họ sẽ biết rằng họ cần làm cho mã rõ ràng hơn
4. Mã hiệu quả so với mã hiệu quả
Khi bạn hiểu mã làm gì, bạn phải hỏi. thay đổi mã có đạt được mục tiêu của nó một cách đơn giản và hiệu quả không? . Nhưng nếu bạn có thể đề xuất một thay đổi mã hiệu quả hơn, bạn nên lưu ý điều đó với người viết mã
5. Giao tiếp hiệu quả
Cách bạn truyền đạt đề xuất của mình trong danh sách kiểm tra là rất quan trọng đối với việc nó có được chấp nhận hay không. Tôi thấy tốt nhất là đặt câu hỏi hướng dẫn và để nhà phát triển đưa ra giải pháp thay thế. Bằng cách đó, đó vẫn là ý tưởng của họ và sẽ ít bị phản đối hơn. Hãy nhớ rằng, đánh giá mã không phải là để cho đồng nghiệp của bạn thấy bạn thông minh như thế nào, mà là làm cho mã tốt nhất có thể
6. Đừng bỏ qua sự phụ thuộc
Một phần thường bị bỏ qua khi xem xét mã là Phụ thuộc. Rất dễ bỏ qua một phần phụ thuộc mới hoặc một mã trong gói mà nó không thuộc về. Đưa mục này vào danh sách kiểm tra để đảm bảo rằng vấn đề này không bị bỏ sót. Điều này cũng có thể làm cho việc xem xét mã nhanh hơn vì bất kỳ vấn đề phụ thuộc nào cũng có thể được giải quyết bởi người viết mã trước khi gửi mã để xem xét
7. Xem xét các vấn đề cụ thể của công ty
Tôi có thể tiếp tục và liệt kê vô số vấn đề có thể áp dụng hoặc không áp dụng cho cơ sở mã cụ thể của bạn. Vào cuối ngày, danh sách kiểm tra của bạn cần được thiết kế riêng cho nhu cầu của bạn
Công ty của bạn có nắm giữ thông tin có giá trị cho khách hàng không? . Mã của bạn có tính mô-đun cao không, các thành phần được sử dụng bởi nhiều vùng mã khác nhau. Đảm bảo mọi thứ được tách rời đúng cách. Nếu công ty của bạn sử dụng thử nghiệm đơn vị thì bạn phải đảm bảo rằng phạm vi thử nghiệm tự động là toàn diện. Mã có thay đổi trong khu vực cần nhiều hiệu suất của phần mềm không?
Vân vân và vân vân
8. Lặp lại và cải thiện
Giống như bất kỳ thiết kế nào trong phần mềm hay cách khác, danh sách kiểm tra sẽ cải thiện theo thời gian. Đặt danh sách kiểm tra vào chương trình nghị sự của một cuộc họp. Nhận phản hồi từ mọi người sử dụng nó để tìm cách cải thiện nó. Đừng quên nhận thông tin đầu vào từ bất kỳ ai không sử dụng nó. Điều này có thể giúp bạn tìm hiểu lý do tại sao và làm thế nào để họ có thể tiếp cận dễ dàng hơn
Đôi khi giải pháp một kích thước phù hợp với tất cả sẽ không hoạt động. Có thể một bộ phận khác cần một danh sách kiểm tra khác và có thể ai đó trong nhóm của bạn cần một cách tiếp cận khác để giúp họ cải thiện chất lượng đánh giá mã của họ. Dù bằng cách nào, danh sách kiểm tra thường không được viết bằng đá và do đó, phát triển và phát triển cùng với cơ sở mã của bạn
Nguồn. hình ảnh. ru
Tạo danh sách kiểm tra đánh giá mã phù hợp, bạn cần thực hiện một số nghiên cứu về danh sách kiểm tra nào có sẵn và tách chúng ra. Tìm các mục trên chúng nói lên thiết kế của công ty bạn và tích hợp chúng
Nhưng quan trọng nhất, hãy tiếp tục cải thiện danh sách kiểm tra đánh giá mã của bạn. Cơ hội để bạn có được một danh sách kiểm tra hoàn hảo ngay lần đầu tiên bạn xây dựng một danh sách là rất mong manh. Tìm ra lỗi nào đã lọt qua quá trình xem xét và thêm các mục trong danh sách kiểm tra cần thiết để ngăn chặn chúng. Và cắt bỏ các mục không tạo ra bất kỳ thay đổi nào. Hãy coi đó là việc giải phóng một số đối tượng không sử dụng trong bộ nhớ của người đánh giá của bạn