Cara refactor untuk Startups 2022: alasan dan pengorbanan

(Diposting silang dari situs web Klotho )

Posting blog ini adalah ikhtisar tingkat tinggi tentang alasan untuk memperbaiki kode dan sistem dalam pengaturan startup. Kami mencakup risiko, pendekatan, dan pengorbanan untuk dipertimbangkan pada tahun 2022.

Bagaimana menilai kapan biayanya sepadan dengan keuntungannya

Jujurlah pada dirimu sendiri

Godaan akan selalu untuk refactor: kode dunia nyata itu berantakan, dan para insinyur tidak suka kode yang berantakan. Pastikan ada kasus bisnis untuk pemfaktoran ulang dengan mengukur berapa banyak waktu yang dihabiskan tim untuk fitur yang terlihat langsung oleh pelanggan.

Riset kami menunjukkan bahwa perusahaan menengah dan startup yang berkembang pesat menghabiskan 39% kapasitas teknis untuk pekerjaan yang tidak berbeda, seperti infrastruktur. Pisahkan cerita menjadi sub-tugas seperti infrastruktur dan pemfaktoran ulang sehingga Anda dapat mengukur ke mana perginya waktu Anda.

Terstruktur dengan baik terpelihara dengan baik

Batasan yang jelas antar modul membuatnya lebih mudah untuk diuji, diterapkan, dan dipantau. Awasi bug yang dilaporkan pelanggan, latensi layanan, dan seberapa sering Anda harus mengembalikan kode. Di ujung lain dari siklus hidup perangkat lunak, ada beberapa indikator yang Anda arahkan menuju kemacetan: berapa banyak waktu yang diperlukan untuk beralih dari desain ke pengiriman, tingkat kepuasan teknik dan peningkatan biaya infrastruktur — ini semua bisa menjadi indikator utama bahwa Anda telah membangun utang.

Titik belok dalam bisnis

Basis kode cenderung mengatur dirinya sendiri dalam tiga dimensi: ukuran tim, kecepatan fitur baru, dan jumlah pelanggan. Ketika angka-angka ini berubah secara signifikan, mungkin sudah waktunya untuk melihat pemisahan komponen.

Jika Anda mengembangkan tim atau meningkatkan laju pengembangan fitur, faktor pembatasnya adalah keterbacaan kode. Mulailah dengan refactoring oportunistik yang ditargetkan. Jika basis pelanggan Anda berkembang, Anda mungkin memerlukan lebih banyak teknologi atau alur kerja yang dapat diskalakan.

Kendalikan apa yang Anda bisa, rencanakan sisanya

Memilih dengan benar tidak akan mencegah perancangan ulang

Refactoring dan re-arsitektur tidak berarti Anda membuat pilihan yang buruk sebelumnya. Lebih sering, kekuatan pendorong di balik arsitektur ulang terkait dengan perubahan persyaratan atau faktor eksternal. Setidaknya ada 4 dimensi signifikan yang akan memaksa re-arsitektur selama masa pakai produk: tingkat pengembangan fitur baru, ukuran tim teknik, jumlah waktu yang dihabiskan untuk pekerjaan yang tidak terdiferensiasi, dan pertumbuhan pelanggan. Masing-masing semakin sulit untuk dikendalikan secara langsung.

Mulailah dengan panggilan mudah…

Dalam empat dimensi, dua yang paling mudah dikendalikan adalah tingkat fitur baru dan ukuran tim teknik. Anda dapat mengontrol kecepatan fitur baru dengan memperketat perencanaan dan prioritas. Menskalakan tim adalah proses yang lebih lambat, tetapi biasanya ini adalah proses yang setidaknya dapat Anda rencanakan.

Jika tim dan tingkat fitur baru kecil, pemfaktoran ulang kemungkinan tidak akan berdampak signifikan pada bisnis. Di ujung lain spektrum, tim besar yang mengerjakan banyak fitur mungkin mendapat manfaat dari pengaturan ulang menjadi tim yang lebih kecil — dan Anda harus mempertimbangkan pemfaktoran ulang atau arsitektur ulang kode agar sesuai. Arsitektur yang memungkinkan batasan organisasi dan kode yang lebih bersih akan memungkinkan produk dan perusahaan untuk berkembang.

…dan kemudian beralih ke yang lebih sulit

Jumlah waktu yang dihabiskan tim Anda untuk pekerjaan yang tidak berbeda mungkin sulit dikendalikan, dan pertumbuhan pelanggan adalah ukuran yang paling sulit untuk dipengaruhi. Jika ini mudah, semua orang akan meminimalkan pekerjaan yang tidak terdiferensiasi dan memaksimalkan pertumbuhan pelanggan! Tetap saja, Anda bisa

mengatasi masalah dengan pendekatan yang hati-hati dan proaktif untuk refactoring.

Langkah pertama adalah mengetahui kapan tidak melakukan refactor. Jika pertumbuhan pelanggan Anda dan jumlah waktu yang dihabiskan untuk pekerjaan yang tidak terdiferensiasi rendah, jangan habiskan waktu untuk melakukan pemfaktoran ulang: fokuslah pada fitur yang berdampak dan terlihat oleh pelanggan. Demikian pula, jika Anda memiliki pertumbuhan pelanggan yang baik dan jumlah pekerjaan yang tidak terdiferensiasi rendah, tim Anda bekerja dengan baik. Pertimbangkan pemfaktoran ulang taktis untuk menghindari bertambahnya jumlah pekerjaan yang tidak terdiferensiasi, tetapi jangan menghabiskan terlalu banyak waktu untuk itu.

Jika tim Anda menghabiskan terlalu banyak waktu untuk pekerjaan yang tidak berbeda, inilah waktunya untuk meninjau kembali arsitektur ke arsitektur yang lebih baik untuk skala perusahaan Anda saat ini.

Jika adopsi pelanggan Anda lebih rendah, prioritas Anda haruslah arsitektur yang lebih murah yang akan memberi Anda lebih banyak landasan pacu.
Jika adopsi pelanggan Anda dan jumlah waktu yang dihabiskan tim Anda untuk pekerjaan yang tidak terdiferensiasi tinggi, mungkin sudah waktunya untuk fokus pada solusi terpusat dan dioptimalkan. Ini biasanya berbentuk tim operasi khusus yang dapat mengeksekusi tugas infrastruktur secara efisien. Ini adalah masalah besar yang harus dimiliki — jadi luangkan waktu sejenak untuk memberi selamat kepada diri sendiri dan tim Anda karena telah sampai di sini!

Miliki target, lalu cari jalan pintas untuk mencapainya

Miliki rencana, meskipun itu tidak sempurna

Setelah Anda berkomitmen pada arsitektur ulang, jangan takut untuk berpikir besar. Bersandarlah pada teknisi Anda untuk menghasilkan kondisi akhir yang mereka sukai, lalu kurangi sesuai kebutuhan. Kemungkinan besar, kesempatan untuk melakukan re-arsitektur besar-besaran hanya akan datang sekali atau dua kali dalam siklus hidup produk, jadi bersiaplah untuk hidup dengan kompromi apa pun yang Anda buat. Tetapi dengan cara yang sama, ketahuilah bahwa bahkan rencana terbaik pun akan serba salah saat Anda mulai menerapkan.

Buat rencana besar, ambil langkah kecil

Setelah Anda tahu di mana Anda ingin kode itu berada, bersikaplah taktis tentang cara mendapatkannya di sana. Kerjakan satu komponen pada satu waktu, atau pilih komponen yang berjarak sejauh mungkin satu sama lain. Jika Anda belum berinvestasi dalam pengujian yang solid, baik di tingkat unit maupun sistem, sekaranglah waktunya. Pengujian akan memberi Anda keyakinan bahwa perubahan Anda tidak akan merusak pengalaman pelanggan yang ada, namun juga dapat membantu tim Anda menemukan definisi selesai. Saat tes lulus, komponen sudah siap!

Teknologi terbaik adalah teknologi yang dapat Anda adaptasi

Kunci untuk mengurangi dampak refactoring dan re-architecting pada startup khususnya adalah dengan menggunakan teknologi yang dapat beradaptasi.

Secara historis, perusahaan memilih teknologi tertentu seperti VM, tanpa server, atau kontainer untuk menghosting aplikasi mereka. Masalahnya adalah beralih dari satu teknologi ke teknologi lainnya sangat mahal, dan apa yang Anda butuhkan hari ini mungkin bukan yang Anda butuhkan besok.

Arsitektur adaptif adalah salah satu yang memungkinkan Anda menghosting aplikasi Anda pada teknologi apa pun dengan mudah. Ini memungkinkan Anda menyesuaikan lingkungan hosting dengan cepat, agar sesuai dengan kebutuhan Anda saat ini. Pilihan teknologi khusus seperti AWS Lambda, Fargate, Kubernetes, gRPC, Linkerd, Azure/GCP dapat dipertukarkan.

Dengan menggunakan kembali konstruksi bahasa pemrograman yang ada seperti fungsi dan event handler, serta antarmuka yang idiomatis untuk setiap bahasa, arsitektur adaptif membuat layanan cloud lebih mudah digunakan.

Cari abstraksi dan alat yang ringan, tetapi cukup fleksibel untuk memungkinkan Anda beralih teknologi. Menurut kami, anotasi Klotho cocok untuk Anda, karena anotasi tersebut memungkinkan Anda memisahkan makna semantik arsitektur Anda dari konfigurasi penerapan — tetapi dengan investasi yang cukup dalam pustaka runtime dan otomatisasi infrastruktur, Anda dapat membuat sendiri solusi yang serupa.