extream programming (xp) là một phương pháp xây dựng phần mềm mới, dựa trên lý thuyết

phương pháp phát triển phần mềm linh hoạt (agile software development), nó nhấn mạnh vào
sự cộng tác (collaboration), tao ra phần mềm một cách nhanh chóng, và phát triển mở rộng một
cách khéo lẻo trong quá trình thực hành. nó được cô đọng lại trong bốn giá trị: sự giao tiếp
(communication), tính đơn giản (simplicity), sự phản hồi (feedback), và sự dũng cảm
(courage).

Đó là khải niệm, hiểu một cách đơn giản, đây là phương pháp phát triển phần mềm trong thời
gian ngắn cho một nhóm nhỏ, khoảng 10 đến 20 người. nó tập trung quanh 12 khái niệm và cũng
là những nguyên tắc cơ bản

1. planning - lập kế hoạch

user stories are written.

- sử dụng các "user-story", một dạng giống như cac thẻ crc nhưng chức
năng lại giống use-case, là các khoản mục công việc phải hoàn thành, là kết quả
của sự trao đổi thảo luận và tham gia đóng góp của tất thành viên trong đội, bao
gồm cả khách hàng. một "user story" thường chỉ ghi đơn giản vì nó được tạo ra khi
chưa có một thiết kế rõ ràng, hay chính xác hơn, nó là một phần của thiết kế.

release planning creates the schedule.

- lập bản kế hoạch sơ bộ, mọi người trong đội nhận các user-stories và
đánh giá thời gian có thể hoàn thành.

make frequent small releases.

- thường xuyên phổ biến những kế hoạch nhỏ, thục hiện những chức năng
bộ phận cho các thành viên trong đội và cho khách hàng.

the project velocity is measured.

- tốc độ của dự án là có thể đo được, nó được tính toán thông qua hạn
hoàn thành của các user-story và số lượng user-story phát sinh mới. thêm vào đó,
việc thường xuyên có các buổi họp nhóm sẽ đánh giá chính xác hơn tiến độ công
việc

iteration planning starts each iteration.

- nhắc lại kế hoạch trước mỗi chu kỳ lặp. (mỗi vòng như vậy kéo dài 1 đến
3 tuần, tùy vào mỗi dự án)

move people around.

- luân chuyển thường xuyên. trong pair-programming, đó là sự thay đổi vai

trò của hai lập trình viên. còn trong toàn đội đó là sự hoàn đổi vị trí, nhiệm vụ. Điều
này có thể thực hiện được vì code là public với tất cả thành viên trong đội và được
viết theo một chuẩn chung.

a stand-up meeting starts each day.

- khởi đầu mỗi ngày làm việc là một cuộc họp nhanh, toàn đội. Đây là thời
điểm để trao đổi về các vướng mắc, những ý tưởng và giải pháp mới. mọi thứ luôn
ở trạng thái sẵn sàng để thay đổi.
 fix xp when it breaks

- tất nhiên những nguyên tắc này không phải bắt buộc bởi mục đich suy
nhất là tạo ra sản phẩm có chất lượng

2. designing - thiết kế

simplicity

-tính đơn giản. thiết kế càng đơn giản thì hoàn thành càng nhanh. nhưng
cần nhớ rằng đây không phải là thiết kế cuối cùng. luôn luôn giữ mọi thứ đơn giản
không có nghĩa là không thể tạo nên những hệ thống phức tạp. một hệ thống phức
tạp có thể được tiến hóa dần dần từ một hệ thống đơn giản nhất. nếu cố gắng xây
dựng một hệ thống phức tạp ngay từ đầu có thể chẳng bao giờ tạo ra cái gì. quá
trình tạo ra sự tiến hóa đó được gọi là refectoring.

choose a system metaphor.

- hãy mô tả hệ thống bằng cách ẩn dụ nó với các thực thể thật trong cuộc sống,
việc này thực chất là đặt tên cho các lớp, các phương thức...nó ảnh hưởng rất lớn đến
cách suy nghĩ khi viết code, tính dễ đọc hay khó đọc của code.

use crc cards for design session

- thẻ crc (class, responsibilities, and collaboration) được sử dụng khi thiết
kế. khái niệm crc là khải niệm quen thuộc khi thiết kế hướng đối tượng.

create a spike solution

- tạo ra các chương trình nhỏ có tính chất minh họa cho một giải pháp hoặc ý
tưởng mới. phần lớn các chương trình này được tạo ra nhanh chóng và thường
không được giữ lại. chức năng của chúng chỉ là minh họa và giúp mọi người quyết
định

never add functionality early

- Đừng bao giờ thêm các chức năng quá sớm, chúng ta sẽ thêm chúng
dần dần sau này. nếu ôm đồm quá sớm mọi thứ sẽ trở nên hồn loạn và khó kiểm
soát.

refactor whenever and wherever possible

- thường xuyên refactor bất cứ lúc nào có thể. refactoring là công việc tổ
chức, sắp xếp lại những đoạn code đã chạy được mà vẫn đảm bảo vượt qua tất cả
các test. thường thì bạn sẽ phải thực hiện điều này khi cảm thấy sự bất ổn trong
code (người ta gọi là bad smells in code) , đó là khi nó trở nên khó đọc, khó thêm
các chức năng mới.

3. testing - kiểm thử

all code must have unit tests

all code must pass all unit tests before it can be released.
when a bug found tests are created
acceptance tests are run often and the score is published
 trong xp, unit testing là một phần cực ký quan trọng. xp giảm nhẹ phần
thiết kế và lồng nó vào trong viêc viết test. có thể mô tả việc này như sau: Đầu tiên
bạn nhận công việc, hình dung ra chương trình khi nó đã hoàn thành, viết test cho
nó, những test này được viết để chạy tự động và sẽ thông báo lỗi. rõ ràng khi viết
test bạn đã hình dung ra phần nào module của mình, nó giống như bạn đặt ra
những cột mốc cho mình và cố gắng vượt qua, lần lượt từng cột một.

khi gặp tìm thấy một lỗi hoặc một khả năng sinh lỗi, hãy bổ sung nó vào
tập test-case. do luôn có một khung để kiểm tra tính chính xác của code nên bạn
hoàn toàn có thể refactor một cách tự do mà không phải bận tâm về việc phát sinh
lỗi mà không kiểm soát được.

xây dựng một phần mềm không giống xây dựng một ngôi nhà. khi xây nhà,
ban thiết kế xong xuôi, sau đó đội xây dựng đến, đọc bản vẽ và thực thi. nhưng với
phần mềm thì khác, thực tế chức tỏ người kỹ sư rất khó có được những hình dung
chính xác nhất về hệ thống sau này. sự phát triển của công nghệ thông tin là quá
nhanh, có thể đến một lúc nào đó nó sẽ ổn định và sẽ giống với việc xây nhà. tuy
nhiên hiện tại thì không. có vẻ nó giống với việc vừa xây vừa phá hơn, mà khi đó
người trực tiếp làm việc với code lại chính là những người nhiều ý tưởng nhất.

thực ra trong mô hình phát triển phần mềm truyền thống, người ta vẫn cố
gắng đi theo mô hình của việc xây nhà. nó tốt, tôi không phủ nhận điều đó. nhưng
nó vẫn thiếu điều gì đó. rõ ràng việc bán một ngôi nhà thì không giống bán một
phần mềm.

coding

the customer is always available

- khách hàng luôn luôn được coi là một thành viên trong đôi. chúng ta hiểu
rằng họ là người sẽ dùng những sản phầm này để kiếm tiền, vì thế có lẽ họ hiểu
mình cần gì. họ sử dụng user-story để can thiệp. phải hiểu khách hàng không phải
lúc nào cũng là đối tác, nên hiểu họ là những người cần sản phầm này vào mục
đich riêng của họ.

code must be written to agreed standards

- code phải được viết theo một chuẩn, điều này cộng với việc public code
trong đội sẽ giúp mọi thành viên đều được đọc và can thiệp vào code của tất cả
các phần trong dự án. không có dòng code nào là của riêng ai cả.

code the unit test first

- như đã nói ở phần testing, phải viết unit test trước khi viết code. Điều này
gần như bắt buộc.

all production code is pair programming

- lập trình đôi, đây là một khái niệm mới. hai lập trình viên sẽ sử dụng
chung một máy tính. một người trực tiếp viết code và một người sẽ hỗ trợ. thường
thì một người viét một người rá soát, tìm sơ hở vào tạo test. mọi quyết định đều
được thảo luận và thống nhất bởi cả hai người. ( để hiểu rõ hơn thì đọc quyển
craftman của r.martin

only one pair integrates code at a time.

 - chỉ một đôi được phép can thiệp vào code ở một thời điểm.

integrate often.

- thường xuyên tích hợp tưng phần vào hệ thống để test ở mức cao hơn

use collective code ownership

- code thuộc sở hữu của cả đội, không có dòng nào là của riêng ai trong
đội.

leave optimization till last

- Để việc tối ưu code sau cùng. Đừng quá bận tâm vào việc này khi đang
code, hay quan tâm tới mục tiêu duy nhất là vượt qua tất cả các test.

no overtime

- không làm quá giờ. hết giờ và nghỉ. hãy để đầu óc thật thoải mái khi bắt
đầu buổi làm việc tiếp theo.

tham khảo :

http://www.extremeprogramming.org

http://www.xprogramming.com

http://en.wikipedia.org/wiki/extreme_programming