Code Review: An Agile Process

Trái ngược với điều mà nhiều người vẫn tin tưởng, những lợi ích của việc thực hiện code review gắn chặt với nguyên lý trên tuyên ngôn agile. Thống kê chứng minh rằng peer code review là một trong những phương pháp hiệu quả nhất để nâng cao chất lượng phần mềm bằng cách giảm bớt các lỗi từ gốc. Bằng việc liên kết phương pháp peer code review với các mục tiêu cụ thể của bạn và các agile sprints, code review trở lên cực kỳ linh hoạt và mang lại nhiều lợi ích mềm mà phát triển từ việc tập trung vào sự tương tác và hợp tác. Các bản tóm tắt nghiên cứu điển hình cung cấp số liệu định lượng và số liệu hỗ trợ cho trường hợp code review linh hoạt (agile).

Điều gì làm cho peer code review linh hoạt ?

Một số người thực hành agile đánh giá rằng peer code review là một di sản không mong muốn tồn tại từ thời đại đen tối phát triển phần mềm theo phương pháp waterfall. Kết quả là, họ mạnh mẽ phản đối việc áp dụng peer code review trong các dự án agile. Bài viết này sẽ cho thấy làm thế nào để code review làm vững mạnh cho các nguyên lý chủ chốt của triết lý phát triển Agile và làm sao code review có thể được thực hiện theo cách phù hợp hoàn hảo với quy trình Agile. Trước tiên xin nhắc lại các nguyên tắc cơ bản của phát triển linh hoạt được thảo luận tại trang web tuyên ngôn Agile:

• Các cá nhân và sự tương tác hơn là các quy trình và công cụ
• Phần mềm làm việc hơn là tài liệu hoàn chỉnh
• Hợp tác với khách hàng hơn là thương thảo hợp đồng
• Đáp ứng thay đổi hơn là chạy theo kế hoạch

Mặc dù những người theo agile thừa nhận rằng các khái niệm ở bên phải có giá trị, nhưng họ đánh giá cao các giá trị bên trái hơn. Các tiền đề là để thích ứng với những thay đổi trong yêu cầu, đáp ứng nhu cầu của người dùng nhanh hơn, sắp xếp hợp lý các quy trình, giảm các vòng lặp phát triển và cho phép năng suất cao hơn. Tất cả điều này làm tăng giá trị kinh doanh bằng cách làm cho việc phát triển mình bạch hơn và đưa phần mềm ra thị trường nhanh hơn.

Code review hỗ trợ quy trình Agile bằng cách nào ?

Một cách thống nhất, các nghiên cứu chỉ ra rằng áp dụng code review sản xuất ra các phần mềm với ít lỗi hơn, nó phù hợp với sự nhất mạnh vào phần mềm làm việc. Điều gì có thể tương tác tốt hươn so với các nhà phát triển đang hợp tác về code và thực hiện cải tiến theo thời gian thực ? Như bạn đã biết,code review hỗ trợ hoàn toàn cho các nguyên tắc Agile bằng cách thúc đẩy sự phát triển phần mềm làm việc, hợp tác và tương tác giữa các nhóm, sự chú ý tới sự xuất sắc về kỹ thuật và khả năng đáp ứng với thay đổi - trong khi duy trì chất lượng cao.

Xem xét ba công ty agile nổi tiếng : Apple, Google và Microsoft. Giống như hầu hết các công ty thành công trong việc ứng dụng Agile, họ đều thích sự chấp nhận sản phẩm và khách hàng trung thành. Không như Microsoft, Apple và Google là những công ty gắn với việc review code, và chất lượng sản phẩm của họ phản ánh những nỗ lực thêm này. Đặc biệt là Apple thường cung cấp các bản nâng cấp và sửa chữa lớn với tốc độ ấn tượng. Cả hai công ty đều gắn chặt code review với văn hóa phát triển của họ; họ "nướng" code revidư trong các Agile Sprint và Iteration để xác định lỗi tiềm ẩn sớm hơn trong chu kỳ của họ. Ở những công ty này, code sẽ không bao giờ được "check-in" trước khi được review. Vậy tại sao lại có rất nhiềm nhóm phát triển phần mềm chống lại việc áp dụng code review trong khi những người khổng lồ trong lĩnh vực đã chứng thực sự thành công của nó ?

Trong quá trình lặp lại, các nhà phát triển dành rất nhiều thời gian vào việc thảo luận các yêu cầu với các bên liên quan và nói về thiết kế và kiến trúc mới nổi với các nhà phát triển phần mềm khác. Đó là sự thật ngay cả khi họ có xu hướng làm việc trong

Vượt qua sự kỳ thị Code review

Theo lịch sử, quy trình tiến hành code review đã khá giống "anti-agile". Như lần đầu được hình thành bởi Michael Fagan năm 1976, kiểm tra code 1 là một quy trình review code nặng nề, dẫn tới một thế hệ các nhà phát triển phần mềm tin rằng các cuộc họp được yêu cầu để review code. Rát nhiều cuộc họp. Các cuộc họp nhàm chán nhấn mạnh các quy trình và công cụ hơn là cá nhân và sự tương tác. Kết quả là ngày nay, các quy trình nặng nề và các cuộc họp được coi là không được ưa thích bởi các tín đồ Agile. Sự kỳ thị này làm hỏng toàn bộ khái niệm về code review, gây ra việc code review được coi là một trở ngại bởi các nhóm dự án Agile. Mặc dù "tội lỗi do liên kết" đã nhạt dần theo thời gian, quan niệm sai lầm vẫn tồn tại. Quan niệm sai lầm lớn nhất là bạn cần một cuộc họp để thực hiện code review. Mặc dù Fagan đã chỉ định các cuộc họp cho cuộc kiểm tra của ông, Lawrence Votta của AT&T không tin rằng các cuộc họp là cần thiết. Nghiên cứu của ông cho thấy rằng khi các nhà phát triển đọc code để xác định lỗi trước cuộc họp , việc tổ chức các cuộc họp chỉ tăng số lượng lỗi tìm thấy thêm 4% ( và tiêu tốn nhiều giờ thời gian quý giá của mỗi thành viên tham gia cuộc họp).

Tuy nhiên, ngay cả những tín đồ Agile, những người nhận ra rằng các cuộc họp là không cần thiết, cũng có quan niệm sai về code review. Họ nói rằng "chúng tôi chỉ sử dụng những kỹ thuật mới nhất ở đây; code review đã là quá khứ và không mang lại giá trị" hoặc "tất cả unit test đã đạt, vậy tại sao chúng tôi cần phải thực hiện code review? ". Nếu bạn bỏ đi những cuộc họp và quy trình nặng nề, nhưng để lại sự tương tác, phản hồi, và sự cống hiến cho những cải tiến liên tục, thì code review đã là một thực hành rất Agile.

Làm thế nào để code review phù hợp với Agile

Để cho các nhà phát triển có thể cởi mở hơn đối với việc áp dụng code review trong môi trường Agile, trước hết họ phải chấp nhận những giả thuyết cho rằng code review có thể trở thành Agile. Đào sâu các nguyên tắc cơ bản của tuyên ngôn Agile cung cấp bằng chứng cụ thể rằng code review là Agile.

Phần mềm làm việc là thước đo chính của tiến độ. Các nhà phát triển phần mềm đã có sai lầm. Một số lỗi được phát hiện tự động bởi unit tests, các công cụ phân tích tĩnh... Cũng giống như các nhà văn chuyên nghiệp dựa vào các biên tập viên và các phần mềm kiểm tra chính tả để xác định lỗi, các nhà phát triển được lợi từ việc các nhà phát triển khác kiểm tra code của họ. Đó là sự thật ngay cả khi họ có xu hướng làm việc trong sự cô lập để thực sự viết code ( tạo cho các nhà phát triển danh tiếng như những người sống nội tâm, một cách ít nhất). Chúng ta biết và chấp nhận rằng các lỗ hổng được phát hiện trong các cuộc thảo luận về yêu cầu, kiến trúc và thiết kế. Nguyên tắc tương tự được áp dụng cho việc viết code. Code review không những phát hiện những lỗ hổng , mà nó còn mang lại lợi ích quan trọng khác của Agilist - sự phản hồi được giữ gần mục đích tạo ra và xảy ra sớm hơn - trước khi code được chuyển sang tay QA hay khách hàng.

Các quy trình agile thúc đẩy sự phát triển bền vững. Nhà tài trợ dự án, nhà phát triển và người dùng nên có khả năng duy trì một tốc độ không đổi vô hạn. Đó là một trật tự cao. Để đạt được mục tiêu này, các nhóm Agile thường áp dụng quyền sở hữu code tập thể. Mục đích ở đây là làm cho các thành viên của nhóm làm quen và hiểu cơ sở của code.

Quyền sở hữu code tập thể thúc đẩy sư phát triển bền vững bằng nhiều cách, bởi vì nó :

• Biến đổi thành viên của nhóm từ "chuyên gia" sang "nhà tổng hợp" trong một số lĩnh vực nhất định
• Giúp loại bỏ sự chậm trễ xảy ra khi có thành viên trong nhóm ốm hoặc ở trong kỳ nghỉ
• Giúp thiết lập tiêu chuẩn code chung T* Đẩy mạnh "cái nhìn và cảm nhận" chung cho cơ sở code
• Đảm bảo rằng mọi thành viên đều đang tạo ra tài liệu chi tiết.

Sự chú ý liên tục đến sự xuất sắc về kỹ thuật và thiết kế tốt giúp tăng tính linh hoạt. Tất cả các nhà phát triển phần mềm đều có cái tôi, và hâù hết là những người tò mò tự nhiên thích học những điều mới. Với dự đoán code review, các nhà phát triển có xu hướng code tốt hơn, bởi vì họ biết rằng danh tiếng của họ là trên đường dây. Không ai muốn được coi là liên kết yếu trong chuỗi.

Một kết quả của agile : một nhà phát triển đánh giá lại code của người khác có thể học được các thủ thuật và kỹ thuật mới; một bước quan trọng trong việc làm chủ bất kỳ nghề nào là được hưởng lợi từ kinh nghiệm của người khác.

Trường hợp Agile cho Code Review: phát hiện ra lỗi sớm và thường xuyên

Phương pháp Agile được xây dựng dựa trên nền tảng mong muốn cung cấp phần mềm làm việc một cách hiệu quả nhất có thể. Khi Agilist làm việc để đạt mục tiêu này, họ thường chấp nhận rằng nhận ra và loại trừ lỗi gần điểm khởi đầu thúc đẩy chất lượng phần mềm. Nhưng liệu nững nhà phát triển có tính tới sự tác động kinh tế của việc làm như vậy ?

Một khách hàng của SmartBear đã quyết định kiểm tra chính xác họ sẽ có thể tiết kiệm được bao nhiêu tiền nếu như thực hiện peer review trong một dự án kéo dài 3 tháng 10000-lines với 10 nhà phát triển. Công ty đã thống kê số lượng lỗi mà QA và khách hàng phát hiện ra trong vòng 6 tháng tiếp theo. Sau đó họ quay lại và giao cho một nhóm phát triển khác thực hiện peer review đối với code được đề cập đến. Sử dụng dữ liệu từ bản phát hành trước của dự án phát triển, công ty đã tính được chi phí trung bình để sửa lỗi trong từng giai đoạn phát triển, do đó họ có thể đo lường trực tiếp số tiền họ có thể tiết kiệm được nếu như thực hiện peer code review từ khi bắt đầu dự án. Kết quả là code review sẽ tiết kiệm được hơn một nửa chi phí để sửa lỗi. thêm vào đó họ tìm ra được 162 lỗi khác.

Tại sao hiệu quả của code review lại quá ấn tượng như vậy? Sự thiếu hợp tác trong quá trình phát triển có thể là thủ phạm. Với các yêu cầu và thiết kế, bạn luôn có các cuộc họp và mời khách hàng, nhà quản lý, nhà phát triển và QA cho ý kiến để tổng hợp kết quả. Bạn làm điều này vì những sai lầm trong yêu cầu hoặc kiến trúc là tốn kém và có thể dẫn tới việc bị lỗ. Sau đó bạn tranh luận các ưu tiên tương đối, độ khó khăn, và các giá trị lâu dài của các lựa chọn và kỹ thuật của bạn.

Tiết kiệm hơn $200K : một tình huống thực tế

Trên thực tế, việc coding là một công việc đơn độc. Ví các nhà phát triển có xu hướng viết code ở những nơi yên tĩnh, nên sự hợp tác chỉ giới hạn ở các bản vẽ trên bảng và một vài giao diện được chia sẻ. Không ai bắt lỗi rõ ràng; không ai đảm bảo tài liệu phù hợp với code. Peer code review đặt yếu tố hợp tác vào giai đoàn này của quá trình phát triển phần mềm.

Xem xét: không có một cuốn sách nào được xuất bản thương mại mà không đuọc kiểm tra bởi các biên tập viên chuyên nghiệp. Quét phần xác nhận trong bất kỳ cuốn sách nào , bạn sẽ thấy những người đánh giá đã giúp loại bỏ những khiếm khuyết. Quá trình đánh giá và chỉnh sửa là một yêu cầu để tạo ra một sản phẩm chất lượng cao. Bạn có thấy là phát triển phần mềm là một sự khác biệt ? Làm sao chúng ta có thể mong đợi các nhà phát triển có thể viết nhiều trang code mà không có lỗi?

Nếu "review" nâng cao chất lượng cảu tiểu thuyết và thiết kế phần mềm, nó cũng sẽ nâng cao chất lượng code. Peer code review bổ sung sự hợp tác rất cần thiết cho giai đoạn phát triển của quy trình phát triển phần mềm.

Các loại code review đơn giản

Code review đơn giản cung cấp sự pha trộn đúng giữa quy trình review code và thực tiễn Agile, cho phép code view hiệu quả mà không cần đầu tư quá nhiều thời gian và gánh nặng. Có bốn phương pháp khác nhau để thực hiện code review đơn giản. Như một việc gặp rất nhiều trong thế giới Agile, mỗi nhóm phải lựa chọn cho mình phương pháp phù hợp nhất.

Trên vai

Đây là kỹ thuật đơn giản nhất cho tất cả: khi tới thời điểm để review code, tìm một nhà phát triển và ngồi cùng anh ấy trước màn hình code. Trao đổi trực tiếp là một phương pháp dễ sử dụng cho tác giả giải thích về code.

Gửi vòng qua email

Khi code đã sẵn sàng, nó được phân phối qua email. Mặc dù email cung cấp cách thụ động hơn để review code, nội dung có thể trở thành lồng vào nhau trong nhiều bài trả lời gây khó khăn cho việc quản lý và tìm kiếm. Hơn nữa, rất khó để xác định khi nào việc review kết thúc.

Lập trình cặp

Một trong những đóng góp quan trọng từ thế giới lập trình cực đoan là lập trình cặp, trong một số cách là review code liên tục. Một cách tuyện vời để chia sẻ kiến thức chuyên môn và thúc đẩy việc tư vấn cho các nhà phát triển ít kinh nghiệm hơn, lập trình cặp đánh giá đi kèm với chi phí cao và nguy cơ người review quá quen thuộc với code, khiến cho việc review kém hiệu quả.

Review với công cụ hỗ trợ

Các công cụ hỗ trợ code review giúp khắp phục những thiếu sót gắn liền với mỗi phuơng pháp nói trên. Các công cụ tự động hóa các nhiệm vụ của việc review code và có thể đóng gói file nguồn, gửi cho người review các thông báo, tạo điều kiện giao tiếp tổng thể và đảm bảo rằng các lỗi được theo dõi và giải quyết

Nguồn : https://smartbear.com/learn/code-review/agile-code-review-process/