Clean code #7: Giữ cho code clean

1. Khi nào cần tái cấu trúc để Clean Code:

Chúng ta sẽ xem xét một số hướng dẫn đơn giản về thời điểm cần cấu trúc lại code hiện có bằng Clean Code Principles, cũng như các kỹ thuật để giữ cho code clean. Khi bạn bắt đầu tận hưởng những lợi ích của Clean Code Principles trong code mình viết, bạn sẽ muốn sử dụng những kỹ thuật tương tự để cấu trúc lại code hiện có. Nhưng tôi muốn ghi nhớ nguyên tắc nếu nó không hỏng thì đừng sửa. Không có gì sai khi cải thiện code base của bạn, nhưng trước khi làm vậy, hãy nhớ 3 quy tắc đơn giản.

a. Bạn cần phải làm việc với code của bạn

Nếu bạn đang tái cấu trúc code, đó phải là code mà bạn đang làm việc. Tái cấu trúc (Refactor) cho những người đọc trong tương lai có giá trị đáng ngờ, vì điều đó có nghĩa là bạn đang đầu tư thời gian ngay bây giờ cho những người đọc có thể không có hiện thực trong tương lai.

Nếu code khó đọc nhưng lại tồn tại trong một hệ thống đã hoạt động đáng tin cậy trong nhiều năm thì đừng mạo hiểm thay đổi nó chỉ vì muốn nó clean.

b. Khó hiểu hoặc khó thay đổi

Việc tái cấu trúc sẽ hữu ích khi bạn thấy code khó hiểu hoặc khó thay đổi. Tôi nhấn mạnh từ "bạn" ở đây vì đây thực sự là chủ quan. Nếu bạn đang sửa một bug đơn giản và thấy code đủ rõ ràng, hãy sửa lỗi và tiếp tục.

Việc tái cấu trúc quá mức code cũ có giá trị không chắc chắn khi quy mô thay đổi của bạn nhỏ. Nhìn chung, quy mô tái cấu trúc của bạn phải phù hợp với quy mô thay đổi code mà bạn đang thực hiện. Nếu bạn chỉ cần thực hiện một thay đổi đơn giản trên một dòng, việc tái cấu trúc nhiều method có thể là quá mức cần thiết.

c. Test coverage để bảo vệ khỏi sự suy giảm code (regression)

Trước khi thực hiện bất kỳ thay đổi nào, hãy đảm bảo bạn có đủ test coverage để đảm bảo những thay đổi của bạn không gây ra sự suy giảm trong code.

2. Không chấp nhận cửa sổ bị hỏng:

Bạn đã bao nhiêu lần làm việc trên một code base được viết và bảo trì kém khiến các lập trình viên không còn tự hào về công việc của mình? Tình trạng đáng buồn này không xảy ra trong một sớm một chiều. Nó là sản phẩm của nhiều thủ thuật và thỏa hiệp nhỏ đã được chấp nhận và bỏ qua trong nhiều năm.

Hãy xem xét một câu chuyện từ ấn bản tháng 3 năm 1982 của tờ Atlantic. Một tòa nhà có một vài cửa sổ bị vỡ mà không được sửa chữa có xu hướng bị kẻ phá hoại đột nhập và đập vỡ thêm nhiều cửa sổ nữa. Cuối cùng, chúng thậm chí có thể đột nhập vào tòa nhà và nếu tòa nhà không có người ở, chúng có thể trở thành người chiếm đất hoặc đốt lửa bên trong.

Vì vậy, khi mọi người thấy một tòa nhà bị coi thường thì rất có thể những người khác cũng sẽ đối xử với tòa nhà đó theo cách tương tự. Và tư duy độc hại này cũng ảnh hưởng đến các dự án phần mềm.

✅ Để duy trì Clean code và tránh phải viết lại tốn kém, chúng ta cần phải tự hào về code base của mình và không để những sai lầm trong quá khứ mở ra cánh cửa cho việc chấp nhận thêm nhiều khoản nợ kỹ thuật (technical debt) hơn nữa.

3. Đánh giá mã & Lập trình cùng nhau:

Trong cả công trình xây dựng thương mại và dân dụng, thanh tra xây dựng thường xuyên xem xét công việc để đảm bảo rằng các đội thi công duy trì chất lượng cao và tuân thủ các chính sách đã đề ra. Sự sắp xếp này cũng hữu ích trong phát triển phần mềm.

• Code Review là một cách cực kỳ hiệu quả để tránh tâm lý cửa sổ bị hỏng mà chúng ta vừa thảo luận. Thường xuyên nhắc nhở các lập trình viên rằng code của họ sẽ được đánh giá ngang hàng sẽ thúc đẩy chất lượng code cao hơn.
• Việc thiết lập các hướng dẫn rõ ràng đảm bảo rằng mọi người đều hiểu rõ về kỳ vọng cũng như những gì được phép và không được phép trong Code Review.
• Code Review đảm bảo tính dễ đọc vì người review code phải có khả năng đọc và hiểu code để hiểu và đánh giá code. Đây là một quá trình tốn thời gian, nhưng giống như việc kiểm tra xây dựng, thời gian và chi phí giúp bảo vệ khỏi nguy cơ phát sinh các vấn đề tốn kém sau này.

Cân nhắc làm việc theo cặp (Pair programming)

• Pair programming cung cấp nhiều lợi ích giống như Code Review, nhưng thực tế hơn. Và việc pair programming làm tăng chất lượng code vì các lập trình viên làm việc cùng nhau ít có khả năng sử dụng các từ viết tắt hoặc các lối code tắt tốn kém và khó hiểu khi viết code.
• Việc ghép nối cũng giúp việc đặt tên và tái cấu trúc dễ dàng hơn vì bạn có người khác để trao đổi ý tưởng khi làm việc. Pair programming còn có nhiều lợi ích khác, nhưng chỉ riêng lợi ích về chất lượng code đã đủ để bạn thử phương pháp này.

4. Quy tắc của Boy Scout:

Leave the campground a little better than you found it (Robert C. Martin)

Robert C. Martin nhắc nhở chúng ta rằng chúng ta nên có cùng mục tiêu này khi làm việc với code hiện có. Nếu chúng ta liên tục để lại code của mình tốt hơn một chút so với khi chúng ta tìm thấy nó thì code base sẽ không cần phải viết lại quá nhiều. Chúng sẽ luôn clean.

5. Tổng kết:

Chúng ta đã được nhắc nhở không nên vội vàng và bắt đầu tái cấu trúc bất kỳ code nào mà chúng tôi thấy không clean.

• Chỉ tái cấu trúc khi cần thiết, chúng ta chỉ nên tái cấu trúc khi cần thiết, nghĩa là đó phải là code mà chúng ta hiện đang cần xử lý và quy mô tái cấu trúc phải tương đương với quy mô của những thay đổi code cần thiết.
• Thiết lập và duy trì các tiêu chuẩn. Việc thiết lập và duy trì các tiêu chuẩn code sẽ giúp code của chúng ta clean hơn.
• Kiểm tra code và theo dõi các cửa sổ bị hỏng. Việc chú ý đến các cửa sổ bị hỏng trong quá trình đánh giá code sẽ giúp đảm bảo chất lượng ứng dụng của chúng ta, và chúng tiếp tục được tôn trọng.
• Ghép nối và chia sẻ kiến thức của bạn. Nếu bạn chưa làm, hãy thử Pair Programming bằng các kỹ thuật này. Bạn có thể thấy rằng việc thiết kế ứng dụng, chọn tên hay và làm rõ ý định của mình với đồng nghiệp sẽ dễ dàng hơn. Và cả hai bạn đều có khả năng phấn đấu làm rõ code của mình bằng cách thúc đẩy lẫn nhau.
• Hãy để lại mã tốt hơn một chút so với khi bạn tìm thấy nó!. Hãy nhớ Boy Scout Rule, khi chỉnh sửa các code hiện có, hãy cố gắng làm cho nó tốt hơn một chút so với lúc bạn mới nhận được. Nếu chúng ta thực hiện như vậy một cách nhất quán thì khả năng chúng ta phải viết lại ứng dụng sau này sẽ ít hơn nhiều.

Cảm ơn bạn đã đọc hết bài viết. Nếu thấy hay hãy để lại mình 1 vote và hẹn gặp lại trong bài viết tiếp theo! 🚀