Viết code nghệ thuật, để phát triển thành Pro

cách đây khoảng mấy chục năm, có nhẽ điều ứng dụng của python quan trọng nhất lúc bạn code chỉ là sự hiệu quả và tối ưu. Lúc ấy RAM của máy tính còn được tính bằng byte thay vì giggabyte, tài nguyên eo hẹp đến mức mỗi lúc máy tính chỉ có thể chạy 1 chương trình. Những ngày đó đã xa rồi.

cộng có tốc độ vững mạnh chóng vánh của phần cứng, tính hiệu quả tụt lại phía sau và dường chỗ cho một nhân tố quan trọng hơn, viết code đẹp, dễ đọc và dễ hiểu. Điều này xuất phát từ thực tiễn là quy mô của những project trở thành to hơn, những mô hình Agile đòi hỏi sự hợp tác giữa mọi người nhiều hơn, môi trường và requirement đổi thay nhanh chóng đòi hỏi code phải thuận lợi thay đổi và bảo trì.

không những thế, khi mới bắt đầu chúng ta thường mang xu hướng viết code xấu. Sở hữu thể vì lười, hoặc với thể bạn nghĩ không sở hữu đủ thời kì để làm công việc tốt hơn, rằng boss sẽ tức giận vì bạn dành quá phổ thông thời kì để viết code đẹp hơn. Cũng sở hữu thể bạn quá mệt mỏi khi viết 1 chương trình nào đấy và chỉ muốn làm xong thôi. Và thế là những đống code thập cẩm có mặt trên thị trường.

những khi nhìn lại đống code đó, chúng ta lại muốn để lại đến https://mindx.edu.vn/ ngày hôm sau. Chúng ta thở phào nhẹ nhàng khi thấy chương trình vẫn hoạt động thông thường, và cho rằng 1 đống code lộn xộn mà chạy được vẫn thấp hơn là ko có gì. Rất nhiều đều ổn cho đến ngày bug xuất hiện, hoặc người dùng ngẫu hứng muốn thêm một vài đổi thay để ứng dụng ngầu hơn. Và mọi rối rắm khởi đầu.

Thế nào là code đẹp

Viết code đẹp đòi hỏi chúng ta phải hình thành được cảm giác về code, cảm giác về tính sạch đẹp của nó (code-sense). Mang những người sinh ra đã có cảm giác này rồi, những người khác phải luyện tập và học hỏi mới đạt được. Nó không chỉ giúp chúng ta nhìn ra một đoạn code là rẻ hay xấu, mà còn cho chúng ta thấy những phương pháp, cách để biến code xấu thành code đẹp.

Tôi muốn code của mình phải tinh tế và hiệu quả. Logic phải rõ ràng để bug chẳng thể ẩn núp được, sự phụ thuộc lẫn nhau giữa các thành phần được tối thiểu hoá để bảo trì dễ hơn, hiệu năng gần như tối ưu để ko khiến người khác khiến code lộn xộn bằng những đoạn tối ưu ko với lề luật. Code đẹp là code làm cho 1 việc tốt.

Bjarne Stroustrup, inventor of C++ and author of The C++ Programming Language

Code đẹp là code thuần tuý và ý đồ rõ ràng. Code đẹp đọc như một đoạn văn hay. Code đẹp ko làm cho mơ hồ ý đồ của người viết, trái lại là sự hài hòa của sự trừu tượng hoá và những câu lệnh điều khiển rõ ràng.

Grady Booch, author of Object Oriented Analysis and Design with Applications

Code đẹp là code sở hữu thể đọc và cải thiện bởi các người khác. Với unit test và acceptance test. Code đẹp sử dụng phương pháp đặt tên mang nghĩa, phân phối một bí quyết xử lý duy nhất cho mỗi mục đích, sự phụ thuộc lẫn nhau được tối thiểu hoá, cung ứng API rõ ràng và đơn giản.

Xem thêm =>>https://mindx.edu.vn/blog/post/lap-trinh-co-ban

“Big” Dave Thomas, founder of OTI, godfather of the Eclipse strategy

Để viết code đẹp hơn
Giới thiệu dông dài đủ rồi, sau đây chúng ta sẽ đi vào phần chính. Các lệ luật sẽ được thể hiện 1 bí quyết ngắn gọn nhất có thể, kèm sở hữu tỉ dụ.

một. Đặt tên có nghĩa

sử dụng tên miêu tả rõ ý đồ
Chọn tên đúng mang thể mất thời kì nghĩ suy, nhưng đảm bảo sẽ tiết kiệm cho bạn rộng rãi thời gian hơn về lâu dài. Cho nên nên chọn tên chăm chút và đổi tên khi bạn mua được trong khoảng thấp hơn.

Tên của biến, hàm hoặc class phải đề cập lên tại sao nó còn đó, nó khiến gì và được dùng như thế nào. Ví như tên biến cần phải ghi chú mới hiểu được, đó là tên chưa biểu hiện được ý đồ.

dùng tên với thể phát âm được, tìm kiếm được
kiếm tìm tiện lợi và nhớ nhanh hơn.

tránh mã hoá
Mã hoá tên biến chỉ khiến chúng ta mất công giải mã. 1 Tỉ dụ về mã hoá tên phổ quát trước đây là Hungarian Notation, được thực hiện bằng cách thêm một đôi chữ cái biểu thị kiểu ngay trước tên biến, ví dụ txtName, iAge...

Điều này đặc biệt đúng mang Java, là 1 ngôn ngữ mang quy định chặt chẽ về kiểu. Các công cụ tăng trưởng (IDE) cũng đã đủ mạnh để highlight các biến quan yếu và có thể phát hiện các lỗi về kiểu ngay tính từ lúc chưa biên dịch code. Do đó mã hoá chỉ khiến việc đổi tên biến, hàm, class trở nên khó hơn. Đồng thời việc đọc code cũng vướng víu hơn.

hạn chế mental mapping
tránh việc người đọc code phải dịch tên bạn đặt ra sang một tên khác mà họ biết. Vấn đề này mang thể xảy ra khi bạn sử dụng những tên ko nằm trong domain của bài toán đặt ra, hoặc sử dụng tên khác có tư duy bình thường.