Xp

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