Quote hàng ngày #1

Quote hôm nay là...

Good code is not just functional, it is also beautiful. Good code is organized, easy to read, and well documented. Organization can be achieved by separating code into useful functions and collecting functions into modules or libraries. Good organization means that at any one time, we only need to focus on a small part of a program.
(Computer Science I - Dr. Chris Bourke)

Chuyện là...

Hôm nay rảnh nợ ngồi đọc quyển Computer Science thì thấy đoạn quote khá hợp ý và mình cũng chiêm nghiệm khá đúng khi đi làm một vài năm. Đôi khi có một vài bạn fresher hoặc junior được mình kèm hoặc muốn được mình góp ý để có thể code tốt hơn sau nhiều lần ăn blame từ các senior, mentor hay leader 🤣.

Mình nghĩ rằng...

Việc code tốt lên thì cũng có nhiều yếu tố, có lý do khách quan ví dụ như được ở trong môi trường làm việc chuẩn, có đủ tài nguyên cần thiết để phát triển, cũng có lý do chủ quan, do bản thân tự thân mày mò để mình tốt hơn, ví dụ như tự đi tham khảo tài liệu, học từ những người giỏi hơn. Chung quy đều là phải có tài liệu, phải có tiêu chuẩn, từ tiêu chuẩn thì mới có thể phát triển mở rộng ra những thứ khác được. Ở đâu đó mình có nghe 1 câu là "Khi bạn có 1 nền tảng vững chắc rồi thì việc bạn giỏi lên chỉ còn là vấn đề thời gian."

Đúc kết...

Quay lại việc code tốt lên, ngoài việc code chạy được, chạy đúng ra thì việc code sạch, đẹp, dễ bảo trì cũng là một yếu tố tiên quyết để đánh giá 1 developer có đủ tính kiên nhẫn, tỉ mỉ và gọn gàng hay không. Qua vài năm đi làm thợ code thì mình đúc kết lại được như thế này:

1. Đầu tiên, bạn phải biết bạn đang làm gì giữa 1 đống chữ (Điều này rất quan trọng, bạn phải biết bạn đang làm gì khi muốn thêm 1 phần code vào giữa những phần khác, phải đánh giá được nó sẽ ảnh hưởng thế nào với những phần code còn lại)
2. Thứ hai, bạn cần phải đặt tên theo một tiêu chuẩn nhất định (cái này gọi là naming convention, refer cái repo này: https://github.com/kettanaito/naming-cheatsheet#naming-convention)
3. Thứ ba, nhận biết một hàm như thế nào là đủ "lớn" và cần refactor (về vấn đề này thực sự có khá nhiều ý kiến, nhưng theo kinh nghiệm cá nhân mình, một hàm thực sự chỉ nên có dưới 50 dòng không tính khoảng trống và comment)
4. Thứ tư, một hàm nên chỉ làm một nhiệm vụ (ví dụ hàm getMessage thì sẽ không tạo thêm message, nó làm mất đi tính uniqueness của hàm và khiến việc đặt tên hàm dường như không còn nhiều ý nghĩa, cùng với việc viết unit test sẽ có cảm giác như đang viết e2e testing vậy)
5. Thứ năm, guard clause có thể giúp bạn code đẹp hơn (nếu bạn thấy quá nhiều if-else lồng nhau thì bạn nên dừng lại và nghĩ về việc refactor đoạn if-else sử dụng điều kiện tổng hợp hoặc guard clause, như này: https://deviq.com/design-patterns/guard-clause)
6. Thứ sáu, nên tuân theo các design pattern và best practice trên internet, đừng tự invent lại những gì đã có sẵn trừ khi bạn nắm chắc được hầu hết các chuẩn khác và nhận ra "Ồ cái này có thể làm tốt hơn")

Và quan trọng hơn cả là luôn học hỏi từ những thứ trên internet, bất cứ điều gì có thể học được đều luôn tốt. Have a nice day!!