Lập trình cực đoan cho một nhà phát triển duy nhất [đã đóng]


10

Tôi đã làm việc với một số khái niệm lập trình cực đoan cơ bản trong hai tuần qua, với quy mô nhỏ, vì lợi nhuận, nhiều người chơi, trò chơi arcade. Tôi đã dành một tuần để phát triển các câu chuyện của người dùng và xác định các yêu cầu để tạo kế hoạch phát hành. Tôi cũng đã dành một tuần để viết mã và áp dụng kế hoạch lặp đầu tiên tôi nghĩ ra. Tôi đã xác định một vài khái niệm rõ ràng hữu ích cho một nhà phát triển.

  • Hội nhập liên tục
  • Không bao giờ thêm chức năng sớm
  • Hướng phát triển thử nghiệm
  • Chọn một ẩn dụ hệ thống
  • Sử dụng một điểm tích hợp duy nhất
  • Kiểm tra tất cả các lỗi
  • Liên tục tái cấu trúc
  • Đặt tốc độ bền vững
  • Sự đơn giản
  • Phát hành thường xuyên

Tôi tò mò liệu tôi có thiếu thứ gì đặc biệt phù hợp để làm việc với một dự án nhà phát triển không?

Ngoài ra, trong ánh sáng này đưa ra ý tưởng về sự đơn giản và phát triển dựa trên thử nghiệm, tốt hơn là sử dụng các nền tảng được thiết lập, giàu tính năng, sẵn sàng?

Hoặc tôi nên làm việc từ đầu, khi khả thi, để tránh gặp phải các vấn đề được đưa ra với các quy tắc như liên tục tái cấu trúc và không bao giờ thêm chức năng sớm?


5
Elosesite, trên c2.com (một trang web được tạo sớm để thảo luận về các khái niệm nhanh (và cụ thể là XP)) - Lập trình cực đoan cho một người dùng

Đó là một nguồn tài nguyên tuyệt vời, cảm ơn bạn. Tôi đặc biệt thích ý tưởng về Cam kết của Allegiance XP.
Kody Manharth

Nếu bạn đọc kỹ, bạn sẽ tìm thấy những cái tên như Ron Jeffries và Kent Beck bình luận ... và đó Wiki của Ward .

Vì vậy, nó được viết bởi những người tạo ra mô hình, thật tuyệt vời. Không biết làm thế nào tôi không vấp phải nó. Tôi đã sử dụng www.extremeprogramming.org
Kody Manharth

2
Không có một viên đạn nào trong câu hỏi của bạn là bắt buộc để phát triển phần mềm thành công. Câu hỏi thực sự là, cái nào bạn thực sự cần?
Robert Harvey

Câu trả lời:


5

Cuối cùng, Lập trình cực đoan là về một tập hợp các phương pháp và phương pháp dẫn đến giá trị kinh doanh được cải thiện. Minh họa tốt nhất về điều này mà tôi đã tìm thấy là từ http://c2.com/cgi/wiki?ExtremeProgrammingEneacChart

Hỗ trợ lập trình cực đoan

Mọi thứ có màu xanh là một phần cốt lõi của XP.

Có những phần của nó ở bên ngoài nó giúp kích hoạt mọi thứ trong khu vực màu xanh và là một phần của XP, nhưng không quan trọng đối với nó. Lưu ý rằng cá nhân tôi không phải là một học viên XP và tôi đã đọc rất nhiều lời chỉ trích về những người "gần như" theo XP mà nhiều người đã nói không phải là XP. Hãy đặt khía cạnh của giáo điều XP sang một bên và xem xét những gì chúng ta có.

Nhận ra rằng một trong những điều đầu tiên và đối với hầu hết mọi thứ là có một cam kết đối với quy trình từ khách hàng. Một thành phần quan trọng của XP là sự tham gia của khách hàng. Điều này cho thấy trong một số điểm như lập kế hoạch phát hành, phát hành nhỏ, đánh giá khách hàng ngoại vi. Đây là những điều mà khách hàng của bạn sẽ cần phải đăng ký nếu bạn sẽ thành công tại XP với tư cách là nhà phát triển solo. Thay vào đó, nếu họ yêu cầu thiết kế và sau đó là giai đoạn phát triển và sau đó thử nghiệm, bạn sẽ không có cam kết từ họ để tiến xa hơn.

XP không có nghĩa là không có kế hoạch. Có một số điểm trong đó lập kế hoạch là một phần của nó - ưu tiên, ước tính câu chuyện của người dùng, lập kế hoạch lặp và định nghĩa nhiệm vụ. Mặc dù bạn là một nhà phát triển về vấn đề này, đây là những điều bạn sẽ cần để làm việc với khách hàng của mình trong việc cung cấp.

Các điểm như quyền sở hữu tập thể của mã và lập trình cặp là những thứ liên quan đến nhiều hơn một. Quyết định dựa trên những thứ như tiêu chuẩn mã hóa dễ dàng hơn nhiều, nhưng điều đó không có nghĩa là bạn không phải tuân theo chúng. Quyền sở hữu mã tập thể vẫn được áp dụng - chỉ có quyền sở hữu cũng là nhà phát triển tiếp theo - không viết mã dành riêng cho bạn và bạn. Lưu ý rằng điều này ở một mức độ nào đó xung đột với 'mã cho thấy tất cả ý định' được kích hoạt bởi lập trình cặp - bạn không cần người đó kiểm tra xem bạn có đang viết mã có thể duy trì hay không nên tài liệu về mã cũng rất quan trọng.

Ngoài những cảnh báo đó, nhiều nguyên tắc thiết kế XP vẫn được áp dụng. Những thứ như thử nghiệm thiết kế đầu tiên, tích hợp liên tục, các cuộc họp với khách hàng, tái cấu trúc, YAGNI, các giải pháp tăng đột biến - những cuộc gọi đó có thể được thực hiện một mình.

Nhận ra rằng solo XP cần nhiều kỷ luật hơn hoặc nhiều hơn so với XP thông thường. XP thường được coi là một phương pháp kỷ luật cao ở chỗ nó đòi hỏi mọi người phải duy trì tuân thủ nghiêm ngặt các thực hành tốt nhất mà nó cố gắng thực hiện. Khi bạn không có huấn luyện viên hoặc người khác để hỗ trợ kỷ luật cần thiết, nó có thể rơi vào tình trạng thực hành mang nhiều nét tương đồng với XP.

Đọc liên quan:

Tôi muốn lấy ra một trích dẫn từ liên kết đầu tiên của c2:

Nhà sáng lập ngôn ngữ Perl nổi tiếng và nhà khoa học điên, Damian Conway tin rằng Lập trình cực đoan thực sự là một cách hiểu sai. Vì nó là hiện thân của nhiều thực hành lập trình tốt mà các lập trình viên được dạy nhưng gần như chắc chắn bỏ qua, ông tin rằng nó thực sự nên được gọi là Lập trình siêu bảo thủ


Khai sáng, để nói rằng ít nhất. Hiện tại tôi đang xử lý các vấn đề về TDD, trong Flash bằng Starling. Tôi đang sử dụng FlexUnit và nó không có khả năng xử lý kiểm tra đồ họa vì nó không có đầu. Sẽ là phù hợp trong các trường hợp như thế này khi chỉ cần ủy thác các thử nghiệm này cho kiểm tra thủ công (ví dụ: thử nghiệm cho logo ở giữa màn hình.) Đây có được coi là thử nghiệm tích hợp không? (tức là mô-đun màn hình Splash có hoạt động đúng với mô-đun sân khấu của Flash không?) Tôi có nên sử dụng khung mô phỏng để mô phỏng tình huống cần thiết không? Các xét nghiệm có thể hoàn toàn là cấu trúc thanh tao?
Kody Manharth
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.