Ngày nảy ngày nay có một Agile,
Agile nói với chúng ta hãy chuyển giao phần mềm sớm và liên tục tới khách hàng. Từ đó, không còn thiết kế nữa. Ý tôi ở đây, không còn thác nước nữa, không còn các thiết kế tổng thể ngay từ đầu nữa.
Vậy phải chăng thiết kế đã chết?
Chúng ta hãy nhìn vào XP, một tập hợp các kỹ thuật lập trình được thiết kế nên với một mục đích duy nhất là tạo ra phần mềm có chất lượng cao nhất. XP không phải là Agile, nhưng tất cả các kỹ thuật đơn lẻ của XP hiện nay đều đã trở thành các best practice trong các quy trình phát triển phần mềm tuân theo Agile.
Và XP rất chú trọng đến thiết kế, chỉ là theo một cách làm khác đi. Khét tiếng và gây tranh cãi nhất là nó từ chối bất kỳ nỗ lực nào để thiết kế dự phòng cho tương lai, mà thay vào đó “sống trong hiện tại” và ủng hộ cách tiếp cận thiết kế tiến hóa. Người dèm pha chụp mũ rằng đó là quy trình phát triển code rồi fix. Đối với tín đồ của XP, cách tiếp cận của XP được nhìn như là sự từ chối các kỹ thuật thiết kế cổ điển như UML, nguyên tắc thiết kế, mẫu thiết kế. Thay vào đó hãy để mã đẹp tự lên tiếng.
Chúng ta thế nào mới hợp lý?
Nội dung
Thiết kế có kế hoạch và thiết kế tiến hóa
Theo lối sản xuất phổ biến, thiết kế tiến hóa là phi công nghiệp và là một thảm họa thuần túy. Thiết kế cuối cùng của phần mềm là kết quả của một chuỗi quyết định thiết kế, mà mỗi bước đều để lại nợ kỹ thuật và khiến phần mềm dần mất đi khả năng sửa đổi— đấy còn chả xứng đáng được gọi là thiết kế.
Chúng ta sẽ dành 10% thời gian đầu của dự án để viết 90% chức năng. Sau đó chúng ta sẽ dành 90% thời gian còn lại của dự án để viết 10% tính năng cuối cùng — mà không biết có xong không.
Thiết kế trước có thể không bao gồm các nước đi xấu như thế, nhưng là chỉ khi nghiệp vụ và công nghệ có ít biến chuyển — vùng Simple trong biểu đồ khả năng đáp ứng dưới đây.
Điều gì xảy ra khi yêu cầu nghiệp vụ hay công nghệ thay đổi — điều xảy ra theo ngày trong ngành của chúng ta hiện tại — và thiết kế cũ không đáp ứng được?
Có thể có một số cách thiết kế tài tình nào đấy giúp bản thiết kế có khả năng chống chịu tốt trước một số thay đổi. Nhưng đồng thời khi dự đoán các thay đổi tương lai, bản thiết kế đó cũng làm vô vọng khả năng đáp ứng trước các thay đổi khác (mà nó không lường trước). Ai mà biết trước được. Và rồi các nhà phát triển cũng sẽ lại sa vào những nước đi chết chóc. Không hơn gì đâu.
Chúng ta rồi sẽ thích thiết kế “code rồi fix”, nhưng chúng ta cần nhận thức rõ các vấn đề của nó và có đối sách cụ thể.
Đối sách của XP
Khi cổ súy cho thiết kế tiến hóa, XP đã có những đối sách cụ thể. Mấu chốt của những đối sách này dựa trên phân tích về đường cong chi phí cho thay đổi của phần mềm. Theo đường cong này, thay đổi xảy ra ở những khâu phân tích thiết kế sẽ gây ra chi phí lũy kế tại khâu sản xuất.
Chừng nào chi phí còn tăng theo cấp số nhân, thiết kế tiến hóa còn chưa thể thành hiện thực được. Và do đó, XP tìm cách uốn thẳng đường cong đến mức đủ để áp dụng thiết kế tiến hóa.
XP làm thẳng đường cong, và sau đó khai thác nó. Kỹ thuật cốt lõi là Kiểm thử và Tích hợp liên tục. Không có sự an toàn đến từ Kiểm thử, toàn bộ XP bị vô hiệu hóa. Còn Tích hợp liên tục là để đồng bộ cho đội sản xuất, để họ yên tâm tạo thay đổi mà không phải lo lắng về những nguy cơ khi tích hợp chức năng với người khác. Sự kết hợp của hai kỹ thuật này làm thẳng đáng kể chi phí thay đổi.
Tái cấu trúc cũng tương tự. Trong bất kỳ trường hợp nào, tái cấu trúc tốt đều làm giảm chi phí của việc thay đổi — và do đó tăng khả năng tiến hóa thiết kế. Martin Fowler từng công nhận rằng mã sau khi tái cấu trúc khiến ông có cảm giác như “trước đó tôi đã viết mã bằng một tay”.
Với chừng đó, thiết kế tiến hóa đã trở nên khả thi. Nhưng không có nghĩa đó là toàn bộ của XP, và XP cổ súy thiết kế tiến hóa không có nghĩa là XP không dự trước thiết kế. Trên thực tế có sự cân bằng ở đây.
Giá trị của sự Đơn giản
Hai phương ngôn nổi tiếng nhất của XP là “làm đơn giản nhất có thể” và “bạn có cần nó đâu”. Con chiên XP sẽ không bỏ những mã chỉ mai mới cần vào chương trình của ngày hôm nay. Thứ nhất, tốn chi phí. Thứ hai, ai biết được đâu ngày mai sẽ khác , với tưởng tượng (và hình như thường thì nó khác thật). Thứ ba, thêm mã nghĩa là thêm độ phức tạp, nghĩa là ngăn chặn khả năng thay đổi — thứ mà XP đang cố tạo ra thêm.
Suy cho cùng ai không muốn đơn giản, nhưng thế nào thì có thể gọi là đơn giản?
Ken Beck giảng giải rằng có bốn dấu hiệu nhận diện một hệ thống đơn giản, theo thứ tự độ quan trọng:
- Vượt qua tất cả các kiểm thử
- Không có hiện tượng lặp
- Rõ ràng tất cả các ý định
- Có tối thiểu lớp và phương thức
Đích đến là đơn giản cực đoan, và để giữ sự an toàn, ràng buộc vượt qua tất cả kiểm thử là cần thiết. Không có hiện tượng lặp là cần thiết để có tư cách tự gọi là “đơn giản”. Không có hiện tượng lặp ngụ ý rằng ở đây không chỉ là không có mã lặp, mà còn là không có ý lặp, không có phương án lặp. Mã nên là tối thiểu để có thể đơn giản, và để mã không dành riêng cho những cái đầu IQ 200 mới đọc nổi, “rõ ý” là ràng buộc cần thiết.
Trọng điểm ở đây là chúng ta không gia tăng độ phức tạp của hệ thống nhiều hơn mức cần thiết trong thời điểm hiện tại. Tái cấu trúc là cần thiết để giữ thiết kế đơn giản nhất có thể. Chúng ta phải tái cấu trúc ngay khi nhận ra rằng chúng ta có thể (làm cho thứ gì đó trở nên đơn giản hơn).
Thiết kế đơn giản khai thác tiềm năng của các kỹ thuật XP. Chỉ khi chúng ta có kiểm thử, có tích hợp liên tục, và tái cấu trúc tốt, chúng ta mới có thể động đến thiết kế đơn giản.
Nhưng đồng thời giữ cho thiết kế đơn giản cũng là cốt lõi để giữ đường cong chi phí được thẳng hơn — tiên quyết để cho thiết kế tiến hóa được khả thi. Và đó lại là tiền đề để sử các kỹ thuật XP. Do đó thiết kế tiến hóa cũng tạo điều kiện cho các kỹ thuật XP nữa.
Giữ cho thiết kế tiến hóa được khả thi, bằng cách giữ đường cong chi phí cho thay đổi luôn thấp, mới là mục đích. Chúng ta giữ gìn điều đó bằng kiểm thử, tích hợp liên tục, tái cấu trúc thường xuyên — và thiết kế đơn giản sẽ là hoa tiêu cho quá trình đó. Chúng ta tái cấu trúc hướng về sự đơn giản nhất có thể, nhưng không phải lúc nào cũng cần đạt được tới mức cực đoan. Suy cho cùng, tái cấu trúc cũng là một chi phí.
Về các Mẫu Thiết kế
Với nhiều người, các mẫu thiết kế dường như mâu thuẫn với XP — việc sử dụng các mẫu thiết kế luôn tốt — chúng giữ cho hệ thống trở nên đơn giản hơn, chi phí sửa đổi ít hơn, sẵn sàng với tiến hóa hơn — nhưng chỉ với những ai quen thuộc với các mẫu thiết kế. Mẫu thiết kế có thể tốt cho XP, nhưng cũng có thể hủy diệt nó.
Tuy vậy, chúng ta có thể thay đổi câu hỏi. Thay vì “như thế nào phù hợp cho chúng ta” thành “như thế nào phù hợp cho hệ thống”. Và quả thật các mẫu thiết kế chưa bao giờ là một ý tưởng tồi. Vậy là chúng ta có câu hỏi đáng hỏi tiếp theo: “Làm thế nào sử dụng chúng”.
Có một lý thuyết ở đây là thiết kế đơn giản sẽ tự dẫn chúng ta vào các mẫu. Với hoa tiêu là thiết kế đơn giản, sau một số phiên tái cấu trúc, mã sẽ tự khớp vào một mẫu nào đó — kể cả khi bạn không nhận ra.
Tuy vậy, đó không thật sự là một cách quá mức hiệu quả. Sẽ luôn tốt hơn nếu biết mình sẽ đi đâu. Vậy nên hãy chuẩn bị một chút, triển khai các mẫu thành thạo một chút, nhận ra gợi ý áp dụng chúng tỉnh thức một chút, đánh giá chi phí và hiệu quả của mỗi mẫu trong sáng một chút.
Mẫu luôn quan trọng.
Về UML
XP có gạch bỏ UML không?
Tại sao có câu hỏi đó? Bởi chúng ta đã quen đồng nghĩa một bộ đồ sộ các UML đóng vai trò thiết kế tổng thể, với bản thân UML vốn chỉ là một ngôn ngữ để thể hiện thiết kế.
Vậy thiết kế tiến hóa có cần ngôn ngữ để thể hiện mỗi bước tiến hóa không?
Câu trả lời là có. Ngôn ngữ để thể hiện thiết kế chính là công cụ giao tiếp. Chúng ta cần giao tiếp hiệu quả, mà UML là một trong số các công cụ. Chúng ta sẽ dùng UML với mục đích giao tiếp, để thỏa mãn mục đích giao tiếp.
Chúng ta cũng sử dụng UML để trực quan hóa thiết kế, và chúng ta cũng sẽ sử dụng khả năng đó để phục vụ chính việc thiết kế — hình dung, làm nổi bật những mấu chốt quan trọng, đánh giá, lên kế hoạch tiết hóa, tất cả đều cần trực quan hóa.
UML luôn quan trọng, nhưng nghĩ về nó khác đi một chút.
Ý chí thiết kế
Kỹ thuật là thứ chết, để nó thực sự tỏa sáng không thể không xét đến yếu tố con người. Thiết kế tiến hóa sẽ chết nếu không có người hội tụ ý chí thiết kế — người sẽ chăm lo cho thiết kế, thường xuyên chú ý vào mã, nhìn ra những chỗ lộn xộn tầm trung, lãnh đạo tái cấu trúc kịp thời, tiến hóa thiết kế và đảm bảo rằng nó luôn đạt chất lượng cao, giao tiếp, truyền đạt và đào tạo ý chí thiết kế của mình cho các nhà phát triển. Những việc đó cần có người — kiến trúc sư — đảm đương.
Có thiết kế không đấy?
Một trong những khó khăn của thiết kế tiến hóa là rất khó để biết liệu việc thiết kế có đang diễn ra không? Việc xen kẽ giữa viết mã và thiết kế gây ra mối nguy rằng mã có thể được viết ra mà không cần tới thiết kế. Sau đó, tiến hóa trở nên viển vông và thất bại.
Kể cả nhà phát triển — những người có cơ hội nhận ra điều này sớm nhất, khi mà mã ngày càng trở nên ngày càng phức tạp và khó phát triển hơn — cũng nhiều khi chủ quan và không nhận ra tình huống. Thế nên vấn đề sẽ càng khó hơn với những người phi kỹ thuật.
Chúng ta cần thận trọng trước bất kỳ dấu hiệu khó khăn khi phát triển nào. Có thể đó là dấu hiệu của việc thiếu vắng thiết kế.
Vậy thiết kế đã chết?
Không hề nhắc đến trực tiếp, nhưng XP đã thay đổi bản chất của thiết kế. Thứ mà “thiết kế” trong XP tìm đến là:
- Lòng kiên định với mong muốn giữ mã trong sáng và đơn giản hết mức có thể
- Kỹ năng tái cấu trúc đủ tốt để có thể sử dụng bất cứ lúc nào
- Kiến thức tốt về các mẫu thiết kế, không chỉ là cách chúng giải quyết vấn đề, mà còn là sự đánh giá bao giờ, và làm thế nào để sử dụng được chúng
- Thiết kế hiện tại với ánh mắt dõi về tương lai, biết rằng những mảnh nào của thiết kế hiện tại sẽ được thay thế trong tương lai
- Biết cách truyền đạt thiết kế đến những người cần hiểu nó, bằng mã, bằng giản đồ, và trên hết — bằng đối thoại
Đó là một bộ mô tả kỹ năng đáng sợ, nhưng dù sao trở thành nhà thiết kế chưa bao giờ là dễ. XP không làm cho nó dễ dàng hơn. Nhưng XP đã cho chúng ta một cách mới để nghĩ về thiết kế hiệu quả và làm cho thiết kế tiến hóa sống lại. Nghĩa là chúng ta có thêm những cách thách thức khác để phát triển — tốt rồi, vì chúng ta cần phát triển.
Chia sẻ của anh Nguyễn Bình Sơn
Xem thêm các bài viết hữu ích khác tại đây!
0 Lời bình