47: Nắm rõ cam kết tiếp theo của bản thân

Tôi đã từng thử hỏi các lập trình viên rằng họ đang làm gì vào lúc đó để xem họ trả lời như thế nào. Người đầu tiên nói: “Tôi đang tái cấu trúc lại những phương thức”. “Tôi đang thêm vào một vài thông số cho hoạt động của trang web”, người tiếp theo trả lời. Người thứ ba bộc bạch: “Tôi đang làm việc trên lịch sử người dùng”.

Trông có vẻ như hai người đầu tiên đã quá tập trung vào các chi tiết trong công việc của họ, trong khi người thứ ba đã nhìn ra được vấn đề lớn hơn, hắn đã để ý rất tốt. Tuy nhiên, khi tôi đặt ra câu hỏi họ sẽ cam kết khi nào và những gì, mọi chuyện thay đổi một cách đột ngột. Hai người đầu tiên đã “clear” những files liên quan và hoàn thành chúng trong vòng hơn một tiếng đồng hồ. Nhưng lập trình viên thứ ba đã nói như sau: “Ồ, tôi đoán là tôi sẽ sẵn sàng trong vòng vài ngày, có thể tôi sẽ thêm một vài class và thay đổi các dịch vụ theo cách nào đó.”

Rõ ràng là hai người đầu tiên có tầm nhìn mục tiêu tổng quát, họ đã lựa chọn những nhiệm vụ mà họ nghĩ rằng nó sẽ hiệu quả hơn, và hoàn toàn có thể hoàn thành trong vòng chưa đến hai tiếng đồng hồ. Một khi họ đã hoàn tất những công việc đó, họ sẽ có thể lựa chọn một tính năng mới mẻ hoặc tái cấu trúc để công việc được tiếp tục. Tất cả code được viết đã được hoàn thành như thế bởi một một mục đích rất rõ ràng và một mục tiêu có giới hạn, khả thi trong tâm trí người lập trình.

Còn lập trình viên thứ ba không thể phân tích được vấn đề và đã làm việc trên mọi khía cạnh cùng một lúc. Anh ấy không hề biết rằng mình sẽ làm gì, cơ bản như thực hiện lập trình speculative hay hy vọng rằng đến một lúc nào đó anh ta có thể thực hiện cam kết. Gần như chắc chắn rằng những đoạn code được viết vào thời điểm bắt đầu của đợt lâu dài này sẽ không phù hợp với solution được xuất ra cuối cùng.

Liệu hai lập trình viên đầu tiên sẽ làm như thế nào nếu những nhiệm vụ của họ tiêu tốn nhiều hơn hai tiếng đồng hồ? Sau khi nhận ra mình đã dành ra quá nhiều, có lẽ họ sẽ vứt bỏ đi những thay đổi, xác định rõ những nhiệm vụ nhỏ hơn, và bắt đầu lại. Thay vì tiếp tục làm việc một cách thiếu tập trung và dẫn đến việc những đoạn code đầu cơ xâm nhập vào kho lưu trữ, thì những thay đổi sẽ bị loại bỏ, nhưng những hiểu biết sâu sắc vẫn sẽ được giữ lại và phát huy.

Người lập trình viên thứ ba có thể sẽ tiếp tục “phỏng đoán” và cố gắng hết sức để biến những thay đổi của anh ta thành một thứ có thể cam kết được. Rốt cuộc, chúng ta vẫn không thể vứt bỏ các thay đổi code mà mình đã thực hiện, điều đó thực sự rất lãng phí. Nhưng không may là việc giữ lại code có thể sẽ khiến cho những code lạ và không rõ ràng dễ dàng xâm nhập vào kho lưu trữ.

Tại một vài thời điểm, kể cả những lập trình viên “cam kết tập trung” vẫn không thể tìm thấy thứ gì hữu ích có thể giúp họ hoàn thành công việc sau hai giờ đồng hồ. Sau đó, họ sẽ chuyển sang chế độ speculative, viết một vài đoạn code và vứt bỏ những thay đổi bất cứ khi nào những insight đưa họ về đúng hướng. Ngay cả những pha hack trông như chả có cấu trúc gì cũng có mục đích của nó: Nghiên cứu về code để có thể xác định nhiệm vụ của mình — đó thực sự là một bước đi vô cùng hiệu quả.

Phải biết rõ được cam kết tiếp theo của bạn là gì, nếu không làm được, hãy vứt bỏ hết những thay đổi, sau đó xác định một nhiệm vụ mới mà các bạn tin tưởng. Hãy thực hiện thực nghiệm speculative bất cứ khi nào cần, nhưng đừng để bị rơi vào mode đó một cách thiếu nhận biết và đừng để các cam kết “phỏng đoán” “rơi” vào kho lưu trữ của mình!