Tạm biệt, Clean Code (2020)

Lời tạm biệt với việc dọn dẹp mã

• Một đồng nghiệp đã check-in đoạn mã họ viết suốt cả tuần vào lúc đêm muộn.
• Triển khai tính năng điều chỉnh kích thước hình dạng trên canvas của trình biên tập đồ họa.
• Mã hoạt động được, nhưng mang tính lặp lại.

Sáng hôm sau...

• Sếp đề nghị nói chuyện riêng và yêu cầu hoàn tác các thay đổi trong mã.
• Ban đầu tôi bị sốc, nhưng rồi nhận ra quyết định của sếp là đúng.

Giai đoạn

• Việc ám ảnh với "mã sạch" và mải mê loại bỏ trùng lặp là một giai đoạn mà nhiều lập trình viên từng trải qua.
• Khi thiếu tự tin vào mã của mình, rất dễ gắn lòng tự trọng và niềm tự hào nghề nghiệp vào những thứ có thể đo đếm được.
• Sau khi học về trừu tượng hóa, ta sẽ muốn dùng nó mỗi khi nhìn thấy mã lặp lại.

Ý kiến của GN⁺

• Điều quan trọng là mục tiêu không phải theo đuổi độ "sạch" của mã, mà đó là một dạng cơ chế phòng vệ khi xử lý các hệ thống phức tạp.
• "Mã sạch" giúp lập trình viên đóng vai trò người dẫn đường trong những vùng chưa biết, nhưng cũng cần biết buông bỏ thay vì chỉ bám chặt vào nó.
• Bài viết này đưa ra một góc nhìn thú vị, nhắc các lập trình viên về tầm quan trọng của hợp tác và tính thực dụng trong quá trình viết và bảo trì mã.

[GN⁺]

Ý kiến Hacker News

• "Clean Code" cần được làm mới hình ảnh thương hiệu

  • Mục tiêu của clean code là làm cho mã đơn giản hơn và dễ bảo trì hơn
  • Giá trị của phần mềm nằm ở khả năng thay đổi theo thời gian
  • Nếu refactoring khiến việc bảo trì trở nên khó hơn thì đó không phải là clean code
  • Việc không thảo luận về refactoring với tác giả ban đầu là một vấn đề khác, không liên quan đến clean code

• Việc lặp lại mã đôi khi có thể là điều tốt, nhưng đó không phải bằng chứng cho thấy clean code là xấu

  • Nếu thay 10 dòng phép tính toán học lặp lại bằng một hàm thì mã có thể trở nên clean hơn
  • Cần review PR và từ chối nếu không đáp ứng tiêu chuẩn
  • Thái độ xem nhẹ tầm quan trọng của clean code cuối cùng sẽ dẫn đến một codebase mà không ai muốn làm việc
  • Bài học ở đây là cần giao tiếp tốt hơn và biết tiết chế

• Một đồng nghiệp đã viết rất nhiều mã bằng cách copy-paste

  • Refactoring nên được đưa lên để review
  • Việc sếp trực tiếp can thiệp và chỉ đạo hoàn tác là một tín hiệu xấu
  • Bài học không phải là copy-paste tốt hơn việc viết hàm

• Rất có thể phiên bản clean code đã thay thế đoạn mã bẩn trước đó

  • Cần rút ra bài học về cách làm việc trong đội nhóm

• Khi thay đổi mã, cần có review từ đồng nghiệp

  • Cần nhận ra rằng đang thiếu một quy trình tốt
  • Chỉ nên refactor mã khi thực sự cần thiết

• Trong lĩnh vực tài chính, thường xuyên phải xử lý các sản phẩm giống nhau nhưng vẫn khác biệt

  • Điều quan trọng là tránh trừu tượng hóa quá mức mà vẫn giữ được clean code

• Các ngôn ngữ như Haskell tối đa hóa mức độ trừu tượng ở cấp độ ngôn ngữ

  • Chúng giảm thiểu trừu tượng hóa theo từng dự án nhưng chi phí học tập lại cao

• Việc tách các phép tính toán học lặp lại vào một hàm riêng là clean code

  • Việc refactor các hàm resize trông như đang hình thành một interface lại là sai lầm

• Giải thích về trừu tượng hóa tồi

  • Vấn đề là thiết kế mà không cân nhắc đầy đủ đến việc sử dụng trong tương lai

• Rob Pike từng nói: "một chút sao chép còn tốt hơn một chút phụ thuộc"

  • Nguyên tắc DRY đôi khi dẫn đến việc thêm trừu tượng, nhưng nếu phần trừu tượng đó không đủ trực giao thì ngược lại còn làm vấn đề tệ hơn