🚅 👇 👩🏼‍🚒 Cara membaca dan memperbaiki 100.000 baris kode per minggu 🕯️ 👩🏻‍🤝‍👨🏽 ⛷️

Pada awalnya, selalu sulit untuk mengetahui proyek besar dan lama. Penilaian arsitektur adalah salah satu kegiatan arsitek. Biasanya Anda harus bekerja dengan proyek besar yang lama, dan hasilnya harus diberikan dalam seminggu.

Cara mengevaluasi proyek dengan ukuran 100k atau lebih baris kode per minggu sambil memberikan hasil yang sangat berguna bagi klien.

Sebagian besar arsitek dan prospek tersebut telah menemukan evaluasi proyek yang serupa. Ini mungkin terlihat seperti proses semi-formal atau sebagai layanan terpisah seperti yang dilakukan di perusahaan kami, toh sebagian besar dari Anda telah berurusan dengan ini.

Bahasa Inggris asli untuk teman-teman non-Rusia Anda ada di sini: Penilaian Arsitektur dalam seminggu .

Pendekatan di perusahaan kami

Saya akan memberi tahu Anda cara kerjanya di perusahaan kami dan bagaimana saya bertindak dalam situasi seperti itu, tetapi Anda dapat dengan mudah mengubah pendekatan ini sesuai dengan kebutuhan proyek dan perusahaan Anda.

Ada dua rasa penilaian arsitektur.

Internal - kami biasanya melakukannya untuk proyek-proyek di dalam perusahaan. Setiap proyek dapat meminta penilaian arsitektur karena beberapa alasan:

Tim berpikir bahwa proyek mereka sempurna dan ini mencurigakan. Kami memiliki kasus-kasus seperti itu dan seringkali dalam proyek-proyek semacam itu semuanya jauh dari sempurna.
Tim ingin menguji proyek dan keputusan mereka.
Tim tahu bahwa semuanya buruk. Mereka bahkan dapat membuat daftar masalah dan penyebab utama, tetapi mereka menginginkan daftar lengkap masalah dan rekomendasi untuk meningkatkan proyek.

Eksternal adalah proses yang lebih formal daripada evaluasi internal. Seorang klien selalu datang hanya dalam satu kasus ketika semuanya buruk - sangat buruk. Biasanya, klien memahami bahwa ada masalah global, tetapi tidak dapat dengan tepat menentukan penyebab dan memecahnya menjadi komponen.

Menilai arsitektur untuk klien eksternal adalah kasus yang lebih kompleks. Prosesnya harus lebih formal. Proyek selalu besar dan lama. Mereka memiliki banyak masalah, bug, dan kode bengkok. Laporan tentang pekerjaan yang dilakukan harus siap dalam waktu maksimum beberapa minggu, di mana harus ada masalah utama dan rekomendasi untuk perbaikan. Oleh karena itu, jika kita berurusan dengan evaluasi eksternal proyek, maka internal akan menjadi omong kosong. Pertimbangkan kasus yang paling sulit.

Penilaian arsitektur proyek perusahaan

Proyek tipikal untuk evaluasi adalah proyek perusahaan besar, lama, dengan banyak masalah. Seorang klien datang kepada kami dan meminta untuk memperbaiki proyeknya. Seperti halnya gunung es, klien hanya melihat ujung masalahnya dan tidak tahu apa yang ada di bawah air (di belakang kode).

Masalah yang bisa dikeluhkan klien dan mungkin tahu tentang mereka:

Masalah kinerja
Masalah Kegunaan
Penempatan Panjang
Kurangnya unit dan tes lainnya

Masalah yang kemungkinan besar tidak disadari klien, tetapi mungkin ada dalam proyek:

Masalah keamanan
Masalah desain
Arsitektur salah
Kesalahan Algoritma
Teknologi tidak pantas
Utang teknis
Proses pengembangan tidak valid

Proses Penilaian Arsitektur Formal

Ini adalah proses formal yang kami patuhi di perusahaan, tetapi Anda dapat menyesuaikannya sendiri tergantung pada perusahaan dan proyek Anda.

Permintaan pelanggan

Klien meminta untuk mengevaluasi arsitektur proyek saat ini. Orang yang bertanggung jawab di pihak kami mengumpulkan informasi dasar tentang proyek dan memilih para ahli yang diperlukan. Tergantung pada proyeknya, ini mungkin para ahli yang berbeda.

Solution Architect adalah orang utama yang bertanggung jawab untuk evaluasi dan koordinasi (dan seringkali satu-satunya).
Pakar khusus yang spesifik - Net, Java, Python, dan pakar teknis lainnya tergantung pada proyek dan teknologi
pakar Cloud - ini bisa berupa arsitek cloud Azure, GCP atau AWS.
Infrastruktur - DevOps, Administrator sistem, dll.
Pakar lainnya adalah data besar, pembelajaran mesin, insinyur kinerja, pakar keamanan, pemimpin QA.

Pengumpulan Informasi Proyek

Anda harus mengumpulkan informasi sebanyak mungkin tentang proyek. Anda dapat menggunakan teknik berbeda tergantung pada situasinya:

Kuisioner dan alat komunikasi lainnya melalui surat. Cara yang paling tidak efisien.
Pertemuan online.
Alat khusus untuk bertukar informasi seperti: Google doc, Confluence, repositori, dll.
Rapat "langsung" sudah siap. Cara paling efektif dan paling mahal.

Apa yang harus diterima dari klien?

Informasi dasar. Tentang apa proyek itu? Tujuan dan nilainya. Tujuan dan rencana utama untuk masa depan. Tujuan dan strategi bisnis. Masalah utama dan hasil yang diinginkan.

Informasi tentang proyek . Tumpukan teknologi, kerangka kerja, bahasa pemrograman. Penempatan di lokasi atau cloud. Jika proyek ada di cloud, layanan apa yang digunakan. Apa pola arsitektur dan desain yang digunakan.

Bukan persyaratan fungsional . Semua persyaratan terkait dengan kinerja, ketersediaan, kegunaan sistem. Persyaratan Keamanan, dll.

Juskeys dasar dan aliran data.

Akses ke kode sumber . Bagian terpenting! Anda pasti harus mendapatkan akses ke repositori dan dokumentasi tentang cara menyusun proyek.

Akses ke infrastruktur . Akan menyenangkan untuk mendapatkan akses ke panggung atau infrastruktur produksi untuk bekerja dengan sistem live. Ini adalah kesuksesan besar jika klien memiliki alat untuk memonitor infrastruktur dan produktivitas. Kami akan berbicara tentang alat-alat ini di bagian selanjutnya.

Dokumentasi . Jika klien memiliki dokumentasi, ini adalah awal yang baik. Mungkin sudah ketinggalan zaman, tapi ini masih awal yang baik. Jangan pernah percaya dokumentasi - cek dengan klien, pada infrastruktur nyata dan kode sumber.

Proses Penilaian Arsitektur

Lalu, bagaimana memproses informasi sebanyak itu dalam waktu sesingkat itu? Pertama-tama, sejajarkan pekerjaan.

DevOps harus memeriksa infrastrukturnya. Saya menuntun mereka ke dalam kode. Insinyur kinerja melihat metrik kinerja. Seorang spesialis basis data harus menggali lebih dalam ke dalam struktur data.

Tetapi ini adalah kasus yang ideal ketika Anda memiliki banyak sumber daya. Biasanya, proyek dievaluasi oleh satu hingga tiga orang. Anda bahkan dapat melakukan penilaian sendiri, yang sering 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 dokumentasi secara manual. Dengan pengalaman yang tepat, Anda dapat dengan cepat memahami kualitas dokumentasi. Apa yang benar di sana dan apa yang jelas tidak sesuai dengan kenyataan. Terkadang Anda mungkin menemukan arsitektur seperti itu dalam dokumentasi yang tidak akan pernah berfungsi dalam kehidupan nyata. Ini adalah pemicu bagi Anda untuk dipikirkan, tetapi bagaimana hal itu dilakukan dalam kenyataan dalam proyek.

Alat yang berguna untuk mengotomatisasi evaluasi proyek

Mengevaluasi kode adalah latihan sederhana. Anda dapat menggunakan penganalisa kode statis untuk menunjukkan masalah desain, kinerja, dan keamanan. Berikut adalah beberapa di antaranya:

Struktur 101 adalah alat yang hebat untuk seorang arsitek. Ini akan menunjukkan kepada Anda gambaran besar, hubungan antara modul dan area potensial untuk refactoring. Seperti semua alat yang baik, harganya sangat mahal, pada saat yang sama Anda dapat menggunakan versi uji coba 30 hari.

SonarQube adalah alat tua yang bagus. Alat untuk analisis kode statis. Memungkinkan Anda mengidentifikasi kode buruk, bug, masalah keamanan untuk lebih dari 20 bahasa pemrograman.

Semua penyedia cloud memiliki alat pemantauan infrastruktur. Ini akan memungkinkan Anda untuk mengevaluasi dengan benar efektivitas infrastruktur dalam hal biaya dan kinerja. Untuk AWS, ini adalah penasihat tepercaya . Untuk Azure, itu hanya Penasihat Azure .

Pemantauan dan pencatatan kinerja tambahan dapat membantu Anda menemukan masalah kinerja di semua tingkatan. Mulai dari database dengan kueri yang tidak efisien, backend dan berakhir dengan frontend. Bahkan jika klien belum menginstal alat-alat ini sebelumnya, Anda dapat dengan cepat mengintegrasikannya ke dalam sistem yang ada untuk mengidentifikasi masalah kinerja.

Seperti biasa, alat yang bagus sangat berharga. Saya dapat merekomendasikan beberapa alat berbayar. Tentu saja, Anda dapat menggunakan open-source tetapi Anda akan membutuhkan lebih banyak waktu untuk ini. Dan ini harus dilakukan terlebih dahulu, dan bukan dalam proses mengevaluasi arsitektur.

Relic Baru - alat evaluasi kinerja aplikasi
Datadog - layanan pemantauan saudara berbasis cloud

Ada banyak alat untuk pengujian keamanan. Kali ini saya akan merekomendasikan Anda alat pemindaian sistem gratis.

OWASP ZAP adalah alat untuk memindai aplikasi web untuk kepatuhan dengan standar keamanan.

Menyatukan semuanya.

Kami sedang menyiapkan laporan

Mulai laporan Anda dengan data pelanggan. Jelaskan tujuan proyek, batasan, persyaratan non-fungsional. Setelah ini, semua data yang masuk harus disebutkan kode sumber, dokumentasi, infrastruktur.

Langkah selanjutnya. Daftar semua masalah yang Anda temukan secara manual atau menggunakan alat otomatis. Tempatkan laporan besar yang dihasilkan secara otomatis di akhir di bagian aplikasi. Di sini harus ada bukti singkat dan ringkas dari masalah yang ditemukan.
Prioritaskan masalah yang ditemukan pada kesalahan, peringatan, skala info. Anda dapat memilih skala Anda sendiri, tetapi ini diterima secara umum.

Sebagai arsitek sejati, Anda harus memberikan rekomendasi tentang cara memperbaiki masalah yang Anda temukan. Jelaskan peningkatan dan nilai bisnis yang akan diterima pelanggan. Cara menunjukkan nilai bisnis darirefactoring arsitektur yang kita bahas sebelumnya.

Siapkan peta jalan dengan iterasi kecil. Setiap iterasi harus berisi waktu untuk pelaksanaan, deskripsi, jumlah sumber daya yang dibutuhkan untuk peningkatan, nilai teknis dan nilai untuk bisnis.

Kami menyelesaikan penilaian arsitektur dan memberikan laporan kepada klien

Jangan pernah hanya mengirim laporan melalui surat. Itu mungkin atau mungkin tidak dibaca sama sekali atau dibaca dan tidak dipahami tanpa penjelasan yang tepat. Singkatnya, komunikasi langsung membantu menghilangkan kesalahpahaman di antara orang-orang. Anda harus mengatur pertemuan dengan klien dan berbicara tentang masalah yang ditemukan, dengan fokus pada yang paling signifikan. Penting untuk memperhatikan klien tentang masalah yang bahkan mungkin tidak ia curigai. Seperti masalah keamanan dan jelaskan bagaimana itu dapat memengaruhi bisnis. Tunjukkan peta jalan Anda dengan peningkatan dan bahas berbagai opsi yang lebih cocok untuk klien. Ini bisa berupa waktu, sumber daya, jumlah pekerjaan.

Sebagai ringkasan reli Anda, kirim laporan Anda ke klien.

Akhirnya

Menilai arsitektur adalah proses yang kompleks. Untuk melakukan penilaian dengan benar, Anda perlu memiliki pengalaman dan pengetahuan yang cukup.

Ini nyata - untuk memberi klien hasil yang bermanfaat baginya dan bisnisnya hanya dalam seminggu. Bahkan jika Anda melakukannya sendiri.

Berdasarkan pengalaman saya, banyak perbaikan diunduh di tengah, dan terkadang tidak pernah dimulai. Mereka yang memilih jalan tengah untuk diri mereka sendiri dan hanya membuat sebagian dari perbaikan yang paling berguna untuk bisnis dengan tenaga kerja minimal, secara signifikan meningkatkan kualitas produk mereka. Mereka yang tidak melakukan apa-apa setelah beberapa tahun dapat sepenuhnya menutup proyek.

Tujuan Anda adalah menunjukkan peningkatan maksimum kepada klien dengan harga terendah.

Artikel lain dari bagian arsitektur dapat dibaca sesuka Anda.

Saya harap Anda membersihkan kode dan solusi arsitektur yang baik.

Grup facebook kami adalah Arsitektur dan Pengembangan Perangkat Lunak .

Cara membaca dan memperbaiki 100.000 baris kode per minggu