Pada awalnya selalu sulit untuk memahami proyek yang besar dan lama. Arsitektur merupakan salah satu kegiatan penilaian seorang arsitek. Biasanya Anda harus mengerjakan proyek lama yang besar, dan hasilnya harus selesai dalam seminggu.
Bagaimana mengevaluasi proyek dengan 100 ribu atau lebih baris kode dalam seminggu sambil tetap memberikan hasil yang benar-benar berguna bagi klien.
Sebagian besar arsitek dan pimpinan teknis pernah mengalami penilaian proyek serupa. Ini mungkin terlihat seperti proses semi-formal atau sebagai layanan terpisah seperti yang dilakukan di perusahaan kami, dengan satu atau lain cara sebagian besar dari Anda pernah menangani hal ini.
Versi asli dalam bahasa Inggris untuk teman Anda yang tidak berbahasa Rusia ada di sini: .
Pendekatan perusahaan kami
Saya akan memberi tahu Anda cara kerjanya di perusahaan kami dan bagaimana saya bertindak dalam situasi serupa, tetapi Anda dapat dengan mudah mengubah pendekatan ini sesuai dengan kebutuhan proyek dan perusahaan Anda.
Ada dua jenis penilaian arsitektur.
Pedalaman β kami biasanya melakukannya untuk proyek-proyek di dalam perusahaan. Setiap proyek dapat meminta penilaian arsitektur karena beberapa alasan:
- Tim menganggap proyek mereka sempurna dan ini mencurigakan. Kami pernah mengalami kasus seperti itu, dan seringkali dalam proyek seperti itu semuanya jauh dari ideal.
- Tim ingin menguji proyek dan solusi mereka.
- Tim tahu segalanya buruk. Mereka bahkan mungkin membuat daftar masalah dan penyebab utama, namun menginginkan daftar lengkap masalah dan rekomendasi untuk memperbaiki proyek.
Luar adalah proses yang lebih formal daripada penilaian internal. Klien selalu datang hanya dalam satu kasus, ketika semuanya buruk - sangat buruk. Biasanya klien memahami bahwa ada masalah global, tetapi tidak dapat mengidentifikasi penyebabnya dengan benar dan memecahnya menjadi beberapa komponen.
Mengevaluasi arsitektur untuk klien eksternal adalah kasus yang lebih kompleks. Prosesnya harus lebih formal. Proyeknya selalu besar dan lama. Mereka memiliki banyak masalah, bug, dan kode yang bengkok. Laporan mengenai pekerjaan yang telah dilakukan harus siap dalam waktu maksimal beberapa minggu, yang harus mencakup permasalahan utama dan rekomendasi perbaikan. Oleh karena itu, jika kita melakukan penilaian eksternal terhadap suatu proyek, maka penilaian internal akan menjadi hal yang mudah. Mari kita pertimbangkan kasus yang paling sulit.
Penilaian arsitektur proyek perusahaan
Proyek yang umum untuk dievaluasi adalah proyek perusahaan besar, lama, dan memiliki banyak masalah. Seorang klien mendatangi kami dan meminta kami untuk memperbaiki proyeknya. Ini seperti gunung es, klien hanya melihat puncak masalahnya dan tidak tahu apa yang ada di bawah air (di kedalaman kode).
Masalah yang mungkin dikeluhkan dan mungkin diketahui pelanggan:
- Masalah kinerja
- Masalah kegunaan
- Penerapan jangka panjang
- Kurangnya unit dan tes lainnya
Masalah yang kemungkinan besar tidak disadari oleh klien, tetapi mungkin ada dalam proyek:
- Masalah keamanan
- Masalah desain
- Arsitektur yang salah
- Kesalahan algoritma
- Teknologi yang tidak tepat
- Hutang teknis
- Proses pembangunan yang salah
Proses peninjauan arsitektur formal
Ini adalah proses formal yang kami ikuti sebagai sebuah perusahaan, namun Anda dapat menyesuaikannya tergantung pada perusahaan dan proyek Anda.
Permintaan dari klien
Klien meminta untuk mengevaluasi arsitektur proyek saat ini. Orang yang bertanggung jawab di pihak kami mengumpulkan informasi dasar tentang proyek dan memilih ahli yang diperlukan. Tergantung pada proyeknya, ahlinya mungkin berbeda-beda.
Arsitek Solusi β orang utama yang bertanggung jawab atas penilaian dan koordinasi (dan seringkali satu-satunya).
Tumpuk pakar tertentu β .Net, Java, Python, dan spesialis teknis lainnya bergantung pada proyek dan teknologinya
Pakar awan β ini bisa berupa arsitek cloud Azure, GCP, atau AWS.
Infrastruktur β DevOps, Administrator sistem, dll.
Pakar lainnya β seperti data besar, pembelajaran mesin, insinyur kinerja, pakar keamanan, pimpinan QA.
Mengumpulkan informasi tentang proyek
Anda harus mengumpulkan informasi sebanyak mungkin tentang proyek tersebut. Anda dapat menggunakan teknik berbeda tergantung situasinya:
- Kuesioner dan metode komunikasi lainnya melalui surat. Cara yang paling tidak efektif.
- Pertemuan daring.
- Alat khusus untuk pertukaran informasi seperti: Google doc, Confluence, repositori, dll.
- Pertemuan βlangsungβ di lokasi. Cara paling efektif dan termahal.
Apa yang harus Anda dapatkan dari klien?
Informasi dasar. Tentang apa proyek ini? Tujuan dan nilainya. Tujuan utama dan rencana untuk masa depan. Tujuan dan strategi bisnis. Masalah utama dan hasil yang diinginkan.
Informasi Proyek. Tumpukan teknologi, kerangka kerja, bahasa pemrograman. Penerapan di lokasi atau cloud. Jika proyek berada di cloud, layanan apa yang digunakan. Pola arsitektur dan desain apa yang digunakan.
Persyaratan non-fungsional. Semua persyaratan terkait kinerja, ketersediaan, dan kemudahan penggunaan sistem. Persyaratan keselamatan, dll.
Kasus penggunaan dasar dan aliran data.
Akses ke kode sumber. Bagian terpenting! Anda pastinya harus mendapatkan akses ke repositori dan dokumentasi tentang cara membangun proyek.
Akses terhadap infrastruktur. Akan menyenangkan jika memiliki akses ke panggung atau infrastruktur produksi untuk bekerja dengan sistem live. Akan sangat sukses jika klien memiliki alat untuk memantau infrastruktur dan kinerja. Kami akan membicarakan alat-alat ini di bagian selanjutnya.
ΠΠΎΠΊΡΠΌΠ΅Π½ΡΠ°ΡΠΈΡ. Jika klien memiliki dokumentasi, ini adalah awal yang baik. Ini mungkin sudah ketinggalan jaman, tapi ini masih merupakan awal yang baik. Jangan pernah mempercayai dokumentasi - ujilah dengan klien, pada infrastruktur nyata dan dalam kode sumber.
Proses Evaluasi Arsitektur
Bagaimana seseorang bisa memproses informasi sebanyak itu dalam waktu sesingkat itu? Pertama-tama, paralelkan pekerjaan.
DevOps harus melihat infrastrukturnya. Petunjuk teknologi ke dalam kode. Insinyur kinerja untuk melihat metrik kinerja. Seorang spesialis database harus menggali lebih dalam struktur data.
Namun ini ideal bila Anda memiliki banyak sumber daya. Biasanya, satu hingga tiga orang mengevaluasi suatu proyek. Anda bahkan dapat melakukan estimasi sendiri, yang sering kali terjadi jika Anda memiliki pengetahuan dan pengalaman yang tepat di semua bidang proyek. Dalam hal ini, Anda perlu mengotomatiskan semua proses sebanyak mungkin.
Sayangnya, Anda harus membaca dokumentasinya secara manual. Dengan pengalaman yang tepat, Anda dapat dengan cepat memahami kualitas dokumentasi. Apa yang benar dan apa yang jelas-jelas tidak sesuai dengan kenyataan. Terkadang Anda mungkin melihat arsitektur dalam dokumentasi yang tidak akan pernah berfungsi di kehidupan nyata. Ini adalah pemicu bagi Anda untuk memikirkan bagaimana hal itu dilakukan dalam kenyataan dalam proyek tersebut.
Alat yang berguna untuk mengotomatiskan evaluasi proyek
Evaluasi kode adalah latihan sederhana. Anda dapat menggunakan penganalisis kode statis yang akan menunjukkan masalah desain, kinerja, dan keamanan. Berikut ini beberapa di antaranya:
adalah alat yang hebat untuk seorang arsitek. Ini akan menunjukkan gambaran besarnya, ketergantungan antar modul dan area potensial untuk pemfaktoran ulang. Seperti semua alat bagus, alat ini memerlukan biaya yang besar, namun Anda dapat memanfaatkan versi uji coba selama 30 hari.
- alat tua yang bagus. Alat untuk analisis kode statis. Memungkinkan Anda mengidentifikasi kode buruk, bug, dan masalah keamanan untuk lebih dari 20 bahasa pemrograman.
Semua penyedia cloud memiliki alat pemantauan infrastruktur. Hal ini akan memungkinkan Anda mengevaluasi dengan tepat efektivitas infrastruktur Anda dalam hal biaya dan kinerja. Untuk AWS ini adalah . Sangat mudah bagi Azure .
Pemantauan dan pencatatan kinerja tambahan akan membantu menemukan masalah kinerja di semua tingkatan. Mulai dari database dengan query yang tidak efektif, backend dan diakhiri dengan frontend. Meskipun klien belum pernah menginstal alat ini sebelumnya, Anda dapat mengintegrasikannya ke dalam sistem yang ada dengan cukup cepat untuk mengidentifikasi masalah kinerja.
Seperti biasa, alat yang bagus sangat berharga. Saya dapat merekomendasikan beberapa alat berbayar. Tentu saja Anda dapat menggunakan sumber terbuka tetapi itu akan memakan waktu lebih lama. Dan ini harus dilakukan di awal, bukan selama proses penilaian arsitektur.
β alat untuk menilai kinerja aplikasi
β layanan pemantauan sistem cloud
Ada banyak alat yang tersedia untuk pengujian keamanan. Kali ini saya akan merekomendasikan Anda alat pemindaian sistem gratis.
β alat untuk memindai aplikasi web untuk memenuhi standar keamanan.
Mari kita satukan semuanya menjadi satu kesatuan.
Mempersiapkan laporan
Mulailah laporan Anda dengan data yang Anda kumpulkan dari klien. Jelaskan tujuan proyek, kendala, persyaratan non-fungsional. Setelah ini, semua data masukan harus disebutkan: kode sumber, dokumentasi, infrastruktur.
Langkah berikutnya. Buat daftar masalah apa pun yang Anda temukan secara manual atau menggunakan alat otomatis. Tempatkan laporan besar yang dibuat secara otomatis di akhir bagian aplikasi. Harus ada bukti singkat dan ringkas mengenai permasalahan yang ditemukan.
Prioritaskan masalah yang ditemukan pada skala kesalahan, peringatan, info. Anda dapat memilih skala Anda sendiri, tetapi ini adalah skala yang diterima secara umum.
Sebagai seorang arsitek sejati, sudah menjadi tanggung jawab Anda untuk memberikan rekomendasi untuk memperbaiki permasalahan yang ditemukan. Jelaskan peningkatan dan nilai bisnis yang akan diterima pelanggan. Bagaimana menunjukkan nilai bisnis dari kita bahas sebelumnya.
Siapkan peta jalan dengan iterasi kecil. Setiap iterasi harus berisi waktu penyelesaian, deskripsi, jumlah sumber daya yang diperlukan untuk perbaikan, nilai teknis, dan nilai bisnis.
Kami menyelesaikan penilaian arsitektur dan memberikan laporan kepada klien
Jangan pernah hanya mengirimkan laporan. Mungkin tidak terbaca sama sekali, atau mungkin tidak terbaca dan dipahami tanpa penjelasan yang tepat. Singkatnya, komunikasi langsung membantu menghilangkan kesalahpahaman antar manusia. Anda harus menjadwalkan pertemuan dengan klien dan membicarakan masalah yang ditemukan, dengan fokus pada masalah yang paling signifikan. Penting untuk menarik perhatian klien pada masalah yang mungkin tidak dia sadari. Seperti masalah keamanan dan menjelaskan dampaknya terhadap bisnis. Tunjukkan peta jalan Anda dengan perbaikan dan diskusikan berbagai opsi yang lebih sesuai untuk klien. Ini bisa berupa waktu, sumber daya, jumlah pekerjaan.
Sebagai ringkasan pertemuan Anda, kirimkan laporan Anda ke klien.
Sebagai kesimpulan
Evaluasi arsitektur adalah proses yang kompleks. Untuk melakukan penilaian dengan benar Anda perlu memiliki pengalaman dan pengetahuan yang cukup.
Dimungkinkan untuk memberikan hasil yang berguna bagi klien dan bisnisnya hanya dalam seminggu. Meski kamu melakukannya sendirian.
Berdasarkan pengalaman saya, banyak perbaikan yang diunduh di tengah-tengah, dan terkadang tidak pernah dimulai. Mereka yang memilih jalan tengah dan hanya melakukan sebagian perbaikan yang paling berguna bagi bisnis dengan biaya tenaga kerja minimal meningkatkan kualitas produk mereka secara signifikan. Mereka yang tidak melakukan apa pun dapat menutup proyek tersebut sepenuhnya setelah beberapa tahun.
Tujuan Anda adalah menunjukkan peningkatan maksimal kepada klien dengan harga minimum.
Artikel lain dari bagian tersebut Anda dapat membaca di waktu luang Anda.
Saya berharap Anda membersihkan kode dan keputusan arsitektur yang baik.
Grup facebook kami - .
Sumber: www.habr.com