Kiến trúc phần mềm tiến hóa có phải là một mâu thuẫn không?

Theo hiểu biết của tôi, kiến trúc tiến hóa sôi sục để làm cho kiến trúc dễ sửa đổi. Bây giờ kiến trúc thường được định nghĩa là những thứ mà bạn nên có ngay vì chúng sẽ khó thay đổi sau này.

Làm thế nào để điều này phù hợp với nhau? Có sự khác biệt nào giữa kiến trúc tiến hóa và đơn giản là giảm thiểu lượng kiến trúc không?

— Frank Puffer
nguồn

"kiến trúc thường được định nghĩa là những thứ mà bạn nên có ngay vì chúng sẽ khó thay đổi sau này." UNLESS bạn mong đợi họ thay đổi. Điều đó tạo ra một sự khác biệt rất lớn và mang lại không gian cho sự tiến hóa trong tương lai.

— Tomasz Maciejewski

Tôi đồng ý rằng đó là một mâu thuẫn trong điều khoản, nếu bạn định nghĩa kiến trúc là "mọi thứ đắt đỏ để thay đổi sau này", đó là định nghĩa tốt nhất tôi đã nghe cho đến ngày nay. Mặc dù vậy, tôi không đồng ý với "bạn nên làm cho đúng", định nghĩa này là lý do khiến người ta phải hoãn các quyết định kiến trúc càng lâu càng tốt (để chúng trở nên thông tin nhất có thể).

— Martin Maat

Câu trả lời:

Bài phát biểu của Neal Ford về Kiến trúc tiến hóa có thể được tìm thấy ở đây.

Diễn giải:

Kiến trúc là những quyết định mà bạn mong muốn bạn có thể nhận được ngay từ sớm trong một dự án, những điều mà mọi người cho là khó thay đổi. Nhưng điều gì sẽ xảy ra nếu chúng ta xây dựng các kiến trúc mong đợi sự thay đổi?

Một kiến trúc tiến hóa hỗ trợ thay đổi gia tăng, có hướng dẫn như một nguyên tắc đầu tiên trên nhiều chiều.

Ông tiếp tục mô tả các kịch bản kiến trúc khác nhau, bắt đầu với Big Ball of Mud, kiến trúc phân lớp, microkernels và REST, và đỉnh cao là các dịch vụ siêu nhỏ, theo ông có n chiều của khả năng tiến hóa (trong đó n là số lượng dịch vụ siêu nhỏ riêng biệt).

Theo Ford, kiến trúc tiến hóa:

Được kết nối lỏng lẻo và gắn kết cao ,
Có thể ghép lại được; các thành phần có thể được lắp ráp để tạo ra kiến trúc mới,
Có thể được thay đổi tăng dần, mà không cần phải đại tu kiến trúc.

Bạn có thể nghĩ Kiến trúc tiến hóa như một kiến trúc meta, nếu bạn thích; một kiến trúc của kiến trúc. Hướng dẫn chỉ đạo các nguyên tắc thiết kế thúc đẩy đúc mọi thứ bằng đất sét thay vì đá.

— Robert Harvey
nguồn

Tôi đồng ý rằng việc đặt từ "tiến hóa" trước từ "kiến trúc" có nghĩa là nó không phải là "kiến trúc" theo nghĩa "truyền thống".

— Robert Harvey

Tôi có thể dễ dàng nghĩ về nó như đặt một cái tên mới cho cùng một thứ cũ. Mọi phương pháp phần mềm tôi có thể nhớ đã khẳng định khả năng thích ứng để thay đổi là một trong những phẩm chất của nó. Nếu điều này là duy nhất, thì chủ yếu là cung cấp ít chi tiết hơn những người khác về cách đạt được điều đó.

— Jerry Coffin

@Euphoric: Điều đó không phù hợp với những gì (ví dụ) Hoare và Dijkstra đã nói khi lập trình có cấu trúc là mới, cũng như những gì Booch, Meyer, v.v., đã nói khi OOP mới, v.v ... Ngược lại: hầu hết đều ủng hộ những gì bạn làm là tạo ra những mảnh nhỏ có thể tái sử dụng, do đó, hầu hết các thay đổi bị giới hạn trong kiến trúc. Bạn sẽ có những mảnh nhỏ đẹp mà bạn có thể dễ dàng sử dụng lại theo những cách khác nhau, bởi vì kiến trúc sẽ thay đổi.

— Jerry Coffin

@Euphoric: Tôi muốn nói ngược lại: lập trình có cấu trúc và OOP (cho hai ví dụ) chủ yếu thực hiện theo lời hứa của họ. Thật khó để nói nhiều về điều này - tôi không mong đợi nhiều chi tiết trong một ghi chú quan trọng, nhưng ít nhất là ngoài ý muốn, nó trông giống như cường điệu hơn và ít chất hơn so với hầu hết các phiên bản trước.

— Jerry Coffin

@Euphoric: ở một mức độ lớn, vâng, họ đã làm. Phần lớn những gì thường lệ ngày nay sẽ có nhiều khả năng thất bại khi sử dụng các phương pháp cũ hơn. Tôi đã tham gia xây dựng một vài hệ thống mà tôi khó có thể tưởng tượng được khi thực hiện với các phương pháp cũ hơn (mặc dù có, tôi cho rằng điều đó sẽ có thể xảy ra). Theo như đọc cuốn sách, có, tôi có thể sẽ - nhưng chưa.

— Jerry Coffin

Vâng, đó là một mâu thuẫn nếu bạn đang làm cho mọi thứ dễ dàng thay đổi một cách bừa bãi. Nếu bạn phải thêm mã để làm cho một cái gì đó "dễ thay đổi" hơn (với "dễ dàng hơn" được xác định kém, như ở đây), thì bạn đã làm cho nó khó thay đổi hơn, đơn giản chỉ vì bạn đã thêm mã. Mặt khác, nếu bạn biết chính xác điều gì sẽ thay đổi, điều rất khó xảy ra, mã bổ sung không nên được xem là sự phức tạp không cần thiết.

Làm cho mọi thứ "dễ thay đổi" có lẽ là lý do chính khiến nhiều phần mềm hiện đại trở nên quá khó khăn và khó thay đổi.

— Frank Hileman
nguồn

Rất đúng, nhưng không thực sự trả lời câu hỏi của tôi.

— Frank Puffer

Hmm câu trả lời cho câu hỏi của bạn là "Có".

— Frank Hileman