CLEAN CODE MỨC ĐỘ CƠ BẢN

Hello, xin chào mọi người. Hôm nay mình viết 1 bài về clean code cơ bản (Thực ra nó là 1 phần nhỏ trong series Clean code, nhưng dài quá chỉ lấy 1 phần ra nói thui).

Clean code thôi chắc chẳng phải nói, ai cũng biết rồi đúng không, nhưng như thế nào để là clean code thì chả có mấy ai nói được chính xác cả. (Thậm chí mỗi người nói 1 kiểu). Do vậy, hôm nay mình sẽ không bàn về làm cách nào để viết code được clear, mà chúng ta sẽ đi vào cách "nhận ra" code của mình có gì đó không được clean nhé.

Để nhận ra code của mình không clean, các bạn có 1 số phương pháp (mình hay dùng) như sau:

1. Phương pháp kẻ ngốc - trí nhớ ngắn hạn:

Ý tưởng của phương pháp này là: Nếu đọc 1 đoạn code/function mà trong vòng 5s không hiểu hàm đó làm gì, thì nó nên được viết lại.

Phương pháp này nhìn chung đơn giản, nhanh, tiện cho reviewer. Các bạn dev junior khi mới viết code xong, thường muốn nhanh nhanh chóng chóng đưa code lên (để được tính là đã fix xong bug hay làm xong task). Nên đọc lại 1 lượt (không mất quá nhiều thời gian, chỉ khoảng vài phút cho mấy tính năng đơn giản). Nếu cảm thấy phải mất nhiều thời gian mới hiểu được, thì nên cân nhắc viết sao cho gọn hơn 1 chút.

2. Phương pháp chia khối.

Ý tưởng của phương pháp này lấy từ python. Vì python không có mở ngoặc, đóng ngoặc, do vậy nếu các câu lệnh sát nhau sẽ rất khó theo dõi. Do đó ở trong python có 1 quy tắc liên quan đến convention là các hàm và các khai báo biến làm cùng 1 mục đích thì nên được viết gần nhau. Còn trong 1 hàm nếu làm nhiều thứ (và chưa có thời gian để refactor hay tách thành 1 hàm con) thì các chức năng con đó nên được viết cách nhau bởi ít nhất 1 dòng trắng.

Sử dụng quy tắc này, có thể khi viết code hàm của các bạn vẫn chưa được clean lắm, nhưng có thể giúp người khác hiểu nhanh, và có thể clean lại nhanh chóng (chỉ việc cắt 1 khối và làm thành 1 hàm là được).

3. Phương pháp chỉ viết hàm "nông"

Hàm nông là hàm được viết mà không có quá nhiều block/scope con chồng chéo lên nhau ở trong hàm. Nếu bạn viết hàm mà có nhiều câu lệnh if ở phía trong lồng vào nhau, thì nó nên được viết lại theo hướng rõ ràng hơn. Nếu các bạn đã biết JS và JS callback hell, thì các bạn cũng sẽ biết hiện tượng sẽ tương tự như vậy. Liên quan tới phương pháp này, có 1 ý nữa cũng cần lưu ý mà các bạn dev junior hay mắc phải. Đó là viết hàm không liên quan, nhưng lại bị phụ thuộc vào nhau. Ở đây thì chỉ có 1 mẹo nhỏ là khi các bạn viết function, nếu các biến có thể mang ra tầng cao nhất (backend thì thường là Controller, mobile thì thường là process xử lý chính), thì nên được viết ở đó.

func login(){
checkLogin();
redirect();
}
func checkLogin(){
doCheck();
saveLog();
}
Ở đây thường sẽ được recommend lại là:
func login(){
checkLogin();
saveLog();
redirect();
}
func checkLogin(){
doCheck();
}

Tại sao lại vậy ? Vì saveLog() nghe tên thôi thì không nằm trong phạm vi của hàm checkLogin cho lắm. Nếu trường hợp cần lưu lại log của login successful hay login fail, thì có thể trả về kết quả của checkLogin, và saveLog() sau (nhìn chung là cố gắng để các hàm không bị phụ thuộc vào nhau). Nhưu vậy, reviewer có thể không cần đọc quá kỹ những hàm lặt vặt checkLoin(), saveLog(), mà chỉ cần đọc xử lý logic gốc (là có thể đoán được các bạn đang định làm gì).

4. Phương pháp viết hàm implicit/explicit.

Đây sẽ là phương pháp nâng cao hơn 1 chút (nhưng nhìn chung được rút ra từ ví dụ của phương pháp viết hàm nông), chúng ta sẽ cần hiểu explicit là gì, implicit là gì (theo định nghĩa của mình nhé). Khi các bạn viết 1 module, có tính đóng và tái sử dụng cao, thì nên viết kiểu implicit. Có nghĩa là hạn chế tối đa các parameters thêm vào để không làm ảnh hưởng đến hàm. Hàm gần như chỉ thực hiện 1 vài thao tác duy nhất và khó mở rộng (Phần này sẽ liên quan đến loại dự án của các bạn nên sẽ không trình bày chi tiết ở đây). Kiểu viết này hay được dùng cho các Core logic hoặc Base Logic như Database/Mail/ ...

Trong trường hợp muốn viết các hàm có tính mở rộng cao (Một số loại dự án, vì đặc thù hay phải đổi spec, hay có tính mở rộng cao) thì nên sử dụng explicit. Có nghĩa là dự báo các thay đổi ở mức cao nhất, viết hàm có rất nhiều tùy chọn/parameters để sử dụng được trong rất nhiều trường hợp. Kiểu viết này hay dùng để viết các helper/common function như transformObject, convert, ...

Trong thực tế sẽ phải trộn nhiều loại như convert string để connect DB, thì chúng ta cần sử dụng linh hoạt để tránh gây ra một "mớ hỗn độn" cho lead. Vì khi lead nhà các bạn "chán" quá rồi là "kệ" chô project trôi đi đâu thì trôi đấy ) Vậy hôm nay đến đây thôi, khi nào có dịp chúng ta sẽ nói những thứ "cao cấp" hơn 1 xíu.