Apakah "arsitektur perangkat lunak evolusi" merupakan kontradiksi?

Dalam pemahaman saya, arsitektur evolusioner bermuara pada membuat arsitektur mudah dimodifikasi. Sekarang arsitektur sering didefinisikan sebagai hal-hal yang harus Anda dapatkan sejak dini karena mereka akan sulit diubah nantinya.

Bagaimana ini cocok? Apakah ada perbedaan antara arsitektur evolusioner dan hanya meminimalkan jumlah arsitektur?

— Frank Puffer
sumber

"Arsitektur sering didefinisikan sebagai hal-hal yang harus Anda dapatkan sejak dini karena mereka akan sulit diubah nanti." KECUALI Anda berharap mereka berubah. Itu membuat perbedaan besar dan memberi ruang bagi evolusi di masa depan.

— Tomasz Maciejewski

Saya setuju itu adalah kontradiksi dalam hal, jika Anda mendefinisikan arsitektur sebagai "segala sesuatu yang mahal untuk diubah kemudian", yang merupakan definisi terbaik yang saya dengar sampai saat ini. Saya tidak setuju dengan "Anda harus memperbaikinya lebih awal", definisi ini adalah alasan mengapa seseorang harus menunda keputusan arsitektur selama mungkin (agar mereka dapat memperoleh informasi sebanyak mungkin).

— Martin Maat

Jawaban:

Intisari Neal Ford tentang Arsitektur Evolusi dapat ditemukan di sini.

Parafrase:

Arsitektur adalah keputusan yang Anda harapkan dapat Anda lakukan sejak dini dalam suatu proyek, hal-hal yang orang anggap sulit untuk diubah. Tetapi bagaimana jika kita membangun arsitektur yang mengharapkan perubahan?

Arsitektur evolusioner mendukung perubahan bertahap dan terarah sebagai prinsip pertama melintasi berbagai dimensi.

Dia melanjutkan untuk menggambarkan skenario arsitektur yang berbeda, dimulai dengan Big Ball of Mud, arsitektur berlapis, microkernels dan REST, dan memuncak dalam microservices, yang katanya memiliki n dimensi kemampuan evolusi (di mana n adalah sejumlah layanan microser berbeda).

Menurut Ford, arsitektur evolusi:

Sangat longgar dan sangat kohesif ,
Komposable; komponen dapat dirakit untuk membuat arsitektur baru,
Dapat diubah secara bertahap, tanpa memerlukan perombakan arsitektur.

Anda dapat menganggap Arsitektur Evolusi sebagai meta-arsitektur, jika Anda suka; sebuah arsitektur arsitektur. Panduan yang menentukan prinsip-prinsip desain yang mempromosikan benda-benda casting di tanah daripada batu.

— Robert Harvey
sumber

Saya setuju bahwa menempatkan kata "evolusioner" di depan kata "arsitektur" berarti bahwa itu bukan "arsitektur" dalam pengertian "tradisional".

— Robert Harvey

Saya bisa lebih mudah menganggapnya sebagai memberi nama baru untuk hal-hal lama yang sama. Setiap metodologi perangkat lunak yang saya ingat telah mengklaim kemampuan beradaptasi untuk berubah sebagai salah satu kualitasnya. Jika ini unik, itu terutama dalam memberikan detail bahkan kurang dari yang lain tentang bagaimana mencapai itu.

— Jerry Coffin

@ Euphoric: Itu tidak sesuai dengan apa (misalnya) yang dikatakan Hoare dan Dijkstra ketika pemrograman terstruktur adalah baru, atau apa yang dikatakan Booch, Meyer, dll., Ketika OOP masih baru, dll. Sebaliknya: kebanyakan menganjurkan bahwa sebagian besar apa yang akan Anda lakukan adalah membuat potongan-potongan kecil yang dapat digunakan kembali, sehingga sebagian besar perubahan terbatas pada arsitektur. Anda akan memiliki potongan-potongan kecil yang bagus yang dapat dengan mudah Anda gunakan kembali dengan cara yang berbeda, karena arsitekturnya akan berubah.

— Jerry Coffin

@ Euphoric: Saya akan mengatakan sebaliknya: pemrograman terstruktur dan OOP (untuk dua contoh) sebagian besar memang memenuhi janji mereka. Lebih sulit untuk mengatakan banyak tentang yang satu ini - saya tidak mengharapkan banyak detail dalam nada utama, tapi setidaknya begitu saja, sepertinya lebih banyak hype dan lebih sedikit substansi daripada kebanyakan pendahulu.

— Jerry Coffin

@ Euphoric: sebagian besar, ya, benar. Banyak dari apa yang rutin hari ini akan jauh lebih mungkin gagal menggunakan metode yang lebih tua. Saya telah terlibat dalam membangun beberapa sistem yang hampir tidak dapat saya bayangkan coba lakukan dengan metode yang lebih lama (walaupun ya, saya kira itu mungkin terjadi). Sejauh membaca buku itu, ya, saya mungkin akan - tetapi belum.

— Jerry Coffin

Ya, itu adalah kontradiksi jika Anda membuat segalanya mudah untuk berubah tanpa pandang bulu. Jika Anda harus menambahkan kode untuk membuat sesuatu "lebih mudah untuk diubah" (dengan "lebih mudah" didefinisikan dengan buruk, seperti di sini), maka Anda telah membuatnya lebih sulit untuk diubah, hanya karena Anda menambahkan kode. Di sisi lain, jika Anda tahu persis apa yang akan berubah, yang sangat tidak mungkin, kode tambahan tidak boleh dipandang sebagai kompleksitas yang tidak perlu.

Membuat hal-hal "mudah diubah" mungkin merupakan alasan utama mengapa banyak perangkat lunak modern menjadi begitu kembung dan sulit untuk diubah.

— Frank Hileman
sumber

Sangat benar, tetapi tidak benar-benar menjawab pertanyaan saya.

— Frank Puffer

Hmm jawaban untuk pertanyaan Anda adalah "Ya".

— Frank Hileman