Làm thế nào là thiết kế kiến ​​trúc được thực hiện trong một môi trường nhanh nhẹn?


59

Tôi đã đọc Nguyên tắc cho Kiến trúc sư Agile , nơi họ xác định các nguyên tắc tiếp theo:

Nguyên tắc số 1 Các đội mã hóa hệ thống thiết kế hệ thống.
Nguyên tắc số 2 Xây dựng kiến ​​trúc đơn giản nhất có thể hoạt động.
Nguyên tắc số 3 Khi nghi ngờ, hãy viết mã ra.
Nguyên tắc số 4 Họ xây dựng nó, họ kiểm tra nó.
Nguyên tắc số 5 Hệ thống càng lớn, đường băng càng dài.
Nguyên tắc # 6 Kiến trúc hệ thống là sự hợp tác vai trò.
Nguyên tắc số 7 Không có độc quyền về đổi mới.

Bài viết nói rằng hầu hết các thiết kế kiến ​​trúc được thực hiện trong giai đoạn mã hóa, và chỉ thiết kế hệ thống trước đó. Điều đó là tốt.

Vậy, thiết kế hệ thống được thực hiện như thế nào? Sử dụng UML? Hoặc một tài liệu xác định giao diện và các khối chính? Có thể là cái khác?


11
Bạn không "làm thiết kế" trong UML. Bạn thực hiện thiết kế và sau đó bạn sử dụng UML để viết nó ra hoặc truyền đạt nó.
tdammers

4
@tdammers: để chính xác, bạn cố gắng sử dụng UML để viết nó xuống và nhận thấy rằng UML là không đủ.
Doc Brown

Câu trả lời:


77

Tuyên bố miễn trừ trách nhiệm: Tôi một kiến ​​trúc sư trong một môi trường nhanh nhẹn, nhưng, như Helmuth von Moltke, Elder nói, "Không có kế hoạch chiến đấu nào sống sót khi tiếp xúc với kẻ thù". Nói cách khác, thực tiễn có nghĩa là chữ cái chính xác của hướng dẫn không thể luôn luôn được tuân theo.

Hầu hết các điểm nêu trên được theo sau là tốt nhất nhóm có thể. Tuy nhiên, nguyên tắc 1 (Các nhóm mã hóa hệ thống thiết kế hệ thống) thực sự khó theo dõi khi nhóm bao gồm hàng chục (hoặc hàng trăm) nhà phát triển phân chia trên các lục địa và múi giờ khác nhau . Điều này không liên quan gì đến kỹ năng hoặc thái độ của các nhà phát triển, hơn nữa vấn đề hậu cần của tất cả họ đều có mặt để thu thập các yêu cầu từ khách hàng và hiểu các hệ thống phức tạp hiện có.

Vậy, thiết kế hệ thống được thực hiện như thế nào? Sử dụng UML? Hoặc một tài liệu xác định giao diện và các khối chính? Có thể là cái khác?

Thông thường, kiến ​​trúc sư xác định các thành phần chính sau đó xác định các giao diện giữa chúng (bao gồm các yêu cầu không chức năng như bảo mật, tốc độ và độ tin cậy) và ủy thác thiết kế bên trong của các thành phần cho các nhóm riêng lẻ . Đây là một sự thỏa hiệp tốt giữa việc để các nhóm thiết kế các thành phần của riêng họ mà không yêu cầu mọi người biết mọi thứ về hệ thống.

Mỗi tổ chức có bộ tiêu chuẩn riêng cho thiết kế kiến ​​trúc và điều này đôi khi thay đổi từ dự án này sang dự án khác trong tổ chức. Thiết kế này được thực hiện trước khi nhóm bắt đầu mã hóa hoặc càng sớm càng tốt và thường chứa (và không phải là một danh sách đầy đủ):

  1. Yêu cầu mở rộng và định nghĩa phạm vi. Chúng bao gồm các trường hợp sử dụng hoặc câu chuyện người dùng xác định các yêu cầu kinh doanh cấp cao hơn. Cá nhân tôi thích sử dụng RFC 2119 cho các yêu cầu phi chức năng. Thiết kế dựa trên và bắt nguồn từ những điều này. Mặc dù nó có thể không phù hợp với định nghĩa chung về thiết kế, nhưng những điều này thường quan trọng không kém.
  2. Một tổng quan bao gồm một mạng lưới cấp cao hoặc sơ đồ thành phần và một trang văn bản. Điều này dành cho đối tượng rất rộng, từ quản lý cấp trên đến dev và QA. Điều này hiếm khi sử dụng UML hoặc ký hiệu được xác định do đối tượng rộng.
  3. Chi tiết cho các thành phần riêng lẻ, thường tập trung vào các giao diện hoặc API giữa chúng như đã đề cập ở trên. Các giao diện có thể được chỉ định là chữ ký phương thức trong ngôn ngữ đích với các chi tiết tiền điều kiện và hậu điều kiện. Các thành phần có thể có sơ đồ mạng, chẳng hạn như hiển thị bố cục của máy ảo trong đám mây hoặc trung tâm dữ liệu và sắp xếp mạng của chúng. Cơ sở dữ liệu quan hệ thường sẽ có sơ đồ Mối quan hệ thực thể.
  4. Một danh sách các rủi ro kiến ​​trúc và giảm thiểu của chúng, nếu biết. Giống như các yêu cầu, những điều này thể hiện quyết định thiết kế và đánh đổi.

Nói tóm lại, thiết kế của một hệ thống trong một quy trình nhanh nhẹn giống hệt như trong một quy trình thác nước truyền thống. Tuy nhiên, trong các môi trường nhanh, ít thiết kế được thực hiện trước và nhiều hơn được giao cho các nhóm thành phần . Điều quan trọng là xác định mức độ đi sâu ban đầu, quyết định trì hoãn và xác định khi nào cần đưa ra quyết định. Các quyết định tác động đến nhiều nhóm phát triển nên được đưa ra sớm hơn, đặc biệt là khả năng mở rộng và bảo mật. Các quyết định như thêm ngôn ngữ bổ sung vào một sản phẩm đã được quốc tế hóa có thể được hoãn lại cho đến khi rất muộn.

Sau khi thiết kế ban đầu được tạo ra, kiến ​​trúc sư làm việc với từng nhóm và xem xét thiết kế của họ. Nếu thiết kế bổ sung hoặc thay đổi thiết kế được yêu cầu cho một đơn vị công việc (chẳng hạn như chạy nước rút), kiến ​​trúc sư nhằm mục đích có sẵn nó vào thời điểm đơn vị công việc bắt đầu. Kiến trúc sư cũng chịu trách nhiệm truyền đạt bất kỳ thay đổi nào cho các nhóm hoặc các bên liên quan bị ảnh hưởng.


3
Đây là một câu trả lời tuyệt vời để những gì vai trò của một kiến trúc sư trong một đội Agile nên được, tuy nhiên nó thực sự không trả lời các câu hỏi về những gì các Thiết kế hệ thống là trước khi bắt đầu phát triển chạy nước rút và thực hành tốt nhất để làm điều đó.
maple_shaft

@maple_shaft Tôi đã mở rộng câu trả lời của mình để tập trung hơn vào thiết kế.
akton

3
Đối với những gì nó có giá trị, như một kiến ​​trúc sư khác, người đã làm việc trong môi trường nhanh nhẹn trong nhiều năm trong các môi trường đa quốc gia lớn, đây là điểm nổi bật.
Rex M

12

Tuyên bố miễn trừ trách nhiệm: Tôi không phải là một huấn luyện viên / kiến ​​trúc sư nhanh nhẹn - đây là những gì tôi đã thấy trong các dự án nhanh mà tôi đã làm việc và tôi nghĩ rằng nó hoạt động tốt.

Tôi không nghĩ nó được định nghĩa hoàn toàn bởi Agile về cách bạn thực hiện kiến ​​trúc - nhanh nhẹn tập trung vào các phương pháp và thực tiễn phát triển. Mặt khác, UML chỉ là một ngôn ngữ để truyền đạt kiến ​​trúc của bạn vượt ra ngoài sự nhanh nhẹn (bạn sử dụng nó nếu nó phù hợp với dự án của bạn và nhóm của bạn).

Một trong những nguyên tắc của kiến ​​trúc thực sự áp dụng, là đưa ra quyết định vào thời điểm chịu trách nhiệm cuối cùng - có nghĩa là sẽ ổn nếu bạn không đưa ra tất cả các quyết định khi bắt đầu dự án, đặc biệt là khi bạn có ít thông tin nhất ở giai đoạn này. Theo thời gian, bạn có thể đưa ra quyết định "phát triển" kiến ​​trúc. Vâng, điều này có thể trông giống như một số làm lại, nhưng điều này cũng là do thực tế là bạn đã học được những điều mới về môi trường, các yêu cầu, những gì có thể những gì không, v.v.

Điều chính mà bạn muốn tránh là sự quay vòng kiến ​​trúc - nơi mã không thực sự phù hợp với bất kỳ kiến trúc cụ thể nào và chỉ là một mớ hỗn độn. Sự khác biệt chính so với việc phát triển một kiến ​​trúc, là trong lần sau, bạn đưa ra các quyết định khó hiểu định kỳ và ghi lại chúng với các lý do rõ ràng, sau đó làm theo để đảm bảo mã của bạn tuân theo nó.


0

Khi thực hiện phát triển theo hướng kiểm tra, bạn tạo mã kiểm tra để kiểm tra các mô-đun của mình một cách cô lập (= càng độc lập với các mô-đun khác càng tốt)

Để dễ dàng tạo mã thử nghiệm, bạn giới thiệu giao diện cho các mô-đun khác có thể dễ dàng bị chế giễu.

Cách này như một mặt ảnh hưởng đến bạn tự động có được một kiến ​​trúc trong đó khớp nối giữa các mô-đun càng nhỏ càng tốt.

Theo tôi tdd cũng là công trình kiến ​​trúc.


Đúng, TDD là một công trình kiến ​​trúc, nhưng trên một thành phần phần mềm. Câu hỏi của tôi thực sự là làm thế nào kiến ​​trúc của một dự án quy mô lớn được tạo ra bằng cách sử dụng các nguyên tắc nhanh.
BЈовић
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.