Làm thế nào để thực hiện đánh giá mã tốt?
Đánh giá mã thực hành tốt Đánh giá mã trong lý thuyết [ngắn]
Đánh giá mã là một phương pháp được sử dụng ngày nay ở hầu hết mọi công ty phát triển phần mềm. Nó cho phép bạn phát hiện lỗi ở giai đoạn sớm hơn của chu kỳ CI / CD và giảm nguy cơ xảy ra lỗi sau này. Đây cũng là một cơ hội tuyệt vời để trao đổi kiến thức giữa các lập trình viên - cả kiến thức về thực hành mã hóa tốt và kiến thức về lĩnh vực của một sản phẩm nhất định
Theo định nghĩa, CR thường được giải thích như sau
Đánh giá mã [cũng. CR, kiểm tra mã, xem lại mã hoặc đọc mã] - là một phương pháp thực hành liên quan đến việc xem xét mã do lập trình viên viết bởi một người khác [thường là đồng đội] để giảm nguy cơ mắc lỗi và điều chỉnh mã đó theo các tiêu chuẩn của công ty về mã đã được thông qua
khéo léo hơn. "Trước khi bất kỳ thứ gì được đưa vào sản xuất, hãy đưa mã của bạn cho ai đó trong nhóm và anh ấy sẽ kiểm tra xem tất cả có phải là git không. "
Và đó là nhiều lý thuyết nhất mà chúng ta có thể tìm thấy trên Internet
Đánh giá mã trong thực tếTrong một bài viết riêng, bạn có thể xem lại các ví dụ cụ thể về Đánh giá mã được thực hiện tốt và chưa tốt trong mã
Dù sao thì trên thực tế, có nhiều hình thức đánh giá mã khác nhau. Có người review code rất cẩn thận, “bám víu” vào từng tên biến, tên method và “nổi đóa” khi thấy comment không cần thiết. Trong những ngôi nhà phần mềm như vậy, tranh chấp thường nảy sinh giữa các lập trình viên cố gắng thuyết phục người khác là đúng. Cuối cùng, nó hủy hoại tinh thần của đội và bầu không khí chung. Những người khác coi việc xem xét mã là một nhiệm vụ khó chịu và cần đánh dấu vào hộp kiểm tiếp theo để phát hành phiên bản tiếp theo của sản phẩm càng sớm càng tốt. Ở đây cũng vậy, đánh giá mã không hoạt động như bình thường.
Cuối cùng, chúng tôi nhận thấy các công ty tuân theo các phương pháp đánh giá mã để tận dụng tối đa chúng.
- Họ sử dụng nó để triển khai các nhà phát triển mới vào mã hiện có
- Họ chia sẻ kiến thức, cho phép những lập trình viên ít kinh nghiệm hơn đạt được cấp độ tiếp theo
- Bằng cách bảo vệ lẫn nhau khỏi sử dụng các giải pháp tồi, họ cẩn thận để không mắc nợ công nghệ
- Cuối cùng, họ cũng cải thiện mối quan hệ giữa các thành viên trong nhóm, tạo ra một môi trường làm việc thân thiện và phát triển
T sự khác biệt giữa các cách tiếp cận khác nhau này về cơ bản đặt ra hai câu hỏi mà chúng tôi sẽ trả lời sau trong bài viết này.
- Làm cách nào để việc xem xét mã của chúng tôi trở thành một sự kiện tích cực cho cả chúng tôi và nhà phát triển khác?
- Làm thế nào để tiến hành đánh giá mã hiệu quả và hiệu quả?
Quy tắc 1. Càng đơn giản càng đẹp
Duyệt quá nhiều mã một lúc cực kỳ mệt mỏi. Khi chúng tôi tập trung vào một đoạn duy nhất trong một thời gian dài, hiệu quả của chúng tôi giảm xuống và nguy cơ bỏ sót lỗi tăng lên. Do đó, tốt hơn hết là bạn nên xem lại các đoạn mã nhỏ. Như vậy làm CR cũng đỡ mệt lắm.
Nhiều nghiên cứu đã được thực hiện với một kết luận được rút ra.
Cam kết nhỏ -> Đánh giá ngắn -> Mã tốt hơn
Không nên hiểu lầm điều này. Đánh giá mã ngắn không có nghĩa là chúng ta nên chạy đua với những đồng nghiệp có thể xem xét càng nhiều dòng mã càng tốt nhanh hơn.
Để tìm điểm chuẩn tốt, chúng tôi có thể sử dụng giá trị trung bình do Google tổng hợp từ nghiên cứu điển hình Đánh giá mã hiện đại của họ. Đối với số lượng tệp được xem.
- 35% đánh giá mã có liên quan chỉ thay đổi thành 1 tệp,
- 90% các thay đổi không nằm trong 10 tệp khác nhau
Tất nhiên, số lượng tệp không phải là thước đo chính xác nếu bạn đang làm việc trong môi trường mà một tệp có thể có vài nghìn dòng mã. Đối với những người xử lý mã dài như vậy, tốt hơn là lấy số dòng mã trung bình dao động trong khoảng 24 [dữ liệu từ cùng một nghiên cứu của Google].
Mức trung bình là ví dụ tuyệt vời về thực tiễn tốt, nhưng bạn cũng nên lưu ý rằng ngay cả Google cũng có các phòng ban mà dòng mã trung bình cho mỗi CR là 250. Nó chỉ xảy ra.
Để đảm bảo rằng quy trình xem xét mã luôn hoàn tất và không có điều gì thiết yếu lọt khỏi sự chú ý của chúng tôi, việc lập danh sách những điều quan trọng nhất cần kiểm tra trong mã của bạn là cực kỳ hữu ích. Sẽ là tốt nhất nếu nó có dạng hộp kiểm.
Có thể dễ dàng tìm thấy các ví dụ khá hay về danh sách kiểm tra CR trên Internet [ví dụ: TẠI ĐÂY ]. Tuy nhiên, chỉ nên coi chúng là phiên bản đầu tiên trong danh sách của riêng chúng tôi, chúng tôi sẽ sửa đổi và điều chỉnh theo tình hình hiện tại theo thời gian.
Nếu mã của chúng tôi rất lộn xộn ngay từ đầu, chúng tôi sẽ không có bất kỳ bài kiểm tra nào trong đó, và hơn nữa, nếu không có nhiều công việc, chúng tôi không thể đưa ra các bài kiểm tra như vậy, thì chẳng ích gì . Trong tình huống như vậy, khi mỗi lần không thể đạt được một nửa số điểm trong danh sách kiểm tra và chúng ta chỉ có thể đặt những điểm trừ vào vị trí của chúng, danh sách kiểm tra như vậy sẽ có tác dụng làm giảm động lực và không khuyến khích chúng ta tiếp tục làm việc khi bắt đầu cuộc phiêu lưu.
Ban đầu, một giải pháp tốt hơn nhiều sẽ là một danh sách ngắn giúp nâng cao chất lượng công việc của chúng tôi nhưng sẽ không làm chúng tôi tê liệt với số lượng phản hồi tiêu cực.
Một ví dụ về danh sách kiểm tra đánh giá mã ngắn cho người mới bắt đầu
- Tôi có hiểu mã tôi đang đọc không?
1A. Tên biến có được chọn đúng không?
1B. Các phương thức có được đặt tên và tham số hóa tốt không?
2. Mã có tuân thủ các tiêu chuẩn mã hóa được chấp nhận rộng rãi không?
3. Mã có đáp ứng những gì được mô tả trong tác vụ không?
Danh sách kiểm tra đánh giá mã đơn giản ở trên sẽ cho phép chúng tôi bắt đầu làm việc với CR và cải thiện mã một cách nhanh chóng và dễ dàng. Chỉ sau một vài lần lặp lại, chúng tôi sẽ có thể thấy rằng mã của chúng tôi bắt đầu trông đẹp hơn một chút - theo nguyên tắc trinh sát, chúng tôi dọn dẹp một chút. Khi chúng ta đã thực hành và có thói quen tránh những sai lầm cơ bản này, chúng ta có thể bắt đầu thêm nhiều điểm hơn vào danh sách này
Ví dụ về các điểm khác sẽ được thêm vào danh sách kiểm tra đánh giá mã của chúng tôi trong các lần lặp lại tiếp theo
- Mã có đáp ứng các quy tắc RẮN không?
- Có bất kỳ sự trùng lặp không cần thiết nào trong đó không?
- Chúng ta có quản lý ngoại lệ tốt không?
- Các bài kiểm tra thích hợp đã được viết chưa?
Như chúng tôi đã đề cập, đây chỉ là những điểm mẫu. Cấu trúc của một danh sách kiểm tra như vậy phải là kết quả của công việc chung của cả nhóm và quan trọng, nó phải là một danh sách được cập nhật một cách có hệ thống khi mã của chúng tôi và kiến thức của chính chúng tôi phát triển và cải thiện
Quy tắc #3. Công cụ đánh giá mãNgười ta nói [không phải vô cớ] rằng một nhà phát triển giỏi là một nhà phát triển lười biếng, và điều này là do khi anh ta không muốn tự mình làm điều gì đó, anh ta sẽ luôn tìm một giải pháp đơn giản để thay thế anh ta trong công việc . Nguyên tắc này cũng áp dụng cho việc xem xét mã và mặc dù chúng tôi chưa thể loại trừ hoàn toàn con người khỏi quy trình này, nhưng đã có một số công cụ mà chúng tôi có thể sử dụng để giúp CR của mình dễ dàng hơn.
Mục đích của bài viết này không phải là đề cập đến tất cả các công cụ đánh giá mã có sẵn, nhưng ba công cụ sau [trình kích hoạt, phân tích mã tĩnh và tiêu chuẩn mã] thực sự đáng để biết.
Gây nên
Để tự động hóa các quy trình liên quan đến đánh giá mã bằng cách sử dụng các công cụ được tạo sẵn, chúng tôi phải có khả năng bắt đầu chúng tự động. Trong chủ đề này, các giải pháp như hook git và đường dẫn bitbucket, tôi. e. các công cụ được tích hợp trong kho mã của chúng tôi, có thể giúp chúng tôi.
Nếu vì lý do nào đó chúng ta không thể hoặc không muốn sử dụng chúng, các giải pháp như Jenkins, Drone. io hoặc Travis phù hợp với chúng tôi.
Phân tích mã tĩnh
Để thuận tiện cho việc giám sát mã, chúng tôi có thể đưa mã vào quy trình phân tích tĩnh
Nhờ quá trình này, chúng tôi sẽ nhận được nhiều loại thông tin khác nhau, chẳng hạn như độ phức tạp của chu trình, tổng số dòng mã trong dự án hoặc số dòng mã trung bình trong tệp. Dữ liệu này sẽ cho phép chúng tôi theo dõi sự phát triển của hệ thống và phản ứng khi chúng tôi quan sát thấy một xu hướng tiêu cực
Ví dụ: nếu số dòng mã trung bình trong các tệp từ bản phát hành này sang bản phát hành khác tiếp tục tăng, thì đó có thể là dấu hiệu cho thấy chúng tôi không làm việc đúng cách trong việc chia mã thành các lớp nhỏ. Rốt cuộc, các lớp nhỏ sẽ dễ bảo trì hơn và kiểm tra chúng sau này
tiêu chuẩn mã
Nếu trong nhà phần mềm của chúng tôi, toàn bộ nhóm làm việc [hoặc cố gắng làm việc] theo một tiêu chuẩn viết mã nhất định, thì cũng có một công cụ sẽ tự động đảm bảo rằng không có gì không đáp ứng tiêu chuẩn của chúng tôi sẽ xuất hiện trong phiên bản sản xuất của chúng tôi. Ví dụ, một công cụ dành cho ngôn ngữ PHP là PHP CS Fixer, công cụ này không chỉ cho phép bạn xác thực các tiêu chuẩn mà còn có thể điều chỉnh mã theo một tiêu chuẩn đã xác định
Quy tắc #4. Làm quan trọng hóa nóĐiểm cuối cùng, nhưng có lẽ là quan trọng nhất - làm cho nó trở nên quan trọng. Bất kể các công cụ được chọn, các tiêu chuẩn được áp dụng và lượng thời gian sử dụng, quy trình xem xét mã và các mục tiêu của nó phải được hiểu rõ trong toàn bộ nhóm phát triển. Trách nhiệm về việc này thuộc về tất cả mọi người - cả những người kiểm tra mã và những người viết mã
Nhiệm vụ của người kiểm tra mã không chỉ là bỏ chọn các hộp kiểm trong danh sách chúng tôi đã chuẩn bị. Một người như vậy cũng nên hướng các nhận xét và đặt chỗ của mình vào mã theo cách mà tác giả của nó hiểu rõ tác động của một thay đổi nhất định hoặc sự thiếu sót của nó và rằng anh ta có thể học được điều gì đó từ phản hồi đó. Chỉ những lời phê bình được truyền đạt đúng cách và mang tính xây dựng mới có tác động tích cực đến sự phát triển của một con người khác. Quan tâm đến khía cạnh này cũng sẽ cải thiện bầu không khí làm việc chung trong nhóm. Rốt cuộc, ai lại không muốn làm việc ở một nơi mà họ có thể không ngừng phát triển kiến thức và kỹ năng của mình?
Đổi lại, tác giả của mã phải học cách tách mình ra khỏi công việc của chính mình - anh ta không thể nhận tất cả các nhận xét một cách cá nhân. Điều cực kỳ quan trọng là các nhận xét mà chúng tôi nhận được do xem xét mã được coi là cơ hội để tìm hiểu và xem các giải pháp khả thi khác. "Tất cả chúng ta đều muốn sản phẩm có chất lượng cao nhất" phải là một trụ cột tuyệt đối của mỗi lần kiểm tra mã
Một yếu tố quan trọng cũng là việc nhúng CR tốt vào quy trình phát triển phần mềm được áp dụng trong một công ty nhất định. Chúng ta không thể để xảy ra trường hợp ai đó dành nhiều thời gian để xem lại mã, rút ra kết luận và quan sát có thể cải thiện mã, và sau đó kiến thức này kết thúc ở một nơi mà không ai quay lại với nó. Những tình huống này gây bức xúc cho những ai code review. Trong một quy trình được tổ chức tốt, luôn có thời gian để cải thiện mã
Cuối cùng, một điều quan trọng. Tranh chấp, xung đột và ý kiến bất đồngMột yếu tố quan trọng của quy trình xem xét mã cũng là sự phát triển của cơ chế giải quyết tranh chấp giữa các lập trình viên không thể giao tiếp với nhau. Việc bỏ qua yếu tố này cuối cùng có thể dẫn đến sự xuất hiện của các xung đột mãn tính và sự suy thoái toàn diện của bầu khí quyển. Nó cũng có thể khiến chúng ta từ bỏ hoàn toàn quy trình kiểm tra mã vì tất cả các ưu điểm và lợi ích của nó.
Trong trường hợp người xem mã đưa ra nhận xét mà tác giả không đồng ý, mỗi nhóm nên có một cơ chế đơn giản và nhanh chóng để đưa ra quyết định cuối cùng. Đây có thể là một câu hỏi nhanh cho một nhà phát triển/người quản lý khác về ý kiến của họ hoặc sắp xếp một cuộc họp ngắn để đưa ra quyết định chung.
Tác giả của bài viết
Mateusz Antkowiak. Dữ liệu trong suốt của nhà phát triển PHP
Lập trình viên chuyên nghiệp trong gần một thập kỷ. Anh ấy bắt đầu hành trình viết mã từ những điểm đến kỳ lạ như Lazarus Pascal hay Delphi, và bây giờ anh ấy bị cuốn hút vào vùng nước ổn định của lập trình hướng đối tượng. Anh ấy có nhiều kinh nghiệm về tự động hóa quy trình, điều này rất hữu ích trong các công cụ RegTech hiện tại của anh ấy trong Dữ liệu minh bạch