DRY — The Evils of Duplication: Khi 'đừng lặp code' bị hiểu sai

Mở đầu

Cả nhà mình lại gặp nhau ở topic tiếp theo trong series "The Pragmatic Programmer" rồi nè. Hồi trước mình cũng từng nghĩ mấy cuốn sách dạng này thường viết lý thuyết suông, đọc xong cũng chả biết áp dụng vô đâu. Nhưng cuốn này khác thiệt — mỗi lần lật ra là lại thấy mấy cái "à ha!" moments. Hôm nay mình sẽ kể mấy bạn nghe về một topic mà nghe tên thôi cũng thấy quen thuộc: DRY — Don't Repeat Yourself, hay "cái ác của sự trùng lặp".

Ảnh: Lukas Blazek — Pexels

DRY — The Evils of Duplication

Chắc ai làm dev cũng từng nghe qua câu "đừng lặp lại code" rồi đúng không? Nhưng tác giả Andy Hunt với David Thomas nói rõ một điều mà nhiều người hiểu sai: DRY không phải là đừng lặp code, mà là đừng lặp kiến thức.

Nghe hơi trừu tượng ha. Để mình giải thích dễ hơn. Hai đoạn code giống nhau về mặt chữ nhưng nếu chúng đại diện cho hai khái niệm khác nhau trong hệ thống thì không phải là vi phạm DRY. Ngược lại, một business rule mà được viết ở 3 chỗ khác nhau với 3 cú pháp khác nhau thì đó mới là DRY bị phá vỡ — vì khi rule thay đổi, mấy bạn sẽ quên mất một trong ba chỗ đó.

Sách chia duplication ra làm mấy dạng: Imposed (bị ép buộc), Inadvertent (vô tình), Impatient (sốt ruột), và Interdeveloper (giữa các dev trong team). Điểm hay là tác giả không chỉ chửi cái xấu mà còn chỉ cách giải quyết từng dạng. Ví dụ như Impatient duplication — cái này mình thấy nhiều nhất: "Để code tạm đã, tí refactor sau." Kết quả là không bao giờ có "tí sau" nào hết.

Ảnh: Christina Morillo — Pexels

Cảm nhận của mình

Có một câu trong sách mà mình thích dữ lắm: "The easiest way to stay DRY is to keep things simple." Lúc còn junior, mình cứ nghĩ viết nhiều code là giỏi, là ra được value cho team. Giờ nghĩ lại thấy ngây thơ quá. Những lần mình gặp bug nhất trong đời đa phần là do sửa một chỗ mà quên sửa chỗ kia — chính xác là cái họa mà DRY nhắm tới.

Mình cũng ấn tượng với phần Interdeveloper duplication — khi nhiều dev trong team cùng implement một logic mà không biết nhau. Giải pháp của sách là khuyến khích trao đổi, code review, và đặc biệt là có một "knowledge repository" chung. Hồi xưa đọc tới đây mình nghĩ "ủa dễ ẹc", nhưng sau khi đi làm thấy team nào cũng có cái tribal knowledge — kiểu "anh A biết chỗ này, chị B biết chỗ kia" — mới thấy nó khó giải quyết cỡ nào.

DRY không chỉ áp dụng cho code đâu mấy bạn. Documentation, config, test data, thậm chí comment — tất tần tật đều có thể bị duplication và gây đau đầu. Comment mà nói cái code đang làm gì thay vì tại sao nó làm vậy cũng là một dạng duplication ác độc đó.

Ảnh: Brett Jordan — Pexels

Kết

Tóm lại, DRY không phải là một luật cứng nhắc kiểu "không được copy paste". Nó là một triết lý: mỗi mẩu kiến thức trong hệ thống chỉ nên có một đại diện duy nhất. Khi bạn thay đổi điều gì, chỉ cần sửa một chỗ và mọi thứ vẫn đồng bộ. Nghe thì đơn giản nhưng làm thì khó lắm — cần kỷ luật, cần teamwork, và cần cả cái "lương tâm nghề nghiệp" nữa.

Bài sau mình sẽ nói về Orthogonality — một khái niệm tưởng khô khao nhưng cực kỳ thực tế trong thiết kế phần mềm. Hẹn gặp lại mấy bạn nha! 📚