ĐẠI HỌC BÁCH KHOA HÀ NỘI
Bộ môn: Kĩ thuật lập trình
TÌM HIỂU VỀ MỘT SỐ MÔ HÌNH LẬP TRÌNH
Giảng viên: Vũ Đức Vượng Thực hiện: Sinh viên: Đỗ Bá Mạnh SHSV:20111830 Lớp CNTT-TT 1.1 Hà Nội, 1/2013 KĨ THUẬT LẬP TRÌNH Lời nói đầu.
Bất kz một ngôn ngữ lập trình nào cũng đều mang tính logic cao và tuân theo
những quy chuẩn cơ bản về toán học. Tuy vậy, mỗi ngôn ngữ lại có những phương
thức riêng để thực hiện những quy chuẩn đó, đặc biệt là trên các lĩnh vực như
hàm (function), biến (variable), phương thức (method) và đối tượng (object). Bên
cạnh sự đa dạng của ngôn ngữ lập trình, cũng dần có rất nhiều mô hình lập trình
được ra đời, trong đó phổ biến nhất có thể kể đến như: Lập trình hướng đối
tượng (object-oriented programming), lập trình thủ tục(procedural programming)
và lập trình cấu trúc (structured programming). Mỗi một mô hình lập trình lại có
những đặc trưng riêng về cách sử dụng cũng như tính trừu tượng hóa đối với các quá trình xác định.
Các nhóm khác nhau trong công nghệ phần mềm đề xướng các phương pháp
khác nhau, các ngôn ngữ lập trình khác nhau tức là các mô hình lập trình khác
nhau. Một số ngôn ngữ được thiết kế để hỗ trợ một mô hình đặc thù (Java hỗ trợ
lập trình hướng đối tượng trong khi Haskell hỗ trợ lập trình chức năng). Một số
ngôn ngữ khác lại hỗ trợ nhiều mô hình (như Python và Common Lisp).
Một số mô hình lập trình cấm các thao tác mà chính ngôn ngữ đó có. Chẳng hạn,
lập trình cấu trúc không cho phép sử dụng lệnh goto. Quan hệ giữa các mô hình
lập trình và các ngôn ngữ lập trình có thể phức tạp vì một ngôn ngữ có thể hỗ trợ
nhiều mô hình lập trình. Thí dụ như C++ được thiết kế để hỗ trợ các phần tử của
lập trình thủ tục, lập trình hướng đối tượng và lập trình tiêu bản.
Mặc dù vậy, những người thiết kế và những người lập trình sẽ quyết định làm
thế nào để xây dựng một chương trình dùng các phần tử của mô hình nào đó.
Người ta có thể viết một chương trình hoàn toàn theo kiểu lập trình thủ tục trong
C++, cũng có thể viết chương trình hoàn toàn hướng đối tượng, hay viết chương
trình có các phần tử của cả hai mô hình.
Ở thời kz đầu, công nghệ phần mềm hoàn toàn dựa trên những thao tác lập
trình bằng mã nhị phân hoặc mã máy, mà đại diện là các giá trị 0 và 1. Điều này
khiến cho quá trình thiết kế, kiểm soát sự hoạt động cũng như sửa lỗi đối với một 1 KĨ THUẬT LẬP TRÌNH
ứng dụng trở nên vô cùng rắc rối và không hiệu quả. Chúng ta coi những phương
thức lập trình ở thời điểm này thuộc mô hình lập trình bậc thấp (low-level
programming paradigm). Về sau, cùng với sự phát triển của công nghệ, những hạn
chế của giai đoạn đầu tiên dần được xóa bỏ với sự ra đời của các ngôn ngữ lập
trình thế hệ thứ 3 là COBOL, Fortran và BASIC, đồng thời, một mô hình lập trình
mới cũng xuất hiện và vẫn tiếp tục được sử dụng hiệu quả và phổ biến cho đến
ngày nay, đó là mô hình lập trình thủ tục (procedural paradigm). Dần dần, chúng
ta chứng kiến sự phát triển mạnh mẽ về số lượng của các mô hình lập trình, mà
cơ bản có thể kể đến các mô hình sau:
 Lập trình cấu trúc - Structured programming.
 Lập trình chức năng - Functional programming.
 Lập trình logic - Logical paradigm
 Lập trình trực quan - Visual programming.
 Lập trình song song - Parallel programming.
 Lập trình phân tán - Distributed programming.
 Lập trình tương tranh - Concurrent programming.
 Lập trình định hướng đối tượng - Component-oriented programming .
 Lập trình cực độ - Extreme programming. …. 2 KĨ THUẬT LẬP TRÌNH
SƠ LƯỢC VỀ MỘT SỐ MÔ HÌNH LẬP TRÌNH PHỔ BIẾN
1. Functional programming. Đặc điểm:
 Nguyên l{ và { tưởng: Toán học và lý thuyết về hàm.
 Các giá trị đã được tạo là không thể biến đổi.
 Trừu tượng hóa một biểu thức thành một hàm và ngược lại, một hàm có
thể được tính toán như một biểu thức.
 Hàm là lớp giá trị đầu tiên.
 Hàm là những giá trị hoàn chỉnh, tương tự như số, danh sách...
 Thích hợp với những tính toán theo yêu cầu.
 Mở ra những khả năng mới.
Functional Programming là thể loại lâu đời nhất trong ba paradigm lập trình
chính. Ngôn ngữ FP đầu tiên là IFP, được phát minh vào năm 1955, một năm
trước khi có Fortran. Sau đó, LISP ra đời năm 1958, một năm trước khi có COBOL.
Cả Fortran và COBOL đều là những ngôn ngữ imperative (hay còn gọi là
procedural). Chúng đặc biệt thành công khi được ứng dụng vào tính toán khoa
học và nghiệp vụ, và trở thành paradigm thống trị trong suốt 30 đầu của kỉ nguyên
thông tin. Vào những năm 1970, Object-Oriented paradigm bắt đầu phát triển.
Cùng với sự trưởng thành của các ngôn ngữ lập trình hướng đối tượng, OO trở
thành paradigm được sử dụng phổ biến nhất cho đến ngày hôm nay.
Từ những năm 1950, mặc dù vẫn phát triển mạnh mẽ và liên tục với các đại diện
như SML, OCaml, APL và Clean, thì FP vẫn chỉ được sử dụng cho mục đích học
thuật và nghiên cứu là chủ yếu. Imperative đạt được thành công bước đầu nhờ
vào những chỉ thị đơn giản. OO thành công nhờ vào khả năng mô hình hóa các bài
toán phức tạp. Còn FP có khả năng gì, tại sao dù ra đời sớm nhưng lại không mang
lại thành công như mong đợi? 3 KĨ THUẬT LẬP TRÌNH
FP xem chương trình là một tập hợp các hàm nhận vào đối số và trả về giá trị.
Không giống như Imperative, FP không tạo ra hiệu ứng phụ và sử dụng đệ qui thay
cho vòng lặp. Hàm trong FP rất giống với hàm
trong toán học vì nó không làm thay đổi trạng thái của chương trình.
 Một đại lượng khi được gán giá trị thì không bao giờ thay đổi giá trị đó.
 Hàm không sửa đổi giá trị của đối số được truyền vào, và giá trị do hàm trả
về hoàn toàn là một giá trị mới.
Về mặt kĩ thuật cài đặt bên dưới, khi giá trị được gán vào một vùng nhớ thì được
đánh dấu là đã sử dụng và không ghi đè lên nữa. Để tạo ra kết quả trả về, các hàm
sao chép giá trị rồi chỉnh sửa trên các bản sao đó, không làm ảnh hưởng đến giá
trị ban đầu, rồi trả về bản sao đã được chỉnh sửa. Các đại lượng không còn được
hàm nào tham chiếu đến sẽ tự động bị hủy để giải phóng bộ nhớ (đây là { tưởng
của bộ thu gom rác trong Java và.NET).
Cơ sở toán học cho FP rất tường minh, cung cấp giải pháp logic và ngắn gọn cho
các vấn đề tính toán. Tuy nhiên, do nó không linh hoạt thay đổi trạng thái và
chuyên sử dụng đệ qui khiến người ta ưa chuộng các paradigm khác hơn để xử lý
các thao tác tính toán thông dụng. 4 KĨ THUẬT LẬP TRÌNH 2. Logical paradigm
Trong lập trình logic, ta có thể sử dụng các vị từ để định nghĩa các khái niệm của
tất cả các môn khoa học khác.
Ví dụ định nghĩa một số nguyên tố:
Số nguyên tố N là một số nguyên lớn hơn 1, chỉ chia hết cho 1 và chính nó.
Để xét xem số N có phải là số nguyên tố hay không, người ta thường sử dụng
dấu hiệu nhận biết: Số nguyên tố là một số nguyên dương, không chia hết cho
mọi số nguyên tố nhỏ hơn nó và 2 là số nguyên tố nhỏ nhất.
Dấu hiệu này có thể mô tả bằng các vị từ như sau:
- 2 là một số nguyên tố.
- N là một số nguyên tố nếu N>0, M là số nguyên tố nào đó, Mchia hết cho M.
Khi mô tả bài toán dưới dạng logic vị từ, ta có thể yêu cầu hệ thống tìm kiếm các
lời giải liên quan đến các khai báo đó. Bài toán cần giải được xem là “mục tiêu”
mà hệ thống phải chứng minh trên cơ sở các tri thức đã được khai báo.
Như thế, toàn bộ các k{ hiệu của ngôn ngữ lập trình suy về một công thức đặc biệt:
- Phát sinh từ một yêu cầu.
- Nhằm chứng minh một mục tiêu. Để trả lời cho câu hỏi đó hệ thống xem nó
như là một “đích” và cố chứng minh “đích” đó bằng cách tạo những suy
diễn trên cơ sở các tri thức đã khai báo.
Một ngôn ngữ logic có thể được dùng trong giai đoạn đặc tả yêu cầu của quy
trình xây dựng một sản phẩm phần mềm. Hơn thế nữa, logic vị từ cho phép biểu
diễn hầu hết các khái niệm và các định l{ trong các bộ môn khoa học. 5 KĨ THUẬT LẬP TRÌNH 3. Visual programming
Như chúng ta đã biết, mỗi loại máy tính (sử dụng loại CPU – Central Processing
Unit xác định) chỉ có thể hiểu và thực hiện trực tiếp được các lệnh cũng như
chương trình theo một loại ngôn ngữ dành riêng được gọi là ngôn ngữ máy.
Tuy nhiên, nếu triển khai các ứng dụng trong thực tế mà phải viết chương trình
trực tiếp bằng ngôn ngữ máy thì sẽ rất phức tạp, đòi hỏi thời gian và công sức
rất lớn, nhiều khi không thể thực hiện được. Vì vậy, người ta tìm cách xây
dựng một ngôn ngữ lập trình riêng gần với các ngôn ngữ tự nhiên, thuận lợi
cho việc triển khai các ứng dụng. Khi thực hiện các chương trình bằng ngôn
ngữ này phải qua một bước dịch chương trình đó sang ngôn ngữ máy để nó có
thể thực hiện. Từ trước đến nay có rất nhiều ngôn ngữ lập trình được ra đời và
phục vụ đắc lực cho việc triển khai các ứng dụng trên máy tính.
Trong giai đoạn đầu, các ngôn ngữ lập trình tuy dễ sử dụng hơn ngôn
ngữmáy nhưng rất khó với các lập trình viên vì chưa đủ mạnh để dễ dàng
triển khai các thuật toán. Chương trình chưa có tính cấu trúc chặt chẽ về
mặt dữ liệu cũng như tổ chức chương trình. Vì vậy, việc triển khai các ứng
dụng trong thực tế bằng các ngôn ngữ lập trình này là rất khó khăn.
Giai đoạn 2 là thời kz của các ngôn ngữ lập trình có cấu trúc. Các ngôn
ngữ lập trình này có đặc điểm là có tính cấu trúc chặt chẽ về mặt dữ liệu và
tổ chức chương trình. Một loạt các ngôn ngữ lập trình có cấu trúc ra đời và
dược sử dụng rộng rãi như : PASCAL, C, BASIC...
Giai đoạn 3 là thời kz của lập trình hướng đối tượng và phương pháp lập
trình có bước biến đổi mạnh. Trong các ngôn ngữ lập trình có cấu trúc thì
một ứng dụng bao gồm hai thành phần riêng là dữ liệu và chương trình. Tuy
chúng có quan hệ chặt chẽ nhưng là hai đối tượng riêng biệt. Trong phương
pháp lập trình hướng đối tượng thì mỗi một đối tượng lập trình sẽ bao hàm
cả dữ liệu và phương thức hành động trên dữ liệu đó. Vì vậy, việc lập trình
sẽ đơn giản và mang tính kế thừa cao, tiết kiệm được thời gian lập trình.
Tuy nhiên, với các phương pháp lập trình trên đều đòi hỏi lập trình viên
phải nhớ rất nhiều câu lệnh với mỗi lệnh có một cú pháp và tác dụng riêng,
khi viết chương trình phải tự lắp nối các lệnh để có một chương
trình giải quyết từng bài toán riêng biệt.
Trong xu hướng phát triển mạnh mẽ hiện nay của tin học, số người sử
dụng máy tính tăng lên rất nhanh và máy tính được sử dụng trong hầu hết
các lĩnh vực của đời sống nên đòi hỏi các ngôn ngữ lập trình cũng phải đơn 6 KĨ THUẬT LẬP TRÌNH
giản, dễ sử dụng và mang tính đại chúng cao. Chính vì vậy phương pháp lập trình trực quan ra đời.
Đặc điểm của các ngôn ngữ lập trình trực quan là dễ sử dụng, triển khai
các ứng dụng một cách nhanh chóng. Đặc điểm:
 Cho phép xây dựng chương trình theo hướng sự kiện (Event-Driven
Programming, nghĩa là một chương trình ứng dụng được viết theo
kiểu này đáp ứng dựa theo tình huống xảy ra lúc thực hiện chương
trình. Tình huống này bao gồm người sử dụng ấn một phím tương
ứng, chọn lựa một nút lệnh hoặc gọi một lệnh từ một ứng dụng khác chạy song song cùng lúc.
 Người lập trình trực tiếp tạo ra các khung giao diện (interface), ứng
dụng thông qua các thao tác trên màn hình dựa vào các đối tượng
(ojbect) như hộp hội thoại hoặc nút điều khiển (control button),
những đối tượng này mang các thuộc tính (properties) riêng biệt
như: màu sắc, Font chữ.. mà ta chỉ cần chọn lựa trên một danh sách cho sẵn.
 Khi dùng các ngôn ngữ lập trình trực quan ta rất ít khi phải tự viết các
lệnh, tổ chức chương trình... một cách rắc rối mà chỉ cần khai báo
việc gì cần làm khi một tình huống xuất hiện.
 Máy tính sẽ dựa vào phần thiết kế và khai báo của lập trình viên để
tự động tạo lập chương trình. 7 KĨ THUẬT LẬP TRÌNH
4. Parallel programming.
Tính toán song song (Parallel Computing) là việc chia một công việc ra thành các
công việc nhỏ và cho các công việc này thực hiện đồng thời với nhau bởi các hệ
thống có nhiều bộ vi xử l{ (multiprocessor) hay bộ vi xử l{ đa nhân (multicore)
nhằm giảm thời gian thực hiện công việc đó xuống. Việc lập trình để tách ra các
công việc nhỏ và sắp xếp để xử l{ song song thì được gọi là lập trình song song.
“Số lượng transistor trong bộ vi xử lý sẽ tăng lên gấp đôi sau mỗi 24 tháng.”
Gordon Moore - sáng lập viên của tập đoàn Intel.
Cùng với định luật Moore, các máy tính hiện nay đã được trang bị các bộ vi xử l{ đa nhân mạnh mẽ.
Tuy nhiên, để tận dụng được sức mạnh đó đòi hỏi các lập trình viên phải tận
dụng được hết các nhân trong bộ vi xử l{. Vì vậy, thay vì lập trình tuần tự như
trước đây chỉ sử dụng một nhân của bộ vi xử l{ thì người lập trình viên ngày nay
phải dùng kỹ thuật lập trình song song để tận dụng hiệu suất của bộ vi xử l{ đa nhân.
Việc lập trình song song không phải lúc nào cũng mang lại hiệu suất cao cho
chương trình. Đối với các công việc chỉ tốn ít hiệu suất thì việc dùng lập trình song
song sẽ không mang lại kết quả như mong đợi do khoảng thời gian để khởi tạo và
quản l{ các tiến trình song song gây nên.
Trong quá trình lập trình song song, lập trình viên khó tránh khỏi việc các tiến
trình cùng sử dụng chung một dữ liệu điều này sẽ gây ra xung đột dữ liệu hoặc
làm dữ liệu bị sai lệch do đó lập trình viên cần phải chú { và áp dụng các kỹ thuật
lập trình để giải quyết vấn đề này.
Bộ vi xử l{ có nhiều nhân sẽ tăng tốc chương trình song song tuy nhiên không có
nghĩa là nó sẽ tăng lên 100% trên một nhân (core) được thêm vào. Thậm chí
chương trình song song không hề tăng hiệu suất lên trong một số trường hợp. Vì
vậy lập trình viên phải biết quyết định khi nào sử dụng lập trình song song bằng
cách sử dụng các công cụ đo lường để xác định được tốc độ thực thi của chương trình. 8 KĨ THUẬT LẬP TRÌNH
Lập trình song song là một công việc rất phức tạp so với lập trình tuần tự thông
thường, người phát triển phải thực hiện một quá trình “song song hóa”, biến đổi
các chương trình tuần tự thành chương trình song song có khả năng tận dụng tối
đa sức mạnh của hệ thống.
Quá trình song song hóa gồm ba giai đoạn bước chính :
 Phân chia chương trình thành các công việc con (Sub-task decomposition).
 Phân tích sự phụ thuộc (Dependence analysic).
 Định thời các công việc (Task scheduling).
Nói một cánh dễ hiểu thì lập trình song song là lập trình để chạy được đa luồng
với các dòng CPU đa nhân hiện nay ( core i3, core i5, core i7,…)
5. Concurrent programming
Lập trình tương tranh là một trong những kỹ thuật quan trọng và cũng là một
thách thức. Một mặt, nó đem lại khả năng sử dụng hiệu quả cho những hệ thống
song song và phân tán. Mặt khác, những rủi ro trong việc tương tác giữa các tiến
trình thực hiện đồng thời có thể gây ra những lỗi phần mềm không dễ dàng để tìm ra.
Trong lập trình tương tranh, một số dòng lệnh có thể được thực hiện đồng thời.
Mỗi dòng lệnh là một chương trình tuần tự, ngoại trừ một thực tế là các dòng
lệnh có thể giao tiếp và gây trở ngại lẫn nhau. Mỗi một dòng lênh là một luồng (
thread ), các chương trình tuần tự còn gọi là chương trình đơn luồng, còn chương
trình viết theo phương pháp tương tranh là chương trình đa luồng. 9 KĨ THUẬT LẬP TRÌNH Đặc điểm:
 Người dùng có thể tương tác với các ứng dụng khi tiến trình đang thực thi.
 Những tiến trình chạy thời gian dài làm trì hoãn các tiến trình ngắn.
 Các chương trình phức tạp được thực hiện tốt hơn trên các bộ xử l{ đa luồng.
 Những tiến trình đòi hỏi điều kiện tiên quyết có thể tạm dừng và đợi đến
khi đáp ứng được để tiếp tục xử l{.
6. Distributed programming.
Lập trình phân tán là một dạng của lập trình song song (tính toán song song). Lập
trình song song tạo ra mối liên hệ giữa máy tính và các đơn vị tính toán, khiến
chúng hoạt động đồng thời đối với một vấn đề cụ thể (dự báo thời tiết chẳng
hạn). Các đơn vị tính toán có thể đặt rất gần nhau hoặc tách rời nhau. Khi các đơn
vị tính toán được đặt tách rời, ta gọi đó là lập trình phân tán. Với mô hình lập
trình này, các đơn vị tính toán thường rất khác nhau, cũng như sự khác nhau giữa
các hệ điều hành và thiết lập mạng máy tính. Những yếu tố đó khiến cho việc lập
trình các tính toán của máy tính trở nên tương đối phức tạp và khó khăn.
Lập trình mạng phân tán, thường có 2 khái niệm chính: peer to peer và client -
server... peer to peer là lập trình ngang hàng giữa 2 máy tính... còn lập trình client
- server là lập trình cho phép n máy client kết nối tới m máy server - đây cũng là
mô hình chúng ta sẽ gặp nhiều trong thực tế …
Có thể chia lập trình mạng thành 3 cấp độ, căn cứ theo mức độ thân thiện với
developer và khả năng triển khai: 10 KĨ THUẬT LẬP TRÌNH
Mức thấp nhất là lập trình sử dụng socket - có thể truyền từng byte, từng stream
lên trên mạng, ứng dụng này thường gặp trong các ứng dụng mạng cỡ nhỏ (vd:
trong 2 máy tính, trong 1 mạng LAN...).
Mức cao hơn là lập trình sử dụng, triển khai ứng dụng theo mô hình dịch vụ
(service) - quản lí mạng theo mô hình: kết nối, tạo tham chiếu client trên server và
trả về, gọi hàm và truyền dữ liệu thông qua proxy của đối tượng trả về từ server
(vd: RMI trên Java hay Remoting trên.NET...), mô hình này thường gặp trong các
ứng dụng mạng cỡ trung bình và lớn, đòi hỏi tính performance cao (vd: các ứng
dụng mạng đòi hỏi kết nối nhiều - liên tục và sử dụng diện rộng như các dịch vụ
chat, game online...), ưu điểm chính của mô hình này là tính performance cao,
bảo mật, nhưng nhược điểm là tính đa nền (multiplatform) và tính khả chuyển
chưa cao (server và client phải cùng 1 công nghệ phát triển.)
Mức cao nhất là triển khai ứng dụng theo mô hình triển khai trên web, điển hình
nhất ta có thể thấy là các web application và web service, mới nhất giờ có công
nghệ WCF của M$ (tổng hợp tất cả trong 1)... mô hình này cho phép triển khai
trên diện rộng, phục vụ lượng khách hàng lớn... nhưng cũng có nhược điểm là
tính performance chưa cao, bù lai, nó có khả năng mềm dẻo (flexibility) cao
(server và client không cần sử dụng chung một công nghệ). Chúng ta thường thấy
những ứng dụng loại này trong các ứng dụng được cung cấp từ một nhà cung cấp
nào đó (vd: các số liệu chứng khoán, thời tiết …). 11 KĨ THUẬT LẬP TRÌNH 12 KĨ THUẬT LẬP TRÌNH
7. Extreme programming.
Extreme Programing là nổi tiếng nhất của phương thức Agile (Agile Method).
Nó được hình thành bởi một tập các thực nghiệm (practice) đơn giản nhưng phụ
thuộc lẫn nhau. Những practice này làm việc với nhau để hình thành một dạng
tổng quát hơn các thành phần của nó.
Khách hàng là thành viên của nhóm phát triển (Customer team member)
Chúng ta mong muốn khách hàng và nhóm phát triền làm việc chung với nhau để
họ hiểu các vấn đề của nhau và cùng giải quyết các vấn đề đó.
Vậy ai là khách hàng ? Khách hàng của một nhóm XP là một hoặc một nhóm
người định nghĩa và xác định độ ưu tiên của chức năng hệ thống (hay sản phẩm).
Đôi khi khách hàng là nhóm nhà phân tích nghiệp vụ hoặc chuyên gia marketing
làm việc cùng một công ty phần mềm với nhóm phát triển. Đôi khi khách hàng là
một đại diện của người dùng. Đôi khi khách hàng cũng chính là người trả tiền.
Nhưng trong một dự án XP, bất kể khách hàng là ai thì họ cũng là một thành viên của nhóm phát triển.
Tình huống tốt nhất là khách hàng làm việc với nhóm phát triển trong cùng một
phòng. Hoặc chí ít là làm việc ở nơi nào đó cách độ 100 feet so với phòng làm việc
của nhóm phát triển. Khoảng cách càng xa thì càng khó thỏa mãn điều kiện
"Customer team member". Nếu khách hàng làm việc trong môt tòa nhà khác hoặc
ở một quốc gia khác thì càng khó mà yêu cầu họ tham gia cùng với nhóm.
Chúng ta sẽ làm gì nếu khách hàng không thể ở gần nhóm phát triển ? Lời
khuyên của tôi là hãy tìm ai đó sẵn lòng làm việc chung và có thể đứng ở vai trò
của một khách hàng thực thụ.
Câu chu n ng i ng ( ser Stories)
Để lên kế hoạch cho một dự án, chúng ta phải biết về yêu cầu, nhưng chúng ta
không nên biết nhiều lắm. Với mục đích lập kế hoạch, chúng ta chỉ cần biết đủ về
yêu cầu để ước lượng chúng. Bạn có thể nghĩ rằng để có thể ước lượng, bạn cần
biết tất cả các chi tiết, nhưng điều này thường không đúng. Bạn cần biết rằng
thực tế có những chi tiết đó, và bạn phải biết rằng các chi tiết đó vô cùng
hỗn tạp, nhưng bạn không cần tới các đặc tả của chúng. 13 KĨ THUẬT LẬP TRÌNH
Đặc tả chi tiết của một yêu cầu thì luôn thay đổi theo thời gian, đặc biệt là khi
khách hàng bắt đầu nhìn thấy hệ thống vận hành như thế nào. Không có cách xác
định yêu cầu nào tốt hơn cách quan sát hệ thống được áp dụng vào thực tế như
thế nào. Vì vậy, thu thập đặc tả chi tiết yêu cầu quá sớm trước khi cài đặt hệ
thống là quá vội vã và uổng phí.
Khi áp dụng XP, chúng ta sẽ cảm nhận được chi tiết của yêu cầu qua các cuộc
trao đổi (nói chuyện) với khách hàng, nhưng chúng ta sẽ không thu thập các chi
tiết đó. Khách hàng sẽ viết vài chữ (đã được thương lượng với chúng ta) lên một
tấm giấy ghi chú (index card). Tờ card này sẽ nhắc chúng ta nhớ về cuộc trao đổi
này. Cũng vào khoảng thời gian này, nhóm phát triển sẽ viết lên tờ card đó các
ước lượng. Họ ước lượng dựa trên cảm giác về các chi tiết nhận được trong cuộc đối thoại
User Story là dấu hiệu ghi nhớ cuộc đối thoại về yêu cầu. Nó là công cụ lập kế
họach mà khách hàng dùng để lên lịch trình cài đặt các yêu cầu dựa trên cơ sở
mức độ ưu tiên và chi phí ước lượng.
Chu kỳ ngắn (Short C cles)
Một dự án XP sẽ giao sản phẩm dở dang (hay dự án đang thực hiện, cùng dịch từ
chữ working project) mỗi 2 tuần. Mỗi bước lặp 2 tuần này sản xuất ra một phần
mềm dở dang đáp ứng một số yêu cầu nào đó của khách hàng. Tại thời điểm cuối
của bước lập, hệ thống được demo cho khách hàng xem và nhận phản hồi của họ.
Kế hoạch b ớc lặp:
Mỗi bước lặp thường kéo dài 2 tuần. Nó đại diện cho một lần giao hàng thử, có
thể sẽ được hoặc không được thêm vào sản phẩm chính thức. Nó là một tập các
user story được chọn bởi khách hàng dựa trên chi phí do nhóm phát triển đưa ra.
Nhóm phát triển đưa ra chi phí cho một bước lặp bằng cách đo chi phí của các
bước lặp họ đã làm trước đó. Khách hàng chọn tùy { số lượng story cho bước lặp
sao cho tổng chi phí ước lượng không vượt quá ngân sách.
Mỗi khi một bước lập được khởi động, khách hàng đồng { không thay đổi định
nghĩa của story và độ ưu tiên. Trong suốt thời gian này, nhà phát triển tự do cắt
các story thành các nhiệm vụ (task) và tự do cài đặt các task này tùy theo thuận
lợi về mặt kỹ thuật và kinh doanh. 14 KĨ THUẬT LẬP TRÌNH
Kế họach phát hành: Nhóm XP thường tạo kế hoạch phát hành tương ứng với
mỗi 6 bước lặp. Một bản phát hành thường là thành quả của 3 tháng làm việc. Nó
đại diện cho 1 lần giao hàng chính và thường sẽ được đưa vào sản phẩm. Một bản
phát hành cũng bao gồm một tập các story được phân độ ưu tiên bởi khách hàng
dựa trên ngân sách mà nhóm phát triển đưa ra.
Nhóm phát triển xây dựng ngân sách cho 1 bản phát hành bằng cách đo chi phí
tiêu tốn của những phiên bản phát hành trước. Khách hàng có thể chọn số lượng
bất kz các story cho 1 bản phát hành sao cho tổng các chi phí ước lượng không
vượt quá ngân sách. Khách hàng cũng xác định trình tự các story được cài đặt
trong 1 bản phát hành. Nếu muốn, nhóm phát triển cũng có thể đưa ra vài bước
lập đầu tiên và xác định xem story nào sẽ được cài đặt trong bước lặp nào.
Các bản phát hành không cố định, khách hàng có thể thay đổi nội dung bất kz
lúc nào. Họ có thể hủy hoặc viết một story mới hoặc thay đổi độ ưu tiên của các story.
Các ch ơng trình kiểm tra sự thỏa mãn êu cầu của sản phẩm (Acceptance Test)
Chi tiết về user story được thu thập trong dạng thức của các acceptance test
được đặc tả bởi khách hàng. Các acceptance test của 1 story được viết ngay trước
hoặc cùng lúc với việc cài đặt story đó. Chúng được viết theo một ngôn ngữ kịch
bản bất kz nào cho phép chúng chạy tự động và có thể lặp lại.
Ngôn ngữ của acceptance test được phát triển và tiến hóa cùng với hệ thống.
Khách hàng có thể thuê nhóm phát triển tạo một hệ thống thực thi kịch bản đơn
giản hoặc có thể họ có bộ phận kiểm soát chất lượng ( A) riêng để phát triển nó.
Nhiều khách hàng nhờ A phát triển công cụ cho việc kiểm tra độ thỏa mãn của
sản phẩm và trực viết các acceptance test.
Mỗi khi một acceptace test thành công, nó được thêm vào nhóm của những
acceptance test đã thành công trước đó, và không bao giờ được phép thất bại.
Nhóm acceptance test tăng trưởng lên và sẽ được chạy nhiều lần trong ngày,
hoặc chạy mỗi khi build hệ thống. Nếu như các acceptance test thất bại thì build
này được báo cáo là hỏng. Như vậy mỗi khi một yêu cầu được gọi là cài đặt xong
thì nó sẽ không bao giờ bị vỡ. Hệ thống chuyển từ trạng thái cũ sang trạng thái 15 KĨ THUẬT LẬP TRÌNH
mới mà không bao giờ được phép không làm việc (nghĩa là phải thỏa mãn các yêu
cầu cũ lẫn mới) lâu hơn vài giờ.
Lập trình theo cặp (Pair Programming)
Mã nguồn sản phẩm được viết bởi các cặp lập trình viên làm việc với nhau trên
cùng một máy tính. Một thành viên của 1 cặp sẽ giữ bàn phím và đánh code.
Thành viên còn lại của cặp sẽ quan sát code được đánh và tìm kiếm lỗi và cải tiến
mã. Cả 2 tương tác với nhau một cách liên tục và cả 2 cùng bận rộn cho công việc viết phần mềm.
Vai trò được thay đổi thường xuyên. Người giữ phím sẽ mệt mỏi và dẫn đến dễ
sai lầm. Người còn lại (trong 1 cặp) sẽ nhận lại bàn phím và điều khiển nó. Bàn
phím được hoán đổi nhiều lần giữa 2 người trong 1 giờ. Mã nguồn kết quả được
thiết kế và được viết bởi cả 2 người. Công sức của cả hai là như nhau.
Mối quan hệ theo cặp sẽ được thay đổi ít nhất 1 lần trong ngày để mỗi lập trình
viên được làm việc ít nhất với 2 người trong ngày. Xuyên suốt 1 bước lặp của XP,
mỗi thành viên của nhóm phát triển phải làm việc với mọi thành viên khác trong
nhóm. Và họ chỉ làm những công việc của trong nội dung của bước lặp đó mà thôi.
Điều này tăng cường sự trãi rộng kiến thức cho toàn nhóm. Trong khi kỹ thuật
đặc trưng vẫn còn nguyên vẹn và các công việc yêu cầu kỹ thuật đặc trưng vẫn
thường được giao cho các chuyên gia thì các chuyên gia này làm việc với hầu hết
các thành viên còn lại trong nhóm . Điều này sẽ trải rộng kiến thức cho toàn nhóm
để các thành viên khác có thể thay thế cho chuyên gia trong các trường hợp khẩn cấp.
Nghiên cứu của Laurie Williams và Nosek đã chỉ ra rằng làm việc theo cặp không
những không giảm hiệu năng của đội ngũ lập trình mà nó còn gia giảm đáng kể tỉ lệ sai sót.
Phát triển theo nh h ớng test ( est riven evelopment)
Tất cả các mã nguồn sản phẩm được viết để làm cho các unit test thành công. Đầu
tiên, chúng ta viết 1 unit test thất bại (fail, chạy sai) bởi vì chức năng dự định test
vẫn chưa tồn tại. Sau đó chúng ta viết mã để cái test này thành công (pass). 16 KĨ THUẬT LẬP TRÌNH
Thời gian lặp lại giữa viết test rồi viết code xảy ra rất nhanh, trong khoảng một
vài phút. Các bộ test và mã cùng tăng trưởng, trong đó bộ test luôn dẫn trước mã
một khoảng cách rất ngắn.
Kết quả là các bộ test phát triển cùng lúc với mã sản phẩm. Những bộ test này
cho phép các lập trình viên kiểm tra chương trình (đang phát triển) có chạy hay
không. Nếu một cặp nào đó thưc hiện một thay đổi nhỏ, họ có thể chạy lại các bộ
test để chắc chắn rằng ho không làm hỏng các đoạn mã khác. Điều này làm cho
công việc refactoring vô cùng thuận tiện.
Khi bạn viết mã để các bộ test thành công, thì mã đó được gọi là mã khả kiểm
(hay mã có thể test, testable code). Ngoài ra, còn có 1 mục tiêu rất quan trọng là
bạn có thể tách bạch các module sao cho chúng có thể được test một cách độc
lập. Như vậy, bản thiết kế theo hướng này cho kết quả là mã nguồn ít bị trùng lặp
nhất. Các nguyên l{ thiết kế OO đóng vai trò là công cụ mạnh mẽ giúp bạn tránh được mã trùng lặp.
Sở hữu tập thể (Collective Ownership)
Một cặp có quyền check out và chỉnh sửa, cải tiến một module bất kz. Không
một lập trình viên nào chịu trách nhiệm cá nhân với một module bất kz hoặc một
kỹ thuật bất kz. Mọi người cùng làm việc với GUI(*). Mọi người cùng làm việc với
middle ware. Mọi người cùng làm việc với database. Không ai có nhiều quyền lực
hơn người khác về một kỹ thuật hay một module nào đó.
Điền này không có nghĩa là XP phản đối chuyên viên. Nếu bạn có kỹ năng về lập
trình GUI, hẳn bạn thích các nhiệm vụ liên quan đến GUI, nhưng bạn sẽ được yêu
cầu bắt cặp với các nhiệm vụ ở middle ware và database. Nếu bạn quyết định học
một chuyên môn thứ hai, bạn có thể đăng k{ các nhiệm vụ và làm việc với chuyên
gia ở chuyên môn đó. Họ sẽ dạy bạn và bạn sẽ không bị "giam giữ" trong chuyên môn của mình.
ích hợp liên tục (Continous Intergation)
Các lập trình viên check in mã và tích hợp nhiều lần trong ngày. ui luật rất đơn
giản, người đầu tiên sẽ check in, những người sau thì merge.
XP sử dụng công cụ quản l{ mã (source control) cho phép nhiều người check
out môt lúc. Điều này có nghĩa là các lập trình viên được phép check out bất kz 17 KĨ THUẬT LẬP TRÌNH
một module nào đó vào bất kz thời điểm nào đó. Khi anh ta check in module (đã
được chỉnh sửa), anh ta phải chuẩn bị merge với các thay đổi do một lập trình
viên bất kz trước đó thưc hiện. Để tránh phải merge quá nhiều trong 1 lúc, các
thành viên nên check in thường xuyên.
Một cặp sẽ làm một nhiêm vụ trong khoảng 1 hay 2 giờ. Họ tạo các bộ test và
mã sản phẩm.Vào một thời điểm thích hợp, có thể là trước khi nhiệm vụ đó được
hoàn thành, họ sẽ quyết định check in các đoạn mã. Trước tiên, họ phải làm cho
các bô test đều thành công. Sau đó, họ mới tích hợp phần code mới vào phần đã
có. Nếu cần thì merge chúng lại. Hoặc nếu cần, họ sẽ hỏi { kiến lập trình viên
check in trước đó. Một khi các thay đổi đã được tích hợp, họ build lại hệ thống.
Họ chạy lại tất cả các test trong hệ thống, bao gồm cả acceptance test. Nếu họ
làm hỏng bất cứ thứ gì, họ phải sửa ngay. Nếu các test đều thành công, khi này họ
mới được gọi là hoàn thành xong một check in.
Như vậy nhóm XP sẽ build hệ thống nhiều lần trong ngày. Họ build toàn hệ
thống từ đầu đến cuối. Nếu kết quả cuối cùng của hệ thống là 1 CD thì họ sẽ tạo
một CD. Nếu kết quả của hệ thống là 1 web site,, họ sẽ cài đặt web site đó, có thể
là trên 1 web server dành riêng cho test.
Chạ bền (Sustainable Pace)
Một dư án phần mềm không phải là một cuộc chạy nước rút, mà nó là một cuộc
chạy marathon. Nhóm nào vừa rời vạch xuất phát đã chạy thât nhanh thì sẽ tiêu
tốn hết năng lượng trước khi họ về đến đích. Để hoàn tất được nhanh thì team
càng phải kiểm soát được tốc độ, họ phải duy trì năng lượng và sự tỉnh táo. Họ
phải chạy với nhịp độ vừa phải và vững chắc.
ui luật của XP là nhóm không được phép làm việc quá giờ (overtime). Ngoại lệ
duy nhất là vào tuần cuối cùng của một phiên bản phát hành. Nếu team đang phải
trong tình huống hoàn tất nhanh chóng kịp tiến độ phát hành thì có thể overtime. 18 KĨ THUẬT LẬP TRÌNH Kết luận
Với lượng kiến thức vô cùng hạn chế cũng như chưa có nhiều thời gian để tìm
hiểu chuyên sâu, báo cáo này không hy vọng mang đến những gì mới mẻ mà đơn
giản chỉ là sự tổng hợp, lược dịch và chỉnh sửa lại các bài viết đã có trên internet,
sách in và một số tài liệu khác. Sai sót về mặt nội dung cũng như khiếm khuyết
trong cách trình bày chắc chắn không thể tránh khỏi, rất mong nhận được sự
thông cảm và giúp đỡ của thầy để báo cáo được hoàn thiện hơn!
Em xin chân thành cám ơn! 19