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

(Website tài trợ bởi: cong tu dong)
bí quyết đây khoảng mấy chục năm, có nhẽ điều khóa học react native quan yếu nhất lúc bạn code chỉ là sự hiệu quả và tối ưu. Khi ấ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 khi máy tính chỉ với thể chạy 1 chương trình. Các ngày đó đã xa rồi.

cộng sở hữu tốc độ lớn 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 yếu tố quan yếu hơn, viết code đẹp, dễ đọc và dễ hiểu. Điều này phát xuất từ thực tại là quy mô của các project trở thành to hơn, các mô hình Agile đòi hỏi sự cộng tác giữa mọi người phổ thông hơn, môi trường và requirement thay đổi mau chóng đòi hỏi code phải tiện lợi thay đổi và bảo trì.

bên cạnh đó, khi mới bắt đầu chúng ta thường với khuynh hướng viết code xấu. Mang thể vì lười, hoặc mang thể bạn nghĩ ko có đủ thời gian để làm công việc tốt hơn, rằng boss sẽ tức giận vì bạn dành quá đa dạng thời gian để viết code đẹp hơn. Cũng mang thể bạn quá mệt mỏi khi viết một chương trình nào đó 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 lúc nhìn lại đống code ấy, chúng ta lại muốn để lại đến ngày hôm sau. Chúng ta thở phào nhẹ nhõm lúc thấy chương trình vẫn hoạt động thường ngày, và cho rằng 1 đống code lộn xộn mà chạy được vẫn tốt hơn là ko với gì. Hồ hết đều ổn cho tới ngày bug xuất hiện, hoặc người dùng ngẫu hứng muốn thêm một đôi đổi thay để ứng dụng ngầu hơn. Và mọi rắc rối bắt đầ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). Sở hữu các người sinh ra đã với cảm giác này rồi, các người khác phải tập dượt 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 cách, phương pháp để 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 không thể ẩn núp được, sự phụ thuộc lẫn nhau giữa những thành phần được tối thiểu hoá để bảo trì dễ hơn, hiệu năng toàn bộ tối ưu để ko làm cho người khác làm cho code lộn xộn bằng các đoạn tối ưu không mang 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 đơn giản và ý đồ rõ ràng. Code đẹp đọc như khóa học lập trình web cho trẻ em 1 đoạn văn hay. Code đẹp ko làm cho mơ hồ ý đồ của người viết, ngược lại là sự phối hợp của sự trừu tượng hoá và các 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 với thể đọc và cải thiện bởi những người khác. Mang unit test và acceptance test. Code đẹp tiêu dùng phương pháp đặt tên sở hữu nghĩa, cung cấp một bí quyết xử lý độc nhất cho mỗi mục đích, sự phụ thuộc lẫn nhau được tối thiểu hoá, phân phối API rõ ràng và đơn giản.

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

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

một. Đặt tên sở hữu nghĩa

dùng tên bộc lộ rõ ý đồ
Chọn tên đúng có thể mất thời kì nghĩ suy, nhưng đảm bảo sẽ tiết kiệm cho bạn phổ biến thời kì hơn về trong tương lai. Bởi thế nên chọn tên kỹ càng và đổi tên lúc bạn tìm được trong khoảng phải chăng hơn.

Tên của biến, hàm hoặc class phải đề cập lên vì sao nó tồn tại, nó làm cho 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, ấy là tên chưa bộc lộ được ý đồ.

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

Điều này đặc biệt đúng có Java, là 1 ngôn ngữ mang quy định chặt chẽ về kiểu. Các phương tiện phát triển (IDE) cũng đã đủ mạnh để highlight các biến quan yếu và có thể phát hiện những lỗi về kiểu ngay tính từ lúc chưa biên dịch code. Vì thế mã hoá chỉ khiến cho 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.

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

tránh mental mapping
hạn chế 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 với thể xảy ra khi bạn tiêu 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 mang tư duy bình thường.

Tên class
Class và đối tượng nên với tên là danh từ hoặc cụm danh trong khoảng như Customer, WikiPage, account. Hạn chế những trong khoảng như Manager, Processor, Data hoặc Info lúc đặt tên class và đối tượng.

Tên hàm
Tền hàm nên được đặt bằng động từ hoặc cụm động từ như postPayment, deletePage hoặc save.

2. Hàm

Ngắn gọn và khiến 1 việc duy nhất
Hàm phải ngắn hết mức với thể. 1 Hàm lý tưởng viết ko quá 20 chiếc. Về nguyên tắc, ví như hàm quá dài hãy chia nhỏ thành những hàm con, mỗi hàm con thực hành 1 việc độc nhất. Tên của hàm phải bộc lộ rõ tác dụng duy nhất của nó.

thông số
Số lượng thông số xuất sắc của một hàm ko nên quá 2. Lúc số lượng tham số đa dạng, coi xét việc đóng gói các thông số liên quan thành class thích hợp.

ko nên dùng thông số ra (output argument), điều này sẽ gây gổ lấp lửng khó hiểu. Vì chúng ta đã quen với việc truyền thông tin vào hàm qua tham số và nhận lại kết quả qua return.

không sở hữu tác dụng phụ
Hàm ko nên thực hiện bất kỳ một việc nào khác ngoài nội dung biểu thị qua tên của nó. Như thế sẽ gây những lỗi khó hiểu do hàm thực hành các hành vi ngoài hiểu biết của người mua.

Hàm checkPassword dưới đây vi phạm điều này, bởi vì nó gọi Session.initialize(). Trong khoảng tên hàm chúng ta chỉ biết nó kiểm tra password, chẳng phải với 1 gợi ý nào là nó sẽ khởi tạo session cả.

sở hữu thể bạn sẽ muốn sửa lại tên hàm thành checkPasswordAndInitializeSession, ngoài ra rõ ràng điều này vi phạm nguyên tắc mỗi hàm chỉ thực hành độc nhất 1 việc.

Tách biệt giữa hành động và truy vấn

Hàm này thực hiện set value cho một tính chất, trả về true giả dụ thành công và false nếu thất bại.

3. Comment

Comment chẳng thể chữa code xấu
1 trong những động cơ để viết comment là do viết code không rẻ. Lúc bạn viết một module nào đấy và thấy nó khó hiểu và ko có công ty. Thế nên bạn tự nhắc với chính mình "À mình phải comment phần này cho dễ hiểu hơn". Đừng khiến cho thế, thấp hơn hết là hãy viết lại code.

Code rõ ràng, dễ hiểu với ít comment tốt hơn rộng rãi so mang code phức tạp, rối rắm với phổ quát comment. Thay vì mất thời gian viết comment giảng giải code, hãy dành thời kì viết lại code.

Comment code không dùng
sở hữu các khi bạn thấy một đoạn code nào ấy không tiêu dùng đến nữa, bạn comment đoạn đó đi vì nghĩ sau này mang thể dùng lại. Đừng khiến thế, hãy xoá nó đi, dùng các source control như Git thì bạn sở hữu thể xem lại lịch sử bất kỳ lúc nào. Đoạn comment đó chỉ khiến cho việc đọc code thêm rắc rối.

4. Định dạng
Độ mở theo chiều dọc giữa các nhóm code
Hầu như code đều được đọc trong khoảng trái sang phải và từ trên xuống dưới. Mỗi mẫu biểu thị 1 biểu thị khăng khăng, mỗi nhóm những dòng thế hiện một suy nghĩ, 1 sự liên quan một mực đến nhau. Các nghĩ suy đó nên được tách biệt với nhau bằng một khoảng trắng.

Khoảng cách giữa những thành phần liên quan
các thành phần mang mối liên quan khăng khít mang nhau nên được đặt sắp nhau. Giảm thiểu trường hợp bạn phải chạy từ file này sang file khác, cuộn lên cuộn xuống chỉ để xem các hàm gọi tới nhau như thế nào.

Khai báo biến
Biến nên được khai báo gần vị trí dùng hết mức với thể. Vì hàm rất ngắn nên khai báo với thể đặt ở đầu hàm.

những tính chất của class nên được khai báo ở đầu class để đảm bảo nhất quán.

những hàm phụ thuộc
nếu 1 hàm gọi 1 hàm khác, chúng nên nằm gần nhau. Hàm được gọi nằm ngay dưới hàm gọi. Điều này giúp cho việc kiếm tìm hàm và đọc hiểu chương trình dễ hơn, đột nhiên hơn.