Bản chất của Thiết kế Phần mềm: Tại sao "Clean Code" chưa phải là đích đến cuối cùng?

Các cuộc thảo luận về thiết kế phần mềm (software design) thường bắt đầu bằng những nỗ lực biện minh: "Tại sao chúng ta nên làm điều này?", "Lợi ích là gì?", hay "Mục đích là gì?". Tôi cho rằng đây là một cách tuyệt vời để bắt đầu, bởi vì các quyết định về sau—ví dụ như khi bạn chọn giữa các mẫu thiết kế (design patterns)—thường được định hướng bởi những mục tiêu đã được xác định ngay tại thời điểm này.

Một số mục tiêu phổ biến thường được nhắc đến bao gồm: tổ chức mã nguồn, giảm nợ kỹ thuật (technical debt), tuân thủ nguyên lý SOLID, tăng tính liên kết (cohesion), giảm sự phụ thuộc (decoupling), cải thiện khả năng bảo trì, thúc đẩy tái sử dụng, hoặc hỗ trợ kiểm thử (testability).

Không còn nghi ngờ gì nữa, đây là những mục tiêu tuyệt vời. Việc theo đuổi chúng chắc chắn sẽ dẫn đến phần mềm có chất lượng tốt hơn nhiều so với việc thiết kế chỉ để "cho có"—hoặc tệ hơn là không quan tâm gì đến thiết kế.

Vấn đề với các chỉ số trung gian (Proxies)

Vấn đề nằm ở chỗ: các mục tiêu này cũng chính là các thước đo. Và nguyên tắc là: bạn đo lường cái gì, bạn sẽ tối ưu hóa cái đó. Điều này khiến việc đo lường "đúng thứ cần đo" trở nên vô cùng quan trọng.

Nếu bạn từng đề xuất cải thiện khả năng tái sử dụng hoặc khả năng kiểm thử và bị hỏi ngược lại "Tại sao điều đó lại cần thiết?", bạn có thể đã nhận ra vấn đề. Những thứ như giảm nợ kỹ thuật, decoupling, cohesion, tái sử dụng, v.v... thực chất không phải là mục tiêu cuối cùng. Chúng nên được coi là các biến số đại diện (proxies) hoặc các nguyên tắc dẫn đường dựa trên giá trị cốt lõi thực sự.

Mối liên kết giữa Công nghệ và Kinh doanh

Tôi từng làm việc với một đồng nghiệp, dù là lập trình viên, nhưng lại cực kỳ giỏi trong việc thuyết phục phía kinh doanh áp dụng các công nghệ mới. Tôi không bao giờ quên cách anh ấy giải thích bí quyết của mình: luôn liên hệ ý tưởng kỹ thuật với việc tăng doanh thu hoặc giảm chi phí. Bạn phải nói chuyện với người làm kinh doanh bằng ngôn ngữ của họ.

Hơn cả việc "bán" một ý tưởng, điều này mang lại cho tôi một góc nhìn mới mẻ về mối quan hệ cộng sinh giữa công nghệ và kinh doanh.

Thước đo thực sự: Cắt giảm chi phí

Công nghệ sinh ra là để phục vụ kinh doanh. Do đó, một thiết kế phần mềm tốt phải là thiết kế giúp giảm thiểu tài nguyên cần thiết để xây dựng và bảo trì hệ thống. Quan điểm này, từng được Uncle Bob (Robert C. Martin) nhắc đến, hoàn toàn khớp với góc nhìn thực tế về kinh doanh.

Mục tiêu—hay giá trị—của thiết kế phần mềm thực chất chỉ là sự cắt giảm chi phí ròng (net reduction of cost).

Vì vậy, thước đo tốt nhất cho một thiết kế tốt chính là nỗ lực cần thiết để thay đổi/thích ứng phần mềm đó:

• Nếu nỗ lực tăng lên theo thời gian, đó là dấu hiệu của thiết kế tồi.
• Nếu nỗ lực giữ nguyên hoặc giảm xuống, đó là dấu hiệu của thiết kế tốt.

Thiết kế phần mềm mang tính dự báo. Không phải lúc nào cũng rõ ràng để biết thiết kế nào sẽ tốn ít công sức bảo trì hơn trong tương lai. Đây là lúc các nguyên tắc thiết kế (như SOLID) phát huy tác dụng như những "biển chỉ dẫn" hoặc các ước lượng gần đúng cho giá trị mà chúng đại diện. Tuy nhiên, chúng không phải là vật thay thế cho mục tiêu gốc, và việc coi chúng là đích đến cuối cùng là một sai lầm.

Kết luận

Thiết kế phần mềm cũng có chi phí (cost). Một chiến lược thiết kế sai lầm có thể gây hại cho cả doanh nghiệp lẫn công nghệ. Nó có thể làm phần mềm phức tạp hơn mà không mang lại lợi ích gì, và cuối cùng đi ngược lại mục đích thực sự của việc thiết kế.

Do đó, điều quan trọng là phải bám sát các giá trị cốt lõi. Thiết kế để giảm chi phí sẽ mang lại lợi ích cho doanh nghiệp, tinh gọn công nghệ, và quan trọng hơn, nó thể hiện năng lực và sự chuyên nghiệp thực sự.