Over-engineering có thể tạm hiểu là “làm phức tạp hóa vấn đề”, một lỗi mà các bạn lập trình viên vừa đi làm hay gặp phải. Bài viết này sẽ làm rõ sai lầm này và đưa ra một số lời khuyên cho các bạn.

Ngày xửa ngày xưa

Xin mở đầu bài viết bằng một câu chuyện nhỏ nhỏ về bạn H. Thuở mới vào trường Đại Học, H được học Java để viết Hello World. Đây là cảnh giới đầu tiên của code học, không biết chiêu thức, chỉ chú tâm viết code cho chạy được.

Đến năm cuối, H đã đạt được cảnh giới thứ hai: biết nhiều hơn, code khá dần. Code đã sạch đẹp dễ nhìn hơn.

Lúc mới đi làm, H dần dần học được nhiều thứ hơn. Vào công ty, được các bác senior chỉ dạy về design pattern, về SOLID. Lúc này, H đã biết nhiều hơn, bắt đầu suy nghĩ nhiều, quá chú trọng vào chiêu thức mà quên đi cội nguồn.

Như các bạn đã thấy, lúc này code của H trở nên vô cùng thâm ảo với Dependency Injection, Design Pattern, v…v, trong khi mục tiêu của code vẫn chỉ là in ra “Hello World”.

Sau bao nhiêu năm lăn lộn giang hồ, đến cuối cùng H đã đạt đến cảnh giới Phản Phác Quy Chân cao nhất của võ học: Dùng cách đơn giản nhất để giải quyết vấn đề. Để in Hello World ra màn hình thì chỉ cần in, không cần dùng những thứ rườm rà rắc rối.

Vậy thế nào là over-enginnering?

Trước tiên, mới các bạn xem ví dụ Hello World dưới đây

https://gist.github.com/lolzballs/2152bc0f31ee0286b722

Có lẽ không bằng hữu nào xem hết nhỉ! Có thể nói ví dụ này là một tinh hoa của võ học, chỉ việc in 1 một dòng Hello World nho nhỏ mà dùng đủ kiếm chiêu design pattern: Strategy, Factory và một đống interface. Tuy nhiên, bản chất nó chỉ là có hoa không quả, quá rườm rà, trong khi nhiệm vụ chính của code chỉ là in. Điều này gọi là over-engineering: Tạo ra một thiết kế phức tạp quá mức cần thiết.

Nhiều người cứ nghĩ code chuẩn phải là code vòng vèo phức tạp. Họ nhét vô design pattern, áp dụng vô số solid principle vào code để thể hiện trình độ. Đây là thói quen rất nguy hiểm, nhiều kẻ code dần bị trầm mê trong đó. Nếu may mắn lên được tầm Đại Sự (Technical Lead) hoặc Tông Sư (Software Architecture), chúng có thể gây họa khôn lường với những design hệ thống rườm rà như bát trận đồ.

Hãy quay lại với ví dụ Hello World phía trên. Giả sử bạn muốn thay “Hello World” thành “Hello Code Dạo”. Với code đơn giản, bạn có thể nhanh chóng tìm ra dòng code in ra màn hình mà thay thế. Với thiết kế phức tạp, bạn phải đọc hiểu code, lần mò tận 4,5 class và interface mới tìm được chỗ cần thay thế.

Việc over-engineering sẽ làm hệ thống trở nên phức tạp quá mức cần thiết. Điều này làm tốn thời gian công sức code, thời gian bảo trì, đồng thời tốn nơ-ron não của developer.

Đôi khi phức tạp là cần thiết

Theo lý thuyết, chúng ta nên tìm cách code đơn giản nhất, design đơn giản nhất để giải quyết vấn đề. Tuy vậy, Einstein lão phật gia đã từng phán một câu: “Phàm làm thứ gì có thể đơn giản thì nên nó cho nó đơn giản, nhưng đừng đơn giản quá”.

Với nhiều hệ thống lớn như Google, Facebook, ta cần một cơ sở hạ tầng, thiết kế phức tạp mới giải quyết được vấn đề. Tuy nhiên, họ vẫn chú trọng vào sự đơn giản. Các bạn thử dùng React của JS, hoặc nghiên cứu GFS của google xem. Cả 2 đều là những thứ khá phức tạp, nhưng lại được giải thích một cách rõ ràng đơn giản.

Khi code cũng vậy. Nếu team bạn cần làm một phần mềm cho cả ngàn người sử dụng, với team đông khoảng 10-20 người, các bạn cần bỏ thời gian xây dựng kiến trúc phần mềm, xây dựng workflow. Tuy nhiên, với các dự án nho lẻ, nếu áp dụng kiến trúc phức tạp, việc over-engineering sẽ làm lãng phí nhiều thời gian, công sức của cả team.

Lời kết

Hãy nhớ, trước khi viết một dòng code, phải tự hỏi: Có cách nào đơn giản hơn để giải quyết vấn đề không? Viết thế này có làm code phức tạp hơn không, người khác có hiểu được ko?

Đừng thấy hay ho vì mình dùng được 4,5 cái design pattern vào code, mình dùng kiến trúc cao siêu. Hãy thấy hay khi code đơn giản đến mức newbie đọc cũng được mà vẫn giải quyết tốt vấn đề, vẫn có thể mở rộng, phát triển.

Xin kết bài bằng vài câu luận bàn về Độc Cô Cửu Kiểm. Lẽ ra bác Kim Dung nên đi làm lập trình viên, kiến giải của bác về tuyệt thế võ công cũng chả kém mấy ông developer nổi tiếng là mấy.

Triết lý của Độc cô cửu kiếm chính là sự linh hoạt, không ép mình vào những quy tắc cứng nhắc, dựa trên các triết lý của triết học Lão giáo, dạy con người sống linh hoạt theo các quy luật của thiên nhiên.

Chiêu thức là chết, người là sống. Học kiếm thì phải linh hoạt, dùng chiêu thức thì phải như nước chảy mây trôi, không cần chính xác từng tí nhưng phải quán triệt với nhau từ đầu đến cuối. Sau đó thì quên đi những gì đã học, cứ theo bản năng mà sử dụng. Càng quên đi những gì đã học thì ra tay càng không có chiêu số, kẻ địch không sao phá được. Đó chính là cảnh giới vô chiêu.

Một số nguồn tham khảo

• https://medium.com/@webseanhickey/the-evolution-of-a-software-engineer-db854689243#.goorp7aep
• http://programmers.stackexchange.com/questions/288146/what-is-the-difference-between-overengineering-underengineering-and-rightengine
• http://blog.startifact.com/posts/older/under-engineering-over-engineering-right-engineering.html
• https://medium.com/@fbzga/we-are-probably-over-engineering-or-under-engineering-86c75971f4d7#.ggh3us8u6