Pertanyaan Aplikasi Pola Strangler Pengalaman & Pikiran


Baru-baru ini saya menemukan sebuah ide yang disebut Pola Strangler Aplikasi. Seperti yang saya pahami, ini adalah solusi untuk masalah dengan sistem warisan besar. Idenya adalah membuat aplikasi baru sekitar aplikasi lama. Biaya dan risiko ini akan jauh lebih kecil daripada penulisan ulang lengkap dari sistem. Perlahan-lahan, seiring waktu, aplikasi baru akan melakukan lebih banyak pekerjaan dan akhirnya mencekik aplikasi warisan lama. Dalam waktu yang berarti, para pengembang dapat bekerja dalam sistem baru yang bersih dengan efisiensi yang lebih tinggi dan semoga menghasilkan kode yang jauh lebih baik.

Di mana saya bekerja sekarang, kita telah sampai pada titik adalah fungsionalitas baru, bahkan hal-hal yang tampaknya sepele, membutuhkan waktu lama untuk berkembang, dengan risiko tinggi untuk memecahkan sesuatu. Kami duduk di sekitar satu juta baris kode, dengan cakupan tes unit mungkin 1-2%. Sistem ini adalah sistem SOA menggunakan layanan web (tidak benar-benar diperlukan) dan lebih prosedural dalam gaya daripada berorientasi objek. Sistem ini baik web & menang, semua ditulis dalam bahasa pemrograman .net.

Akhirnya pertanyaannya: Dalam mempertimbangkan ide / pola baru ini, saya ingin tahu apakah ada yang memiliki pengalaman menggunakan pola yang ingin mereka bagikan. Misalnya, apa cara yang baik untuk mengimplementasikannya (mengaitkan peristiwa dari aplikasi lama, misalnya)? Juga, jika ada yang memiliki pemikiran tentang hal ini, mengapa itu akan menjadi ide yang baik atau buruk, itu akan dihargai juga.

Referensi:


32
2017-07-13 10:52


asal


Jawaban:


Masalah terbesar yang harus diatasi adalah kurangnya keinginan untuk benar-benar menyelesaikan pencekikan (biasanya kemauan politik dari pemangku kepentingan non-teknis, yang dimanifestasikan sebagai kurangnya anggaran). Jika Anda tidak benar-benar mematikan sistem lama, Anda akan berakhir dengan kekacauan yang lebih buruk karena sistem Anda sekarang memiliki dua cara untuk melakukan semuanya dengan antarmuka yang canggung di antara keduanya. Belakangan, gelombang pengembang lain mungkin akan memutuskan untuk mencekik apa yang ada di sana, menulis aplikasi pencekik lain, dan sekali lagi kurangnya kemauan dapat meninggalkan sistem dalam keadaan yang lebih buruk, dengan tiga cara melakukan sesuatu.

Jika proyeknya besar, lari dari berbagai daerah, maka Anda HARUS mendapatkan konsensus global tentang seperti apa keadaan akhir negara dan bagaimana semua orang akan bekerja sama untuk mencapainya. Sementara aplikasi lama dicekik, penting bagi tim remote untuk berkomunikasi setiap hari, bekerja sama dalam pekerjaan jika memungkinkan dengan melakukan pemrograman berpasangan jarak jauh, dan menyelesaikan setiap kesalahpahaman atau ketidaksetujuan segera setelah mereka muncul. Jika tidak, ada bahaya bahwa setiap tim regional akan memutuskan untuk menulis aplikasi pencekik mereka sendiri dan mereka akan bertemu di suatu tempat di tengah dan bertempur habis-habisan, membuat sistem menjadi lebih buruk.

Apa pun yang Anda lakukan, jangan melakukan refactoring / mencekik di cabang yang berbeda dari aliran utama pembangunan. Kesulitan menggabungkan akan menjadi tidak dapat diatasi.

Saya telah melihat sistem-sistem kritis yang telah menderita kedua nasib ini, dan berakhir dengan sekitar empat atau lima "arahan arsitektur strategis" dan "arsitektur negara masa depan". Satu proyek besar multi-lokasi berakhir dengan delapan mekanisme persistensi baru yang berbeda dalam arsitektur barunya. Lain berakhir dengan dua skema database yang berbeda, satu untuk cara lama dalam melakukan sesuatu dan yang lain untuk cara baru, skema tidak pernah dihapus dari sistem dan ada juga beberapa hirarki kelas yang dipetakan ke satu atau bahkan kedua skema ini.

Akhirnya, jika Anda memperkenalkan teknologi yang baru bagi tim atau untuk mendukung / mempertahankan staf (misalnya menambahkan pesan async yang andal ke apa yang saat ini merupakan arsitektur client / server tiga-lapis sinkron), maka Anda harus memastikan bahwa ada teknisi berpengalaman memimpin proyek yang tahu bagaimana membangun sistem dengan teknologi itu, dan mendukung sistem tersebut. Dan para pemimpin teknologi tersebut harus tetap dengan proyek untuk beberapa waktu setelah aplikasi lama telah dicekik sepenuhnya. Jika tidak, arsitektur akan menurun karena pengembang yang tidak berpengalaman memodifikasinya dengan cara yang mereka ketahui tetapi tidak dengan cara yang sesuai dengan arsitektur baru.


22
2017-07-13 11:16



Risiko besar dari pola ini adalah Anda akhirnya menjalin kode lama dan kode baru untuk mendapatkan perilaku yang Anda butuhkan, terutama jika kode lama tidak pernah dirancang untuk dicekik (yaitu tidak menyajikan antarmuka yang konsisten bersih).

Pengalaman saya dengan ini adalah bahwa debugging menjadi lebih sulit seiring waktu karena tidak jelas apakah fungsionalitas bermasalah telah muncul di kode baru atau kode lama (atau masalah bersama antara keduanya).

Saya tahu Martin Fowler berbicara tentang menulis kode yang dirancang untuk dicekik, tetapi menurut saya itu hanyalah cara lain untuk mengatakan bahwa desain modular itu bagus, mmmkay; itu tidak kontroversial dan cukup jelas.


8
2017-07-13 11:00



Nama sekolah tua untuk ini adalah "pembungkus". Kedengarannya bagus; siapa yang ingin mengacaukan aplikasi lama ketika Anda dapat menulis sesuatu yang baru dan bersih untuk mengisolasinya? Masalahnya adalah itu menciptakan lapisan goo, dan itu tidak lama sebelum seseorang memutuskan bahwa bungkus itu sendiri berantakan. Apa solusi untuk ini? Bungkus lain? Seperti yang saya lihat, pembungkus dan "pencekik" semacam itu pada dasarnya berakhir sebagai pelapis lapis baja aplikasi asli dan akhirnya membuat hidup Anda lebih sulit. Tetapi orang sering memilih solusi jangka pendek yang suboptimal dalam jangka panjang. Lagi pula, tidak ada yang akan memperhatikan sampai Anda lama pergi.


4
2017-07-13 11:17



Premis dasar di balik pencekik adalah benar-benar hebat: alih-alih mencoba melakukan gaya "big bang" sekaligus pengganti sistem warisan, Anda malah membangun aplikasi pencekik dengan membuat irisan vertikal di bawah lapisan, menggantikan setiap fitur yang ada satu oleh satu sampai sistem asli dapat dinonaktifkan. Ini bekerja dengan baik, dalam teori dan dalam praktik - mungkin salah satu hal terbaik tentang itu adalah bahwa ia sangat mengurangi risiko teknologi dan membantu fokus tim untuk mengganti fitur yang paling penting. Jika sistem baru tidak berfungsi, orang hanya dapat menggunakan sistem lama.

Apa yang bisa salah?

  • Organisasi mungkin menemukan bahwa itu bisa menjadi sulit untuk menjaga jangka panjang proyek penyegaran infrastruktur yang didanai di belakang proyek-proyek baru yang menjanjikan fitur baru, keunggulan kompetitif, potensi pendapatan, atau meningkatkan pangsa pasar - terutama untuk organisasi yang fokus pada produk atau layanan. Ini adalah salah satu dari mereka segera masalah yang terlihat, dan sementara itu kambing hitam yang mudah, biasanya tidak satu-satunya ancaman.
  • Ketika sistem digantikan terlalu terhubung dengan sistem menggantikannya, ini dapat menyebabkan kesulitan teknis meningkat secara dramatis - itu mungkin OK untuk meminta mereka berbagi satu titik integrasi tertentu, tetapi lebih dari itu adalah masalah. Ketika tim menjadi terganggu oleh tantangan teknologi yang mereka ciptakan untuk diri mereka sendiri, mereka tidak bekerja lebih lama secara efektif dan garis waktu proyek keluar dari spiral kontrol.
  • Tim teknologi yang diatur secara horizontal mungkin memiliki terutama waktu yang sulit dengan Pola StranglerApplication, sebagai irisan vertikal yang diperlukan untuk menyelesaikan pekerjaan membutuhkan integrasi dengan beberapa departemen atau tim untuk diselesaikan, dan masing-masing kelompok memiliki sendiri lepaskan siklus, tujuan, dan tekanan organisasi.
  • Jika ada penggantian staf teknis atau manajemen kunci selama proyek, kadang-kadang orang-orang baru yang mewarisi proyek menemukan bahwa mereka tidak menyukai sistem baru yang lebih baik daripada sistem yang digantikannya - memimpin mereka untuk memulai berpotensi sistem ketiga.
  • Terkadang Anda mungkin berhasil sebagian, dan membuat versi baru dari sistem -tapi saat itu tiba saatnya untuk kembali dan menulis ulang sistem yang lebih rendah pentingnya untuk memulai menggunakan sistem baru, orang terlalu sibuk membuat hal-hal baru yang keren sistem baru. Sekarang Anda memiliki dua sistem. Atau, jika Anda sudah selesai ini sebelumnya, Anda akan memiliki tiga.

Semua masalah ini adalah    dikelola tentu saja. Akan sangat membantu untuk mengatur kembali tim, tetap    pemisahan bersih antara sistem, memberi perhatian khusus pada proyek    arah, dan menetapkan tujuan yang realistis di sekitar menggantikan yang ada    sistem.


4
2017-10-21 22:12



Menurut pengalaman saya, driver untuk melakukan hal ini adalah menambahkan fungsionalitas tambahan daripada mengabaikan basis kode asli. Setelah fungsionalitas baru ditambahkan, kasus bisnis langsung untuk menyelesaikan perubahan akan melemah dan momentum hilang. Tentunya ini tidak harus terjadi dan Anda harus pada rencana awal untuk menghindari hal ini.

Salam


2
2017-07-13 11:17