Apakah ada aroma arsitektur?

Ada banyak sumber daya di web yang merujuk ke dan mencantumkan bau kode. Namun, saya belum pernah melihat informasi tentang aroma arsitektur . Apakah ini didefinisikan di suatu tempat, dan apakah ada daftar yang tersedia? Apakah ada penelitian formal yang dilakukan terhadap cacat arsitektur, dan dampaknya terhadap kecepatan proyek, cacat, dan sejenisnya?

Sunting: Saya tidak benar-benar mencari daftar di jawaban, tetapi dokumentasi (di web atau di buku) tentang bau arsitektur.

• Arsitektur Multitier Ketika Anda memiliki Layers on Layers on Layers on Layers ... Anda mengerti maksud saya di sini, dalam aplikasi Anda. Saya menyebutnya Over Layered Architecture
• Abstraksi berlebihan sedemikian rupa sehingga Anda tersesat dalam kode.
• Arsitektur Futuristik Ini terjadi ketika solusinya terlalu futuristik. Pada kenyataannya tidak ada yang bisa memprediksi persyaratan baru. Oleh karena itu sebagian besar implementasi futuristik hanyalah buang-buang waktu dan sumber daya.
• Teknologi Arsitektur Antusias Arsitek menyukai teknologi baru dan dia memproduksinya. Tanpa tahu apakah itu sudah dibuktikan sebelumnya.
• Over Kill Architecture Masalah sederhana diselesaikan oleh faktor eksponensial dari keterampilan dan teknologi arsitektur.
• Arsitektur Cloud Saya menyebutnya arsitektur cloud karena arsitektur tidak memiliki koneksi ke yang sebenarnya. Ini hanya beberapa diagram Visio yang bagus.

Kurangnya kebalikannya juga benar.

Berikut adalah tautan dari Sepuluh Kesalahan Arsitektur Perangkat Lunak .

Semuanya bisa dikonfigurasi . Ketika seorang arsitek memberi tahu Anda bahwa sistemnya tahan-perubahan atau sangat dapat disesuaikan karena konfigurasi yang luas, itu adalah aroma arsitektur.

Masalahnya adalah Anda benar-benar hanya dapat menyediakan mekanisme konfigurasi untuk apa yang menurut Anda saat ini perlu dikonfigurasikan, tetapi begitu aplikasi Anda berada di alam bebas, itu tidak akan cukup. Kemudian, mekanisme konfigurasi meluas dan meluas, dan akhirnya Anda mendapatkan Inner Platform Effect.

Dan kemudian Anda berada di neraka perangkat lunak.

Basis data yang dirancang oleh ORM! Atau backend database yang non-relasional yang harus relasional. Atau database tempat Anda mendesain untuk menggunakan tampilan yang memanggil tampilan yang memanggil tampilan, tidak hanya mereka terlalu lambat (database harus dirancang untuk kinerja sejak awal tidak lebih lambat) tetapi ketika Anda perlu melakukan perubahan, mereka mengerikan untuk dilacak. (Lebih dari abstraksi seperti yang dikatakan @AmirResaei membuatnya mudah tersesat dalam kode ketika Anda perlu memperbaiki sesuatu yang ada di bagian bawah semua lapisan itu.)

Aroma kode dan aroma arsitektur adalah satu dan sama. Kode mulai "berbau" karena arsitektur yang kurang optimal.

Dalam buku mani Martin Fowler tentang topik tersebut, Refactoring , ia menyajikan serangkaian Code Smells dan mengidentifikasi cara untuk membuatnya kembali keluar dari sistem Anda. Refactoring to Patterns dari Joshua Kerievsky lebih jauh menekankan ide ini dengan memberikan pola arsitektur khusus untuk memperbaiki berbagai bau kode (dan bagaimana cara merevisinya dengan langkah demi langkah).

Sebagian besar refactoring dilakukan untuk mengurangi kode suboptimal melalui arsitektur yang disempurnakan. Orang dapat berargumen bahwa satu-satunya "Arsitektur Bau" yang lahir secara alami (selain Big Ball of Mud), adalah Arsitektur BDUF (Big Design Up Front). Di mana Anda mencoba mengakomodasi semua yang Anda butuhkan sebelum baris kode pertama ditulis. Sebuah proyek perangkat lunak yang gesit di mana desain dilakukan sesuai kebutuhan (bahkan saya berani mengatakan di mana kode diperlakukan sebagai desain ), akan memiliki arsitektur yang tumbuh secara organik.

(Banyak) Menggabungkan -dalam bentuk apa pun- adalah yang membuat arsitektur berbau. Semakin banyak ditambah, semakin baunya.

Yang mengatakan: tidak ada kopling sama sekali sering mencium masalah kinerja.

Inilah satu bau arsitektur / desain konkret yang saya temui sepanjang waktu: analisis dan pelaporan langsung dari basis data transaksional.

Ini tentu saja OK dalam beberapa situasi (yaitu laporan ringan), tetapi dalam banyak kasus pelaporan dan persyaratan pemrosesan transaksional bertentangan. Namun, karena ini adalah hal yang sederhana / murah untuk dilakukan, laporan dijalankan langsung dari DB transaksional. Ini menyebabkan semua jenis sakit kepala di kedua sisi persamaan.

Ini biasanya terlihat di aplikasi Enterprise LOB, btw. Saya mengerti bahwa banyak UKM tidak memiliki sumber daya atau pengetahuan untuk membuat gudang dan data (lupakan tentang kubus, atau pengaturan peta-pereduksi), tetapi banyak organisasi besar yang pernah bekerja dengan saya memiliki masalah yang sama.

Ketika merancang suatu sistem, arsitek harus benar-benar menyadari bahwa pelaporan - terutama laporan analisis - dan persyaratan transaksional sebaiknya diperlakukan sebagai masalah yang terpisah dan tidak hanya disatukan di tingkat basis data.

Saya tidak yakin apakah ini selayaknya cocok di tingkat arsitektur, tetapi jika saya melihat sekelompok kelas manajer / modul dalam apa yang seharusnya menjadi desain OO maka itu adalah jaminan bahwa satu-satunya orang yang akan memahami arsitektur / desain adalah arsitek / perancang sendiri tanpa banyak penjelasan / pembelajaran oleh orang lain.

Ada banyak aroma arsitektur yang didokumentasikan oleh komunitas. Set yang biasa terjadi adalah sebagai berikut.

• Ketergantungan Cyclic: Bau ini timbul ketika dua atau lebih komponen arsitektur saling bergantung secara langsung atau tidak langsung.
• Ketergantungan yang Tidak Stabil: Bau ini timbul ketika suatu komponen bergantung pada komponen lain yang kurang stabil dari dirinya sendiri.
• Komponen Tuhan: Bau ini terjadi ketika komponen terlalu besar baik dalam hal LOC atau jumlah kelas.
• Konsentrasi Fitur: Bau ini terjadi ketika komponen menyadari lebih dari satu masalah / fitur arsitektur.
• Fungsi Terserak: Bau ini muncul ketika beberapa komponen bertanggung jawab untuk mewujudkan keprihatinan tingkat tinggi yang sama.
• Struktur Padat: Bau ini muncul ketika komponen memiliki ketergantungan yang berlebihan dan padat tanpa struktur tertentu.

Baru-baru ini saya menyiapkan taksonomi bau . Saat ini, ia mendokumentasikan 38 aroma arsitektur dan lebih dari 260 total bau kode.