Lâu lâu trên blog Tạp Chí Lập Trình mới lại có một bài hút khách như vậy. Anh bạn Mê Kim Dung đã có những phân tích khá sắc sảo về tính đơn giản của các thiết kế trong các sản phẩm công nghệ hiện đại.
Nguyên lí về sự đơn giản (Simplicity) được nhắc đến từ rất lâu. Ngay từ đầu thập kỉ trước, KISS (“Keep it Short and Simple”, hay “Keep It Simple, Stupid!”) đã là một nguyên lí căn bản của Extreme Programming, và của cả OSS (được đề cập đến trong kinh điển “The Cathedral and the Bazaar“).
Câu hỏi về “tại sao” được trả lời rất thuyết phục. Nhưng đến cái phần này thì mới ngại: HOW? Đặc biệt với các bạn làm phần mềm vốn quen với lối làm việc kiểu tuần tự Phân tích>Thiết kế>Mã hóa>Kiểm thử>Đóng gói.
Trong bài có nhắc tới một thống kê của Standish:
“Thống kê cho thấy trong một hệ thống thông thường có đến 45% số lượng chức năng không bao giờ dùng đến, 35% ít khi dùng, chỉ có 20% là thường sử dụng. Vậy đừng lo việc lược bớt chức năng sẽ làm phần mềm của bạn không đáp ứng được yêu cầu người sử dụng. Thực tế, nhiều chức năng chỉ làm đội chi phí và thêm bối rối cho phía khách hàng mà thôi.”
Tuy vậy, làm sao để cắt đi cái 45%+35% kia là cả một câu chuyện dài trong ngành phần mềm, cho đến giờ vẫn còn là vấn đề nổi cộm. Hơn thế, làm sao để có được một thiết kế cho phép việc đó (tức là cắt bỏ đi những cái dư thừa), làm sao để luôn giữ cho thiết kế thật đơn giản? Đó cũng là câu chuyện dài không kém. Vì nó động tới sự kiên trì và đòi hỏi nỗ lực để đạt được một trình độ kĩ năng nhất định.
Tôi có gợi ý cho bạn đọc bài này nhé: Go Agile 😉
Tiện đây xin chia sẻ hai tài liệu thuyết trình ngắn của tôi, một cái về Simple Design, một practice không thể thiếu của các nhà phát triển linh hoạt; một cái về nguyên lí tương đồng giữa Agile và Phần mềm Tự do Mã mở (FOSS) hòng cung cấp thêm một một vài ý tưởng để hiện thực hóa cái How ở trên.
Về Simple Design:
Về so sánh giữa Agile và FOSS, trong đó có nhiều quan điểm được nhắc lại trong bài viết của Mê Kim Dung:
