Khi bạn đọc hiểu code chính là lúc bạn đang rewriting code

Nếu bạn hỏi một nhà phát triển phần mềm rằng họ dành thời gian để làm công việc gì nhiều nhất, thì họ sẽ nói với bạn rằng họ dành phần lớn thời gian để viết code.

Tuy nhiên, nếu bạn thực sự quan sát công việc mà các nhà phát triển phần mềm dành thời gian của họ để làm, thì bạn sẽ nhận ra rằng họ dành phần lớn thời gian của họ đểcố gắng hiểu code:

Phần lớn thời gian làm việc của một lập trình viên là dùng để đọc hiểu code.

Như Peter Hallam đã giải thích:

Tại sao việc chỉnh sửa code lại tốn thời gian gấp 5 lần việc viết code mới? Code mới trở thành cũ hầu như tức thì. Bạn viết một số code mới. Sau đó ra ngoài làm một tách cà-phê. Và đột nhiên tất cả code của bạn vừa viết trở thành code cũ. Code mới toanh thì hầu như chỉ có ở giai đoạn thiết kế ban đầu tuy nhiên giai đoạn này thì không nhiều. Hầu hết các dự án phát triển phần mềm đều sử dụng phương pháp phát triển lặp lại. Thiết kế kiến trúc phần mềm, lập trình, kiểm thử, lặp lại. Lặp lại rất nhiều. Chỉ có code ở trong phần lặp đầu tiên mới được xem là code hoàn toàn mới. Sau quy trình lặp đầu tiên thì code đó nhanh chóng bị chỉnh sửa ngày càng nhiều hơn code mới. Hơn nữa, hầu hết tất cả thay đổi code được thực hiện trong quá trình sửa lỗi (fix bug) thì đều rơi vào trong thể loại chỉnh sửa code. Hãy nhìn [nhóm phát triển ra sản phẩm Visual Studio của Microsoft]; những milestones (điểm mốc quan trọng) trong quá trình sửa lỗi của chúng tôi cũng nhiều như là những milestones về những đặc trưng mới vậy. Công việc chỉnh sửa code tiêu tốn nhiều thời gian của một nhà phát triển phần mềm chuyên nghiệp hơn là việc viết ra code mới.

Tại sao việc đọc hiểu code lại tốn thời gian gấp 3 lần so với việc chỉnh sửa code? Trước khi chỉnh sửa code, thì trước tiên bạn phải hiểu nó làm cái gì đã. Điều này cũng đúng trong bất kỳ hoạt động tái cấu trúc code đang tồn tại – bạn phải hiểu hành vi của đoạn code đó đến mức bạn có thể đảm bảo rằng việc tái cấu trúc đó đã không làm thay đổi bất kỳ điều gì không mong muốn. Khi bạn debugging, thời gian bạn dành để hiểu vấn đề đó lớn hơn rất nhiều lần so với thời gian bạn thực sự dùng để sửa lỗi. Một khi bạn đã sửa được vấn đề đó, bạn cần phải hiểu phần code mới để đảm bảo rằng công việc sửa lỗi vừa làm là đúng đắn. Thậm chí khi viết code mới, thì bạn cũng chẳng bao giờ phải bắt đầu từ con số không. Bạn sẽ gọi đến những phần code đã tồn tại để thực hiện hầu hết công việc của bạn. Hoặc là sử dụng code đã viết rồi hoặc là một thư viện được cung cấp bởi Microsoft, hoặc thậm chí một dll do hãng thứ ba cung cấp. Trước khi gọi đến phần code đang tồn tại này thì bạn phải hiểu nó cặn kẽ trong từng chi tiết. Khi viết ứng dụng về XML đầu tiên của mình, thì tôi đã phải dành rất nhiều thời gian để hiểu chi tiết của những lớp thư viện XML hơn là tôi thực sự viết code. Khi bổ sung thêm những đặc trưng mới thì bạn phải hiểu về những đặc trưng đang tồn tại đến mức bạn có thể sử dụng lại ở nơi thích hợp. Việc đọc hiểu code là hoạt động mà các nhà phát triển phần mềm chuyên nghiệp dành hầu hết thời gian của họ để thực hiện.

Tôi nghĩ rằng cái cách mà hầu hết các nhà phát triển phần mềm “hiểu” code thì cũng đồng nghĩa với việc họ đang rewrite nó. Joel bạn tôi thì cho rằng việc rewriting code luôn luôn là một ý tưởng tồi. Tôi không chắc điều đó có chính xác hay không. Nhưng theo như cuốn sách The Universe in a Nutshell, thì có nói rằng dòng chữ được viết trên tấm bảng đen của nhà vật lý nổi tiếng Richard Feynman tại thời điểm ông ta qua đời là:

Cái gì mà tôi không thể tạo ra được, thì tôi không hiểu được.

Điều đó không có nghĩa là các lập trình viên muốn viết lại mọi thứ; mà nó có nghĩa rằng có rất ít các lập trình viên có đủ thông minh để hiểu code mà không cần rewrite nó. Và cũng giống như việc tôi tin vào sự hiệu quả của việc đọc code, tôi cũng tin chắc rằngchỉ có một cách để trở nên giỏi hơn trong việc viết code đó là phải viết code thật nhiều.Càng nhiều càng tốt. Dù tốt, dù xấu, hay bất cứ thứ gì đi chăng nữa. Không ai lại muốn các nhà phát triển phát minh lại cái bánh xe (lần nữa), nhưng việc cứ ngồi đọc để xem những chiếc bánh xe đó hoạt động như thế nào thì kém xa so với trải nghiệm lái xe vòng quanh trên một số chiếc bánh xe mà bạn đã tự tạo ra chúng.

Việc hiểu code của một ai đó– thực sự hiểu làm thế nào tất cả chúng có thể hoạt động trơn tru với nhau– mất một số lượng lớn những nỗ lực trí óc. Và, thậm chí sau đó một câu hỏi đặt ra là, liệu mã nguồn có phải thực sự là cách tốt nhất để hiểu một ứng dụng? Sau khi đọc những suy nghĩ khiêu khích của Nate Comb trong một bài blog, thì tôi cũng cảm thấy thắc mắc:

Có phải Martians đang mong muốn hiểu các quy luật của trò game nổi tiếng World of Warcraft (WoW) tốt hơn bằng cách cố gắng đọc mã nguồn của nó hoặc ngồi xem hàng triệu giờ video ghi lại cảnh chiến đấu trên màn hình?

“Liệu một ai đó ngồi đọc mã nguồn trò chơi thì bạn có nghĩ rằng họ có thể học được cách làm thế nào để chơi giỏi trò [Monopoly] (một trò đánh bài)?”

Tôi đã làm việc trên rất nhiều ứng dụng mà thậm chí phần lớn source code là do chính tay tôi viết, và tôi cũng đã gặp vấn đề trong việc giải thích chính xác ứng dụng đó làm việc như thế nào. Hãy tưởng tượng sẽ khó như thế nào đối với việc giảng giải này đối với dự án mà có 3, hoặc 5, hoặc 12 lập trình viên giam gia.

Liệu mã nguồn có thực sự nói lên câu chuyện của ứng dụng đó? Tôi cũng không chắc nữa. Có thể cách tốt nhất để hiểu một ứng dụng thì nghịch lý thay, đó là lờ đi toàn bộ mã nguồn của nó. Nếu bạn muốn biết ứng dụng đó thực sự làm việc như thế nào, thì hãy quan sát cẩn thận xem người dùng sử dụng nó ra sao. Sau đó hãy viết một phiên bản của chính bạn.