Buku “Arsitektur evolusi. Dukungan untuk perubahan terus menerus "

Inilah saatnya untuk melihat kembali postulat-postulat yang tetap tidak berubah selama bertahun-tahun. Dunia yang berubah secara dinamis menentukan aturannya sendiri, termasuk dalam arsitektur komputer. Perubahan yang terjadi membutuhkan pendekatan baru, memaksa sistem yang kaku menjadi fleksibel dan beradaptasi dengan kondisi baru. Apakah perencanaan jangka panjang dimungkinkan jika semuanya terus berubah? Bagaimana mencegah kerusakan bertahap dari solusi arsitektur dari waktu ke waktu? Di sini Anda akan menemukan jawaban dan rekomendasi yang akan melindungi karakteristik paling penting dari proyek dalam konteks perubahan berkelanjutan. “Buku ini menandai tonggak penting dalam pemahaman masalah saat ini. Ketika orang menjadi sadar akan peran perangkat lunak di abad ke-21, informasi tentang bagaimana menanggapi perubahan sambil mempertahankan apa yang telah dicapai menjadi keterampilan penting dalam pengembangan perangkat lunak. " - Martin Fowler

Arsitektur Evolusi: Perangkap dan Antipattern

Kami menghabiskan banyak waktu membahas tingkat konektivitas yang tepat dalam arsitektur. Namun, kami juga hidup di dunia nyata dan mengamati banyak interkoneksi yang mengganggu kemampuan proyek untuk berkembang.

Dua praktik desain buruk yang tampak dalam proyek perangkat lunak telah diidentifikasi: perangkap dan antipattern. Banyak pengembang menggunakan kata antipatterns sebagai istilah slang "buruk," tetapi arti sebenarnya perlu diklarifikasi. Perangkat lunak antipattern terdiri dari dua bagian. Bagian pertama: antipattern adalah praktik yang awalnya tampak seperti ide yang baik, tetapi berubah menjadi kesalahan. Bagian kedua: untuk sebagian besar antipattern, ada banyak alternatif yang jauh lebih baik. Pengembang arsitektur memperhatikan banyak antipattern hanya dalam retrospeksi, sehingga sulit untuk menghindarinya. Jebakan pada pandangan pertama tampak seperti ide yang bagus, tetapi segera memanifestasikan dirinya sebagai cara yang buruk. Dalam bab ini, kita melihat perangkap dan antipattern bersama-sama.

Arsitektur teknis

Bagian ini berfokus pada praktik umum yang digunakan dalam industri, yang khususnya merugikan kemampuan tim untuk mengembangkan arsitektur.

Antipattern: Vendor King

Beberapa perusahaan besar membeli perangkat lunak Enterprise Resource Planning (ERP) untuk menyelesaikan tugas-tugas bisnis umum, seperti akuntansi, manajemen inventaris, dan operasi rutin lainnya. Ini berfungsi jika perusahaan bersedia untuk menekuk proses bisnis mereka dan solusi lain untuk menyesuaikan alat ini, dan dapat digunakan secara strategis ketika pengembang arsitektur memahami keterbatasan dan keuntungan.

Namun, banyak organisasi menjadi terlalu ambisius sehubungan dengan perangkat lunak dari kategori ini, yang mengarah ke antipemernah dari vendor vendor, yang arsitekturnya sepenuhnya didasarkan pada produk-produk pemasok, yang secara patologis mengikat organisasi ke alat ini. Perusahaan yang membeli rencana pemasok perangkat lunak untuk meningkatkan paket dengan plug-in untuk memperluas fungsionalitas dasar agar sejalan dengan bidang subjek perusahaan. Namun, untuk waktu yang lama, alat ERP tidak dapat dikonfigurasi secara memadai untuk sepenuhnya melaksanakan apa yang dibutuhkan, dan pengembang menemukan diri mereka tidak berdaya sebagai akibat dari keterbatasan alat dan karena mereka menjadikannya pusat alam semesta arsitektur. Dengan kata lain, para pengembang arsitektur membuat pemasok raja arsitektur mereka, mendikte keputusan masa depan.

Untuk menghindari antipattern, seseorang harus mempertimbangkan perangkat lunak hanya sebagai titik integrasi lain, bahkan jika awalnya memiliki berbagai tanggung jawab. Dengan asumsi integrasi pada tahap awal, lebih mudah untuk mengubah karakteristik yang tidak berguna dengan titik integrasi lainnya, menggulingkan raja dari tahta.

Dengan menempatkan alat atau platform eksternal di jantung arsitektur, pengembang telah secara signifikan membatasi kemampuan mereka untuk berkembang dalam dua arah utama, yaitu, secara teknis dan dari sudut pandang proses bisnis. Pengembang secara teknis dibatasi oleh pilihan pemasok terkait sistem penyimpanan, infrastruktur yang didukung, dan banyak pembatasan lainnya. Dari sudut pandang area subjek, alat enkapsulasi besar akhirnya menderita dari antipattern "Perangkap pada 10% terakhir". Dari sudut pandang proses bisnis, alat ini tidak dapat mendukung alur kerja yang optimal; ini adalah efek samping atau perangkap dalam 10% terakhir. Sebagian besar perusahaan ditutup dengan mengirimkan ke platform, mengganti proses, daripada mencoba menyesuaikan alat. Semakin banyak perusahaan melakukan ini, fitur yang kurang khas ada di antara perusahaan, yang hebat karena perbedaannya bukan keuntungan.

Prinsipnya mari kita berhenti bekerja dan menyebutnya sukses adalah salah satu yang biasanya dipertimbangkan pengembang ketika berhadapan dengan paket ERP di dunia nyata. Karena mereka membutuhkan investasi waktu dan uang yang signifikan, perusahaan enggan untuk menyetujui mereka ketika mereka tidak bekerja. Tidak ada departemen teknis yang mau menerima kerugian jutaan dolar, dan pemasok alat tidak mau menerima implementasi multi-layer yang buruk. Dengan demikian, masing-masing pihak setuju untuk menghentikan pekerjaan dan menyebutnya sukses dengan sebagian besar fungsi yang dijanjikan tidak terpenuhi.

Jangan mengaitkan arsitektur Anda dengan raja pemasok.

Alih-alih menjadi mangsa ke antipattern dari raja pemasok, pertimbangkan melihat produk pemasok sebagai titik integrasi lain. Perkembangan dapat mengisolasi perubahan dalam alat pemasok dari dampak arsitektur mereka dengan membangun lapisan resistensi terhadap kehancuran antara titik integrasi.

Trap: abstraksi berlubang

Semua abstraksi non-sepele sampai batas tertentu penuh dengan lubang.
- Joel Spolsky

Perangkat lunak modern bersandar pada menara abstraksi: sistem operasi, platform, dependensi, dll. Sebagai pengembang, kami membangun abstraksi sedemikian rupa sehingga kami tidak memiliki kemampuan untuk terus-menerus berpikir ketika berada di level yang lebih rendah. Jika pengembang perlu menerjemahkan angka biner yang berasal dari hard drive ke dalam teks untuk program, mereka tidak akan pernah bisa melakukan apa pun! Salah satu kemenangan perangkat lunak modern adalah seberapa baik kita dapat membangun abstraksi yang efektif.

Tetapi abstraksi itu mahal, karena tidak ada abstraksi yang sempurna, dan jika ya, itu bukan abstraksi, tetapi sesuatu yang nyata. Menurut Joel Spolsky, semua abstraksi non-sepele memiliki lubang (bocor). Ini adalah masalah bagi pengembang karena kami percaya abstraksi selalu akurat, tetapi seringkali sangat runtuh.

Meningkatnya kompleksitas tumpukan teknologi baru-baru ini mengubah abstraksi menjadi masalah yang menghancurkan. Dalam gbr. 7.1 menyajikan tumpukan teknologi khas yang berasal dari sekitar 2005.

Dalam tumpukan ini, nama vendor pada blok berubah tergantung pada kondisi lokal. Seiring waktu, ketika perangkat lunak menjadi lebih terspesialisasi, tumpukan teknologi kami menjadi lebih kompleks, seperti yang ditunjukkan pada Gambar 2. 7.2.


Seperti yang dapat dilihat pada gambar. 7.2, setiap bagian dari ekosistem perangkat lunak telah berkembang dan menjadi lebih kompleks. Karena masalah yang dihadapi pengembang menjadi semakin kompleks, demikian juga solusi mereka.

Abstraksi berlubang awal , di mana abstraksi destruktif tingkat rendah menyebabkan kekacauan yang tak terduga, adalah salah satu efek samping dari meningkatnya kompleksitas tumpukan teknologi. Bagaimana jika salah satu abstraksi pada level terendah gagal, misalnya, beberapa efek samping tak terduga dari panggilan basis data yang tampaknya tidak berbahaya? Karena ada begitu banyak lapisan, kegagalan ini akan pindah ke atas tumpukan ini, mungkin menyebabkan "metastasis" di jalurnya, memanifestasikan dirinya dalam pesan kesalahan yang tertanam dalam di UI. Debugging dan analisis retrospektif menjadi lebih sulit semakin kompleks tumpukan teknologi.

Cobalah untuk sepenuhnya memahami setidaknya satu tingkat abstraksi di bawah tingkat di mana Anda biasanya bekerja.
- Perangkat lunak Sages

Meskipun memahami lapisan di bawah ini adalah saran yang baik, menjadi semakin sulit untuk diikuti karena peranti lunaknya mengkhususkan diri dan menjadi lebih kompleks.

Meningkatkan kompleksitas tumpukan teknologi adalah contoh dari masalah keseimbangan dinamis. Tidak hanya perubahan ekosistem, tetapi bagian-bagian penyusunnya menjadi lebih kompleks dan membingungkan seiring waktu. Mekanisme yang diusulkan untuk melindungi perubahan yang berkembang, yaitu penggunaan fungsi kebugaran, dapat melindungi titik rapuh koneksi arsitektur. Arsitek mendefinisikan invarian pada titik integrasi utama, seperti fungsi kesesuaian, yang berfungsi sebagai bagian dari pipa penyebaran, memastikan bahwa abstraksi tidak mulai mengalir dengan cara yang tidak diinginkan.

»Informasi lebih lanjut tentang buku ini dapat ditemukan di situs web penerbit

Untuk habrozhitelami, diskon 20% untuk kupon - Arsitektur evolusi