Có mùi kiến ​​trúc?

Có hàng tấn tài nguyên trên web đề cập đến và liệt kê mùi mã. Tuy nhiên, tôi chưa bao giờ thấy thông tin về mùi kiến ​​trúc . Điều này được xác định ở đâu đó, và có một danh sách có sẵn? Đã có nghiên cứu chính thức nào được thực hiện về các khiếm khuyết kiến ​​trúc, và tác động của chúng đối với tốc độ dự án, các khiếm khuyết và tương tự?

Chỉnh sửa: Tôi không thực sự tìm kiếm một danh sách trong các câu trả lời, nhưng tài liệu (trên web hoặc trong một cuốn sách) về mùi kiến ​​trúc.

• Kiến trúc đa nhiệm Khi bạn có Lớp trên Lớp trên Lớp trên lớp ... bạn sẽ thấy quan điểm của tôi ở đây, trong ứng dụng của bạn. Tôi gọi nó là Kiến trúc nhiều lớp
• Quá trừu tượng theo cách mà bạn bị lạc trong mã.
• Kiến trúc tương lai Điều này xảy ra khi giải pháp quá tương lai. Trong thực tế không ai có thể dự đoán các yêu cầu mới. Do đó, hầu hết việc thực hiện tương lai chỉ là lãng phí thời gian và tài nguyên.
• Kiến trúc nhiệt tình về công nghệ Kiến trúc sư thích công nghệ mới và ông đã đưa vào sản xuất. Mà không biết nếu nó đã được chứng minh trước đó.
• Over Kill Architecture Một vấn đề đơn giản đã được giải quyết bằng yếu tố hàm mũ của kỹ năng và công nghệ kiến ​​trúc.
• Kiến trúc đám mây Tôi gọi nó là kiến ​​trúc đám mây vì kiến ​​trúc không có kết nối với thực sự. Nó chỉ là một số sơ đồ Visio đẹp.

Việc thiếu hoàn toàn ngược lại cũng đúng.

Đây là liên kết của Mười lỗi kiến ​​trúc phần mềm hàng đầu .

Mọi thứ đều có thể cấu hình . Khi một kiến ​​trúc sư nói với bạn rằng hệ thống của anh ta có khả năng thay đổi hoặc tùy biến cao vì khả năng cấu hình rộng, đó là mùi kiến ​​trúc.

Vấn đề là bạn thực sự chỉ có thể cung cấp các cơ chế cấu hình cho những gì bạn nghĩ ngay bây giờ sẽ cần phải được cấu hình, nhưng một khi ứng dụng của bạn không hoạt động, nó sẽ không đủ. Sau đó, các cơ chế cấu hình mở rộng và mở rộng, và cuối cùng bạn có được Hiệu ứng nền tảng bên trong.

Và sau đó bạn đang ở trong địa ngục phần mềm.

Một cơ sở dữ liệu được thiết kế bởi ORM! Hoặc một phụ trợ cơ sở dữ liệu không liên quan nên có quan hệ. Hoặc cơ sở dữ liệu nơi bạn thiết kế để sử dụng các chế độ xem gọi chế độ xem gọi chế độ xem, không chỉ chúng quá chậm (cơ sở dữ liệu phải được thiết kế để thực hiện ngay từ đầu) mà khi bạn cần thay đổi, chúng rất kinh khủng để theo dõi (Quá trừu tượng như @AmirResaei đã nói giúp dễ bị lạc trong mã khi bạn cần sửa một cái gì đó ở dưới cùng của tất cả các lớp đó.)

Mùi mã và mùi kiến ​​trúc là một và giống nhau. Mã bắt đầu "ngửi" vì kiến ​​trúc không tối ưu.

Trong cuốn sách bán kết của Martin Fowler về chủ đề Tái cấu trúc , ông trình bày một loạt các Mùi Mã và xác định cách để tái cấu trúc chúng ra khỏi hệ thống của bạn. Tái cấu trúc các mẫu của Joshua Kerievsky nhấn mạnh thêm ý tưởng này bằng cách đưa ra các mẫu kiến ​​trúc cụ thể để sửa các mùi mã khác nhau (và cách tái cấu trúc cho chúng từng bước).

Hầu hết tái cấu trúc được thực hiện để giảm bớt mã tối ưu thông qua kiến ​​trúc nâng cao. Người ta có thể lập luận rằng "Mùi kiến ​​trúc" tự nhiên duy nhất (không phải là Big Ball of Mud), sẽ là Kiến trúc của BDUF (Thiết kế lớn phía trước). Nơi bạn cố gắng đáp ứng mọi thứ bạn cần trước khi dòng mã đầu tiên được viết. Một dự án phần mềm nhanh, trong đó thiết kế được thực hiện khi cần thiết (ngay cả tôi dám khẳng định nơi mã được coi là thiết kế ), sẽ có kiến ​​trúc của nó phát triển một cách hữu cơ.

(Rất nhiều) Khớp nối - trong bất kỳ hình thức nào - là những gì làm cho kiến ​​trúc có mùi. Càng ghép nối, nó càng có mùi.

Điều đó nói rằng: không có khớp nối nào thường có mùi vấn đề hiệu suất.

Đây là một mùi kiến ​​trúc / thiết kế cụ thể mà tôi gặp phải mọi lúc: phân tích và báo cáo trực tiếp từ cơ sở dữ liệu giao dịch.

Điều này chắc chắn là ổn trong một số tình huống (ví dụ như báo cáo nhẹ), nhưng trong nhiều trường hợp, yêu cầu xử lý giao dịch và báo cáo bị xung đột. Tuy nhiên, vì đó là điều đơn giản / rẻ tiền để làm, các báo cáo được chạy trực tiếp từ DB giao dịch. Điều này gây ra tất cả các loại đau đầu ở cả hai phía của phương trình.

Điều này thường thấy trong các ứng dụng Enterprise LOB, btw. Tôi hiểu rằng nhiều SMB không có tài nguyên hoặc bí quyết để tạo kho và bảng dữ liệu (quên các hình khối hoặc thiết lập giảm bản đồ), nhưng nhiều tổ chức lớn hơn mà tôi đã làm việc có cùng một vấn đề.

Khi thiết kế một hệ thống, kiến ​​trúc sư thực sự cần lưu ý rằng báo cáo - đặc biệt là báo cáo phân tích - và các yêu cầu giao dịch được coi là vấn đề riêng biệt và không chỉ gộp lại ở cấp cơ sở dữ liệu.

Tôi không chắc liệu điều này có phù hợp ở cấp độ kiến ​​trúc hay không, nhưng nếu tôi thấy một loạt các lớp / mô đun quản lý trong cái được cho là thiết kế OO thì đó là một đảm bảo rằng người duy nhất sẽ hiểu kiến ​​trúc / thiết kế là kiến ​​trúc sư / nhà thiết kế mà không có nhiều lời giải thích / học hỏi của người khác.

Có rất nhiều mùi kiến ​​trúc được ghi nhận bởi cộng đồng. Một bộ thường xảy ra là sau đây.

• Sự phụ thuộc theo chu kỳ: Mùi này phát sinh khi hai hoặc nhiều thành phần kiến ​​trúc phụ thuộc lẫn nhau trực tiếp hoặc gián tiếp.
• Sự phụ thuộc không ổn định: Mùi này phát sinh khi một thành phần phụ thuộc vào các thành phần khác kém ổn định hơn chính nó.
• Thành phần Thần: Mùi này xảy ra khi một thành phần quá lớn hoặc theo thuật ngữ LỘC hoặc số lượng các lớp.
• Nồng độ tính năng: Mùi này xảy ra khi một thành phần nhận ra nhiều hơn một mối quan tâm / tính năng kiến ​​trúc.
• Chức năng phân tán: Mùi này phát sinh khi nhiều thành phần chịu trách nhiệm nhận ra mối quan tâm cấp cao tương tự.
• Cấu trúc dày đặc: Mùi này phát sinh khi các thành phần có sự phụ thuộc quá mức và dày đặc mà không có bất kỳ cấu trúc cụ thể.

Gần đây tôi đã chuẩn bị một nguyên tắc phân loại mùi . Hiện tại, tài liệu này có 38 mùi kiến ​​trúc và hơn 260 mã tổng mùi.