Get in touch
or send us a question?
CONTACT

CÁC ANTI-PATTERN NÊN TRÁNH ĐỂ CODE KHÔNG BIẾN THÀNH “ĐỐNG RÁC”

 Design Pattern là những mẫu thiết kế code giúp giải quyết vấn đề, giúp code dễ bảo trì, dễ mở rộng hơn.

Anti pattern cũng là những cách thiết kế để giải quyết vấn đề, nhưng sử dụng nó lại… gây ra nhiều vấn đề hơn.

Một anti-pattern được nhiều người biết đó là hút thuốc lào thay cho thuốc lá, cách này cai được thuốc lá nhưng sẽ gây ra nhiều vấn đề vệ sinh và môi trường hơn.

Trong bài này, mình sẽ chia sẻ những anti-pattern chúng ta hay .. lỡ để nhầm vào code, hậu quả và cách giải quyết nó.

số lượng anti-pattern nhiều không đếm xuế, tính từ tầm planning, thiết kế architecture hệ thống, thiết kế object/module, cho tới lúc viết code.

Có nguyên quyển sách nói về anti-pattern

AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis:  Amazon.co.uk: J. Brown, William: 9780471197133: Books

Những Anti Pattern  phổ biến

Hard-code, Magic String và Number

Đây là 3 Anti Pattern, nhưng do chúng na ná giông giống nhau nên mình gom lại luôn:

  • Hard-code tức là… code cứng 1 số giá trị, 1 số logic cần thay đổi vào thẳng trong code (database connection, 1 số config).
  • Magic string và magic number tức là code cứng 1 con số, 1 string ảo diệu nào đó, mà không ghi rõ số/string đó từ đâu ra, nó là gì

Cách giải quyết: Anti Pattern này rất dễ xử lý. Chỉ cần không hardcode những giá trị config (mà đọc từ file config hoặc biết môi trường), tách các magic number ra thành biến riêng hoặc viết thêm comment là được.

God Class (The Blob) – Class siêu to không lồ

Đây là một pattern hay gặp ở những bạn sinh viên đang làm đồ án, hoặc ở các dự án quá cũ, do dev non tay viết.

Gob Class tức là Class siêu to khổng lồ Thần Thánh, làm gì cũng được nên gọi là God. Tình trạng này xảy ra khi mấy ông dev gom quá nhiều tính năng vào 1 class.

Class này có những cái tên như Helper, Utils, Controller, Main… và rất bự (có khi tới 3-5000 dòng code). Mỗi lần chỉnh sửa, thêm bớt tính năng là 1 cực hình.

Class siêu to khổng lồ chức năng vẹo gì cũng có

Cách giải quyết

  • Tuân thủ nguyên tắc Single Responsibility trong SOLID, mỗi class chỉ nên giữ 1 trách nhiệm
  • Refactor dần lại code, tách class thành các class nhỏ hơn, gom nhóm các function/data hay dùng chung thành 1 class riêng

Code theo phong cách Copy và Paste

Các bạn đừng lầm tưởng AntiPattern này là copy code trên mạng về bỏ vào code của mình nhé!

Đây là pattern theo kiểu viết code 1 lần, những lần sau cần dùng thì copy nguyên đoạn code cũ qua, sửa sửa lại 1 chút cho chạy được.

Cách giải quyết

  • Cách đơn giản nhất vẫn là tách đoạn code cần sử dụng thành hàm riêng, library riêng để dùng
  • Lưu ý: Có nhiều khi 3,4 hàm khác nhau quá thì đừng nên cố viết thành 1 hàm rồi tái sử dụng, code sẽ còn… rối hơn tách riêng ra.

Premature Optimization

Optimize code (Tối ưu code) là việc chỉnh sửa/viết lại code nhằm giảm dung lượng, hạn chế input/output, tăng tốc độ thực thi, giảm lượng phần cứng cần sử dụng.

Đôi khi, việc optimize code quá sớm (chưa biết chạy chậm chỗ nào, otpimize đoạn nào) là hoàn toàn không cần thiết, nó còn làm code phức tạp hơn, khó đọc, khó debug hơn.

Cách giải quyết

  • Không optimize vội hay optimize quá sớm. Hãy hỏi xem code đó có cần, có đáng để optimize hay không
  • Khi code chạy chậm, hãy dùng profiler để xác định đoạn code gây chậm, sau khi optimize thì dùng profiler để đo lại trước
  • Các bạn có thể xem lại bài Luận về Optimize Code của mình.

Spaghetti Code

Spaghetti Code để chỉ code rối như canh hẹ, lộn, … rối như mấy cọng mì spaghetti.  Đây là những dòng code móc nối nhiều module/class với nhau, flow đi vòng vèo, cực kì khó đọc và khó sửa.

Nguyên nhân là do team code mà không có design cụ thể, do developer lười nên code đại. Hoặc do requirement đổi liên tục, chồng chéo nhau, nhưng các module và design không được update, nên cũng gọi nhau chồng chéo luôn!

Cách giải quyết

  • Đây là Anti Pattern khó giải quyết triệt để nhất! Vì nó không chỉ liên quan tới code, mà còn liên quan tới thiết kế của các module trong hệ thống
  • Cách dễ nhất là đập bỏ và viết lại khi đã hiểu rõ logic ban đầu, nhưng sẽ tốn nhiều thời gian, có thể thiếu requirement
  • Nên refactor code dần dần, tách thành từng phần nhỏ. Có thể design lại các module nếu cần

Nguồn tham khảo :