Viết clean code: Code “đẹp trai” và code “xấu gái” có gì hay ho?

Bài viết được sự cho phép của tác giả Sơn Dương

Trong sự nghiệp viết code, bạn sẽ nhận ra là bất kỳ ngôn ngữ nào, sẽ luôn có những good code – tạm gọi là code “đẹp trai” và bad code – tạm gọi là code “xấu gái”. Cả hai loại code này đều có thể chạy đúng logic. Nhưng những code “xấu gái” lại gây ra một vấn đề lớn khi maintain dự án. Dưới đây là một số kinh nghiệm viết clean code cho dự án.

Lập trình viên có nên trau chuốt khi viết code?

Trên thực tế, bất kể chương trình của bạn có chạy tốt tới đâu, vào một thời điểm nhất định nào đó sẽ có người nhúng tay vào việc đọc hoặc thay đổi lại code của bạn.

Có thể là thêm tính năng mới, sửa bug hoặc đơn giản chỉ là đọc để hiểu rõ “đứa con” của bạn hoạt động như thế nào.

Ngược lại, sẽ có lúc bạn cũng phải làm điều tương tự với code của những người khác. Cuộc đời mà!

Mọi chuyện sẽ thuận lợi hơn nếu bộ code dễ đọc và dễ hiểu, hay nói cách khác là code phải “đẹp trai”.

Bạn có tưởng tượng được tầm quan trọng của code chất lượng cao? Vậy hãy lật ngược vấn đề khi nghĩ tới hậu quả mà code “xấu gái” có thể mang tới. Đó chính là sự tổn thất về tiền bạc, nhân lực và sự lãng phí thời gian để đọc hiểu, sửa chữa những đoạn code vô cùng “xấu gái”.

Bạn viết một đoạn code và sau đó đoạn code đó được sử dụng ở rất nhiều nơi trong dự án. Do đó việc cung cấp những thông tin cần thiết về đoạn code của bạn thực sự rất quan trọng cho chính bạn và cả đồng nghiệp của bạn.

Có không ít lần mình bắt gặp các đồng nghiệp tán phét với nhau về việc họ không thể nhớ nổi đoạn code hay logic mà họ đã viết chỉ mấy ngày trước đó.

Đối với một đoạn code “xấu gái”, bạn sẽ phải mất nhiều thời gian hơn để tìm được đáp án cho câu hỏi “mình đã làm cái quái gì vào lúc đó nhỉ?”

Một số lời khuyên viết clean code gọn gàng, mạch lạc

#1. Hãy viết “còm men” một cách khoa học

Viết clean code

Hầu hết các ngôn ngữ hiện nay đều hỗ trợ viết comment trong code. Comment giúp cho các đoạn code trở nên dễ hiểu và thuận lợi hơn cho việc bảo trì dự án sau này.

Những dòng comment sẽ được đánh giá cao khi chỉ ra được tại sao phải viết code như thế này thay vì chỉ mô tả đoạn code này làm nhiệm vụ gì. Bởi vì người ta đọc code là người ta đã hiểu code làm gì rồi đâu cần giải thích lại.

Việc comment cũng cần phải ngắn gọn và xúc tích nhất có thể, đừng dài dòng lê thê như viết văn bởi vì người đọc đã quá buồn ngủ khi đọc code rồi.

Comment tốt là comment giải thích được tại sao mọi thứ được làm như vậy. Chứ không phải nói chỗ này làm gì, có tác dụng gì, tự bản thân code đã nói lên được điều đó rồi.
  Bộ guide để viết code sạch dành riêng cho Vue

#2. Nhớ viết code thụt dòng đúng chuẩn (Indention)

Viết clean code

Một code được đánh giá là “đẹp trai” lý tưởng phải sở hữu đường cong “body” như trong hình. Chúng phải thể hiện được nơi đoạn code bắt đầu và kết thúc để bất cứ ai nhìn vào cũng có thể hiểu được. Khi hiểu được thì việc tiếp tục phát triển chương trình sẽ đơn giản hơn rất nhiều.

  Là lập trình viên thì có nên chỉ viết code thôi không ?

#3. Chuẩn hóa file Readme’s

Sẽ là rất phức tạp nếu bạn có một project cần tiêu tốn hàng giờ để mò cài đặt môi trường và triển khai. Đây chính là lúc cần đến Readme như một vị cứu tinh.

Tốt nhất bạn nên viết một đoạn giới thiệu ngắn gọn về dự án trước khi mô tả phần code. Một Readme có cấu trúc như tại đây

Tham khảo việc làm Java Developer hấp dẫn trên TopDev

#4. Luôn đặt tên hàm, tên lớp theo chuẩn (Naming Conventions)

Rất nhiều lần chúng ta bắt gặp một class với cái tên ApiManager – cái tên chẳng hề thể hiện được mục đích rõ ràng của lớp đó.

Bạn nên tham khảo quy tắc đặt tên bằng cách search trên Google từ khóa “best coding practice“.

Điều này giúp bạn phân biệt được khi nào và ở đâu một biến sẽ ra khỏi phạm vi chỉ bằng việc nhìn vào một block code.

Tất cả tên của lớp hay hàm(method, function) đều phải có ý nghĩa. Đọc là hiểu tác dụng chính của nó, ngoại trừ những đối tượng tạm thời (ví dụ như tên biến trong vòng for :

for(int i = 0; i< length; i++)
Một cái tên tốt là cái tên mà khi đọc lên nó chứa đựng đầy đủ thông tin về công dụng cũng như cách sử dụng và điều này chỉ có thể làm được nếu tuân thủ nguyên tắc “single responsibility”.

#5. Hạn chế tối đa Magic Numbers

Magic Numbers tức là bạn tự định nghĩa một hằng số và chương trình sẽ chỉ chạy đúng với hằng số đó.

Không ai có thể biết được tại sao con số đó được chọn lựa. Không ai THỰC SỰ biết được những con số đó ảnh hưởng đến chương trình như thế nào. Ngoại trừ việc thay đổi chúng, đồng nghĩa với phá vỡ logic mọi thứ.

Những con số ma thuật đó đều chẳng tốt đẹp gì cả. Vì vậy, hãy né chúng ngay để tự cứu lấy mình!

Mình lấy một ví dụ với đoạn code sau:

if(a < 8 && b < 8 && c < 8){
    do_something();
}

Ta thấy lệnh so sánh giá trị 3 biến a,b,c với số 8 tồn tại 2 vấn đề.

  • Thứ nhất: số 8 trong trường hợp này trở thành “magic number“. Khi bạn đọc qua đoạn code này, chắc chắn bạn không biết 8 đang biểu diễn cho cái gì. Đối với tác giả đoạn code này thì đó là thời gian làm việc ban ngày của công nhân – 8 tiếng đồng hồ và chắc chỉ mình tác giả đoạn code này thực sự biết điều đó
  • Thứ hai: số 8 được lặp lại 3 lần ở các phép so sánh. Như vậy, khi cần thay đổi giá trị 8 thành 7 hoặc tăng lên 12 chẳng hạn, ta sẽ phải đi dò từng vị trí mà 8 xuất hiện… Rất bất tiện và dễ phát sinh lỗi.

vì vậy để viết code clean hơn, ta nên phẫu thuật chỉnh hình nó thành như sau:

// Số giờ làm việc trong ngày của công nhân
final int WORK_HOURS = 8;

if(a < WORK_HOURS && b < WORK_HOURS && c < WORK_HOURS){
    do_something();
}

#6. Một số quy tắc khác

Và thật ra còn hàng trăm hàng ngàn thứ khác để giúp code chúng ta trở nên đẹp đẽ hơn. Viết clean code cho đẹp là cả một quá trình. Để tóm lại thì mình có một số ý sau.

  • Code đẹp là một code được tổ chức tốt. Đừng để code của bạn trở thành đống lộn xộn, mà giới developer hay gọi là “spaghetti code”.
  • Code đẹp là code phải được comment đầy đủ. Comment tại sao lại viết code như thế, thay vì code đó chạy như thế nào. Tốt hơn hết là nên có ví dụ về cách sử dụng.
  • Code đẹp không phải là code “thông minh”. Code “thông minh” đến mức người đọc không thể hiểu nổi. Thì dù có chạy đúng logic vẫn là code “ngu”. Vì vậy, nên code thật đơn giản và rõ ràng, đọc phát hiểu liền.
  • Code đẹp cần được thực hiện từ các đơn vị tính toán nhỏ nhất. Tức là mỗi hàm chỉ làm một việc thôi, để nó có thể tái sử dụng nhiểu nhất có thể.

Kết luận

Trên đây là toàn bộ những chia sẻ của mình về kinh nghiệm viết clean code. Hi vọng nó sẽ giúp các bạn tránh được những bug tiềm tàng.

Với những lưu ý kể trên, hãy cùng cố gắng để trở thành cha đẻ của những code “đẹp trai” nhất trong mắt tất cả mọi người.

Bài viết gốc được đăng tải tại vntalking.com

Xem thêm:

Xem thêm Việc làm IT hấp dẫn trên TopDev