|
Xin chào
Guest
| Đăng ký
| Đăng nhập
|
|
|
| Trang chủ | Những mạch mới | Mạch chưa trả lời | Người dùng trực tuyến | Thành viên | Giúp đỡ |
Diễn đàn SEGVN
Software Engineering Terminology
Fundamental Concepts
Mạch: Lập trình cực đoan - eXtreme Programming (EP)
|
| Không có thành viên nào đang xem mạch |
|
Trạng thái mạch: Bình thường Tổng số bài viết trong mạch này: 3 |
|
| Tác giả |
|
JohnVu
Prof. Tham gia: 29-12-2008 Tổng số bài đã viết: 849 Trạng thái: Offline |
Lập trình cực đoan eXtreme Programming (EP) là phương pháp phát triển phần mềm đã được Kent Beck mô tả bằng các tài liệu có liên quan do Martin Fowler và Ron Jeffries sinh ra. Mới thoáng nhìn, người ta có thể nghĩ rằng nó là phương pháp được thiết kế với sự tập trung vào lập trình, không phải vào kĩ nghệ phần mềm. Tuy nhiên, bản thân là một người lập trình EP, tôi tin nó bao quát nhiều ý tưởng kĩ nghệ phần mềm tuyệt hảo như lập trình cặp đôi, phát triển gia tăng, khách hàng tại chỗ, tích hợp liên tục, và kiểm thử liên tục. Mục đích đằng sau eXtreme Programming là thời gian chu kì và quản lí rủi ro. Và nó cũng không thực sự mới; nó chỉ lấy các khái niệm nổi tiếng và đẩy chúng tới các giới hạn. Theo ý kiến của tôi, nó có tác dụng tốt cho tổ nhỏ (2 tới 6 người) làm sản phẩm phần mềm riêng lẻ với việc tích hợp hay trao đổi dữ liệu có giới hạn. Cũng giống như tập bất kì môn thể thao một cách mù quáng đều rất nguy hiểm, làm eXtreme Programming, mà không hiểu rõ ràng những giới hạn của nó về sử dụng phương pháp này, có thể dẫn dự án EP vào môi trường hỗn độn không thể thức. eXtreme Programming (EP) is a software development method that has been described by Kent Beck with related materials generated by Martin Fowler and Ron Jeffries. At first glance, one may think that it is a method designed with a focus on programming, not software engineering. However, as an EP programmer myself, I believe it covers many excellent software engineering ideas like pair programming, incremental development, on-site customer, continuous integration, and continuous testing. The goals behind eXtreme Programming are cycle time and risk management. And it's not really new; it just takes well-known concepts and pushes them to the limits. In my opinion, it works well for a small team (2 to 6 people) doing stand-alone software products with limited integration or data exchange. Just like blindly doing any sport can be very dangerous, doing eXtreme Programming, without clearly understanding its limitations on the usage of the method, can lead an EP Project into an ad hoc chaotic environment. ---------------------------------------- Prof. Vu Carnegie Mellon University |
||
|
|
Minh.CMUDuyTan
Novice Việt Nam Tham gia: 01-08-2009 Tổng số bài đã viết: 1 Trạng thái: Offline |
Thầy có thể nói rõ cho em hiểu về điểm mạnh và yếu của eXtreme Programming không? |
||
|
|
JohnVu
Prof. Tham gia: 29-12-2008 Tổng số bài đã viết: 849 Trạng thái: Offline |
Trong phương pháp mau lẹ agile, lập trình cực đoan (XP) có lẽ là cách tiếp cận "hướng tổ" nhất với việc phát triển phần mềm. Nguyên tắc then chốt là từng thành viên phải hỗ trợ lẫn nhau trong phát triển vì hai người là tốt hơn một người (lập trình cặp đôi) do đó cách tiếp cận này yêu cầu người phát triển phần mềm có kỉ luật rất ca, có kĩ năng cao và giầu kinh nghiệm để làm nó cho đúng. Bởi vì XP không yêu cầu nhiều tài liệu, nhiều người tưởng nó là đơn giản và dễ dàng. Tuy nhiên, bản chất thực của XP là: Tổ nhỏ, nhiều trao đổi, làm chủ tập thể, và trách nhiệm chia sẻ cho nên tổ không cần làm tài liệu bởi vì họ biết đích xác điều người khác đang làm. Cũng như tất cả những phương pháp mau lẹ khác, sự tham gia của người dùng vào dự án là cần có và thành viên tổ XP làm việc trực tiếp cùng người dùng trên cơ sở hàng ngày cho nên không có nhu cầu về tài liệu yêu cầu. Dự án thường bắt đầu với âập kế hoạch, cấu phần chính của lập kế hoạch là "chuyện của người dùng" (Tương tự như trường hợp sử dụng hay mô tả yêu cầu hành vi cho một mảnh phần mềm trong phương pháp phát triển khác.) Thành viên tổ dùng các câu chuyện để xác định khối việc cần thực hiện và từng khối kéo dài khoảng hai tới ba tuần, tương tự như “Sprint-nước rút” trong phương pháp Scrum. Trước khi viết mã, tổ đồng ý về qui trình, chuẩn viết mã và bắt đầu “lập trình cặp đôi” bằng việc để hai thành viên ngồi cạnh nhau, người này bắt đầu viết mã khi người kia quan sát, giúp đỡ sửa mã và giải quyết các vấn đề khi mà được viết. Sau một chốc, họ đổi vai trò và tiếp tục viết mã cho tới khi họ hoàn thành nhiệm vụ cho ngày. Như bạn có thể thấy tại sao trong XP, mọi người đều biết việc của nhau bởi vì họ thường xuyên cải tiến, sửa lỗi, sửa chữa, giúp đỡ lẫn nhau. Quan niệm then chốt của XP là tioafn bộ tổ sở hữu mã và bất kì thành viên tổ nào cũng có thể làm thay đổi để cải tiến nó cho nên đến cuối từng khối; sản phẩm có chất lượng cao. Như tôi đã nói trước đây, phần lớn phương pháp mau lẹ đều làm việc tốt cho dự án nhỏ nơi yêu cầu không ổn định. Sức mạnh của XP là ở cách tiếp cận lập trình theo tổ để tạo ra sản phẩm chất lượng cao trong môi trường thay đổi nhanh. XP yêu cầu nỗ lực lớn trong làm việc theo tổ, luồng thông tin tự do; nhiều trao đổi, thường xuyên cải tiến, sửa chữa, hoàn chỉnh và những điều này có thể điểm yếu của nó nếu các thành viên tổ không hợp tác với nhau. XP sẽ không có tác dụng trong dự án lớn hay phức tạp bởi vì nó yêu cầu kiểu kĩ năng khác. Nhân tiện, nếu thành viên tổ không có kĩ năng cao, không có kinh nghiệm và không được đào tạo làm việc theo tổ, XP có thể là thảm hoạ. Bởi vì XP không có tài liệu nhưng dựa chủ yếu vào trao đổi tổ và chia sẻ thông tin, nếu thành viên tổ không được chuẩn bị tốt thì phương pháp này sẽ không có tác dụng. Cũng vậy, nếu bạn không thích bị chỉ trích, hay không thích nhìn người khác chữa mã của bạn, thì bạn không thể dùng được XP. ----English version---- Among agile method, extreme programming (XP) is probably the most “team oriented” approach to software development. The key principle is each member must support others in the development as two people are better than one (Pair programming) therefore this approach requires very highly discipline, highly skilled and highly experienced software developers to do it correctly. Because XP does not require a lot of documentation, many people think that it is simple and easy. However, the real essences of XP are: Small team, lot of communications, collective ownership, and shared responsibility so the team does not need documentation because they know exactly what others are doing. Just like all other agile methods, user participation in the project is required and XP team members work with users directly on a daily basis so there is no need for requirements documentation. The project usually begins with planning, the main component of planning is the “user story" (Similar to use case or descriptions of the behavioral requirements for a piece of software in other development methods.) Team members use the stories to define a block of work to be done and each block lasts about two to three weeks, similar to the “Sprint” in Scrum method. Before coding, the team agrees on the process, the coding standard, and start “Pair programming” by having two members sit next to each others, one starts coding when other observes, helps correct the code and solves problems as the code is written. After a while, they switch roles and continue the coding until they complete their task for the day. As you can see why in XP, everyone know about each others’ works because they constantly improving, fixing, correcting, helping each others. The key concept of XP is the entire team owns the code and any team member can make changes to improve it so in the end of each block; the product is of high quality. As I mentioned previously, most agile methods work well for small project where requirements are not stable. The strength of XP is in the team programming approach to create high quality product in a fast changing environment. XP requires significant efforts in teamwork, free flow of information; lots of communication, constantly improving, fixing, refactoring and these could be its weaknesses if team members are not cooperate with each others. XP will not work in large or complex project because it requires different type of skills. By the way, if team members are not highly skills, not experienced and not receive training in team work, XP could be a disaster. Because XP does not have documentation but relies mostly on team communication and sharing information, if team members are not well prepared it will not work either. Also, if you do not like to be criticized, or do not like to see other fixing your code, then you can not use XP. ---------------------------------------- Prof. Vu Carnegie Mellon University ---------------------------------------- [Thay đổi 1 lần, thay đổi lần cuối bởi JohnVu lúc 04:13:58 07-08-2009] |
||
|
|
|
Múi giờ hiện tại là GMT 22:42:35 05-02-2012 |
