🧭 Tạm biệt SOLID, Chào đón CLARITY
— Một hành trình cá nhân đến sự rõ ràng trong lập trình —
🕰️ Ngày xửa ngày xưa, khi mới bước chân vào con đường lập trình, phát triển phần mềm , việc tìm kiếm thông tin là điều không dễ dàng. Những cuộc tranh luận nhỏ nhặt diễn ra khá thường xuyên vì ai cũng có quan điểm riêng. Khi đó, chúng ta đọc sách để hiểu về các best practices, học cách viết code cho đúng và tránh những lỗi cơ bản.
📚 Những kiến thức cũ thường rất giá trị, vì đã được kiểm nghiệm qua thời gian và nhiều kỹ sư tài năng.
🌊 Thế giới thay đổi – và công nghệ cũng vậy
Ngày nay, chúng ta đang ngập trong thông tin và quan điểm. Trong môi trường như vậy, đôi khi những suy nghĩ cổ điển lại trở nên đáng tin cậy hơn vì đã “sống sót” qua thời gian.
Tuy nhiên, không phải mọi thứ cũ đều phù hợp với hiện tại. Giờ đây, bạn dễ dàng bắt gặp các bài viết cho rằng Clean Architecture là quá phức tạp, hay Clean Code chứa những ví dụ kém thực tế.
💣 Và rồi… có SOLID – một bộ nguyên tắc từng làm ta "đau khổ" không ít lần
✔ Ý tưởng thì tốt.
❌ Nhưng cách hiểu thì mỗi người mỗi kiểu.
Hỏi 10 lập trình viên về mỗi nguyên lý trong SOLID, thì thế nào cũng có người bảo bạn đang hiểu sai. Việc cố gắng áp dụng SOLID một cách máy móc có thể dẫn đến những đoạn code khó bảo trì, quá nhiều interface nhỏ, class "nhẹ như lông hồng", và cấu trúc phức tạp.
🎭 Tệ hơn là khi SOLID bị dùng như một vũ khí tranh luận trên các diễn đàn:“Cái này vi phạm SOLID rồi!”
❌ SOLID chưa bao giờ lỗi thời nhưng cũng đã đến lúc chúng ta cần một lối tư duy mới để phù hợp với từng hoàn cảnh
🌟 Mình xin giới thiệu: CLARITY
(Minh bạch - Rõ ràng - Dễ hiểu)
🔤 C – Consistent Abstraction Levels
🧠 Đừng trộn lẫn các tầng logic trong code.
Khi đang xử lý giao diện (UI animation), đừng map DTO sang domain model. Không thực hiện phép toán theo bit cấp thấp khi đang ở tầng tổng hợp dữ liệu. Ở mỗi nơi, xác định mức độ trừu tượng hiện tại và bám sát nó.
🧩 L – Limit Interfaces
Interface là công cụ, không phải cứu cánh. Mọi interface đều làm tăng độ phức tạp của hệ thống bằng cách ảnh hưởng đến khả năng khám phá. Nếu bạn có hàng trăm giao diện, sẽ trở nên khó để tìm ra cách triển khai của chúng, cách chúng được xây dựng và cách chúng liên quan đến phần còn lại của hệ thống
Đặc biệt là các giao diện chỉ có một implementation. Quy tắc chung: nếu bạn chỉ có một triển khai, đừng tạo giao diện. Nếu cần một triển khai khác trong tương lai, thật dễ dàng để trích xuất một - IDE rất giỏi trong việc đó. Loại bỏ một giao diện dự phòng khó hơn nhiều.
🌐 A – API Over Implementation
Hầu hết thời gian, API nên là mối quan tâm chính của bạn.
Một API rõ ràng nhưng code bên trong chưa hoàn hảo vẫn tốt hơn một API rối rắm với logic tuyệt vời.
🛠 Vẽ sơ đồ hệ thống trước, rồi mới nghĩ đến chi tiết cài đặt.
🔗 R – Reduce Dependency Complexity
Tránh tạo class nếu không thực sự cần thiết.
Interactor → Repository → Datasource chỉ để gọi API đơn giản? ❌ Bỏ đi.
🔒 I – Isolate Dependency Creation
Tách biệt nơi tạo object với nơi sử dụng nó.
Điều này giúp dễ test, dễ bảo trì.
Không nhất thiết phải dùng DI framework, nhưng nó giúp bạn tiết kiệm kha khá code thừa.
⚖️ T – Take Exceptions When Justified
📣 Nguyên lý là hướng dẫn – không phải luật bất di bất dịch.
Nếu bạn biết mình đang làm gì, hiểu lý do, thì phá luật là chấp nhận được.
Dùng 1 interface chỉ để mock một thư viện bên ngoài? Được, nếu bạn có lý do chính đáng.
🧭 Y – You Decide
Cuối cùng, chính bạn là người viết ra dòng code ấy. Các nguyên tắc sẽ hướng dẫn bạn chứ không phải quyết định phong cách viết code của bạn.
Học nguyên lý, đọc codebase, thảo luận với người khác.
Và quyết định theo hoàn cảnh, chứ không rập khuôn.
✅ Tóm tắt: Hãy chọn CLARITY Chữ cái Ý nghĩa
C-Consistent abstraction levels
L-Limit interfaces
A-API over implementation
R-Reduce dependency complexity
I-Isolate dependency creation
T-Take exceptions when justified
Y-You decide
🎉 Chúc bạn viết code vui vẻ – và rõ ràng! 💬 Nếu bạn từng mệt mỏi vì SOLID, thử CLARITY nhé!
Cảm ơn mn đã quan tâm theo dõi
Nguồn : https://krossovochkin.com/posts/2025_05_05_when_solid_breaks_choose_clarity/