Quoted

Gã hỏi lại: "Bộ mày nghĩ giá trị của chương trình nằm trong mã nguồn sao? Không phải vậy. Giá trị của một chương trình nằm trong cái đầu của mày đó."

Trả lời cho sự ngạc nhiên của tôi, gã gật đầu và nói: "Gần như là như vậy. Tao giả định chuyện vứt bỏ mã nguồn là một việc giá trị và hữu dụng. Tao giả định mày không nên xem đó là chuyện hoang phí. Tao giả định mày không nên ôm khư khư cái mã nguồn của mày."

Gã lờ đi và tiếp tục. "Cứ mỗi lần mày thêm vào một "test case" mới, mày phải cho nó vượt qua được bằng cách làm cho mã nguồn càng tổng quát hơn. Bây giờ thử đưa ra thay đổi đơn giản nhất, tổng quát hơn giải pháp đầu tiên của mày xem sao."

"Trời! Không được!" Jerry nói. "Mình cần phải 'refector' ngay lúc này để có thể thấy cấu trúc thực sự tiến hoá, không thì chúng ta chỉ chồng chất cái bừa bộn trên cái bừa bộn và chúng ta sẽ không còn biết mình đang làm gì nữa."

Jerry hỏi: " Mày có thể nghĩ ra được cái test case nào bị hỏng không?"

Ðiều làm tôi kinh ngạc và vẫn còn làm tôi kinh ngạc là sau mỗi cái test case chúng tôi lại tuồn ra một giải pháp tốt hơn. Nếu không rấn lên mỗi lần một test case thì tôi không nghĩ sẽ bao giờ dính vào lối khai triển đơn giản này. Tôi không biết chuyện gì sẽ xảy ra với những projects lớn hơn nữa?

"Bởi," Jerremy giải thích, "đặc điểm quan trọng nhất của một lập trình viên giỏi là khả năng suy nghĩ một cách trừu tượng. Thật ra rất ít người có thể làm như thế. Mày mới vừa chứng tỏ là mày có thể làm điều này."

"Đúng rồi, đúng rồi. Vâng, đôi khi chúng ta viết test sai. Bugs -4- có thể xảy ra bất cứ nơi nào. Đó là lý do tại sao viết cả test lẫn mã nguồn là việc nên làm. Bằng cách này, cậu viết mọi thứ hai lần. Tôi có cậu cháu làm kế toán cho tàu vận tải, và cậu ấy luôn luôn lưu các chi tiết chuyển ngân vào hai hồ sơ kế toán riêng biệt. Cậu ấy gọi nó là gì nhỉ? Ồ, vâng, sổ sách đôi. -5- Cậu ấy nói rằng cách này giúp cậu ngăn ngừa và lục tìm các sai sót. Và đây chính là chuyện chúng ta đang làm, phải không cậu bé thân mến. Chúng ta viết tất cả các hàm hai lần. Một lần trong phần test, và một lần trong mã nguồn. Và nó thật sự giúp chúng ta ngăn ngừa và tìm các sai sót, phải không nào?"

"Alphonse thân mến, cách duy nhất để hoàn thành chương trình này nhanh chóng là làm tối đa những gì cậu có thể. Nếu cậu vội vã, hay nếu cậu đi đường tắt, cậu trả phải trả giá xứng đáng trong giai đoạn tìm lỗi. Ông C trả công cho thời gian của cậu, cậu bé, và ông ấy muốn kết quả tốt nhất cậu có thể làm được. Mã nguồn chính là sản phẩm của cậu, cậu bé thân mến, và ông ấy không muốn trả cho thứ sản phẩm kém chất lượng. Ông ta không muốn nghe rằng cậu hoàn tất được ngày làm do vấy vá cho xong chuyện bởi vì ông ta biết cậu sẽ trả một giá rất đắc cho tính vấy vá. Ông ấy chỉ muốn thứ mã nguồn tốt nhất mà cậu có thể viết được. Ông ta muốn mã nguồn sạch, có nghĩa lý và đã được thử nghiệm cẩn thận ở mức tối đa cậu có thể tạo ra. Và rồi, cậu bé thân mến, ông C thừa biết rằng nếu cậu làm như vậy, cậu sẽ hoàn tất nhanh chóng hơn những cậu ngốc non choẹt kia cứ ngỡ chúng có thể xong chuyện nhanh hơn với thói nhếch nhác. Bây giờ, mình hãy đi làm một chén trà nhỉ?"

"Xoá đoạn mã đi Alphonse. Toàn rác rưởi."

Tôi nhìn gã chằm chằm. Tôi đã tiến triển quỷ tha nó đi! Bây giờ gã lại muốn tôi xoá hết những dấu ấn tiến triển ấy. Nhưng gã ấy đúng. Tôi không hiểu đoạn mã. Và tôi chẳng có tí test nào có thể chứng minh từng bước một là mọi thứ chạy đúng nhưng dự tưởng. Nếu mã nguồn của tôi thực sự làm việc đúng (và bây giờ tôi bắt đầu thật sự băng khoăn không biết nó làm việc đúng được mấy phần) nó chạy được do may mắn hơn do thiết kế đàng hoàng.

Tôi đoán có lẽ trong suốt thời gian đi học ở trường, tôi bị thuần dưỡng với lối viết mã thật nhanh rồi dành cả khối thời gian để debug. Vì lẽ gì đó tôi cảm thấy việc debugging không chậm chạp. Và ở đây thì chúng tôi viết hàng loạt những cái tests dường như rất mất thời gian. Cho đến lúc này, chúng tôi chẳng tốn tí thời gian cho việc debugging; vậy mà vì lẽ gì đó nó cũng chẳng làm tôi cảm thấy nhanh hơn tí nào. Chắc cách này nhanh hơn nhưng sao tôi cảm thấy lê thê quá chừng.