Đừng Chạy Nhanh Hơn Tầm Nhìn Của Mình! — Don't Outrun Your Headlights (Pragmatic Programmer #27)
Mở đầu
Chào mấy bạn, lại là mình đây! Đang đọc dở cuốn "The Pragmatic Programmer" — 20th Anniversary Edition — mà càng đọc càng thấm. Hồi đầu mình nghĩ sách này chắc cũng chỉ dạy mấy thứ lý thuyết viển vông, ai ngờ đâu từng topic như một "cú đập bàn" tỉnh ngộ luôn.
Hôm nay tới Topic 27: Don't Outrun Your Headlights — Đừng chạy nhanh hơn... tầm nhìn của mình! Nghe cái tên thôi cũng thấy kịch tính rồi đúng không? Để mình kể cho mấy bạn nghe nha.
Ảnh: Septimiu Lupea — Pexels
Don't Outrun Your Headlights — Chuyện cái đèn xe và bài học cho dân IT
Trong sách kể một câu chuyện rợn tóc gáy: Một chiếc xe hai chỗ ngồi phóng vun vút trên đường núi tối om, mưa như trút nước. Tới khúc cua tay áo, xe mất lái, lao qua lan can và bốc cháy dưới thung lũng. Cảnh sát trưởng lắc đầu: "Chắc tại nó chạy nhanh hơn đèn xe rồi."
Nghe có vẻ đơn giản, nhưng ẩn dụ này sâu xa hơn mình nghĩ nhiều. Không phải là chạy quá tốc độ ánh sáng — mà là chạy nhanh hơn khả năng phản ứng của mình với những gì đang xảy ra. Giống như đèn xe chỉ chiếu xa được chừng 160 feet, trong khi quãng đường thắng xe ở tốc độ 70 dặm/h là tới 464 feet. Thấy chưa, xe đã dừng không kịp trước khi mình kịp thấy chướng ngại vật!
Ảnh: Christina Morillo — Pexels
Ứng dụng vào coding thì sao?
Dân lập trình tụi mình cũng hay mắc cái bẫ y này lắm. Bao nhiêu lần mình ngồi vẽ kiến trúc cho hệ thống "sẽ dùng trong 5 năm tới", dự đoán xem 3 tháng sau khách hàng cần tính năng gì, hay ước lượng thời gian cho task "chắc tầm 2 tuần là xong" — và rồi vỡ mồm.
Sách đưa ra Tip 42 cực kỳ xương máu:
"Always take small, deliberate steps, checking for feedback and adjusting before proceeding. Consider that the rate of feedback is your speed limit."
Dịch ra là: Luôn đi từng bước nhỏ, có chủ đích, kiểm tra phản hồi rồi mới đi tiếp. Và tốc độ của mình bị giới hạn bởi… tốc độ nhận được phản hồi!
Ngẫm thấy đúng ghê. Mấy bạn thử nhớ lại xem: khi nào mình code nhanh và ít bug nhất? Là lúc mình viết xong một hàm, chạy unit test liền, thấy đúng, rồi viết tiếp. Còn lúc nào đau đầu nhất? Là lúc design nguyên một module đồ sộ trong đầu, rồi code nguyên 3 ngày, tới lúc chạy thử thì nó sai bét và không biết sai chỗ nào.
Tip 43 cũng quan trọng không kém: "Avoid fortune-telling" — Đừng làm thầy bói! Hôm nay mình nghĩ mình biết tuốt, nhưng mà Black Swan (thiên nga đen — ý nói biến cố hiếm gặp không lường trước được) nó núp đâu đó. Như câu chuyện trong sách: hồi những năm 90, cả làng công nghệ tranh luận dữ dội về Motif vs OpenLook cho desktop GUI. Và rồi cả hai đều thua — cái browser và web mới là thứ thống trị.
Ảnh: Alberlan Barros — Pexels
Bí kíp: Làm code dễ thay thế, đừng cố đoán tương lai
Thay vì mất công thiết kế cho một tương lai bất định, sách khuyên mình nên tập trung làm code dễ thay thế (replaceable). Nghĩa là: code hôm nay viết xong, mai mốt có requirement mới thì mình quăng đi làm lại cũng không xót. Muốn vậy thì code phải gọn, ít phụ thuộc (low coupling), có trách nhiệm rõ ràng (high cohesion).
Cái này mình thấy liên quan mật thiết tới mấy topic trước trong cuốn sách:
- Tracer Bullets (Topic 12) — bắn từng phát, thấy trúng đích mới bắn tiếp
- Prototypes (Topic 13) — làm thử nhanh để học hỏi
- Refactoring (Topic 40) — cải tiến từng bước nhỏ
Cảm nhận của mình
Topic này làm mình nhớ tới một lần hồi mới đi làm. Công ty giao cho mình tính năng "tìm kiếm nâng cao" cho một trang thương mại điện tử. Mình vẽ design pattern, elasticsearch mapping, cache strategy — cả một hệ thống đồ sộ. Làm mất 3 tuần, tới lúc demo khách hàng mới vỡ lẽ: họ chỉ cần search đơn giản theo tên sản phẩm thôi! Những thứ mình design hết công hết sức chẳng bao giờ dùng tới. Suốt ngày ngồi tiếc mấy cái code đó nhưng refactor thì mệt.
Giờ ngẫm lại: mình đã outrun headlights của chính mình. Mình cố đoán xa quá, trong khi feedback từ khách hàng còn chưa kịp nhận. Giá như hồi đó mình chịu khó hỏi khách hàng sớm hơn, làm cái prototype nhỏ trước, thì đã tiết kiệm được khối thời gian.
Cái hay của topic này là nó không khuyên mình "đừng có tham vọng" hay "chỉ làm mấy cái nhỏ nhặt". Nó khuyên mình biết giới hạn của mình — và trong giới hạn đó, làm tốt nhất có thể. Không có gì sai khi nghĩ lớn, chỉ là hãy bước từng bước nhỏ thôi.
Kết
Tóm lại, Topic 27 nhắc mình nhớ: đừng chạy nhanh hơn đèn xe. Hãy đi từng bước nhỏ, lấy feedback làm kim chỉ nam, và thay vì cố đoán tương lai thì hãy làm code dễ thay đổi.
Tới hẹn lại lên! Bài sau mình sẽ nói về Topic 28 — Decoupling. Cảm ơn mấy bạn đã đọc tới đây nha. Nếu thấy hay thì rủ đồng nghiệp đọc cùng, để cả team cùng làm việc tỉnh táo hơn!