Làm cách nào để tạo kiến ​​trúc / thiết kế của một ứng dụng trong Agile?

Nếu tôi sắp phát triển một ứng dụng Doanh nghiệp, nhưng theo như tôi hiểu từ quy trình nhanh, tôi chia các tính năng thành các phần nhỏ và phát triển chúng lặp đi lặp lại. Tôi đã sử dụng để tạo cơ sở dữ liệu và cốt lõi của ứng dụng trước, sau đó tôi mở rộng các lần lặp này.

Câu hỏi là: Tôi có phải giữ những gì tôi đã từng làm trước đây (phát triển cốt lõi trước tiên) hay tôi phải phân phối phát triển cốt lõi qua phát triển câu chuyện? Sau này, tôi không chắc mã sẽ đủ linh hoạt cho các tiện ích mở rộng trong tương lai!

Bất kỳ ý tưởng?

Đừng phát triển cốt lõi trước . Một nguyên tắc chính của phát triển Agile là viết mã tối thiểu cần thiết cho các tính năng đã hoàn thành. Bằng cách đó bạn có thể giao hàng bất cứ lúc nào. Mã vẫn linh hoạt vì bạn liên tục tái cấu trúc để loại bỏ trùng lặp. Tái cấu trúc được hỗ trợ bởi các thử nghiệm tự động bạn đã viết cho từng tính năng khi bạn xây dựng nó. Lõi phát triển tự động khi bạn tính đến việc sao chép từ mã cấp cao hơn.

Về cơ bản, thay vì xây dựng tính linh hoạt trong một nỗ lực thường vô ích để giảm thiểu các thay đổi mã đắt tiền trong tương lai, Agile xây dựng các thử nghiệm tự động để hỗ trợ tái cấu trúc, do đó thay đổi mã là tương đối rẻ.

Tái cấu trúc của Martin Fowler là cuốn sách yêu thích của tôi về các kỹ thuật tái cấu trúc hiệu quả. Nó dễ dàng hơn nhiều để đưa ra một lõi có thể sử dụng hơn là xác định một mặt trước. Xác định lõi có thể sử dụng trước khi triển khai tính năng là gần như không thể, trừ khi bạn chỉ đang thực hiện lại API hiện có. Và không có giá trị trong đó.

Cách tiếp cận của tôi để phát triển nhanh là xây dựng "các lát cắt dọc". Tôi lấy một câu chuyện từ UI để lưu trữ và thực hiện nó. Tôi có một số công cụ gọn nhẹ mà tôi sử dụng để hỗ trợ quá trình này (như khung IRep repository / UnitOfWork đơn giản có bộ điều hợp cho Bộ nhớ (thường để thử nghiệm), Entity Framework và NHibernate. Tại thời điểm này tôi không nghĩ có nhiều đối số về việc người ta có nên sử dụng O / RM hay không mà nên sử dụng cái nào. Và đối với tôi, nó phụ thuộc vào môi trường.

Tôi đã thấy rằng phương pháp này chiến thắng những người không tán thành về phát triển nhanh vì họ sẽ thấy phần mềm hoạt động nhanh hơn so với việc tôi dành nhiều thời gian trước để tạo ra lõi. Kết hợp với Thiết kế hướng tên miền và một số kỹ thuật khác mà tôi sử dụng, tôi thường có thể nhận được rất nhiều chức năng làm việc trước người dùng rất nhanh.

TDD hoặc thậm chí kiểm tra đơn vị hậu hoc rất quan trọng vì một phần của việc duy trì vận tốc khi ứng dụng của bạn phát triển là có mạng lưới an toàn mà bộ kiểm thử đơn vị toàn diện cung cấp. "Tôi cần phải thay đổi lớp học này, làm thế nào để đảm bảo tôi không phá vỡ bất cứ thứ gì?" Với bộ kiểm thử đơn vị tốt, đơn giản như chạy bộ kiểm tra đó. Không, nó trở thành vấn đề chạy thủ công thông qua ứng dụng của bạn để xác minh. Không vui vẻ gì cả.

Chế tạo khung ngang tối thiểu hỗ trợ một lát chức năng dọc. Khung được chế tạo để có thể mở rộng và là nơi tập trung nhiều nỗ lực nhất ban đầu. Các lát cắt dọc của chức năng là để hạ thấp rằng khung hỗ trợ giá trị thực. Trong các lần lặp lại tiếp theo dành ít nỗ lực hơn khi khung được hiện thực hóa và nhiều hơn để xây dựng các khả năng sử dụng khung. Tiếp tục theo cách này cho đến khi phần lớn nỗ lực tập trung vào chức năng bằng cách sử dụng khung phát triển qua các lần lặp.