Nguyên tắc DRY trong lập trình và công việc: hiểu đúng để không lạm dụng

Gần như lập trình viên (Developer) nào cũng nghe câu “đừng lặp lại chính mình” từ những ngày đầu học nghề. Nhưng nguyên tắc DRY bị rút gọn thành khẩu hiệu chống copy-paste đã làm mất phần quan trọng nhất của nó, thậm chí khiến nhiều đoạn mã trở nên khó sửa hơn. Bài viết trả lại phát biểu gốc và chỉ ra ranh giới nên dừng.

1. Nguyên tắc DRY là gì theo phát biểu gốc

DRY viết tắt của Don’t Repeat Yourself, xuất hiện trong cuốn The Pragmatic Programmer do Andy Hunt và Dave Thomas viết, xuất bản năm 1999. Phát biểu gốc của hai tác giả là: mỗi mẩu tri thức phải có một biểu diễn duy nhất, rõ ràng và có thẩm quyền trong hệ thống. Đọc kỹ sẽ thấy câu này không hề nhắc tới ký tự, dòng lệnh hay thao tác sao chép, mà nhắc tới tri thức và tính thẩm quyền của nơi lưu giữ nó.

Tri thức ở đây là một quy tắc nghiệp vụ, một công thức tính hay một cấu hình. Khi cùng một quy tắc tồn tại ở ba nơi, người sửa phải nhớ cả ba, và sai sót thường xuất hiện ở lần sửa thứ hai chứ không phải lần đầu. Chi phí thật nằm ở khâu bảo trì, không nằm ở số dòng mã bạn gõ.

2. DRY nói về tri thức, không phải về các đoạn mã trông giống nhau

Đây là chỗ nguyên tắc DRY hay bị hiểu chệch. Hai hàm có thể giống nhau tới từng dòng nhưng phục vụ hai nghiệp vụ độc lập, chẳng hạn cách tính phụ cấp đi lại và cách tính phí giao hàng tình cờ cùng nhân với một hệ số. Gộp chúng thành một hàm dùng chung nghĩa là bạn tuyên bố hai nghiệp vụ ấy phải thay đổi cùng nhau mãi mãi. Đến ngày phòng nhân sự đổi cách tính phụ cấp, người sửa phải thêm tham số điều kiện rồi thêm nhánh rẽ, và hàm chung ấy dần thành nơi không ai dám đụng vào.

Trùng lặp ngẫu nhiên là thuật ngữ chỉ đúng tình huống này. Cách phân biệt thực dụng là tự hỏi: khi có yêu cầu mới, hai chỗ này có buộc phải đổi cùng lúc không. Nếu có thì chúng chia sẻ tri thức và nên gộp, nếu không thì chỉ tình cờ giống nhau. Tư duy ấy nằm trong nhóm kỹ năng thiết kế mà bài Kỹ năng cần có của lập trình viên đề cập ở phần nền tảng chuyên môn.

3. Khi DRY bị đẩy quá đà

Áp dụng nguyên tắc DRY một cách máy móc dẫn tới trừu tượng hóa quá sớm, tức tạo lớp dùng chung khi chưa đủ dữ kiện để biết cái chung thật sự là gì. Lập trình viên Sandi Metz viết trong bài The Wrong Abstraction rằng lặp lại rẻ hơn nhiều so với một trừu tượng hóa sai. Vài khái niệm dưới đây được dùng như đối trọng với DRY.

Khái niệm	Nội dung	Vai trò
Rule of three	Hai lần lặp thì để yên, tới lần thứ ba mới tách ra dùng chung	Cho bạn một điểm dừng cụ thể, được Martin Fowler phổ biến trong cuốn Refactoring
WET	Cách nói ngược lại DRY, tạm hiểu là viết mọi thứ hai lần	Nhắc rằng lần lặp đầu tiên chưa đủ dữ kiện để khái quát
AHA	Avoid Hasty Abstractions, tránh trừu tượng hóa vội vàng, do Kent C. Dodds nêu	Ưu tiên khả năng thay đổi hơn là gộp sớm cho gọn

Điểm chung của ba khái niệm là khuyên bạn chờ thêm dữ kiện. Hai bản sao chưa cho biết sự giống nhau là bản chất hay trùng hợp, còn bản thứ ba thường đủ để nhìn ra quy luật.

Lặp lại một đoạn mã là chi phí bạn nhìn thấy được; một trừu tượng hóa sai là chi phí bạn chỉ phát hiện sau vài tháng, khi mọi thay đổi đều phải lách qua nó.

Thói quen cân nhắc này được quan sát ngay ở vòng phỏng vấn kỹ thuật; bạn có thể xem các việc làm CNTT phần mềm đang tuyển trên CareerLink để đối chiếu yêu cầu ở từng cấp độ.

4. Áp dụng nguyên tắc DRY vào công việc văn phòng

Ra khỏi phạm vi lập trình, tinh thần một nguồn duy nhất vẫn giữ nguyên giá trị. Một con số chỉ nên có một nơi lưu có thẩm quyền, còn các báo cáo khác tham chiếu về đó thay vì chép tay sang từng tệp. Chuyện quen thuộc ở nhiều phòng ban là chỉ tiêu doanh thu nằm trong ba bảng tính, mỗi bảng do một người cập nhật, tới cuộc họp thì không ai biết con số nào mới nhất. Vấn đề không nằm ở việc sao chép mà ở chỗ không nơi nào được coi là bản gốc.

– Chốt một tệp hoặc một hệ thống làm nơi lưu gốc cho mỗi loại số liệu quan trọng.

– Dùng biểu mẫu chung cho toàn bộ phận thay vì để mỗi người tự chỉnh một bản riêng.

– Viết quy trình một lần vào tài liệu nội bộ rồi dẫn liên kết, thay vì giải thích lại trong từng email.

Cách kiểm chứng giống hệt bên lập trình: hỏi xem khi một dữ kiện thay đổi, bạn phải sửa ở mấy nơi. Con số càng lớn thì rủi ro sai lệch càng cao.

5. Câu hỏi thường gặp

1. Copy-paste code có phải lúc nào cũng vi phạm nguyên tắc DRY không?

Không hẳn. Nếu hai chỗ sao chép phục vụ hai nghiệp vụ độc lập và không thay đổi cùng nhau, giữ hai bản riêng có thể rẻ hơn gộp chung. Điều nên tránh là chép một quy tắc nghiệp vụ rồi quên mất mình đã chép.

2. Vậy nên gộp lại ở thời điểm nào là hợp lý?

Quy tắc số ba là mốc tham khảo thực dụng: tới lần lặp thứ ba, bạn đã có đủ mẫu để nhìn ra phần chung. Quan trọng hơn con số là ba chỗ đó có cùng lý do thay đổi hay không.

3. Người không làm kỹ thuật có cần biết nguyên tắc DRY không?

Có ích, vì bản chất là quản lý một nguồn thông tin gốc. Người làm nhân sự, kế toán hay vận hành gặp đúng vấn đề đó dưới dạng bảng tính trùng lặp và biểu mẫu mỗi nơi một kiểu.

Hiểu đúng nguyên tắc DRY nghĩa là chuyển câu hỏi từ “hai chỗ này có giống nhau không” sang “hai chỗ này có cùng một tri thức không”. Cách đặt câu hỏi ấy giữ cho hệ thống dễ sửa, đồng thời tránh được những lớp dùng chung cồng kềnh sinh ra từ thiện chí gộp sớm. Hãy thử soi lại một dự án bạn đang làm và tìm xem con số nào đang nằm ở nhiều nơi.

Nội dung trong bài mang tính tham khảo, tổng hợp từ tài liệu kỹ thuật phổ biến; cách áp dụng cụ thể thay đổi theo quy mô hệ thống và bối cảnh từng đội nhóm.

Minh An