Arsitek Perangkat Lunak: mengapa diperlukan dan apa kutukannya

Tamu edisi baru podcast Dry Oars adalah arsitek perangkat lunak Yegor Taflanidi. Kami sedang mendiskusikan apa peran metafisik ini, apa kesulitan yang ada dalam pekerjaan dan apa yang harus dilakukan kekuatan gelap dengan itu.

gambar

Artyom Kulakov dan Roma Choryev adalah pengembang Redmadrobot. Mereka merekam podcast tabung di mana, bersama dengan para tamu, mereka membahas berbagai aspek dalam menciptakan produk-produk TI. Di bawah ini adalah tautan ke masalah baru dan jawaban untuk beberapa pertanyaan mendesak.


Pengaturan waktu
01:40 Egor menceritakan bagaimana ia menjadi seorang arsitek
12:40 Mitos populer: seorang arsitek adalah tahap pengembangan tertinggi seorang pengembang; arsitek tahu semua yang terbaik dan yang paling; arsitek tidak menulis kode (karena dia lupa bagaimana melakukannya); seorang arsitek duduk dan menggambar beberapa skema
31:20 Diskusi tentang bahasa pemrograman modern
39:10 Sistem / Solusi / Arsitek dll. Apa artinya semua ini?
47:50 Diskusi tentang "kutukan" yang sama
50:24 Bagaimana menjadi arsitek (peringatan: beberapa lelucon)
55:16 Manajemen waktu: satu hari kerja seorang arsitek - apa yang dia lakukan?
01:03:39 Apa saja kesulitan dalam pekerjaan dan bagaimana cara mengatasinya
01:13:49 Dan apa selanjutnya: apa vektor pembangunan
01:26:59 Jawaban untuk pertanyaan: apa cara yang benar untuk arsitek?

Siapa arsitek perangkat lunak?


Arsitek adalah spesialis yang membangun sistem TI untuk menyelesaikan masalah bisnis. Ia berpengalaman dalam semua nuansa desain sistem.

Jika Anda perlu mengembangkan, misalnya, aplikasi, maka arsitek akan memberi tahu Anda cara melakukannya tanpa menginjak menyapu. Dia akan menjelaskan teknologi apa yang akan digunakan, masalah apa yang bisa ditemui, dan akan meletakkan dasar untuk pengembangan proyek. Perancang pesawat memutuskan dari mana membuat pesawat itu, dan arsitek memutuskan dengan teknologi apa untuk mengembangkan sistem TI yang akan menyelesaikan masalah.

Haruskah seorang arsitek memahami segalanya?


Dalam percakapan itu ternyata ini keluar dengan sendirinya. Arsitek terlibat dalam situasi yang berbeda: ia berkomunikasi dengan pelanggan, memecahkan masalah teknik dan bahkan berpartisipasi dalam perencanaan proyek. Jika Anda mau atau tidak, Anda masuk lebih dalam ke bisnis dan mengunduh keterampilan manajerial. Egor menjelaskan:

- Seluruh esensi bermuara pada dua hal: arsitek harus menyelesaikan masalah bisnis dan ia harus mengambil sistem dari batasan. Jika Anda tahu bahwa sistem tidak memiliki kemampuan fisik untuk mengimplementasikan ini atau hal-hal lain, tetapi ada kebutuhan bisnis, maka tugas Anda adalah mencari tahu bagaimana dan menyatukan semuanya. Kita dapat mengatakan: pastikan bahwa domba-domba itu utuh dan serigala penuh.

Pada siang hari, seorang arsitek melewati sejumlah besar informasi dari manajer, pengembang, pelanggan. Karena itu, pada akhirnya ternyata dia akrab dengan situasi dari berbagai sudut. Artyom diringkas:

- Arsitek lebih tentang lebar daripada kedalaman. Misalnya, Anda tidak perlu dapat bekerja dengan refleksi dan beberapa hal tingkat rendah di Android, tetapi penting untuk memahami bagaimana semuanya bekerja secara umum.

Apakah arsitek menulis kode?


Singkatnya, beberapa kode arsitek. Lebih lanjut tentang ini dalam wacana lima menit di podcast, mulai pukul 10:25 malam. Spoiler: Ini tentang kode sempurna, masalah perfeksionis, dan persyaratan bisnis.

Bagaimana cara menjadi seorang arsitek?


Berdasarkan pengalaman mereka, mereka mengatakan bahwa tidak mungkin untuk beralih dari pengembang ke arsitek. Pertama, perlu ada kebutuhan untuk posisi ini. Hanya kemudian seseorang dari tim dipilih untuk itu atau spesialis dari luar dipanggil.

- Kami memiliki cara ini: perusahaan berkembang, jumlah orang dan proyek bertambah. Kualitas harus dipertahankan, sehingga tiba saatnya ketika β€œceruk tanggung jawab” muncul.

Apakah arsitek tingkat perkembangan tertinggi?


Studio sepakat bahwa ini jelas merupakan tonggak dalam pengembangan pengembang. Tapi jangan menganggap arsitek sebagai versi yang lebih baik dari "senior". Egor menjelaskan bahwa arsitek bukanlah penutup dan bukan langit-langit. Spesialis seperti itu memiliki keterampilan yang kuat dalam memecahkan masalah teknik, sehingga ada banyak pilihan untuk pengembangan. Misalnya, Anda bisa pergi ke IoT, mendesain bahasa pemrograman, atau pergi ke area yang berdekatan.

Dan "kutukan" macam apa?


Jadi Yegor menjelaskan fenomena ini:

- "Kutukan" adalah ketika ada kebutuhan akan seorang arsitek, dan seseorang menempati posisi ini, maka tidak ada orang lain di perusahaan ini yang bisa menjadi seorang arsitek.

Dia mengatakan bahwa spesialis yang menjabat tidak mungkin dapat melakukan hal lain di masa depan (di dalam perusahaan). Ini disebabkan oleh kenyataan bahwa sulit untuk "mendidik" wakil seseorang. Ini terjadi karena berbagai alasan: tugas seorang arsitek sulit untuk didelegasikan, tidak selalu ada orang yang ingin menggantikan, dan tidak ada cukup waktu untuk pelatihan.

Dengarkan podcast di platform yang nyaman - SoundCloud , Apple , Google Podcasts .

Tautan yang bermanfaat


Artikel, video, dan buku penting bagi mereka yang ingin bertransformasi menjadi seorang arsitek:

Banyak artikel dan video bermanfaat yang berguna untuk berpindah dari pengembang ke arsitek.

Arsitektur Perangkat Lunak dalam Praktek, L. Bass - dasar-dasar menjadi seorang arsitek.

Arsitektur Sistem Perangkat Lunak: Bekerja Dengan Stakeholder Menggunakan Sudut Pandang dan Perspektif adalah salah satu buku utama yang paling menggambarkan prinsip-prinsip arsitek.

Rilis!!: Desain dan Gunakan Perangkat Lunak Siap Produksi - cerita tentang cara merancang perangkat lunak dan apa yang terjadi ketika itu dirancang dengan bengkok.

Pola Arsitektur Aplikasi Perusahaan - memoar lama Martin Fowler tentang cara mendesain perangkat lunak.

Desain Berbasis Domain - Menangani Kompleksitas di Jantung Perangkat Lunak E. Evans - tentang pemodelan yang tepat.

Menerapkan UML dan Pola: Pengantar Analisis dan Desain Berorientasi Objek dan Pengembangan berulang C. Larman - project @ document,% username%.
Mengembangkan persyaratan untuk perangkat lunak, K. Wigers - Microsoft menulis tentang mengembangkan persyaratan.

Gambaran umum pola desain.

Ayo bahas masalah ini di obrolan Telegram.

Source: https://habr.com/ru/post/id482094/


All Articles