Ai là bạn thân trong lập trình của bạn?

Tôi liên tục cảm thấy ngạc nhiên vì code của mình đã trở nên tốt hơn rất nhiều sau khi nhờ một đồng nghiệp xem qua nó. Ý tôi không phải là một buổi review trang trọng trong một phòng họp, hoặc đăng công khai code lên internet để mọi người vào soi xét, hay một dạng hình thức lập trình cặp phiền hà nào đó. Chỉ đơn giản là thử tóm tắt và giải thích rồi đưa code của mình cho một lập trình viên đồng nghiệp — đó là tất cả việc phải làm.

Điều này thì dĩ nhiên là không có gì mới. Cuốn sách tuyệt vời của tác giả Karl Wiegers làPeer Reviews in Software: A Practical Guide đã chỉ dẫn rạch ròi về điều này từ năm 2002.

Bạn nên có một người bạn thân trong lập trình để review code lẫn nhau.

Tôi không nghĩ có ai đó lại đi tranh cãi về giá trị của việc có một người khác xem qua những dòng code của bạn, nhưng vẫn có nhiều trường hợp mà người ta ngăn cản nó. Trong chương sách có tiêu đề Một Chút Trợ Giúp Từ Những Người Bạn Của Bạn (pdf), thì tác giả Karl đã giải thích như sau:

Những lập trình viên bận rộn thường miễn cưỡng dành thời gian để xem xét công việc của một đồng nghiệp. Bạn thường có tâm lý sai lầm trong việc đánh giá thấp một đồng nghiệp mà đi nhờ bạn review lại code của anh ta. Liệu có phải anh ta thiếu tự tin? Liệu có phải anh ta muốn bạn làm những điều anh ta đang nghĩ? Một số người không tán thành việc review code còn giễu cợt rằng, “Bất kỳ ai mà cần người khác review lại code của anh ta thì không nên được trả lương như là một nhà phát triển phần mềm”.

Trong một nền văn hóa kỹ nghệ phần mềm lành mạnh, các thành viên trong nhóm thường gắn kết với nhau để nâng cao chất lượng và làm tăng hiệu suất công việc của họ. Họ hiểu rằng cái thời gian mà họ dành vào việc xem xét sản phẩm công việc của đồng nghiệp thì sẽ được bù lại khi mà những thành viên khác trong nhóm xem xét lại những sản phẩm của chính họ. Những kỹ sư phần mềm tốt nhất mà tôi từng biết thì đều hăng hái trong việc tìm kiếm những người review code cho họ. Thực vậy, việc tiếp nhận nhiều người reviewer trong suốt sự nghiệp đã giúp họ trở thành những nhà phát triển phần mềm tốt nhất.

Bổ sung vào chương sách trên, bạn có thể đọc Chương 3 (pdf) trên trang web Process Impact. Điều này thì không đơn thuần chỉ là cảm tính, mà có những dữ liệu thực sự đằng sau nó. Nhiều nghiên cứu đã chỉ ra rằng việc xem xét code thì mang lại hiệu quả rất lớn.

Trung bình tỉ lệ phát hiện ra lỗi chỉ 25% khi sử dụng unit testing, 35% nếu dùng function testing, và 45% khi sử dụng integration testing. Trái lại, hiệu suất trung bình của việc review thiết kế và code thì lên đến 55% hoặc 60%.

Vì vậy tại sao bạn lại không thực hiện công việc review code cơ chứ? Có thể chỉ bởi vìbạn vẫn chưa tìm thấy một người bạn thân trong lập trình cho mình!

Hẳn bạn còn nhớ hồi chúng ta còn đi học, khi đó người ta thường khuyên bạn nên kiếm lấy một cậu bạn thân và gắn kết với họ phải không nào? Điều này sẽ giúp cho bạn tránh được những rắc rối và trở nên an toàn hơn. Vâng, quy luật tương tự cũng nên áp dụng khi bạn đang xây dựng phần mềm. Trước khi bạn check-in code, thì hãy đưa chúng cho anh bạn thân của mình xem qua trước. Bạn có thể giải thích điều đó được không? Điều đó gợi cho bạn điều gì? Có bất cứ điều gì mà bạn bỏ sót không?

Bây giờ đây tôi sẽ gửi đến bạn liên kết của một bức hình biếm họa này.

Nhưng nghiêm túc mà nói, bức tranh biếm họa này minh họa chính xác điều mà chúng ta đang tìm kiếm. Nó không cần phải quá phức tạp mới trở nên hiệu quả. WTFs/minute là một đơn vị đo lường hoàn toàn chấp nhận được để sử dụng cùng với bạn thân lập trình của bạn. Cộng đồng XP (Extreme Programming) đã quảng bá về lập trình cặptrong nhiều năm, nhưng tôi nghĩ rằng hệ thống bạn thân là một cách thực hành rất khác nhưng lại thu được những kết quả tương tự.

Bên cạnh đó, có ai mà lại không muốn trở thành một nửa của một cặp coding tuyệt vời nào đó phải không nào?

Đó là cách hào hứng hơn rất nhiều so với kiểu bị trói buộc vào cùng một cái máy tính với một người khác. Bạn hãy nghĩ về tất cả những cặp đôi hoàn hảo kinh điển ngoài kia:

• Batman và Robin
• Tango và Cash
• Lennon và McCartney
• Mario và Luigi
• Starsky và Hutch
• Siegfried và Roy
• Turner và Hooch
• Abbott và Costello
• Crockett và Tubbs
• Steve Jobs và Wozniak
• Bert và Ernie
• Ponch và Jon
• Hall và Oates
• Cheech và Chong

Những cá nhân riêng lẻ có thể tạo ra những thứ rất tuyệt vời, nhưng hai người đồng nghiệp có động cơ thúc đẩy cao thì có thể hoàn thành thậm chí còn tốt hơn nhiều khi họ làm việc cùng với nhau. Hãy chắc chắn rằng có ít nhất một lập trình viên đồng nghiệp là người mà bạn ngưỡng mộ hoặc ít ra thì cũng đủ tôn trọng để nhận vào hệ thống bạn thân của bạn. (Và nếu không, thì bạn có thể nên cân nhắc đến chuyện nhảy sang một công ty khác.)

Một trong những điểm thú vị nhất của lập trình đó là bạn không phải làm nó một mình.Vì vậy câu hỏi đặt ra là: Ai là bạn thân lập trình của bạn?

Techtalk via vinacode