Những nguyên tắc, định luật thông dụng khi lập trình

Thomas Paine- triết gia nổi tiếng người Anh từng nói:

"An army of principles can penetrate where an army of soldiers cannot"

("Đội quân nguyên tắc có thể xuyên thủng cả những nơi mà đội quân con người không thể")

Trong bất cứ lĩnh vực nào, việc tuân theo những nguyên tắc (được đúc rút, tích lũy bởi nhiều người, đúng đắn sau một thời gian dài) sẽ làm cho công việc có thể thực hiện dễ dàng hơn, tránh được những sai lầm mà người đi trước đã mắc phải.

Và những nguyên tắc cơ bản trong lập trình dưới đây đã được áp dụng và chứng minh sự đúng đắn trong một thời gian dài, vì vậy hãy làm theo để công việc "múa phím" của bạn dễ dàng hơn.

Nguyên tắc KISS (Không phải hôn hít gì đâu):

KISS = Keep It Simple Stupid

KISS có nhiều biến thể khác nhau như "Keep It Short and Simple", "Keep It Simple and Straightforward" và "Keep It Small and Simple".

Tựu chung lại, hàm ý của nó vẫn hướng về một sự đơn giản và rõ ràng trong mọi vấn đề. Và như vậy, sự đơn giản là mục đích trọng tâm trong thiết kế, còn những cái phức tạp không cần thiết thì nên tránh.

Trong lập trình, KISS nghĩa là hãy làm cho mọi thứ (mã lệnh của bạn) trở nên đơn giản và dễ nhìn hơn. Hãy chia nhỏ vấn đề ra những bài toán nhỏ đơn giản hơn, viết mã để xử lý nó, biến nó thành các lớp và các hàm riêng biệt, đừng để một lớp hay một phương thức có hàng trăm dòng lệnh, hãy để nó trở về con số chục thôi.

Đừng viết những lớp hay phương thức theo kiểu spaghetti hay all-in-one (tất cả trong một) như dao thụy sĩ, hãy để mọi thứ thật đơn giản để bạn luôn có thể hiểu được, và kết hợp chúng với nhau để giải quyết được các bài toán lớn.

Nguyên tắc YAGNI:

YAGNI = You Aren’t Gonna Need It

Là những lập trình viên, đôi khi chúng ta suy nghĩ quá nhiều về tương lai của dự án nên chúng ta code thêm thật nhiều tính năng “phòng khi chúng ta cần đến nó” hay “Cuối cùng chúng ta sẽ dùng đến nó”. Ý nghĩ này sai hoàn toàn. Bạn đã không cần đến nó thì bạn sẽ không cần đến nó trong hầu hết tất cả các trường hợp! “You Aren’t Gonna Need It!”.

Nếu bạn nghĩ một chức năng sẽ hữu dụng trong tương lai, hãy cứ bình tĩnh và xem lại những công việc đang chờ bạn giải quyết ngay. Bạn không thể lãng phí thời gian của mình để code những tính năng mà bạn sẽ phải sửa nó hay thay đổi nó bởi vì nó không phù hợp với nhu cầu của khách hàng, hay trong trường hợp xấu nhất là nó sẽ không được sử dụng đến.

--> tốt nhất là hãy giải quyết thành công vấn đề hiển hiện trước mắt đã, khách hàng không vẽ việc cho bạn thì bạn cũng đừng tự vẽ việc cho mình