Truyện kể rằng, thuở xưa có người tên Tôn Tử, người Lạc An nước Tề. Vì nội chiến nên phải dời tới kinh đô của nước Ngô, ẩn cư rồi chuyên tâm nghiên cứu binh pháp.

Sau nhiều năm ẩn cư, quan sát thế sự và kinh nghiệm tác chiến của các bậc tiền nhân, ông đã viết ra cuốn: "Binh Pháp Tôn Tử" đồng thời xuất sơn phò tá vua Ngô. 

Kể từ đó nước Ngô bách chiến bách thắng, uy chấn thiên hạ.

Binh pháp Tôn Tử tuy viết rất nhiều về kinh nghiệm chiến tranh, cách chiến thắng mọi trận chiến. Thế nhưng, Tôn Tử lại cho rằng cảnh giới cao nhất chính là … không chiến mà vẫn thắng.

Đọc đi đọc lại một hồi, mình ngẫm thấy điều này cũng khá đúng với ngành lập trình. Do vậy, mình chia sẻ trong bài này để anh em cùng nghiền ngẫm nhé!

Luận lý của Tôn Tử

Bách chiến bách thắng, phi thiện chi thiện giả dã
Bất chiến nhi khuất nhân chi binh, thiện chi thiện giả dã (thiên Mưu Lược - Tôn Tử Binh Pháp)

Tạm dịch
Kẻ mạnh đích thực không phải là người bách chiến bách thắng.
Không đánh cũng khiến địch đầu hàng, mới là kẻ mạnh thực sự

Ngoài 2 câu nói trên, ông cũng phân tích rộng thêm

Trong phép dùng binh, có thể khiến cho toàn bộ nước địch đầu hàng là thượng sách, đánh tan tành nước ấy chỉ là thứ sách. 
Có thể khiến toàn bộ quân ngũ đầu hàng là thượng sách, phá vỡ quân ngũ của địch chỉ là thứ sách. 

Cho nên, để đánh thắng quân địch, tài trí nhất là biết dùng mưu, thấp hơn thì dùng các biện pháp ngoại giao, thấp hơn nữa là dùng vũ lực, hạ sách nhất mới phải đánh.

Đây là một cách nhìn khá độc đáo vào thời đại đó, nhưng ngẫm lại thì lại rất chuẩn xác!

Bắt đầu một cuộc chiến đòi hỏi đầu tư rất nhiều tài nguyên, tiền của đề huấn luyện binh linh, rèn đúc vũ khí, chuẩn bị lương thực hậu cần … Trực tiếp đánh trận sẽ có thương vong, hao binh tổn tướng, gây thù oán giữa 2 bên.

Cách hay nhất là nghĩ cách để thắng trận, mà không cần phải chiến đấu. Đỡ tốn tài nguyên, đỡ hao binh tổn tướng.

Ngẫm lại, mình bỗng thấy điều này không chỉ áp dụng được trong chiến tranh, mà còn áp dụng được trong ngành lập trình chúng mình.

Cảnh giới cao nhất của việc code chính là… không code

Ngẫm lại, mấy ông developer tụi mình cũng chẳng khác mấy ông tướng ngày xưa. Mấy ông tướng ngày xưa thì đam mê xông pha trận mạc, còn mấy ông dev mình thì đam mê code.

Mỗi khi có tranh cãi, xung đột, mấy ông tướng chỉ muốn cầm quân ra trận, dùng vụ lực giải quyết vấn đề. Mỗi khi có yêu cầu, có vấn đề cần làm, mấy ông dev mình chỉ muốn … code thêm tính năng, thêm hệ thống để giải quyết vấn đề.

Thế nhưng, nếu bình tĩnh ngẫm lại, các bạn sẽ thấy tuy việc code rất sướng, nhưng khi code nhiều lên thì hệ thống sẽ gặp phải rất nhiều vấn đề:

• Mỗi tính năng code thêm sẽ đòi hỏi phải có document, test cho tính năng đó. Mỗi công nghệ dùng thêm sẽ đòi hỏi các thành viên phải biết công nghệ đó!
• Thêm một thành phần vào hệ thống (server, database, message queue) thì phải có chỗ để deploy nó, phải có người quản lý, update nó, giữ cho nó hoạt động
• Hệ thống càng nhiều code, càng phức tạp thì càng dễ xảy ra lỗi, khó quản lý. Code càng để lâu mà không bảo trì sẽ có rất nhiều technical debt, khó mở rộng, sửa chữa
• Khi code quá nhiều tính năng, hệ thống quá phức tạp, không có document, những thành viên của team sẽ không thể nào nắm được toàn bộ hệ thống

Do vậy, những người có kinh nghiệm sẽ thấy thêm code là thêm phiền, càng nhiều code là càng nhiều gánh nặng. Cách hay nhất là giải quyết vấn đề bằng cách … không code, hoặc bỏ bớt code luôn cho nó gọn.

 

Mấy bác developer nước ngoài cũng rất hưởng ứng cách nghĩ này. Repo nocode có đến hơn 40k starts là biết https://github.com/kelseyhightower/nocode

Chuyện của anh Senior và cậu Junior

Có 1 câu chuyện cười ngắn như thế này

Phòng nhân sự đang muốn nâng cấp qui trình, cần 1 phần mềm quản lý nhân sự, tính toán, xuất báo cáo, phân quyền...

Cậu junior rất hào hứng, bỏ 1 tuần để đi lấy requirement từ khách hàng, thêm 1 tuần nữa để thiết kế DB, tìm hiểu công nghệ, thiết kế UI, architecture.
Sau đó, cậu báo với PM là sẽ mất tầm 3-4 tháng để release bản đầu tiên.

Thấy lâu, anh senior rủ mấy ông nhân sự đi uống cà phê mất nửa buổi để hỏi han.
Ngay chiều hôm đó, phòng nhân sự đã có qui trình mới, tự động, đủ thứ phân quyền report chạy trên .... Google Sheet.

Hệ thống vẫn hoạt động ngon lành 3,4 năm nay; dù cho anh senior lẫn cậu junior đã nghỉ hết.

Đấy, thay vì mất thời gian design, viết code, test, anh senior chỉ cần hiểu qui trình, áp dụng lên Google Sheet là xong. Tính năng phòng nhân sự yêu cầu vẫn đầy đủ, mà lại ít tốn thời gian, đỡ phải bảo trì/nâng cấp.

 

Tạm kết

Tất nhiên, không phải vấn đề nào cũng có thể giải quyết bằng cách … không code. Nếu thế thì chắc nhiều ông developer thất nghiệp hết rồi. Thế nhưng, đôi khi viết thêm code, làm hệ thống phức tạp lên chưa hẳn đã là cách giải quyết vấn đề tốt nhất!

Mong rằng, sau khi đọc xong bài này, bạn sẽ … lười code đi một chút. Mong rằng, mỗi khi viết code, bạn sẽ có suy nghĩ “Có cách nào giải quyết vấn đề này nhanh gọn hơn, ít phức tạp hơn không”.

Suy cho cùng, chúng ta được trả tiền để giải quyết vấn đề, không phải để viết nhiều code, phải không nè!