Orthogonality — Khi 'mỗi thứ lo việc của mình' là chìa khóa của code sạch

Mở đầu

Mấy bạn ơi, mình lại lên đây tiếp nè. Tuần này mình tiếp tục với series cảm nhận "The Pragmatic Programmer" — cuốn sách mà mình nghĩ anh em dev nào cũng nên đọc ít nhất một lần trong đời. Bài hôm nay mình sẽ nói về Topic 10: Orthogonality, một concept nghe có vẻ cao siêu nhưng thực ra gần gũi hơn mình tưởng.

Cuốn sách này hay ở chỗ nó không dạy mình code theo kiểu "làm A rồi làm B", mà dạy mình tư duy — cái mà sau này áp dụng được trong mọi ngôn ngữ, mọi dự án.

Ảnh: Alexandra Krainyukhova — Pexels

Orthogonality — Cái gì mà "vuông góc" với code?

Nghe chữ "orthogonality" (tính trực giao) là thấy toán học ha. Nhưng đừng lo, giải thích đơn giản thế này: hai thứ gọi là orthogonal khi thay đổi cái này không ảnh hưởng tới cái kia. Giống như remote TV vậy — mình bấm tăng volume thì không làm đổi kênh, mỗi nút lo việc riêng của nó.

Trong phần mềm, orthogonality là một trong những nguyên lý quan trọng nhất mà mình nghĩ dev nào cũng nên thấm. Sách đưa ra mấy ví dụ cực kỳ thực tế:

• Module độc lập: Một class/service chỉ lo một việc. Đổi cơ sở dữ liệu từ PostgreSQL sang MySQL không làm sập tính năng gửi email.
• Component tách rời: Layer nào biết layer đó. UI không cần biết business logic xử lý ra sao.
• Thiết kế theo chiều dọc, không ngang: Khi thêm tính năng mới, mình thêm module mới — không phải sửa hết mấy module cũ.

Tác giả còn nhấn mạnh một câu rất đắt: "Orthogonality is closely related to Don't Repeat Yourself (DRY)." Vì khi code không bị trùng lặp, mỗi thay đổi chỉ cần làm ở một chỗ — đó cũng chính là lúc orthogonality được đảm bảo.

Ảnh: Markus Spiske — Pexels

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

Cái hay của topic này là nó không chỉ áp dụng cho code, mà còn cho cách làm việc của team. Sách nói về "orthogonal teams" — mỗi team phụ trách một mảng riêng, không giẫm chân lên nhau. Nhìn lại công ty mình đang làm, thấy đúng ghê.

Còn nhớ hồi mới đi làm, mình gặp một cái bug "kinh điển": sửa cái hiển thị ngày tháng ở màn hình A, vô tình làm hỏng luôn báo cáo xuất PDF ở màn hình B. Tại sao? Vì code format date được dùng chung lung tung, không có module riêng, ai cần là copy paste. Thiếu orthogonality đó mấy bạn.

Kể từ lúc đọc được khái niệm này, mình bắt đầu để ý kỹ hơn mỗi khi thiết kế: module này có đang làm đúng một việc không? Nếu mình đổi cái này, có cái khác bị ảnh hưởng không? Chỉ một câu hỏi đơn giản vậy thôi mà đã cứu mình khỏi không biết bao nhiêu lần đau đầu debug.

Sách còn chỉ mình cách test orthogonality: nếu mình thấy một bug ở module A mà phải mở cả module B, C, D ra sửa thì chắc chắn thiết kế đang có vấn đề. Nghe đơn giản nhưng xưa giờ có ai chỉ mình vậy đâu.

Ảnh: Canva Studio — Pexels

Kết

Orthogonality không phải thứ gì cao siêu — nó là nguyên lý "mỗi thứ chỉ lo việc của mình" được áp dụng một cách có hệ thống. Cả trong code, kiến trúc, team, cho tới quy trình làm việc. Khi nào mình design mà thấy "sửa chỗ này không ảnh hưởng chỗ kia" là lúc mình đã làm đúng.

Bài sau mình sẽ nói về Topic 11: Reversibility — cái này cũng hay không kém nha. Hẹn mấy bạn tuần sau!