kiến ​​trúc Agile

Question

Tôi bắt đầu luận văn tốt nghiệp của tôi và chủ đề sẽ là "nhanh nhẹn kiến ​​trúc"

Về cơ bản, nó sẽ bắt đầu với một mô tả của methologies phát triển phần mềm truyền thống, và sự ra đời tiếp theo của phương pháp nhanh nhẹn, hoàn thiện các khuyến nghị và một thiết kế của một kiến ​​trúc ứng dụng linh hoạt dễ dàng thích ứng với những thay đổi cố hữu trong xây dựng phần mềm.

Câu hỏi của tôi là, bạn sẽ đề xuất các mẫu thiết kế và thực tiễn thiết kế nào cho kiến ​​trúc như vậy? Tôi quan tâm đến các mẫu cho phép tối đa hóa tách lớp như chèn phụ thuộc, khả năng bảo trì cao và trừu tượng tối đa từ vấn đề cụ thể.

Answer 1

Tôi khuyên bạn nên điều sau đây:

1. Pattern Repository
2. Đặc điểm kỹ thuật Pattern
3. Dependency Injection
4. Domain Driven Design

Về cơ bản tất cả mọi thứ đám đông ALT.NET rao giảng.

Answer 2

Thực hành IoC chắc chắn và lập trình hợp đồng nói chung sẽ nằm ở đầu danh sách của tôi. Từ một vấn đề kinh nghiệm, mặc dù, tôi sẽ cảnh báo chống lại trừu tượng quá nhiều từ vấn đề đơn giản chỉ vì lợi ích của trừu tượng. Ví dụ. trừu tượng bởi vì bạn có thể và không phải vì bất cứ ai sẽ có thể sử dụng sự trừu tượng đó. Tôi đã thấy loại kiến ​​trúc đó xấu đi và chỉ cần thêm mức độ phức tạp quá cao vào một hệ thống làm cho việc bảo trì hệ thống tồi tệ hơn.

Một số loại vòng phản hồi xung quanh quy trình phát triển của bạn - có thể là kiểm tra đơn vị, hội nhập liên tục và/hoặc cuộc họp "scrum". Tôi nhận ra rằng không thực sự rơi vào phạm vi "kiến trúc" nhanh nhẹn, nhưng nếu bạn không có và quá trình nhanh nhẹn, thì không có mức độ kiến ​​trúc "định hướng nhanh" nào quan trọng.

Answer 3

Đây là một câu hỏi thú vị. Một kiến ​​trúc có thể được tạo ra một cách nhanh nhẹn trong sự cô lập? Nếu chúng ta đang xem xét một thứ gì đó như XP thì tôi hơi nghi ngờ. Hoặc có thể tôi đã hiểu lầm, nhưng điều đó không bao giờ ngăn tôi mở rộng ...

Trong XP, để có cách tiếp cận tôi biết nhiều hơn, chúng ta sẽ có một số cấu trúc trong một thời gian rất ngắn sau khi chúng tôi bắt đầu một dự án; về thời gian câu chuyện đầu tiên hoàn thành, trên thực tế. Trong quá trình viết truyện ban đầu, chúng tôi đã bắt đầu nhận được một số ý tưởng về những gì chúng tôi có thể xây dựng - đó là điều không thể tránh khỏi: các lập trình viên có xu hướng suy nghĩ về mặt mã. Nhưng suy nghĩ quá xa phía trước đưa chúng ta vào lãnh thổ YAGNI. Tôi nghĩ rằng phần lớn kiến ​​trúc của một ứng dụng được phát triển trong một môi trường nhanh nhẹn được dự kiến ​​sẽ nổi lên thông qua, cụ thể là việc tái cấu trúc liên tục và chuyên dụng để loại bỏ trùng lặp. Vì vậy, có lẽ câu hỏi là nhiều để đánh giá nếu có những đặc điểm cụ thể - hoặc các lớp đặc điểm - các kiến ​​trúc được phát triển như là kết quả của một quá trình nhanh sẽ có xu hướng hiển thị. Và sau đó tôi nghĩ rằng nó sẽ phụ thuộc vào loại ứng dụng chúng tôi đang xây dựng, mặc dù một số nguyên tắc đã được đề cập (một vài trong số đó tôi thậm chí hiểu) phải có khả năng.

Answer 4

Theo như tôi quan tâm, Agile không thuyết giảng bất kỳ "Kiến trúc" nào như vậy.Agile là một phương pháp dựa trên các nguyên tắc cơ bản có hiệu lực quản lý dự án, chu kỳ phát hành và thực hành phát triển chung nhưng chắc chắn không phải là kiến ​​trúc phần mềm.

Tất cả các mẫu phần mềm được liệt kê ở đây có thể được sử dụng bằng cách sử dụng quy trình thác nước mạnh, đó là sự anathema để phát triển Agile.

Answer 5

Onion Architecture

example

Answer 6

Là phương tiện nhanh nhẹn mà bạn nắm lấy thay đổi, tức là chấp nhận thay đổi trong các yêu cầu và quyết định thiết kế và chấp nhận refactoring vv .. nhiều điều cách "truyền thống" sẽ tiết kiệm nụ cười khi, vì bạn là chạm vào thứ gì đó đang hoạt động/đã đồng ý trước đó.

Trong các phương pháp như XP cố gắng giữ chất lượng cao bằng cách viết các bài kiểm tra đơn vị. Hãy giả vờ như chúng ta đều đồng ý viết bài kiểm tra đơn vị.

Bây giờ, đây là nơi bạn có thể giới thiệu một số kiến ​​trúc để hệ thống có thể kiểm tra hoặc thử nghiệm, vì không phải tất cả các hệ thống đều có thể kiểm tra. Ví dụ: làm lớp giữa có thể gọi được và lớp giao diện người dùng riêng biệt từ logic nghiệp vụ, v.v.

Answer 7

Thực tiễn thiết kế thiết yếu tôi khuyên bạn nên xây dựng bộ khung kiến ​​trúc đầu tiên, chức năng đầu cuối, hữu ích . Để xác thực nó càng sớm càng tốt bằng phản hồi thực.

Đây là những gì mà các lập trình viên thực dụng gọi là "Dấu đầu dòng" và Alistair Cockburn là "walking skeleton".

Bạn cũng có thể xác định đơn đăng ký là gì trong ngữ cảnh của luận án của bạn? Bạn chỉ xem xét application software hoặc bạn có còn giải quyết các hệ thống phức tạp hơn không?

Answer 8

Nếu Robert Martin có bất cứ điều gì để nói về nó (và ông gọi là cuộc họp Tuyên ngôn Agile gốc IIRC), thì kiến ​​trúc hoàn toàn có mọi thứ liên quan đến Agility. Toàn bộ phần đầu tiên của cuốn sách của mình Agile Software Development, Principles, Patterns, and Practices là về nguyên tắc kiến ​​trúc SOLID. Điều này đã phần nào gây tranh cãi trong một số quý nhưng tôi không hiểu tại sao. Nếu codebase của bạn là giòn và nặng nề kết hợp thì nó không thể rất cởi mở để thay đổi, đó là dấu hiệu của sự nhanh nhẹn. Quá trình phân tách khái niệm từ thực hành mã là một điều rất nhanh nhẹn để làm.

Nguyên tắc 1 của tuyên ngôn: "Chúng tôi đánh giá các cá nhân và giao tiếp qua các quy trình và công cụ".

Xác định Agile "quá trình" như là một trừu tượng tách biệt với kiến ​​trúc của codebase với tôi vi phạm tinh thần của nguyên tắc đầu tiên này.