🤰🏻 🤯 🐠 Kami menjual Arsitektur Refactoring ke klien atau apa masalah pengembang 👩‍👦‍👦 🧕 🚰

Refactoring arsitektur atau desain selalu merupakan masalah yang menyakitkan pada suatu proyek. Manfaat refactoring jelas bagi kami spesialis teknis, tetapi seringkali sulit bagi klien untuk menjual dan mendukung gagasan ini. Alasan utamanya adalah karena kami para spesialis teknis tidak tahu cara berbicara dengan bisnis.

gambar

Masalah utama adalah komunikasi antara teknisi dan orang-orang yang menghasilkan uang. Mereka berbicara bahasa yang berbeda, meskipun mereka mencoba untuk menyelesaikan masalah yang sama.

Artikel ini adalah terjemahan dari aslinya dari Bahasa Inggris: Arsitektur Refactoring dan Desain Refactoring Cara Menjualnya Klien . Jika Anda memiliki kolega yang tidak bisa berbahasa Rusia, mereka bisa membaca yang asli di bulg saya.

Manfaat refactoring jelas bagi semua profesional teknis, tetapi seringkali kita tidak dapat menyampaikan ide ini kepada bisnis. Mengapa ini terjadi? Kami melewati beberapa langkah kecil namun sangat penting untuk bisnis ini.

Kami membagi seluruh proses menjadi 6 langkah sederhana namun perlu:

Tentukan penyebab masalahnya.
Putuskan perubahan apa yang perlu dilakukan.
Pembenaran keputusan
Buat rencana refactoring
Buat peta jalan
Sajikan keputusan Anda

Temukan penyebab masalahnya

Langkah ini cukup akrab bagi kami sebagai spesialis teknis. Pertimbangkan itu dengan contoh nyata.

Bangunan macet setelah hampir setiap komit.

Ada beberapa alasan mengapa ini bisa terjadi:

Komponen aplikasi sangat erat terkait dan saling tergantung satu sama lain
Komponen aplikasi tidak memiliki isolasi yang tepat
Kurangnya unit test
Kurangnya proses SDLC dan CI / CD

Satu lagi contoh. Penerapan aplikasi membutuhkan waktu lama, dan masalah kinerja juga diamati.

Alasan utama mungkin:

Aplikasi monolitik tumbuh cepat dan menjadi terlalu besar untuk satu aplikasi
Aplikasi ini besar dan mengkonsumsi banyak RAM dan kekuatan prosesor.
Aplikasi ini rumit dan tidak ditulis dengan baik

Putuskan perubahan apa yang perlu dilakukan.

Langkah selanjutnya sedikit lebih rumit, tetapi masih akrab dan tidak rumit untuk + pengembang senior. Kita semua ahli teknis yang baik dan selalu tahu apa yang perlu ditingkatkan. Dan pada saat ini kami membuat kesalahan dan lari ke klien dengan kata-kata mari kita lakukan .

Tapi kami adalah arsitek yang cerdas dan kami akan mengikuti rencana kami 6 langkah langkah demi langkah.

Berdasarkan contoh sebelumnya dengan aplikasi monolitik, solusinya jelas. Pecahkan aplikasi yang besar dan kompleks menjadi modul yang lebih kecil dan independen. Ini adalah langkah pertama menuju arsitektur berorientasi layanan atau layanan mikro.

gambar

Pembenaran keputusan

Kami akan membagi langkah ini menjadi dua fase: pembenaran teknis dan bisnis .

Alasan teknis tampaknya logis bagi kami. Pecahkan monolit menjadi layanan yang lebih kecil, yang hasilnya kami dapatkan:

Komponen yang lebih berbeda
Masalah build tidak akan terlalu sering
Layanan kecil mengkonsumsi lebih sedikit RAM dan daya prosesor, sebagai hasilnya - kinerja yang lebih baik
Layanan terpisah dapat digunakan lebih cepat dan independen satu sama lain

Pembenaran dari sudut pandang bisnis adalah langkah yang sangat penting yang sering dilupakan oleh para pakar teknis. Anda harus ingat apa yang penting untuk bisnis. Benar - itu uang .

Singkatnya: jika refactoring tidak menguntungkan bisnis - tidak masuk akal untuk melakukannya.

Berdasarkan contoh kami, Anda dapat menawarkan klien manfaat berikut:

Fitur baru akan dikembangkan lebih cepat
Kualitas aplikasi akan lebih baik, sebagai akibat dari biaya yang lebih rendah untuk perbaikan bug dan pengguna aplikasi yang puas, yang juga secara positif mempengaruhi bisnis
Mengurangi biaya pengembangan dan penyebaran
Lebih mudah untuk menemukan profesional yang termotivasi dan berpengalaman yang siap untuk bekerja dengan proyek ini.

Rencana refactoring

Rencana harus jelas dan terperinci. Setiap iterasi harus dijelaskan dengan jelas dan semua perubahan arsitektur dan desain harus didokumentasikan.

gambar

Buat paket Anda, Anda harus menjawab pertanyaan-pertanyaan berikut:

Apa tujuan dari iterasi ini?
Berapa nilai teknis dan bisnis dari iterasi ini?
Bagaimana cara mempersingkat waktu iterasi?

Peta jalan

Langkah yang sangat penting . Luangkan waktu untuk melakukan ini jika Anda benar-benar ingin menjual refactoring ke bisnis.

Setiap manajer dan pebisnis ingin mengetahui jawaban atas dua pertanyaan:

Berapa harganya?
Itu akan makan waktu berapa lama?

Cobalah untuk memecah refactoring menjadi iterasi kecil. Setiap iterasi harus membawa nilai teknis dan bisnis. Cukup sulit untuk menjual refactoring selama bertahun-tahun dan menelan biaya jutaan dolar tanpa hasil antara.

Setiap iterasi harus berisi informasi tentang durasi dan jumlah spesialis yang diperlukan untuk ini. Informasi ini akan membantu manajer menjawab dua pertanyaan dasar yang ditanyakan sedikit lebih tinggi.

Kumpulkan metrik proyek sebelum dan sesudah refactoring di setiap iterasi. Ini akan membantu Anda menunjukkan nilai teknis dan bisnis yang dibawa oleh iterasi ini.

Saya mempresentasikan keputusan saya

Sebelum Anda pergi dengan keputusan Anda ke bisnis, tanyakan kepada manajer langsung Anda. Tampak samping selalu baik, terutama jika itu merupakan tampilan sisi bisnis. Mungkin manajer Anda memiliki lebih banyak konteks dan akan membantu Anda mengubah rencana sesuai dengan harapan bisnis.

Anda perlu tahu bagaimana menjawab pertanyaan klasik.

Biasanya ketika Anda menyajikan refactoring arsitektur, sebuah bisnis mungkin bertanya. Mengapa kita perlu refactoring? Tahun lalu kami menghabiskan cukup uang untuk arsitektur, dan sekarang kami memiliki masalah lagi.

Ada jawaban klasik untuk pertanyaan klasik. Solusi arsitektur ini bagus setahun yang lalu, tetapi bisnis tumbuh dan berubah, dan arsitektur harus berubah dengannya.

Kiat nomor 2. Jangan membuat klien Anda panik. Berikan informasi sebagai hal yang mendesak, tetapi bukan sebagai bencana. Katakan bahwa Anda memiliki enam bulan untuk refactor, tetapi Anda harus memulainya hari ini.

Akhirnya . Saat mempresentasikan keputusan Anda, cobalah untuk mendidik orang, bukan menyalahkan. Ingatlah bahwa ketika menyalahkan orang, Anda akan menghadapi perlawanan dari mereka. Anda harus mencari cara untuk menyelesaikan masalah, bukan penyebabnya.

Akhirnya

Refactoring mahal dan sulit dijual ke bisnis
Refactoring arsitektur bukan hanya masalah teknis, masih perlu dijual ke bisnis
Ingat manfaat refactoring untuk bisnis Anda.
Itu selalu lebih mudah untuk menjual refactoring kecil, tetapi sering daripada besar, tetapi sekali

Anda dapat menemukan lebih banyak artikel tentang arsitektur dan soft skill arsitektur pada sumber asli.

Refactoring yang bagus untuk semua orang!

Kami menjual Arsitektur Refactoring ke klien atau apa masalah pengembang