Thiết Kế Tốt
Thiết kế xuất sắc
Vài ngày trước, tôi có ý định viết thêm một cuốn sách nữa. Rất nhiều bạn bè đã cổ vũ tôi, nhưng hiện tại tôi vẫn chưa thể bắt tay vào được. Lý do chính gồm ba điểm sau:
Thứ nhất, công việc hiện tại quá bận rộn, gần như ngập trong deadline. Tôi cảm giác mình đang bị cuốn vào một vòng xoáy không lối thoát. Trước tiên cần dành thời gian sắp xếp lại công việc, lập kế hoạch chi tiết, giải quyết ổn thỏa các vấn đề tồn đọng. Không chỉ là kỹ thuật, quản lý, hợp tác nhóm hay vận hành dự án, mà là tổng hòa của hàng loạt yếu tố phức tạp. Tôi phải cố gắng hết sức để vượt qua giai đoạn này.
Thứ hai, cuốn sách trước tôi viết quá vội vàng. Dù nội dung đã tích lũy một thời gian, nhưng vẫn chưa đủ dày dặn. Kinh nghiệm viết sách còn quá ít ỏi. Tôi không sợ bị chỉ trích vì sai sót, mà sợ chính mình sẽ hối hận khi nhìn lại.
Thứ ba, nếu tiếp tục viết, tôi chỉ tập trung vào một vài chủ đề trọng tâm. Tuy nhiên ý tưởng vẫn chưa chín muồi. Dù đã tích lũy được kha khá tư liệu, nhưng để biến thành sách thì vẫn còn thiếu. Viết sách khác hoàn toàn so với viết blog bâng quơ.
Anh Meng Yan gợi ý tôi nên phác thảo dàn ý trên blog trước, viết đại vài chương rồi xin ý kiến cộng đồng, từ từ chỉnh sửa thành sách. Tôi cũng có ý tưởng tương tự, nhưng ngay cả dàn ý cơ bản lúc đầu có lẽ cũng phải viết theo cảm hứng, sau đó mới tổng hợp các ý tưởng rời rạc thành đề cương chính thức.
Gần đây tôi chủ yếu dùng C và Lua để phát triển, nên sẽ lấy đó làm nền tảng. Giả định độc giả đã nắm vững C. Tôi muốn bàn về cách xây dựng một phần mềm hoàn chỉnh từ góc độ kỹ thuật - thế nào là một phần mềm tốt?
Một câu hỏi cốt lõi, cũng là vấn đề muôn thuở: Thế nào là thiết kế tốt?
Thiết kế tốt phải dễ triển khai. Nó có thể tinh tế nhưng không được phức tạp khó hiểu.
Trong ngành phần mềm, không có gì là mới mẻ cả. Những ý tưởng bạn nghĩ ra, chắc chắn đã có người nghĩ đến trước. Mỗi phần mềm đều có vòng đời nhất định, nhiệm vụ của chúng ta là hoàn thành sứ mệnh trong giai đoạn đó. Phần mềm thường phải đưa vào sử dụng nhanh chóng, rồi tiến hóa qua quá trình vận hành. Sự tiến hóa này không thể phụ thuộc vào một cá nhân. Khi càng nhiều người tham gia, sự đồng thuận càng giảm. Chỉ khi mọi lập trình viên đều hiểu rõ và chấp nhận, phần mềm mới tránh được sự biến chất tiêu cực.
Chúng ta thường nói đến mô-đun hóa, tính kết dính cao và độ kết nối thấp. Bản chất là cách quản lý độ phức tạp - biến việc phát triển phần mềm khó khăn thành các bài toán nhỏ dễ giải quyết hơn. Nhưng chính những mối liên hệ phức tạp giữa các mô-đun lại là thách thức lớn nhất cho người thiết kế.
Một số nguyên tắc nghe thì hay nhưng thực hiện rất khó. Ví dụ: làm sao đảm bảo đầu vào/đầu ra của mô-đun không có hiệu ứng phụ? Bạn có thể đảm bảo mỗi đầu vào chỉ tương ứng duy nhất một đầu ra không? Hay như việc phân tầng mô-đun - nếu A phụ thuộc B, B phụ thuộc C, làm sao đảm bảo A hoàn toàn độc lập với C? Thậm chí còn có trường hợp tệ hơn là ba mô-đun phụ thuộc vòng tròn lẫn nhau.
Trừu tượng hóa là công cụ tuyệt vời, nhưng nếu lạm dụng sẽ tạo ra những hệ thống cồng kềnh. Dù cuối cùng có thể lắp ráp như xếp lego, hay thuê thêm lập trình viên làm việc theo mẫu đơn giản, nhưng hiệu năng phần mềm sẽ tụt giảm nghiêm trọng, bug ẩn nấp lâu ngày rồi bùng phát thành thảm họa.
Thiết kế tốt đòi hỏi sự thấu hiểu vấn đề như nghệ nhân mổ bò - cắt xẻ chính xác ở điểm yếu nhất. Khi làm được điều này, bạn đã thành công một nửa.
Việc giải quyết vấn đề không liên quan đến ngôn ngữ lập trình. Tranh luận về ngôn ngữ là vô nghĩa. Như đã nói, nếu thiết kế tốt và quan hệ mô-đun rõ ràng, hầu hết ngôn ngữ phổ biến đều có thể triển khai. Tôi chọn C thay vì C++ để tránh tranh cãi về tính năng: “Có nên dùng cái này không? Tính năng kia có hiệu năng tốt hơn không?”
Hiệu suất lập trình phụ thuộc vào cá nhân và ngôn ngữ. Nhưng với thiết kế tốt, hiệu quả không còn lệ thuộc vào ngôn ngữ nữa. Giai đoạn triển khai, niềm vui và sự tự tin của lập trình viên khi hoàn thành giao diện mới là thước đo thiết kế. Lúc này, ngôn ngữ hiệu quả (ít mã nguồn) hay dễ học (giảm lỗi) đều có ưu thế.
Trong nhóm của tôi, tôi ưu tiên phương pháp giúp lập trình viên triển khai dễ dàng. Không cần quan tâm chi tiết ngôn ngữ, không cần học nhiều khái niệm mới (nhất là những thứ đặc thù dự án), thậm chí code review không quá khắt khe vẫn đảm bảo chất lượng.
Tôi tin rằng khi phần mềm phát triển đến giai đoạn trưởng thành, người thiết kế không cần viết nhiều code nữa. Dù hiện tại tôi vẫn viết hàng ngày, nhưng không cảm thấy nhàm chán.
Việc ôm đồm mọi thứ không tốt, nhưng chỉ khi bạn tạo ra thiết kế xuất sắc, dù ai triển khai cũng không thể làm hỏng được. Lúc đó, việc bạn tự viết hay nhờ thêm đồng nghiệp hỗ trợ không còn quan trọng nữa.