Vì sao không nên loại bỏ trùng lặp trong mã quá sớm
- Nếu áp dụng nguyên tắc DRY (Don't Repeat Yourself) quá cứng nhắc, điều đó có thể dẫn đến sự trừu tượng hóa "premature" và khiến các thay đổi trong tương lai trở nên phức tạp hơn
- Cần suy nghĩ xem phần trùng lặp đó có thực sự không cần thiết hay là một chức năng sẽ phát triển độc lập theo thời gian
- Dù hàm hay lớp có vẻ giống nhau, chúng vẫn có thể mang những ngữ cảnh và yêu cầu nghiệp vụ khác nhau
- Thay vì chỉ làm cho mã ngắn hơn, hãy nghĩ xem mục đích của hàm có còn được giữ nguyên theo thời gian hay không
- Rủi ro của việc trừu tượng hóa: nếu một tính năng có khả năng phát triển theo hướng khác, thì trừu tượng hóa có thể phản tác dụng
- Khi thiết kế trừu tượng hóa, không nên gắn kết quá sớm những hành vi mà về lâu dài có thể phát triển riêng biệt
- Khi còn nghi ngờ, hãy giữ các hành vi tách rời cho đến khi theo thời gian xuất hiện đủ mẫu hình chung để biện minh cho việc gắn kết chúng
- Ở quy mô nhỏ, quản lý sự trùng lặp có thể đơn giản hơn là xử lý độ phức tạp do trừu tượng hóa premature gây ra
- Ở giai đoạn đầu phát triển, nên chấp nhận một chút trùng lặp và chờ đợi việc trừu tượng hóa
- Các yêu cầu trong tương lai thường khó dự đoán
- Cần nghĩ đến nguyên tắc YAGNI (You Aren't Gonna Need It)
- Sự trùng lặp có thể sẽ không trở thành vấn đề, hoặc theo thời gian sẽ cho thấy rõ nhu cầu về một sự trừu tượng hóa đã được cân nhắc đầy đủ
10 bình luận
Ngay từ đầu, việc áp dụng DRY nên được thực hiện theo hướng giảm bớt khi đang có lặp lại,
nhưng nếu suy nghĩ về code dựa trên DRY như một tiêu chuẩn đi trước thì có vẻ là cách áp dụng sai.
Trong các ý kiến trên Hacker News,
ý này là điều tôi đồng cảm nhất:
Sự hiểu lầm về nguyên tắc DRY: DRY là để ngăn chặn sự trùng lặp của thông tin/tri thức, chứ không phải trùng lặp code. Nếu chỉ tập trung vào trùng lặp code thì có thể dẫn đến tối ưu hóa không cần thiết.
Chẳng phải trong giai đoạn quá độ chúng ta thường suy nghĩ rất nhiều về những chuyện như vậy sao? Vì không có thứ gọi là code hoàn hảo nên ngày nào cũng phải trăn trở, đó hẳn cũng là công việc của chúng ta. Có lẽ còn tùy từng trường hợp.
Gần đây thỉnh thoảng lại xuất hiện những bài viết thể hiện góc nhìn hoài nghi về các cấu trúc có mức độ trừu tượng hóa cao.
MSA, clean code, SOLID, DRY, v.v...
Có lẽ mọi người đang cảm thấy mệt mỏi với những từ ngữ như thế.
Thực ra, những thứ đó chỉ là các cột mốc tham khảo khi ta suy nghĩ về việc viết code dễ đọc, dễ hiểu, không rò rỉ bộ nhớ, không lỗi và chạy nhanh mà thôi...
Cứ áp dụng vừa phải, sao cho phù hợp với tình hình kinh doanh mà mình đang đối mặt lúc này là được.
https://velog.io/@kineo2k/…
Bài viết quá hay. Đặc biệt mình thấy điều này càng quan trọng hơn khi chuyển từ mô hình thác nước sang mô hình Agile. Dù là Agile nhưng chúng ta vẫn cố dự đoán tương lai quá nhiều.
Bao nhiêu vội thì mới gọi là “quá sớm”?
Câu trả lời quá dễ: nếu làm ngay từ đầu thì đó là “vội vàng”.
Vấn đề khó hơn một chút là khi nào làm thì mới là “không vội vàng”.
Nghe như chơi chữ, nhưng nếu ngay từ đầu cứ đừng làm thì sẽ thành "không vội vàng" nhỉ ^^;
Đúng vậy, đặc biệt là trong Agile
Ý kiến trên Hacker News
Áp dụng nguyên tắc DRY từ sớm: Việc áp dụng nguyên tắc DRY ngay từ đầu là điều nên làm. Sử dụng một codebase chung sẽ hiệu quả hơn so với xử lý riêng các dữ liệu tương tự.
Thứ tự ưu tiên của best practice: Không phải mọi best practice đều như nhau. Ưu tiên tính dễ đọc và tính kết dính là điều quan trọng. Viết code là quá trình lựa chọn practice tốt nhất.
Hiểu lầm về nguyên tắc DRY: DRY nhằm ngăn chặn sự trùng lặp thông tin/tri thức chứ không phải trùng lặp code. Nếu chỉ tập trung vào trùng lặp code, điều đó có thể dẫn đến tối ưu hóa không cần thiết.
Vấn đề về khả năng tái sử dụng: Có những trường hợp một chức năng cụ thể không được tái sử dụng trong bối cảnh khác. Cần có cách tiếp cận tốt hơn để tránh lặp lại công việc.
Vấn đề của các giải pháp DRY phức tạp: Đôi khi code lặp lại lại tốt hơn một giải pháp DRY phức tạp. Áp dụng DRY quá sớm có thể gây ra những vấn đề cấu trúc ngoài dự kiến.
DRY không phải là best practice: Sự lặp lại thường là tín hiệu cho thấy cần có sự trừu tượng hóa. Việc áp dụng DRY một cách bừa bãi là lỗi mà các kỹ sư trình độ trung cấp thường mắc phải.
Ví dụ code đơn giản: Hai hàm có thể được gộp thành một hàm. Điều quan trọng là phải giải thích rõ ưu và nhược điểm của việc refactor.
Vấn đề bảo trì của code DRY: Code DRY có thể trở nên phức tạp và khó bảo trì. Ngược lại, code WET thì đơn giản hơn nhưng việc thay đổi lại có thể dự đoán được.
Tác dụng phụ của nguyên tắc DRY: Nguyên tắc DRY có thể làm codebase trở nên phức tạp và khó bảo trì hơn. Một số sách về clean code đã gây ảnh hưởng tiêu cực đến ngành.
Khái quát hóa và hiệu năng: Việc khái quát hóa có thể ảnh hưởng tiêu cực đến hiệu năng. Việc lặp lại code phù hợp với các mẫu dữ liệu cụ thể có thể hữu ích cho tối ưu hiệu năng.