Tư duy DRY – Don’t Repeat Yourself

DRY là viết tắt của Don’t Repeat Yourself, nghĩa là Đừng lặp lại chính mình. Đây là một nguyên tắc quan trọng trong quá trình phát triển phần mềm, khuyến khích các lập trình viên tránh viết code trùng lặp nhiều lần.

Lợi ích của DRY?

• Dễ bảo trì: Khi code không bị lặp lại, việc sửa lỗi và cập nhật sẽ trở nên dễ dàng hơn. Thay vì phải sửa đổi nhiều nơi khác nhau, bạn chỉ cần sửa đổi một chỗ duy nhất.
• Dễ mở rộng: Khi code được viết theo tư duy DRY, việc thêm tính năng mới sẽ trở nên dễ dàng hơn. Bạn không cần phải sao chép và dán code hiện có, mà chỉ cần tạo ra code mới để sử dụng lại các chức năng đã có.
• Dễ hiểu: Code phát triển theo tư duy DRY thường dễ đọc và dễ hiểu hơn code bị lặp lại. Điều này giúp cho các lập trình viên khác dễ dàng tham gia vào dự án và hiểu được cách thức hoạt động của mã.
• Giảm thiểu lỗi: Việc lặp lại code có thể dẫn đến lỗi. Khi bạn chỉ viết code một lần, bạn sẽ giảm thiểu nguy cơ mắc lỗi. Các unit test sẽ nhỏ và dễ bao quát toàn bộ vấn đề hơn.

Cách áp dụng tư duy DRY

Sử dụng các thư viện phổ biến

Các thư viện phổ biến như Bootstrap 5, Swiper Slide, Flickity Slider,… được thiết kế với nhiều triết lý và nguyên tắc gần giống DRY, cung cấp các mức độ giảm thiểu code lặp khi bạn triển khai dự án.

Sử dụng thư viện nội bộ tự phát triển

Một khi các công ty có nhiều nhóm phát triển phần mềm, bạn sẽ cân nhắc tới việc thu thập và xây dựng các pattern (mẫu) hoặc components phổ biến, đóng vai trò cốt lõi cho nhiều dự án. Khi đó, các thư viện tự phát triển đóng vai trò quan trọng giúp các dự án tiếp theo có cơ sở giảm thiểu việc code lặp, tiết kiệm thời gian và công sức.

Trừu tượng hóa (Abstract)

Trừu tượng hóa là quá trình tập trung vào các khái niệm chung và bỏ qua các chi tiết cụ thể. Khi bạn trừu tượng hóa code, bạn có thể tạo ra các function và class có thể được sử dụng lại trong nhiều trường hợp khác nhau.

Sử dụng các mẫu thiết kế

Các mẫu thiết kế là những giải pháp đã được thử nghiệm và kiểm chứng cho các vấn đề lập trình phổ biến. Sử dụng các mẫu thiết kế có thể giúp bạn viết mã DRY và dễ bảo trì hơn. Các mẫu thiết kế có sử dụng Design System (bao gồm Typography – kiểu font chữ, Colors – màu sắc, Spacing – tỷ lệ khoảng cách, Sample Components – các định dạng component trong dự án) giúp quy chuẩn mọi thứ tốt hơn, và khi code sẽ tái sử dụng cao.

Những sai lầm và ví dụ phổ biến khi thiếu đi triết lý DRY

Trong quá trình mình cùng team triển khai dự án cho khách hàng, đôi lúc team phải xử lý các dự án của các công ty khác. Một số lỗi sau có thể nhận ra trong quá trình phát triển và tiếp xúc các dự án CNTT.

Code lặp

Một slider có sự tương đồng cao trong nhiều trang thì có thể chỉ cần code một lần và đưa ra config chung hoặc riêng. Một số dự án có DEV non tay thì sẽ gặp tình trạng copy code từ trang này sang trang khác, tạo ra vô số initialization class hoặc method giống không khác nhau một dòng nào. Điều này rất dễ gặp với các sinh viên mới ra trường hoặc các bạn làm việc trong đội nhóm không có leader cứng tay và review code tốt.

Code khó hiểu

Khó có dòng code nào tốt nếu nó xuất hiện ở nhiều chỗ và chẳng có sự thống nhất nào cả. Có thể ở trang này hay trang kia, cách thể hiện của nó có vẻ gần giống nhau nhưng lại đặt tên biến, đặt tên function khác nhau. Điều ấy khiến việc đọc hiểu code và mở rộng chức năng trở nên khó khăn hơn.

Khó bảo trì

Thực tế, chi phí bảo trì của dự án sẽ thường tăng 150-200% nếu code base được tổ chức thiếu sự kiểm soát ban đầu ngay trong quá trình sản xuất phần mềm. Mình cũng có khách hàng thực tế phải chịu chi phí tăng 150% so với các đầu task thông thường, với lý do là hệ thống code do team cũ triển khai thiếu sự đồng bộ, chưa module hoá tốt dẫn đến thời gian để xử lý task kéo dài hơn.

Khó mở rộng

Cũng với lý do tương tự công việc bảo trì phần mềm, việc mở rộng chức năng trên các dự án chưa có tư duy DRY cũng gian nan không kém. Muốn bổ sung các component khi chưa có tổ chức các thư viện component trong dự án sẽ cần bạn refactor rất nhiều thứ, thay vì đơn giản thêm component.

Dễ tăng số lượng lỗi

Không hề ngạc nhiên nếu trong dự án thiếu đi DRY, số lượng lỗi được phát hiện có phần tăng đáng kể. Các unit test không đạt hiệu quả do nhiều module không có tính kế thừa, dẫn tới manual test nhiều hơn automation test, hoặc dẫn tới khung thời lượng dành cho testing tăng đáng kể.

Kết luận

Trong thực tế, team mình triển khai tư duy DRY bằng cách kết hợp một phần thư viện bên ngoài (có giản lược) với thư viện nội bộ do team Code Tốt tự triển khai. Nhờ vậy, nhiều dự án đã tiết kiệm được thời gian và công sức phát triển dựa trên các component và function hỗ trợ có sẵn.