Đừng phát triển theo lối đập chuột

Thiết kế chương trình hướng đối tượng

Center of Excellence, SaigonTech

Bài đọc thêm

Đừng phát triển theo lối đập chuột

Venkat Subramaniam

Các nhà quản lý dự án luôn phải đối diện với áp lực xuất xưởng thật nhanh. Thời gian là yếu tố cốt lõi. Làm thế nào để bạn có thể nhanh chóng hoàn thành công việc?

Hãy hình dung tổ của bạn có hai lập trình viên (programmers), Bernie và Rob. Cả hai đều có khả năng, có kiến thức nghiệp vụ ngang nhau, và có cùng kỹ năng ngôn ngữ. Trong quá trình phát triển, bạn nhận ra rằng Bernie hoàn thành phần thi công (implementation) nhanh hơn Rob nhiều.

Trong lúc Bernie tập trung kết thúc nhanh phần viết mã (code), Rob lại dành thời gian viết rồi tiếp tục tái cấu trúc (refactor) mã. Anh đặt lại tên biến (variables) và tên phương thức (methods) cho tốt hơn. Khi chương trình chạy ổn, anh tổ chức code thành những đơn vị nhỏ hơn. Rồi anh kiểm thử (test) để đoan chắc rằng từng đơn vị code phải thực hiện đúng điều anh muốn đơn vị đó làm. Khi đã khá hài lòng, anh mới tuyên bố nhiệm vụ thi công đã hoàn tất.

Song giả định rằng bạn không biết được các chi tiết này. Nếu bạn chỉ xét đến tốc độ hoàn thành công việc, rõ ràng là Bernie giỏi hơn, đúng không?

Vài tuần trôi qua, đến lúc bạn trình cho khách hàng những chức năng (features) mới. Như thường lệ, khách hàng thích thú với các chức năng đó, nhưng rồi họ muốn bạn thay đổi và cải thiện chúng. Bạn yêu cầu lập trình viên của mình thực hiện các thay đổi đó. Khi bạn trình chức năng mới, đã được cải tiến, cho khách hàng, họ thử dùng và hài lòng với những chức năng do Rob thực hiện.

Chẳng may, họ phát hiện ra điểm lạ trong các chức năng do Bernie thực hiện. Trong lúc Bernie lập trình để cho những chức năng mới chạy tốt, thì một vài bộ phận khác không còn hoạt động tốt như trước đây nữa. Khách hàng ghi nhận đây là khuyết điểm, nên bạn yêu cầu Bernie phải chỉnh sửa. Khách hàng kiểm tra lại. Giờ thì điều kỳ cục thậm chí còn xuất hiện nhiều hơn. Chuyện gì đang xảy ra vậy?

Nếu bạn có em nhỏ, bạn biết chắc điều gì đang diễn ra. Bernie đã tạo ra một ứng dụng Đập Chuột (Whack-A-Mole). Đập Chuột là một đồ chơi. Trẻ em dùng búa gỗ để đập các chú chuột ngẫu nhiên ngóc đầu lên. Chúng ngạc nhiên và thích thú đoán xem chú chuột tiếp theo nào sẽ chui ra. Tuy nhiên, việc sửa chữa những ứng dụng mà lỗi phát sinh tại các vị trí ngẫu nhiên thì không sao vui được. Ban đầu Bernie chạy nước rút, song lại chệch hướng.

Trong khi Rob bề ngoài có vẻ chậm chạp hơn, thật ra là anh đang tạo code chất lượng cao. Anh có tiến độ làm việc bền vững. Phẩm chất tốt của code ban đầu đã giúp anh thực hiện những thay đổi một cách nhanh chóng. Thêm vào đó, các kiểm thử (tests) ban đầu anh viết ra đã giúp anh tiếp nhận phản hồi tức thì về sự tương thích giữa code mới và các bộ phận khác bên trong ứng dụng (application).

Khi tính toán thời gian hiện thực một chức năng, đừng chỉ xem xét thời lượng phát triển ban đầu. Hãy cộng thêm thời gian nâng cấp, sửa đổi, và cải thiện code. Quá trình phát triển và kiểm thử code có chất lượng sẽ mất thời gian. Đó chỉ là tổn thất ngắn hạn. Nhưng sẽ đem lại lợi ích dài hạn.

Bạn hãy tự vấn xem mình có muốn nhanh nhanh hay muốn thưởng thức hương vị của tiến độ bền vững.

Nguồn

Subramaniam V. (2009) Avoid Whack-a-Mole Development, 97 Things Every Project Manager Should Know, Davis B. (ed), O'Reilly, Sebastopol, CA.