Tại sao phải viết code thật đẹp?

Là lập trình viên, chắc hẳn ai cũng hiểu khi làm việc với bất kì một ngôn ngữ, một framework, hay một thư viện nào đó chúng ta đều được nhắc nhở về những “best practices” và “bad practices” (chơi chữ đó).

Và chúng ta cũng thường tự lừa dối bản thân rằng cho dù lâu lâu chúng ta vẫn buông lơi đôi tay, viết vài dòng code “không được đẹp” một tí thì kết quả sau đó chương trình vẫn chạy đúng, trừ một vài trường hợp không nghe lời các bậc cao nhân mà cứ cắm mặt làm “bad practices” đẫn đến ứng dụng bị những vấn đề về performance hay thậm chí là crash giữa chừng, mà mấy câu chuyện này nhiều khi còn dẫn tới việc thất thoát tiền của, tốn thời gian để sửa chữa,… Đáng sợ chưa.

Tại sao phải viết code thật đẹp?

Các vấn đề, cũng như hệ quả của việc viết code “không được đẹp” thường nằm trong quá trình phát triển ứng dụng, ví dụ như debugging hay sửa đổi tính năng,… Trong môi trường làm việc thực tế, cho dù ứng dụng của các bạn có chạy tốt cỡ nào, thì vẫn có những khả năng người khác (co-worker) mò vào đọc code, hoặc thậm chí là thay đổi code của bạn nếu có nhu cầu, ví dụ như họ muốn viết chức năng mới dựa trên cái cũ, họ phải fix một con bug liên quan tới code của bạn, hay đơn giản là họ muốn đọc để hiểu hệ thống hoạt động như thế nào. Và tất nhiên điều tôi nói không loại trừ một ai, kể cả các bạn cũng vẫn phải làm những điều tương tự.

Thế giới này sẽ tươi đẹp hơn nhiều nếu tất cả các thể loại code người ta viết ra đều dễ đọc và dễ hiểu.

Làm sao để viết code thật đẹp?

Các bạn viết code một lần, nhưng các bạn phải theo những dòng code đó cả “một đời”, vì thế việc cẩn trọng về cách đặt tên, hay document lại những thành phần phức tạp càng trở nên quan trọng. Nhiều khi mới code xong hôm qua, hôm nay đã quên mất mấy cái logic phức tạp bên trong nó rồi chứ chưa nói đến chuyện 5, 10 năm sau mò vào coi lại.

Một trong những thứ giúp ích được cho chúng ta đó chính là code comment. Chắc hẳn nhiều bạn đang thắc mắc, thế kỉ bao nhiêu rồi mà còn code comment, giờ là thời đại của “self documented” code rồi. Ừ thì không ai phủ nhận việc viết code “self documented”, nhưng mà các bạn đang bị lầm tưởng về chuyện tác dụng của comment trong code. Giá trị của code comment không nằm ở chỗ nói đoạn code này có tác dụng gì, làm cái gì, giá trị của code comment nằm ở chỗ giải thích tại sao đoạn code này phải viết như vậy. Và việc “self documented” chỉ có thể giúp được phần “chỗ này làm gì” hay “cái này có tác dụng gì” thô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.

Quay lại với chuyện “self documented” code, để mà làm được chuyện này, các bạn phải luôn nhớ trong đầu về quy tắc đặt tên (naming convention). Sách dạy khá nhiều thứ rồi, ví dụ như các quy tắc viết hoa viết thường, gạch dưới, etc… Điều quan trọng mà tôi muốn nói đó là, các bạn hãy luôn nhớ trong đầu về nguyên tắc “single responsibility”, chỉ cần các bạn hiểu điều này, cuộc sống sẽ trở nên dễ dàng hơn rất nhiều.

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”.

Ngoài ra, một trong những điều tôi rất hay gặp trong quá trình làm việc đó là mọi người thường nhắm mắt làm ngơ việc sử dụng magic number trong code. Đây quả thực là tội ác, khi mà khi nhìn vào những phép so sánh hay những phép gán, chẳng ai có thể hiểu được ý nghĩa của những con số đó, tại sao lại phải là nó mà không phải là một số khác. Cũng không ai có thể đề phòng được những “tác dụng phụ” có thể xảy ra nếu lỡ tay thay đổi nó. Vì thế hãy tránh sử dụng magic number, mà thay vào đó là đem hết chúng vào trong file constant, rồi đặt một cái tên “thật hay” hoặc thậm chí là thêm vài dòng comment giải thích ý nghĩa, thì người khác đọc code sẽ cảm thấy “yêu” bạn hơn nhiều lắm.

Một thứ khác, dù rất nhỏ nhưng lại có giá trị vô cùng lớn để làm code đẹp đẽ hơn đó chính là indentation, hay chúng ta thường gọi thân thương là “thò ra thụt vô”. Cái gì cũng vậy, để mà được công nhận là đẹp thường phải đi với một kết cấu tốt (nếu các bạn hiểu), code cũng vậy. Ví dụ mà block code bắt đầu “thò ra” một kiểu, lúc kết lại “thụt vô” một kiểu khác thì ai đọc mà không khó chịu đúng không.

Ngoài ra còn gì không?

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 code cho đẹp là cả một quá trình và để tóm lại thì chúng ta có một số ý sau.

Code đẹp là code có kết cấu tốt, được tổ chức tốt chứ không như một đống lộn xộn, mà giới developer thế giới hay nói là “spaghetti code” đó.
Code đẹp là code phải được test đầy đủ, tốt hơn hết là nên có ví dụ về cách sử dụng.
Code đẹp không đồng nghĩa với code “khôn”, bạn nghĩ code bạn “khôn”, nhưng không straight forward, người đọc không hiểu thì cũng có ý nghĩa gì đâu, code vẫn là gớm thôi.
Code đẹp là code ngắn gọn, từng unit phải “nhỏ xinh” vữa đủ, và dễ dàng để tái sử dụng.
Thế nhé, hãy code thật đẹp để thế giới này trở nên “tươi đẹp hơn”, cảm ơn các bạn đã dành thời gian để đọc và hẹn gặp lại các bạn trong các bài viết tiếp theo.

Bài gốc: Codeaholicguy