Sekali lagi tentang kompleksitas arsitektur dan ambang pintu masuk

Dalam artikel ini, saya akan menyentuh pertanyaan ambang untuk memasuki proyek dengan arsitektur yang mapan dan memberikan beberapa opsi untuk menjawab pertanyaan yang sangat sering ditanyakan: mengapa begitu sulit?

Pertanyaan ini sering muncul di kalangan pendatang baru yang datang ke proyek. Atau ada situasi ketika proyek masuk ke dukungan dan pengembangan di tangan baru, dan pengembang baru juga memiliki pertanyaan ini. Dan jarang, salah satunya mencoba mencari tahu alasan sebenarnya mengapa demikian di sini dan bukan sebaliknya. Ini dapat menyebabkan konsekuensi yang menyedihkan bagi bisnis, misalnya, pengembang baru mungkin bersikeras untuk menulis ulang seluruh aplikasi dari awal.
Untuk meminimalkan risiko seperti itu, alih-alih bertanya mengapa begitu sulit? ajukan pertanyaan seperti itu:

• Apa persyaratan untuk proses pengembangan yang ditetapkan oleh arsitek?
• Apa hasil dari proses pengembangan yang dibutuhkan pada output?

Persyaratan proses pengembangan

Pertama, pengembang harus mempelajari sistem proses pengembangan, ia harus mengajukan pertanyaan berikut:

• Sistem apa proses yang dibangun?

Seringkali dalam pengembangan kustom, proyek dengan persyaratan yang tidak ambigu dan serangkaian fungsi tetap datang ke input. Seberapa berkembangnya mereka - ini adalah topik dari artikel lain. Dan proses pengembangan dalam proyek tersebut paling sering dibangun sesuai dengan sistem air terjun, karena melibatkan umpan balik langsung dari pengguna produk - setelah pengembangan seluruh fungsionalitas produk , sedangkan dengan model berulang, umpan balik dapat diperoleh setelah iterasi pertama. Untuk proyek-proyek seperti itu, arsitek biasanya sudah memiliki arsitektur yang mapan yang memenuhi persyaratan tertentu untuk proses ini. Apa persyaratan untuk proses pengembangan yang dilakukan oleh arsitek?

1) Proses pengembangan pipa harus serumit mungkin bagi pengembang. Dan penolakan terhadap kode yang memasuki repositori proyek harus terjadi secara maksimal dan, jika mungkin, tanpa partisipasi dari arsitek itu sendiri.

Yaitu pipa tertentu harus dikonfigurasi dalam proses. Kode yang melewati seluruh pipa ini dianggap memuaskan. Ini sangat penting karena seorang arsitek yang baik perlu menyelamatkan pengembangnya dari sakit kepala dan tanggung jawab untuk tidak bekerja perakitan setelah kode masuk ke repositori. Jika tidak ada saluran pipa semacam itu, pengembang Anda akan mengalami tekanan yang konstan. Jika kode masuk ke repositori dan pipa menerimanya, dan kode ini merusak perakitan atau merusak fungsi yang sudah berfungsi - ini sudah merupakan masalah dari pipa itu sendiri.

Karena itu, dalam pipa seperti itu , Anda harus menggunakan:

• Banyak penganalisa kode statis
• Tes otomatis dan pengujian kepatuhan piramida
• Perhitungan cakupan kode otomatis dengan tes
• Gerbang ke kualitas kode (Gerbang kualitas). Untuk semua jenis metrik: persentase cakupan kode dengan pengujian, persentase duplikasi kode, bau kode, keamanan, bug, dll.
• ulasan lintas kode
• dll

Semua poin ini bersama-sama mengarah pada pertanyaan pengembang: mengapa begitu sulit?

Misalnya, coba tulis tes untuk kode ini:

class SomeService( private val restApi: SomeApi // SomeApi -  ,   ,      ) { fun doSomething(): Single<SomeResult> = restApi.loadSomething() .map { /*-   */ } } 

Anda harus menjalankan tes seperti itu di perangkat android asli, atau pada emulator. Dan ini akan segera menyebabkan penarikan signifikan dalam persyaratan kedua untuk proses pengembangan:

2) Elemen-elemen Pipeline Otomatis dan proses pengembangan harus dilakukan secepat mungkin

Jika pengembang Anda harus menunggu lama untuk menyelesaikan tes - ini adalah masalah pipa Anda dan jika arsitektur tidak memungkinkan untuk mempercepat proses ini - ini adalah masalah arsitektur Anda

Mari kita tulis ulang contohnya:

 interface SomeApi { fun loadSomething(): Single<NetworkResult> } class NetworkSomeApi : SomeApi { override fun loadSomething(): Single<NetworkResult> { /*,    */ } } class SomeService( private val restApi: SomeApi // SomeApi -  ,       ) { /*CODE*/ } 

Kami melihat bahwa kompleksitas kode telah meningkat, tetapi dari sudut pandang proses pengembangan - kami telah membuat arsitektur lebih fleksibel, sekarang kami tidak harus menjalankan tes logika bisnis untuk blok map di emulator atau pada perangkat, jalankan saja dalam tes cepat. Ini akan mengurangi jumlah tes integrasi yang perlu dijalankan dalam lingkungan yang lambat.

Pola desain yang dipilih oleh arsitek dapat mengurangi jumlah tes integrasi yang mahal. Jangan malas dan berurusan dengan pola yang populer saat ini: MVP , MVVM , MVI .

Mari kita bicara sedikit lebih banyak tentang navigasi di aplikasi. Kami juga ingin dapat mengujinya, dan mengujinya dalam tes cepat. Sekali lagi, kita mendapatkan "komplikasi" dari arsitektur, karena kita harus menyembunyikan sistem navigasi di aplikasi di belakang abstraksi.

Dan kami juga ingin dapat menghubungkan komponen-komponen sistem kami menggunakan DI, membangun grafik dependensi dan memeriksa kebenarannya pada tahap kompilasi proyek, dan tidak dalam runtime. Kemudian Belati 2 beserta komponen dan subkomponennya yang mengerikan dengan modul muncul di atas panggung, yang pada akhirnya membingungkan para pemula yang malang.

Dan saat-saat "kerumitan" arsitektur untuk pemula yang tidak jelas banyak menumpuk. Secara alami, tanpa memahami proses pengembangan dan persyaratan untuk proses ini, mereka memiliki pertanyaan yang sama - mengapa begitu sulit?

Hasil dari Proses Pengembangan

Untuk mengevaluasi keberhasilan proses pembangunan built-in dan, secara tidak langsung, arsitektur proyek, perlu untuk menganalisis hasilnya. Sebagai aturan, hasilnya adalah produk (aplikasi jika kita berbicara tentang pengembangan ponsel). Dan metrik kesuksesan produk berbeda untuk semua orang: pelanggan memiliki metrik yang sama, pengembang memiliki metrik sendiri, pengguna produk memiliki metrik sendiri.

Paling tidak, Anda, sebagai arsitek yang menciptakan jalur pipa untuk proses pengembangan, harus mempertimbangkan ketika mengevaluasi efektivitas proses pengembangan metrik dan metrik bisnis perusahaan Anda.

Ini adalah proses yang berkelanjutan: pengembangan -> pengumpulan metrik -> analisis hasil -> membuat modifikasi yang diperlukan untuk proses pengembangan.

Dengan demikian, hasilnya mempengaruhi pembentukan proses pengembangan dan proses pengembangan sudah mempengaruhi perubahan dalam arsitektur proyek. Yaitu ide penting yang ingin saya sampaikan adalah bahwa arsitektur adalah sekunder, hasil utama dan proses pengembangan .

Kesimpulan

Sebagai kesimpulan, katakanlah lagi:

• tanpa memahami proses pengembangan dan persyaratan untuk proses ini, pengembang menciptakan perasaan tentang arsitektur proyek yang rumit;
• arsitektur adalah hasil sekunder, primer dan proses pengembangan;

Tanpa memahami hal-hal ini, pengembang mungkin ingin mengambil dan menulis ulang semuanya dari awal. Menurut pendapat saya, ini dibenarkan hanya ketika proses pengembangan dan hasilnya tidak sepenuhnya memuaskan pelanggan dari pengembangan ini.

Untuk pemula, saya menyarankan Anda untuk memulai proyek dengan pipeline pengembangan yang disempurnakan. Ambang masuk ke proyek-proyek semacam itu tinggi, tetapi melangkahinya, Anda akan secara serius mendekati pemahaman tentang bagaimana proses pembangunan dibangun.