Không tồn tại thứ gọi là Clean Code

xguru · 2022-02-03T10:55:01+09:00

Mọi người vẫn nỗ lực vì mã nguồn “clean”, nhưng “clean” không phải là một thước đo hữu ích Mã nguồn không thể đơn giản chỉ là “clean”. Vì “clean” không mô tả được gì về mã nguồn cả Khi mọi người nói mã nguồn là clean, thường là vì nó xuất sắc theo một cách nào đó Clean Code có thực sự là mã nguồn tốt không? Mã nguồn có thể xuất sắc vì nhiều lý do khác nhau → dễ đọc, dễ hiểu, đơn giản, hiệu năng tốt, an toàn, thanh lịch, dễ kiểm thử, được đóng gói, có thể mở rộng, dễ bảo trì, có thể tái sử dụng.. Nhưng ở một số khía cạnh, những đặc tính này lại xung đột với nhau → đoạn mã đơn giản nhất có lẽ không phải là đoạn dễ kiểm thử nhất → interface và dependency được inject giúp việc kiểm thử thuận tiện hơn, nhưng lại xa rời tính đơn giản → dùng quá nhiều singleton thì có thể dễ hiểu hơn, nhưng chưa chắc đã là một ứng dụng dễ bảo trì Một số trong đó về bản chất là đối lập nhau, nên có thể khó đáp ứng tất cả cùng lúc → Vì kỹ thuật là Trade-off (đánh đổi), nên đội ngũ hoàn toàn có thể thảo luận với nhau về những phương án đánh đổi được nói tới ở đây Nếu mã nguồn là xuất sắc, chúng ta cần nói rõ "vì sao" Khi ai đó nói một giải pháp là “clean”, thường là họ không thể lý giải hợp lý nguyên nhân mà chỉ nói đó là lựa chọn tốt hơn Để có một cuộc thảo luận mang tính xây dựng về giải pháp kỹ thuật, cần có khả năng giải thích rõ vì sao một giải pháp tốt hơn giải pháp khác → thay vì chỉ nói “clean”, hãy nói “được tách rời, dễ hiểu, dễ kiểm thử...” Cần sử dụng thuật ngữ chính xác Việc viết code nói chung là môn thể thao đồng đội. Khi tự mình hack thì có thể làm tùy ý, nhưng khi làm việc với đội ngũ thì phải thảo luận ý tưởng Thảo luận về giải pháp kỹ thuật bằng ngôn ngữ cụ thể, và để cả nhóm có cùng một cách hiểu chung, là điều rất quan trọng để mọi người hiểu nhau Cụm từ “clean code” có ý nghĩa khác nhau với mỗi người → với ai đó là kiến trúc được định nghĩa tốt, với người khác lại là code được viết đơn giản với phong cách định dạng nhất quán.. Những từ như “đóng gói”, “dễ kiểm thử”, “có thể tái sử dụng” có ý nghĩa mà tất cả chúng ta đều cùng đồng ý Khi dùng những từ cụ thể hơn để mô tả đặc tính của mã nguồn, chúng ta sẽ chắc chắn hơn rằng mình đang ở cùng một trang “clean” có độ chính xác tương đương với từ “tốt” Vậy thì “Clean Code” là gì? Tôi đi đến kết luận rằng khi mô tả code là “clean”, điều đó thường có nghĩa là “code này tốt, nhưng tôi không hoàn toàn chắc lý do vì sao” → hoặc là biết vì sao code tốt, nhưng không tìm ra được từ ngữ diễn đạt rõ ràng Việc rèn luyện trực giác như vậy cũng tốt, nhưng không nên dừng ở đó. Ta nên đào sâu hơn để hiểu “vì sao đoạn code này tốt” → đoạn code này có đặc tính nào khác mà những đoạn khác không có không? Và đặc tính đó có thực sự phù hợp nhất với dự án của chúng ta không? Có lẽ đó chưa chắc là giải pháp đúng Điều tôi mong là chúng ta có thể chắc chắn rằng thứ mình cần không phải là clean code, mà là ______ code

(steveonstuff.com)

43 điểm bởi xguru 2022-02-03 | 6 bình luận | Chia sẻ qua WhatsApp

Mọi người vẫn nỗ lực vì mã nguồn “clean”, nhưng “clean” không phải là một thước đo hữu ích
Mã nguồn không thể đơn giản chỉ là “clean”. Vì “clean” không mô tả được gì về mã nguồn cả
Khi mọi người nói mã nguồn là clean, thường là vì nó xuất sắc theo một cách nào đó

Clean Code có thực sự là mã nguồn tốt không?

Mã nguồn có thể xuất sắc vì nhiều lý do khác nhau
→ dễ đọc, dễ hiểu, đơn giản, hiệu năng tốt, an toàn, thanh lịch, dễ kiểm thử, được đóng gói, có thể mở rộng, dễ bảo trì, có thể tái sử dụng..
Nhưng ở một số khía cạnh, những đặc tính này lại xung đột với nhau
→ đoạn mã đơn giản nhất có lẽ không phải là đoạn dễ kiểm thử nhất
→ interface và dependency được inject giúp việc kiểm thử thuận tiện hơn, nhưng lại xa rời tính đơn giản
→ dùng quá nhiều singleton thì có thể dễ hiểu hơn, nhưng chưa chắc đã là một ứng dụng dễ bảo trì
Một số trong đó về bản chất là đối lập nhau, nên có thể khó đáp ứng tất cả cùng lúc
→ Vì kỹ thuật là Trade-off (đánh đổi), nên đội ngũ hoàn toàn có thể thảo luận với nhau về những phương án đánh đổi được nói tới ở đây

Nếu mã nguồn là xuất sắc, chúng ta cần nói rõ "vì sao"

Khi ai đó nói một giải pháp là “clean”, thường là họ không thể lý giải hợp lý nguyên nhân mà chỉ nói đó là lựa chọn tốt hơn
Để có một cuộc thảo luận mang tính xây dựng về giải pháp kỹ thuật, cần có khả năng giải thích rõ vì sao một giải pháp tốt hơn giải pháp khác
→ thay vì chỉ nói “clean”, hãy nói “được tách rời, dễ hiểu, dễ kiểm thử...”

Cần sử dụng thuật ngữ chính xác

Việc viết code nói chung là môn thể thao đồng đội. Khi tự mình hack thì có thể làm tùy ý, nhưng khi làm việc với đội ngũ thì phải thảo luận ý tưởng
Thảo luận về giải pháp kỹ thuật bằng ngôn ngữ cụ thể, và để cả nhóm có cùng một cách hiểu chung, là điều rất quan trọng để mọi người hiểu nhau
Cụm từ “clean code” có ý nghĩa khác nhau với mỗi người
→ với ai đó là kiến trúc được định nghĩa tốt, với người khác lại là code được viết đơn giản với phong cách định dạng nhất quán..
Những từ như “đóng gói”, “dễ kiểm thử”, “có thể tái sử dụng” có ý nghĩa mà tất cả chúng ta đều cùng đồng ý
Khi dùng những từ cụ thể hơn để mô tả đặc tính của mã nguồn, chúng ta sẽ chắc chắn hơn rằng mình đang ở cùng một trang
“clean” có độ chính xác tương đương với từ “tốt”

Vậy thì “Clean Code” là gì?

Tôi đi đến kết luận rằng khi mô tả code là “clean”, điều đó thường có nghĩa là “code này tốt, nhưng tôi không hoàn toàn chắc lý do vì sao”
→ hoặc là biết vì sao code tốt, nhưng không tìm ra được từ ngữ diễn đạt rõ ràng
Việc rèn luyện trực giác như vậy cũng tốt, nhưng không nên dừng ở đó. Ta nên đào sâu hơn để hiểu “vì sao đoạn code này tốt”
→ đoạn code này có đặc tính nào khác mà những đoạn khác không có không? Và đặc tính đó có thực sự phù hợp nhất với dự án của chúng ta không? Có lẽ đó chưa chắc là giải pháp đúng
Điều tôi mong là chúng ta có thể chắc chắn rằng thứ mình cần không phải là clean code, mà là ______ code

6 bình luận

kkw855 2023-04-18

Cảm ơn bài viết hay ~~

choijaekyu 2022-02-04

Đừng tùy tiện đá văng legacy code

Mày đã từng một lần đáp ứng được requirement đầu tiên của ai đó chưa?

sumkim 2022-10-12

Tôi đồng cảm.

rtyuiop 2022-02-03

Có vẻ như trong "cuốn sách đó", clean code mà tác giả nói đến tập trung vào hai yếu tố trong số này là "dễ hiểu" và "có thể kiểm thử". Tất nhiên, tôi cũng cho rằng cả hai đều là những thước đo rất quan trọng. Tuy nhiên, vì đặc tả vẫn chưa được chuẩn hóa hoặc thư viện vẫn chưa hoàn thiện nên đôi khi vẫn phải dùng những thứ thường được gọi là "hack", và theo cách này, có vẻ như việc chấp nhận đánh đổi chất lượng của code để bảo đảm chất lượng của chương trình là điều không thể tránh khỏi.

spilist2 2022-02-03

Tôi đồng cảm. Khi xem “clean” là “chất lượng cao”, thì như Weinberg đã nói, chất lượng là thứ gì đó có giá trị với một ai đó, nên tôi nghĩ trong đội ngũ cần có tiêu chí và định nghĩa về chất lượng.

xguru 2022-02-03

Đây là bài viết cho rằng thay vì nói mơ hồ là “clean code”, hãy chỉ rõ vấn đề muốn nói.

Về chủ đề này, trên Hacker News cũng có nhiều ý kiến khác nhau về cách hiểu “clean code”. Hãy xem cả phần bình luận nữa.

There’s No Such Thing as Clean Code https://news.ycombinator.com/item?id=30111516

Chủ đề có hơi khác một chút, nhưng bạn cũng có thể tham khảo bài viết dưới đây đã từng được đăng trước đây.

Tạm biệt, clean code [bản dịch] https://vi.news.hada.io/topic?id=1321