Topic 8: The Essence of Good Design — Thế nào là một thiết kế tốt?

Ảnh: Alexandra Krainyukhova — Pexels

Mở đầu

Chào mấy bạn, lại là mình đây! 😊

Series "The Pragmatic Programmer" vẫn tiếp tục rồi nha. Hôm nay mình lật qua Topic 8 – The Essence of Good Design trong Chapter 2: A Pragmatic Approach. Nghe cái tên "bản chất của thiết kế tốt" nghe cao siêu vậy thôi, chứ thực ra tác giả nói một điều cực kỳ đơn giản, ai cũng hiểu được. Mình đọc xong gật gù suốt, vì nó đúng cái mình trăn trở từ lâu mà không biết diễn tả thế nào cho gọn.

Bản chất của Good Design là gì?

Tác giả đặt câu hỏi: Có một nguyên lý duy nhất nào mà nếu nắm được nó, mọi quyết định thiết kế đều trở nên rõ ràng không?

Câu trả lời là ETC — Easier to Change. Dễ thay đổi.

Đó. Chỉ vậy thôi. Một thiết kế tốt là một thiết kế mà khi yêu cầu thay đổi (và nó luôn thay đổi), bạn không phải vỡ mặt. Code của bạn có thể thích nghi, module có thể thay thế, dependency có thể swap ra vô — tất cả vì nó được thiết kế để dễ thay đổi.

Cái hay là nguyên lý này không phải một công thức kỹ thuật khô khan. Nó là kim chỉ nam để bạn tự hỏi mỗi khi đưa ra quyết định: "Lựa chọn nào làm cho hệ thống dễ thay đổi hơn?" Nếu bạn chọn được cái dễ thay đổi hơn, thì đó là quyết định đúng.

Tác giả cũng phân tích tại sao DRY, Orthogonality, Reversibility, Tracer Bullets đều chỉ là những cách khác nhau để nói lên một điều: giúp code dễ thay đổi. DRY loại bỏ duplication để khi thay đổi bạn chỉ cần sửa một chỗ. Orthogonality giúp thay đổi module này không ảnh hưởng module kia. Reversibility giữ cho bạn linh hoạt đổi hướng. Tất cả đều quy về ETC.

Ảnh: Miguel Á. Padriñán — Pexels

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

Mình thấy Topic này hay ở chỗ nó không dạy bạn một pattern cụ thể nào, mà dạy bạn cách suy nghĩ. Giống như học võ thuật vậy — thay vì học từng đòn, bạn học nguyên lý để tự sáng tạo ra đòn thế phù hợp.

Hồi mới đi làm, mình từng viết một cái module xử lý payment cho nhiều cổng thanh toán khác nhau. Hồi đó mình chưa đọc cuốn này, nhưng tự nhiên làm theo bản năng: tách mỗi cổng thành một class riêng, dùng interface chung, config-driven. Sau đó, team yêu cầu thêm cổng mới — mất đúng nửa ngày. Sếp khen. Mãi sau mới biết cái "bản năng" đó chính là ETC: mình vô tình thiết kế module theo hướng dễ thay đổi trước khi biết nó có tên.

Còn có lần khác, mình thấy một bạn trong team viết cái hàm xử lý đơn hàng dài 500 dòng, trong đó nhồi hết validation, tính toán, gửi email, cập nhật database — tất cả trong một chỗ. Mình hỏi "Sao không tách ra?" Bạn ấy bảo: "Thấy nó chạy được rồi, sửa sau." Và đúng là khi sửa sau… không ai dám đụng vô. Cả team sợ function đó. Đó là ETC phiên bản ngược — code được thiết kế để KHÔNG thể thay đổi, và nó trở thành legacy ngay từ ngày đầu.

Bài học ở đây là: dễ thay đổi không phải là một tính năng, nó là một thuộc tính thiết yếu của code sống. Code nào không dễ thay đổi là code chết.

Một điểm thú vị nữa: tác giả nói ETC không chỉ áp dụng cho code, mà còn cho kiến trúc, quy trình, thậm chí documentation. Hồi mình viết docs cho team, mình bắt đầu để mỗi trang ở dạng markdown riêng thay vì một file duy nhất — dễ cập nhật, dễ review, dễ tìm. Đó cũng là ETC đấy.

Ảnh: Brett Jordan — Pexels

Kết

The Essence of Good Design là Topic nền tảng cho tất cả những Topic sau. Nếu bạn chỉ nhớ được một câu từ cuốn sách này, hãy nhớ câu này: "Good design is easier to change than bad design."

Mỗi lần viết code, hãy tự hỏi mình: "Lựa chọn hôm nay có giúp tôi thay đổi dễ dàng vào ngày mai không?" Nếu câu trả lời là không, dừng lại và suy nghĩ lại.

Hẹn mấy bạn ở Topic sau — DRY — The Evils of Duplication. Topic này chắc quen thuộc với nhiều bạn rồi, nhưng đọc trong sách nó có góc nhìn sâu hơn mình tưởng đó! 🙌