Kiến trúc Model-View-Presenter trong .NET

Khảo sát mẫu kiến trúc MVC cổ điển và một mẫu kiến trúc thừa kế từ nó hiện được ứng dụng rộng rãi trong môi trường .NET, đó là kiến trúc MVP.

Trong các nền tảng lập trình hiện đại như .NET, khi mà các công cụ và kĩ thuật hỗ trợ lập trình giao diện người dùng (UI) ngày càng trở nên mạnh mẽ và tiện dụng thì chúng ta thường có xu hướng đưa nhiều xử lý bên ngoài vào các lớp UI. Kết quả là các thành phần UI này chứa nhiều xử lý logic và dữ liệu mà lẽ ra nên tách rời thành những thành phần riêng. Việc tách rời xử lý và trình bày vì những lí do sau:
Trong một hệ thống, UI là thành phần có nhiều khả năng thay đổi nhất nên việc tách rời các thành phần UI giúp có thể thay đổi các thành phần UI này một cách độc lập mà không ảnh hưởng đến các thành phần xử lý khác. Đặc biệt việc tách rời các thành phần dữ liệu khỏi UI còn cho phép trên cùng một thành phần dữ liệu này, ta có thể phát triển nhiều thành phần UI khác nhau cho các cách trình bày khác nhau.
Các code xử lý đặt trong các thành phần UI còn gây khó khăn cho việc testing (unit-test). Việc test các thành phần UI thường hoặc phải chạy ứng dụng thủ công hoặc sử dụng các runner script để thực hiện việc tương tác tự động lên các thành phần UI, do đó sẽ tốn nhiều chi phí và thời gian hơn để kiểm tra các xử lý bên trong các thành phần này.
Việc đưa nhiều xử lý vào các lớp UI còn dẫn đến khả năng là trùng lắp code xử lý. Những xử lý lẽ ra có thể dùng chung thì lại xuất hiện lặp lại ở nhiều thành phần UI có chức năng tương tự nhau. Việc tách các xử lý này ra ngoài ra còn tăng tính tái sử dụng code và dễ bảo trì hơn.
Các vấn đề trên là các vấn đề cơ bản được đặt ra cho các hệ thống tương tác (interactive system). Để giải quyết chúng, một số giải pháp được đề ra trong đó phổ biến nhất là mẫu kiến trúc MVC (Model-View-Controller). Trong bài viết này, chúng ta sẽ khảo sát mẫu kiến trúc MVC cổ điển và một mẫu kiến trúc thừa kế từ nó, hiện được ứng dụng rộng rãi trong môi trường .NET, đó là kiến trúc Model-View-Presenter.

Mẫu kiến trúc Model-View-Controller cổ điển

Tổng quan
Mẫu kiến trúc Dolphin Smalltalk Model-View-Presenter chia ứng dụng thành các phần dữ liệu (data), trình bày (presentation) và các xử lý logic thuộc phần trình bày (presentation logic) thành những thành phần riêng biệt.
Lịch sử
Phiên bản Dolphin Smalltalk Model-View-Presenter (gọi tắt là Dolphin MVP) là phiên bản của MVP được xây dựng dựa trên phiên bản Taligent MVP xuất hiện trước đó. Dolphin MVP được xây dựng về cơ bản bên ngoài tương tự như MVC cổ điển nhưng khác nhau ở vai trò của Controller và Presenter.
Cấu trúc

Các thành phần
Model chứa dữ liệu và các tính toán xử lý logic để giải quyết vấn đề mà phần mềm hướng tới (business logic).
View là thành phần đảm nhận trình bày từ những dữ liệu của Model. View bao gồm những gì thể hiện trên màn hình như các control, form, widget,…
Presenter là thành phần đảm nhận các xử lý về trình bày mà nó cần đến sự tương tác trên dữ liệu.
Phối hợp các thành phần
Trong khi vai trò của Model không thay đổi so với MVC cổ điển. Thành phần View của Dolphin MVP cũng thực hiện việc trình bày từ nội dung của Model và gắn kết với Model thông qua Observer Pattern. Tuy nhiên, nó thực hiện bắt các sự kiện xảy ra ngay bên trong nó. Một vài trường hợp đơn giản như TextView, dữ liệu nhập được xử lý trực tiếp và cập nhật thay đổi trực tiếp vào Model còn hầu hết các trường hợp khác, việc xử lý được chuyển giao cho Presenter đảm trách khi cần thao tác đến Model.
Trong khi View đảm nhận trình bày thì Presenter đảm trách cách Model được thao tác và thay đổi như thế nào bởi giao diện người dùng. Presenter là nơi chứa các xử lý đặc trưng của ứng dụng (application logic so với business logic của Model). Một điểm đáng chú ý khác là Presenter có khả năng thao tác trực tiếp lên View mà nó gắn kết, điều này khác biệt với phiên bản Taligent MVP xuất hiện trước đó.
So sánh Dolphin MVP và MVC cổ điển
Điểm khác biệt cơ bản của Dolphin MVP và MVC cổ điển là sự khác nhau về vai trò của Presenter và Controller, nó cũng dẫn đến sự khác nhau về vai trò giữa hai thành phần View. Trong Dolphin MVP, sự hiện diện của Controller bị loại bỏ, thay vào đó, việc xử lý các dữ liệu input được View đảm nhận và được chuyển cho Presenter khi có yêu cầu tương tác đến Model.
Mẫu kiến trúc MVP của Martin Fowler
Tóm tắt
Martin Fowler là một trong những người đâu tiên đi sâu và nghiên cứu về các phiên bản của MVP. Vào năm 2006, Fowler tuyên bố sự kết thúc của các kiến trúc MVP cổ điển và tự chia MVP thành hai phiên bản mới là Passive View và Supervising Controller.

Martin Fowler dùng thuật ngữ Controller thay vì Presenter trong mẫu của mình

Trong mẫu Passive View, thành phần View được loại bỏ hoàn toàn các xử lý logic và tương tác đến Model. Thay vì vậy, nó chuyển giao các xử lý cho Controller đảm trách. Controller đảm nhận tương tác đến Model và cập nhật View khi có thay đổi từ Model. Controller là thành phần trung gian liên lạc giữa View và Model.
Trong mẫu Supervising Controller, View đầu tiên bắt lấy các sự kiện và sau đó chuyển giao cho controller xử lý. Để cập nhật thay đổi từ Model, View dùng data-binding và Observer pattern cho các xử lý đơn giản còn đối với các xử lý phức tạp sẽ nhờ đến Controller đảm nhận.
So với Supervising Controller chứa View đảm nhận xử lý sự kiện đơn giản thì với Passive View, thành phần View được tách rời hoàn toàn khỏi các xử lý, kể cả các xử lý cơ bản ở mức giao diện cũng được giao hoàn toàn cho Presenter xử lý. Điều này tạo thuận lợi hơn cho việc testing vì khi đó các thành phần Model và Presenter có thể được kiểm tra một cách độc lập mà không phụ thuộc vào giao diện. Phiên bản MVP của Microsoft đầu tiên được xây dựng dựa trên Passive View sau đó mẫu Supervising Controller cũng được hỗ trợ với một số điều chỉnh.
Phiên bản MVP của Microsoft
Lịch sử
Khởi đầu từ các framework Smart Client Software Factory and Web Client Software Factory dựa trên kiến trúc MVP được các nhóm nghiên cứu về pattern của Microsoft tạo ra từ năm 2006, Microsoft sau đó bắt đầu đưa MVP vào các tài liệu hướng dẫn và ví dụ về lập trình giao diện trong .NET framework. Mô tả dưới đây dựa trên phiên bản MVP được mô tả trong tạp chí MSDN vào năm 2006 (tham khảo 2) và có thể xem là kiến trúc cơ bản cho các framework trên. Ngoài ra, còn có một số framework MVP khác cũng được phát triển trên nền tảng .NET như MVC# hay NMVP.
Xin lưu ý là phiên bản cũ của Web Client Software Factory ban đầu được tổ chức dựa trên Passive View (cấu trúc bên dưới) nhưng với phiên bản hiện tại thì cấu trúc dựa trên Supervising Controller cũng được hỗ trợ.
Cấu trúc

Các thành phần
Model chứa dữ liệu và các tính toán xử lý logic để giải quyết vấn đề mà phần mềm hướng tới (business logic).
View là thành phần đảm nhận trình bày từ những dữ liệu của Model và là tổng hợp của các form, control được sử dụng.
Presenter là thành phần đảm nhận các xử lý về trình bày cũng như tương tác đến dữ liệu bên dưới và có thể tương tác để thay đổi View trong quá trình xử lý.
Phối hợp các thành phần
Mẫu kiến trúc MVP của Microsoft tương tự như Passive View nhưng nó bổ sung thêm ràng buộc là các Presenter chỉ có thể truy cập đến View thông qua các interface IView. Điều này giúp Presenter không phụ thuộc đến cài đặt cụ thể của View và có thể dễ dàng test Presenter một cách độc lập. Điều này đạt được do sử dụng IView, chúng ta có thể dùng kĩ thuật “Mock” để thay thế các xử lý cụ thể của View khi test Presenter. Ngoài ra, mối quan hệ giữa Presenter và Model là quan hệ một chiều (chiều còn lại là gián tiếp). Hệ quả của các liên kết là chúng ta có một mô hình đa lớp (multi-layer) như cấu trúc ở trên theo ý nghĩa các thành phần ở một layer chỉ phụ thuộc và sử dụng các thành phần ở layer ngay bên dưới nó.
Theo mẫu Microsoft MVP, khi một View gắn liền với một interface IView. Khi View được tạo ra, nó tạo ra một đối tượng private Presenter và gắn nó vào đối tượng này thông qua IView. Khi một sự kiện xảy ra, View bắt lấy và sau đó kích hoạt một phương thức của Presenter mà sau đó, nó có thể tương tác với Model. Một số sự kiện như bắt đầu hiển thị và đóng của View cũng được gửi tới để Presenter kích hoạt một số phương thức tương ứng, điều này giúp cho một số công việc như khởi tạo và giải phóng dữ liệu cho View được dễ dàng hơn.
Model theo Microsoft MVP cũng thường được tổ chức bổ sung một lớp Service nằm bên trên để tương tác với Presenter, qua đó giảm bớt sự phụ thuộc đến các xử lý data nằm sâu bên dưới. Ngoài ra, để điều khiển việc liên lạc giữa các View hay các Presenter, một thành phần thường được bổ sung gọi là Application Controller. Trong một ứng dụng có thể có nhiều Application Controller để quản lý các nhóm MVP. Ngoài ra, thay vì sử dụng Presenter để tương tác với Model, một cách là giao tất cả các thao tác này cho Application Controller đảm trách.
Một ví dụ minh họa đơn giản
Để minh họa mẫu Microsoft MVP, chúng ta sẽ cùng khảo sát một ví dụ đơn giản: tạo một form hiển thị danh sách sinh viên cùng chức năng thêm mới trên danh sách sinh viên đó. Với mục tiêu là minh họa cách tổ chức và liên kết giữa các thành phần là chủ yếu, chúng ta không đi sâu vào cài đặt cụ thể (bạn có thể tham khảo source code đi kèm bài viết, source code được tổ chức ở dạng project của VS 2008).
Ứng dụng được tổ chức thành 5 project: View, Presenter, DataService, Model và DataTransferObject. Trong đó, View là application còn các project khác là library. Các project phụ thuộc lẫn nhau theo thứ tự project phía trước sử dụng trực tiếp project phía sau, ngoại trừ DataTransferObject chức các loại dữ liệu được dùng chung cho 3 project View, Preseneter và DataService. Model là project chứa các tương tác trực tiếp đến dữ liệu và không phụ thuộc vào bất cứ thành phần nào khác.

Giải thích các project:

• Model: chứa dữ liệu giả lập (StudentData.xml), schema (StudentDataSet.xsd) và lớp tiện ích được xây dựng bên trên (DataAccess.cs).
• DataTransferObject: chứa đối tượng dữ liệu được dùng chung cho các project ở mức cao hơn (Student.cs).
• DataService: được xây dựng bên trên Model, chuyển đổi dữ liệu từ Model sang DataTransferObject và xây dựng các tiện ích bên trên đối tượng transfer này (Service.cs).
• Presenter: chứa interface của View dùng cho Presenter truy cập (IViewForm) và lớp Presenter (StudentPresenter).
• View: chứa form view (ViewForm.cs) và Program.cs.

Trong bài viết khác, chúng ta sẽ tìm hiểu phương pháp TDD (Test-driven development) và ứng dụng nó để phát triển ứng dụng theo mẫu Microsoft MVP trong môi trường .NET.
Tài liệu tham khảo:

1. Martin Fowler, GUI Architectures
2. Jean-Paul Boodhoo , Design Patterns: Model-View-Presenter
3. Buschmann F., Meunier R., Rohnert H. & Sommerlad P. & Stal M. (1996). Pattern-Oriented Software Architecture: A System of Patterns.
4. Martin Fowler , Patterns of Enterprise Application Architecture.
5.  http://en.wikipedia.org/wiki/Model_View_Presenter
6.  http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
7. Derek Greer, Interactive application architecture patterns
8. Views Testability Guidance
9. Dolphin MVP paper

Mẫu kiến trúc Model-View-Controller

Tổng quan
Mẫu kiến trúc Model-View-Controller là phương pháp chia nhỏ các các thành phần dữ liệu (data), trình bày (output) và dữ liệu nhập từ người dùng (input) thành những thành phần riêng biệt.
Lịch sử
MVC được hình thành bởi các nghiên cứu của Trygve Reenskaug vào khoảng các năm 1978-1979. Sau đó nó được điều chỉnh và được cài đặt lần đầu tiên vào các lớp của thư viện Xerox PARC Smalltalk-80. MVC cổ điển hiện tại ít được sử dụng trong môi trường lập trình desktop như trước đây nhưng hiện tại nó vẫn được sử dụng cực kì rộng rãi như là kiến trúc cơ bản trong các môi trường lập trình web.
Cấu trúc

Các thành phần
Model chứa dữ liệu và các tính toán xử lý logic để giải quyết vấn đề mà phần mềm hướng tới (business logic). Thành phần model thường được trình bày ở dạng Domain Model .
View là thành phần đảm nhận trình bày từ những dữ liệu của Model. View bao gồm những gì thể hiện trên màn hình như các control, form, widget,…
Controller là thành phần đảm nhận việc xử lý đáp trả lại các dữ liệu được đưa vào từ người dùng như các sự kiện chuột, bàn phím, các tương tác lên các control… Controller là cầu nối giữa người sử dụng và ứng dụng.
Phối hợp các thành phần
Trong kiến trúc MVC, mỗi bộ ba Model-View-Controller được thiết kế tương ứng cho các đối tượng mà người dùng có thể tương tác.
Model nắm giữ trạng thái, cấu trúc và các hành vi của dữ liệu được thể hiện và tương tác bởi người dùng. Model không phục thuộc và tương tác trực tiếp lên các thành phần khác. Thay vì vậy, khi có thay đổi, nó thông báo cho những thành phần như View tương ứng thông qua cơ chế là Observer pattern. Model còn cung cấp phương tiện để các thành phần khác tương tác lên nó.
View lấy các thông tin từ Model và trình bày đến người dùng. Trên cùng một model, có thể có nhiều View cùng đăng ký. Khi có một thay đổi từ Model, tất cả các View đều được thông báo thông qua observer mà nó đã đăng ký.
Mỗi View khi được tạo ra sẽ tạo ra một Controller đi kèm với nó. Trong khi các View đảm nhận kết xuất dữ liệu thì các Controller đảm nhận việc xử lý dữ liệu từ người dùng. Với mỗi sự kiện nhận được, Controller có thể xử lý và tương tác trực tiếp lên thành phần View và Model tương ứng để đáp trả. View và Controller là hai thành phần cấu thành nên giao diện người dùng của ứng dụng. Chúng lưu giữ liên kết trực tiếp đến Model. Trong khi Controller có thể thay đổi dữ liệu theo yêu cầu của người dùng thì View tương tác để lấy dữ liệu cập nhật vào chính nó từ Model.
Nhầm lẫn thường gặp
Một nhầm lẫn thường gặp trong quan hệ giữa các thành phần MVC là khi xem mục đích của Controller như là thành phần trung gian để tách rời View khỏi Model. Trong khi thực tế, kiến trúc MVC tách rời dữ liệu và xử lý trung tâm khỏi phần trình bày thông qua cơ chế là Observer Pattern chứ không phải Controller. Nhiệm vụ của Controller là cần nối giữa người dùng là ứng dụng, không phải giữa View và Model.
Vấn đề của MVC
Trong khi mục đích chính của MVC là tách rời trình bày và các xử lý bên trong. Việc phân rõ vai trò xử lý ouput (View) và input (Controller) là một hệ quả nhằm hoàn thiện cơ chế cho ý tưởng trên. Hiện nay trong nhiều môi trường lập trình hiện đại, nhiều control được cung cấp và hoàn thiện hơn (nhiều xử lý sự kiện cơ bản đã được hỗ trợ sẵn) so với trước đây nên việc khoáng tất cả các xử lý sự kiện cho một thành phần độc lập như Controller không còn là vấn đề quan trọng nữa.
Trong khi đó, những cơ chế như Observer Pattern cũng có vấn đề của riêng chúng. Trong khi được dùng như phương tiện hiệu quả để loại bỏ sự phụ thuộc của Model vào các thành phần khác, nó có một vấn đề lớn là tại một thời điểm, chúng ta khó có thể xác định điều gì sẽ xảy ra bằng cách đọc code và việc thực hiện các testing cũng khó khăn hơn. Hơn nữa, do Model chỉ liên kết gián tiếp đến View thông qua Observer Pattern, khi sự thay đổi trạng thái của Model cần đến một vài thao tác xử lý phức tạp để áp dụng lên giao diện thì với mô hình cổ điển sẽ gặp khó khăn.
Một vấn đề khác là chúng ta cần lưu trữ tình trạng hiện tại của UI (UI state), ví dụ trong danh sách sinh viên thì chúng ta cần biết sinh viên nào đang được chọn. Trong khi thành phần UI nắm giữ dữ liệu trình bày đang được chọn thì dữ liệu sinh viên thuộc về Model, như vậy dữ liệu về sinh viên được chọn sẽ được lưu trữ ở đâu khi cần truy xuất đến?
Vì những lí do trên, MVC sau này đã có những thay đổi và bổ sung nhất định (như khái niệm Application Model). Kiến trúc MVP chúng ta sẽ bàn dưới đây cũng dựa trên tư tưởng cơ bản của MVC nhưng với cách tiếp cận khác nhằm mục đích khắc phục các khuyết điểm đã có.

Agile: Tổ chức của một đội dự án XP

Nguồn: The Art of Agile Development by J Shore & S Warden.
Phần tiếp theo của: Agile Development: Giới thiệu Extreme Programming

Một đội dự án XP làm việc cùng nhau trong một không gian mở không có các phòng riêng hoặc vách ngăn. Vào đầu mỗi vòng lặp, đội tổ chức một cuộc họp kéo dài từ 2 đến 4 giờ để tổng kết những công việc vừa hoàn thành và lập kế hoạch cho phần việc tiếp theo. Hàng ngày, cả đội tham gia một cuộc họp ngắn từ 5 đến 10 phút thảo luận về công việc trong ngày. Ngoài hai kiểu họp chính thức này, từng thành viên tự lập kế hoạch làm việc cho mình. Hình thức “tự tổ chức” (self-organization) là một đặc điểm chung của các dự án theo triết lí Agile.
Trong một dự án phần mềm, những hiểu biết về sản phẩm luôn được nắm giữ bởi nhiều cá nhân. XP thừa nhận thực tế này bằng cách tạo ra một nhóm làm việc hỗn hợp với đầy đủ các vai trò cần thiết. Một đội dự án XP thường bao gồm các thành viên sau đây:
Đại diện khách hàng (onsite customer): Chịu trách nhiệm xác định các yêu cầu (requirement) cho phần mềm. Công việc quan trọng nhất của người này là lập kế hoạch. Khi bắt đầu dự án, đại diện khách hàng xác định các tính năng (feature/story) cần có của phần mềm, tìm cách nhóm các tính năng này thành các phần nhỏ có thể phát triển và bàn giao lần lượt và định ra lịch trình bàn giao từng phần. Trong quá trình thực hiện dự án, đại diện khách hàng nhận phản hồi từ các thành viên khác và điều chỉnh kế hoạch cho phù hợp.
Nhiệm vụ thứ hai của đại diện khách hàng là giúp các lập trình viên hiểu các yêu cầu chi tiết cho sản phẩm. Trong các dự án XP, tài liệu đặc tả (SRS) chỉ là công cụ trợ giúp cho đại diện khách hàng mà thôi. Người này sẽ đóng vai trò một tài liệu “sống”, luôn sẵn sàng trả lời các câu hỏi từ các lập trình viên.
Đại diện khách hàng không nhất thiết phải là khách hàng thật mà chỉ cần là một thành viên hiểu rõ các yêu cầu của phần mềm. Thực nghiệm cho thấy giữa hai nhóm có chất lượng lập trình viên tương đương nhau thì nhóm có sự tham gia của khách hàng tạo ra sản phẩm tốt hơn hẳn. Nếu khách hàng không thể đến ngồi ở văn phòng của bạn, hãy đưa đội dự án của bạn đến ngồi cùng với khách hàng!
Thực nghiệm cũng cho thấy tỉ lệ hai đại diện khách hàng cho ba lập trình viên là phù hợp. Tất nhiên, tỉ lệ này phụ thuộc vào độ phức tạp của sản phẩm. Hãy ghi nhớ rằng khối lượng công việc của các đại diện khách hàng là rất lớn bởi họ luôn phải “chạy trước” các lập trình viên.
Người quản lí sản phẩm (product manager/owner): Người này chịu trách nhiệm định hướng cho dự án và sản phẩm, bao gồm các công việc: Xác định các tính năng của sản phẩm và thứ tự ưu tiên của chúng, hướng dẫn đại diện khách hàng, làm việc với các bên liên quan đến dự án (stakeholder), đánh giá tiến độ dự án và giải quyết các vấn đề về tổ chức. Ngoài ra, người quản lí sản phẩm còn chịu trách nhiệm đưa sản phầm ra thị trường, bao gồm các việc quảng cáo, bán hàng và hỗ trợ khách hàng.
Người quản lí sản phầm phải am hiểu thị trường và các lợi ích mà phần mềm sẽ mang đến cho khách hàng. Đồng thời, người này phải có khả năng cộng tác và thoả hiệp với các đòi hỏi đa dạng, nhiều khi mâu thuẫn nhau, từ các cá nhân có quyền lợi liên quan đến dự án. Người quản lí sản phẩm phải được trao đủ quyền lực để có thể nói không với các yêu cầu không phù hợp. Một dự án chỉ nên có duy nhất một người quản lí sản phầm nhằm đảm bảo tính thống nhất cho định hướng của dự án.
Các chuyên gia nghiệp vụ (Domain Expert): Các lập trình viên ít khi hiểu biết tường tận về một lĩnh vực cụ thể nào đó, ví dụ như tài chính hay hoá học. Bởi vậy, XP yêu cầu sự tham gia của các chuyên gia hiểu rõ lĩnh vực chuyên môn của phần mềm đang được phát triển, chẳng hạn như các chuyên gia phân tích tài chính hay các nhà nghiên cứu hoá học. Những người này sẽ nghiên cứu nghiệp vụ của phần mềm để sẵn sàng trả lời câu hỏi của các lập trình viên.
Trong các dự án nhỏ, người quản lí sản phẩm thường kiêm luôn vai trò chuyên gia nghiệp vụ.
Người thiết kế giao diện (Interaction Designer): Giao diện người dùng (user interface) là bộ mặt của sản phẩm. Người dùng thường đánh giá chất lượng phần mềm thông qua chất lượng giao diện mà họ tương tác hàng ngày. Nhiệm vụ của người thiết kế giao diện là tìm hiểu mong muốn của khách hàng cũng như thói quen làm việc thường ngày của họ và từ đó thiết kế bộ mặt của sản phẩm.
Đừng nhầm lẫn giữa người thiết kế giao diện và người thiết kế đồ họa (graphic designer). Người thiết kế giao diện nghiên cứu tương tác giữa người dùng và sản phẩm. Trong khi đó người thiết kế đồ họa tạo ra các thành phần cụ thể như âm thanh, hình ảnh hay cách bố trí giao diện (layout).
Lập trình viên (Programmer): Nếu nhiệm vụ của người đại diện khách hàng là tối đa hóa giá trị của sản phẩm thì nhiệm vụ của các lập trình viên là tối thiểu hóa chi phí bằng việc lập trình theo cách hiệu quả nhất. Nhiệm vụ của các lập trình viên trong dự án XP là:
Ước lượng thời gian và nguồn lực cần thiết để thực hiện các chức năng của phần mềm, từ đó trợ giúp đại diện khách hàng trong việc lập kế hoạch. Lập trình viên cũng trao đổi trực tiếp với đại diện khách hàng để làm rõ các yêu cầu của phần mềm.
Các lập trình viên làm việc theo cặp (pair programming) và sử dụng phương pháp phát triển dựa trên test (test-driven development). Mỗi lập trình viên có trách nhiệm viết test, viết và tối ưu hóa mã nguồn, thiết kế và liên tục cải tiến thiết kế của chương trình. Mã nguồn được xem là sở hữu tập thể, tất cả các lập trình viên đều có quyền và nghĩa vụ sửa các lỗi mà họ phát hiện ra, bất kể lỗi đó do ai gây ra. Chuẩn lập trình (coding standard) đóng vai trò thiết yếu hỗ trợ cho cách làm việc này. Các lập trình viên liên tục tích hợp mã nguồn vào hệ thống và test một cách cẩn thận nhằm đảo bảo rằng phần mềm đủ tiêu chuẩn để đóng gói và bàn giao cho khách hàng vào cuối mỗi chu kì phát triển. Các lập trình viên chỉ viết tài liệu khi cần thiết nhằm trợ giúp cho việc bảo trì phần mềm trong tương lai.
Trong đội lập trình cần có một số thành viên có kinh nghiệm thiết kế phần mềm, có trách nhiệm hướng dẫn các lập trình viên khác. Đội cũng cần các thành viên có kinh nghiệm về các lĩnh vực cụ thể như cơ sở dữ liệu hay bảo mật.
Thực nghiệm cho thấy một dự án XP nên có từ 4 đến 10 lập trình viên.
Tester: Các dự án XP nói chung không cần nhiều tester. Các lập trình viên được trông đợi sẽ chuyển giao các chương trình gần như không có lỗi cho tester. Các chương trình test tự động (automated test) cũng làm giảm số lượng tester cần thiết.
Các dự án XP thường có tỉ lệ tester/lập trình viên từ 1/4 đến 1/6. Một số dự án còn không có tester mà sử dụng đại diện khách hàng và lập trình viên vào vai trò này!
Quản lí dự án/Hướng dẫn viên (Project Manager/Coach): Là những người có kinh nghiệm về XP, làm nhiệm vụ giúp đỡ các thành viên khác thực hiện các quy tắc của XP cũng như giao tiếp với các cá nhân bên ngoài dự án.
Các thành viên khác: Hãy nhớ rằng có rất nhiều người có lợi ích liên quan đến dự án nhưng không làm việc cùng đội dự án. Họ là những người dùng cuối, lãnh đạo cấp cao, phòng nhân sự…(gọi chung là các stakeholder). Những người này dù không “lộ mặt” nhưng đều có ảnh hưởng đến thành công của dự án. Người quản lí sản phẩm phải thấu hiểu được những yêu cầu rất đa dạng của đội ngũ này.
Một dự án XP không nhất thiết phải có đầy đủ các thành viên nói trên, hoặc  ngược lại có thể sử dụng thêm các thành viên khác nếu cần. Một thành viên trong dự án có thể đảm nhiệm nhiều vai trò cũng lúc. Chẳng hạn, người quản lí sản phẩm có thể đồng thời là chuyên gia nghiệp vụ hoặc quản lí dự án. Đại diện khách hàng có thể kiêm vai trò thiết kế giao diện. Các lập trình viên có thể làm công việc của tester.
Một dự án XP thường có từ 4 đến 10 lập trình viên. Một dự án có 6 lập trình viên thường cần 4 đại diện khách hàng, 1 tester và 1 người quản lí sản phẩm, tổng cộng là 12 thành viên. Nếu số lập trình viên là 10, sẽ cần đến 6 đại diện khách hàng, 3 tester và một người quản lí sản phẩm, hợp thành một nhóm 20 người. Đây cũng là con số tối đa của một dự án XP thông thường.
Kích thước nhóm lớn sẽ gây khó khăn cho việc giao tiếp giữa các thành viên. Bởi vậy, XP khuyến khích tuyển dụng các thành viên có kinh nghiệm thay vì tăng số lượng người.

Tài liệu tham khảo
Sách: The Art of Agile Development by James Shore and Shane Warden.
Web: http://agilemanifesto.org/

The Art of Agile Development – Giới thiệu chung

Nguồn: The Art of Agile Development by J Shore & S Warden.

Agile là gì?

Agile là một triết lí (philosophy) cho việc phát triển phần mềm. Nói cách khác, đó là một cách “tư duy” về các dự án phần mềm. Các triết lí của Agile được cụ thể hóa bởi một số phương pháp phát triển phần mềm (method), chẳng hạn như Extreme Programming (XP) hay Scrum, gọi tắt là các phương pháp Agile.

Mỗi phương pháp Agile bao gồm một tập hợp các quy tắc (pratice), chẳng hạn quy tắc về sử dụng công cụ quản lí mã nguồn, quy tắc về các chuẩn lập trình hay quy tắc trình diễn sản phẩm hàng tuần cho khách hàng.

Triết lí Agile được đưa ra trong một bản tuyên ngôn (manifesto) gồm 4 điểm và được làm rõ hơn bởi 12 quy tắc.

Vì sao chúng ta cần Agile?

Theo quan niệm truyền thống, một dự án phần mềm được coi là thành công khi sản phẩm được giao đúng hạn, trong ngân sách cho phép và làm đúng yêu cầu của khách hàng. Trên thực tế, nhiều dự án thỏa mãn tất cả các tiêu chí này nhưng rút cuộc vẫn bị coi là thất bại bởi phần mềm làm ra không được người dùng ưa thích, hoặc không mang lại nhiều lợi ích cho các cá nhân, tổ chức sử dụng chúng.

Ngoài các yếu tố truyền thống nói trên, một dự án phần mềm chỉ được coi là thành công khi thỏa mãn ba tiêu chí: Thành công ở mức cá nhân, thành công về mặt kĩ thuật và thành công ở mức công ty. Thành công ở mức cá nhân giúp kích thích các thành viên trong nhóm. Thành công về kĩ thuật đảm bảo khả năng bảo trì và tiến hóa của sản phẩm. Vị trí của nhóm sẽ được bảo đảm nhờ các thành công mà nhóm mang lại cho công ty. Các phương pháp Agile giúp cho dự án phần mềm đạt được ba thành công này.

Ba tiêu chí đánh giá thành công của một dự án phần mềm

Thành công ở mức công ty

Agile nhắm đến việc tạo ra giá trị cho công ty trong khi làm giảm chi phí. Đồng thời, Agile giúp sớm xác định các kì vọng đối với sản phẩm đang được phát triển. Nhờ đó, những dự án không mang lại giá trị như mong đợi sẽ được phát hiện sớm, tiết kiệm chi phí cho công ty.

Theo phương pháp Agile, các chuyên gia về nghiệp vụ (business) sẽ làm việc trực tiếp cùng với đội dự án. Các chức năng quan trọng nhất của sản phẩm được tập trung phát triển trước và được đưa vào vận hành sớm nhất có thể. Các phiên bản mới với các tính năng mới sẽ lần lượt được đưa thêm vào.

Agile giúp tăng cường khả năng giao tiếp giữa các thành viên trong nhóm. Chất lượng mã nguồn được cải tiến liên tục. Tiến độ dự án cũng được xem xét và đánh giá một cách thường xuyên.

Thành công về mặt kĩ thuật

Trong Extreme Programming, một phương pháp tuân theo triết lí Agile, các lập trình viên làm việc cùng nhau. Nhờ vậy, các chi tiết quan trọng sẽ không bị bỏ sót, mỗi đoạn code sẽ được kiểm tra bởi ít nhất hai người. Các lập trình viên liên tục tích hợp những đoạn code vừa viết vào hệ thống, cho phép một phiên bản mới của phần mềm được “ra lò” bất cứ khi nào nó góp thêm một giá trị đáng kể. Hơn nữa, toàn bộ đội dự án tập trung hoàn thành một chức năng trước khi chuyển sang chức năng tiếp theo. Bởi vậy, tiến độ công việc được kiểm soát tốt hơn và dự án có thể dễ dàng “chuyển hướng” khi có những thay đổi từ phía khách hàng.

Ngoài ra, Extreme Programming cũng đề xuất những quy tắc giúp tạo ra các thiết kế và các đọan mã tốt. Chẳng hạn, quy tắc “phát triển dựa trên kiểm thử” (test-driven development) trợ giúp lập trình viên viết các chương trình thực hiện đúng chức năng mong muốn.

Thành công về mặt cá nhân

Mỗi thành viên trong dự án Agile, dù ở bất kì cương vị nào, cũng đều cảm nhận được một cách rõ ràng sự thành công của bản thân.

Các lập trình viên nhận thấy trình độ kĩ thuật cũng như tầm ảnh hưởng của mình đối với dự án được nâng cao, chẳng hạn trong việc ước lượng và lập kế hoạch. Quyền tự chủ của đội dự án cũng được tăng cường.

Các tester nhận thấy họ có ảnh hưởng lớn đến chất lượng sản phẩm, đồng thời giảm được các công việc lặp lại một cách nhàm chán.

Nhà quản lí dự án hài lòng vì kiểm soát được tiến độ công việc, dự án thực hiện đúng các cam kết và làm thỏa mãn khách hàng.

Khách hàng, người sử dụng, các chuyên gia nghiệp vụ cảm thấy hài lòng vì điều kiển được hướng đi của dự án và các ý kiến được lắng nghe.

Các nhà lãnh đạo cao cấp sẽ cảm thấy hài lòng vì dự án mang lại lợi nhuận lớn cho công ty.

Bản tuyên ngôn 4 điểm cùng 12 quy tắc của Agile

Tuyên ngôn 4 điểm của Agile là:

1. Cá nhân và các tương tác quan trọng hơn quy trình và công cụ.
2. Tập trung làm cho phần mềm chạy được thay vì viết tài liệu.
3. Cộng tác trực tiếp với khách hàng thay vì dựa trên hợp đồng.
4. Phản ứng với các thay đổi thay vì tuân theo một kế hoạch định sẵn.

Bản tuyên ngôn được cụ thể hóa bằng 12 nguyên tắc sau:

1. Ưu tiên cao nhất của dự án là thỏa mãn khách hàng bằng việc bàn giao sản phẩm sớm và liên tục.
2. Hoan nghênh các thay đổi từ phía khách hàng, kể cả các thay đổi vào giai đoạn cuối.
3. Bàn giao sản phẩm theo chu kì từ vài tuần đến vài tháng. Chu kì ngắn tốt hơn chu kì dài.
4. Các nhân viên hiểu nghiệp vụ và các lập trình viên phải làm việc cùng nhau hàng ngày.
5. Tổ chức dự án xoay quanh những cá nhân tích cực. Hỗ trợ và tin tưởng họ.
6. Phương pháp giao tiếp tốt nhất trong đội dự án là gặp mặt trực tiếp.
7. Các chức năng đã họat động là thước đo chính cho tiến độ dự án.
8. Khuyến khích phát triển bền vững: Lập trình viên, người dùng, nhà quản lí…phải có khả năng tham gia dự án một cách liên tục.
9. Liên tục cải tiến chất lượng thiết kế và mã nguồn.
10. Tính đơn giản giữ vai trò cốt yếu. Làm càng ít càng tốt.
11. Những yêu cầu và thiết kế tốt nhất được nảy nở từ những nhóm làm việc tự chủ.
12. Sau những khoảng thời gian nhất định, đội dự án xem xét cách thức cải tiến hiệu quả công việc.

Áp dụng Agile

Không phải dự án nào cũng nên áp dụng Agile. Nếu mục tiêu của bạn là tăng năng suất lao động, làm cho các lập trình viên làm việc nhanh hơn thì Agile có thể không phù hợp bởi các quy tắc của nó không nhằm tăng năng suất của đội dự án.Trước khi quyết định áp dụng Agile cho dự án của mình, bạn phải trả lời được câu hỏi: liệu Agile có giúp bạn thành công hơn hay không?.

Các dự án có đặc điểm sau đây có thể phù hợp với Agile:

• Mức độ rủi ro thấp.
• Thành viên nhóm có kinh nghiệm.
• Yêu cầu thay đổi thường xuyên.
• Kích thước nhóm nhỏ. Các thành viên làm việc cùng một địa điểm.
• Văn hóa công ty ưa thích sự “không trật tự” (thrive on chaos).

Trái lại, những điều kiện sau đây là vật cản cho việc áp dụng Agile:

• Kích thước nhóm lớn ( hơn 20 thành viên bao gồm lập trình viên, tester,…).
• Các thành viên phân tán về mặt địa lí (ví dụ các dự án outsource).
• Văn hóa làm việc theo mệnh lệnh.

Tài liệu tham khảo:

Sách: The Art of Agile Development by James Shore and Shane Warden.

Web: Tuyên ngôn và các nguyên tắc của Agile

(Còn tiếp…)

Agile: Giới thiệu Extreme Programming

Nguồn: The Art of Agile Development của J Shore & S Warden. Phần tiếp theo của: Agile Development: Giới thiệu chung

Extreme Programming (gọi tắt là XP, một số tài liệu tiếng Việt dịch là “lập trình cực hạn”) là một phương pháp phát triển phần mềm tuân thủ triết lí Agile. Trong số các phương pháp Agile thì XP là một trong các phương pháp hoàn thiện nhất và nhận được nhiều sự quan tâm nghiên cứu nhất. Một số phương pháp Agile khác là Scrum và Agile Unified Process (AUP).

Vòng đời của một dự án XP

Các hoạt động cơ bản của một dự án phần mềm là:

1. Lập kế hoạch (planning).
2. Phân tích yêu cầu (analysis).
3. Thiết kế (design).
4. Lập trình (programming).
5. Test.
6. Bàn giao sản phẩm (deploy).

Mô hình cổ điển thác nước (waterfall) sắp xếp các hoạt động này theo thứ tự tuyến tính, đầu ra của hoạt động này là đầu vào của hoạt động tiếp theo. Các mô hình lặp (iterative – chẳng hạn mô hình tăng trưởng hay mô hình tiến hóa) sắp xếp các hoạt động này xen kẽ lẫn nhau.

Hình 1: (a) Mô hình thác nước. (b) Mô hình lặp

XP hoạt động theo mô hình lặp. Sản phẩm được chia ra thành các phần tăng trưởng nhỏ, mỗi phần được phát triển trong vòng một hoặc vài tuần gọi là một vòng lặp (iteration). Với mỗi phần tăng trưởng, đội dự án thực hiện tất cả các hoạt động: lập kế hoạch, phân tích, thiết kế, lập trình, test và bàn giao. Ưu điểm của mô hình này là đội dự án nhanh chóng nhận được phản hồi từ phía khách hàng. Những thay đổi cần thiết sẽ được áp dụng ngay trong lần lặp tiếp theo.

Hình 2: Vòng đời của một dự án XP

Lập kế hoạch

Kế hoạch tổng thể của dự án được lập trong những tuần đầu tiên. Đại diện của khách hàng và các lập trình viên cùng nhau chia dự án thành các phần tăng trưởng nhỏ, ước lượng thời gian và công sức thực hiện chúng và vạch ra lịch trình phát triển cho từng phần tăng trưởng. Kế hoạch tổng thể sẽ được điều chỉnh tùy theo tình hình trong phần sau của dự án.
Mỗi phần tăng trưởng có một kế hoạch thực hiện cụ thể được vạch ra vào đầu mỗi vòng lặp. Đội dự án sẽ họp mặt hàng ngày để cập nhật tình hình công việc.

Phân tích
XP không dành riêng một khoảng thời gian cố định ban đầu cho việc phân tích yêu cầu. Trái lại, đại diện của khách hàng sẽ ngồi làm việc chung với đội dự án. Người đại diện này không nhất thiết phải là khách hàng thật, chỉ cần là người hiểu rõ nhất các yêu cầu cho sản phẩm. Khi cần thông tin, các lập trình viên chỉ việc đến trao đổi trực tiếp với người này.
Đối với những yêu cầu khó hiểu, đại diện khách hàng cùng với các tester tạo ra những ví dụ chi tiết gọi là “customer test”. Đối với các giao diện đồ họa, đại diện khách hàng cùng đội dự án tạo ra các bản phác thảo trước khi bắt tay vào lập trình. Một số dự án thuê người thiết kế giao diện riêng.

Thiết kế và lập trình
Trong một dự án XP, thiết kế của sản phẩm được cải tiến liên tục. Hoạt động này được thực hiện nhờ phương pháp phát triển dựa trên test (test-driven development hay TDD). TDD gắn kết chặt chẽ các công việc thiết kế, lập trình và test. Các lập trình viên phải làm việc theo cặp, một trong hai người viết các dòng lệnh cụ thể còn người kia suy nghĩ về thiết kế của chương trình.
Các lập trình viên tích hợp code vài giờ một lần và đảm bảo rằng phiên bản mới đủ tiêu chuẩn về mặt kĩ thuật để bàn giao ngay cho khách hàng.
Mã nguồn được coi là sở hữu tập thể. Mọi người được yêu cầu sửa lỗi bất kể lỗi đó do ai gây ra.

Test
Tất cả các thành viên trong dự án XP đều có trách nhiệm đảm bảo chất lượng sản phẩm. Các lập trình viên thực hiện unit test và integration test. Đại diện khách hàng kiểm tra công việc của lập trình viên và trợ giúp họ bằng các customer test. Khi các tester tìm ra lỗi, cả đội cùng nhau phân tích nguyên nhân và tìm cách cải tiến quy trình để ngăn ngừa lỗi tái diễn.
Tất cả các regression test đều được thực hiện tự động (bởi code mới được tích hợp vào hệ thống một cách liên tục) và được chạy bởi các lập trình viên khi họ tích hợp code mới vào hệ thống.
Lập trình theo cặp góp phần làm tăng chất lượng công việc.

Bàn giao sản phẩm
Hệ thống được trình diễn nội bộ hàng tuần và được bàn giao cho khách hàng theo kế hoạch đã định trước hoặc theo nhu cầu của khách hàng.

Tài liệu tham khảo
Sách: The Art of Agile Development của James Shore và Shane Warden: http://jamesshore.com/Agile-Book/
Web: http://agilemanifesto.org/

(còn tiếp…)