Apa yang harus Anda bawa ke meja sebagai Arsitek Perangkat Lunak? [Tutup]

Ada banyak pertanyaan dengan jawaban yang baik tentang peran Arsitek Perangkat Lunak (SA) pada StackOverflow dan Programmer SE . Saya mencoba mengajukan pertanyaan yang sedikit lebih fokus daripada itu. Definisi SA sangat luas sehingga untuk pertanyaan ini mari kita mendefinisikan SA sebagai berikut:

Arsitek Perangkat Lunak memandu desain keseluruhan proyek, terlibat dengan upaya pengkodean, melakukan tinjauan kode, dan memilih teknologi yang akan digunakan.

Dengan kata lain, saya tidak berbicara tentang istirahat manajerial dan rompi di puncak (kata-kata berima lebih lanjut dihilangkan) jenis SA. Jika saya mengejar segala jenis posisi SA saya tidak ingin jauh dari pengkodean. Saya mungkin mengorbankan beberapa waktu untuk berinteraksi dengan klien dan Analis Bisnis, dll., Tetapi saya masih terlibat secara teknis dan saya tidak hanya mengetahui apa yang terjadi melalui rapat.

Dengan mengingat hal-hal ini, apa yang harus dibawa SA ke meja? Haruskah mereka datang dengan mentalitas "meletakkan hukum" (untuk berbicara) dan menegakkan penggunaan alat-alat tertentu agar sesuai dengan "jalan mereka," yaitu, pedoman pengkodean, kontrol sumber, pola, dokumentasi UML, dll? Atau haruskah mereka menentukan arah dan strategi awal kemudian diletakkan kembali dan melompat sesuai kebutuhan untuk memperbaiki arah kapal?

Tergantung pada organisasi ini mungkin tidak berfungsi. SA yang bergantung pada TFS untuk menegakkan segala sesuatu mungkin berjuang untuk mengimplementasikan rencana mereka di perusahaan yang hanya menggunakan StarTeam. Demikian pula, SA perlu fleksibel tergantung pada tahap proyek. Jika itu adalah proyek baru, mereka memiliki lebih banyak pilihan, sedangkan mereka mungkin memiliki lebih sedikit untuk proyek yang ada.

Berikut adalah beberapa cerita SA yang saya alami sebagai cara berbagi latar belakang dengan harapan jawaban atas pertanyaan saya juga dapat menjelaskan beberapa masalah ini:

• Saya telah bekerja dengan SA yang kode ditinjau secara harfiah setiap baris kode tim. SA akan melakukan ini bukan hanya untuk proyek kami tetapi juga proyek lain dalam organisasi (bayangkan waktu yang dihabiskan untuk ini). Awalnya bermanfaat untuk menegakkan standar tertentu, tetapi kemudian menjadi melumpuhkan. FxCop adalah bagaimana SA akan menemukan masalah. Jangan salah paham, itu adalah cara yang baik untuk mengajar pengembang junior dan memaksa mereka untuk memikirkan konsekuensi dari pendekatan yang mereka pilih, tetapi bagi pengembang senior itu terlihat agak kejam.

• Satu SA tertentu menentang penggunaan perpustakaan tertentu, mengklaim itu lambat. Ini memaksa kami untuk menulis banyak kode untuk mencapai hal-hal yang berbeda sementara perpustakaan lain akan menghemat banyak waktu. Maju cepat ke bulan terakhir proyek dan klien mengeluh tentang kinerja. Satu-satunya solusi adalah mengubah fungsionalitas tertentu untuk menggunakan pendekatan yang awalnya diabaikan meskipun peringatan awal dari para devs. Pada saat itu banyak kode yang dibuang dan tidak dapat digunakan kembali, yang mengarah ke kerja lembur dan stres. Sayangnya estimasi yang digunakan untuk proyek ini didasarkan pada pendekatan lama yang dilarang untuk digunakan oleh proyek saya sehingga itu bukan indikator yang tepat untuk estimasi. Saya akan mendengar PM mengatakan "kami pernah melakukan ini sebelumnya,"

• SA yang akan menegakkan penggunaan DTO, DO, BOs, lapisan Layanan dan sebagainya untuk semua proyek. Pengembang baru harus mempelajari arsitektur ini dan SA secara tegas menerapkan pedoman penggunaan. Pengecualian untuk pedoman penggunaan dibuat ketika benar-benar sulit untuk mengikuti pedoman tersebut. SA didasarkan pada pendekatan mereka. Kelas untuk DTO dan semua operasi CRUD dihasilkan melalui CodeSmith dan skema basis data adalah bola lilin serupa lainnya. Namun, setelah menggunakan pengaturan ini di mana-mana, SA tidak terbuka untuk teknologi baru seperti LINQ to SQL atau Entity Framework.

Saya tidak menggunakan pos ini sebagai platform untuk ventilasi. Ada aspek positif dan negatif dari pengalaman saya dengan cerita SA yang disebutkan di atas. Pertanyaan saya sampai ke:

1. Apa yang harus dibawa SA ke meja?
2. Bagaimana mereka bisa mencapai keseimbangan dalam pengambilan keputusan?
3. Haruskah seseorang mendekati pekerjaan SA (sebagaimana didefinisikan sebelumnya) dengan mentalitas bahwa mereka harus menegakkan aturan-aturan dasar tertentu?
4. Ada hal lain yang perlu dipertimbangkan?

Terima kasih! Saya yakin tugas-tugas pekerjaan ini dengan mudah diperluas ke orang-orang yang merupakan dev senior atau lead teknis, jadi jangan ragu untuk menjawab pada kapasitas itu juga.

Arsitek Sistem harus:

1. Tentukan arsitektur tingkat tinggi
2. Berpartisipasi dalam ulasan kode
3. Menyetujui teknologi yang digunakan
4. Bantu pengembang dalam upaya pengkodean mereka
5. Pelihara dan pantau jadwal pengembangan
6. Menghasilkan artefak SA, seperti diagram UML, grafik Gantt dan sejenisnya.

SA harus tahu cara membuat kode, dan harus berpartisipasi dalam beberapa pekerjaan pengkodean, basahi tangan mereka, begitulah. Ini membuat mereka tetap terhubung dengan gestalt dari upaya pengembangan. Seperti yang pernah dikatakan Paman Bob Martin , sang Arsitek harus melakukan beberapa pengkodean sendiri, sehingga ia dapat melihat rasa sakit yang ditimbulkannya pada orang lain dengan desainnya.

SA harus memiliki kata terakhir pada semua keputusan desain, teknologi dan gaya pengkodean. Tapi, seperti semua manajer, tugas SA adalah membersihkan jalan bagi orang-orangnya sehingga mereka bisa produktif. Itu berarti, sebagian besar, bahwa pengembang harus memutuskan, pada tingkat mereka, bagaimana masalah harus diselesaikan. Ini berarti bahwa SA menjaga bos berambut runcing keluar dari bilik pengembang. Dan itu berarti bahwa SA berusaha membantu, sesuai kebutuhan.

Seperti semua manusia, SA dapat dan memang melakukan kesalahan. Yang baik belajar dari kesalahan itu, dan menjadi SA yang lebih baik.

Saya tidak pernah bertemu dengan seorang Arsitek yang berguna, terutama karena mereka tidak praktis.

Bagi saya masalah terbesar yang pernah saya lihat adalah:

• kepatuhan buta terhadap proses demi proses
• buta bias terhadap teknologi sebelum mengetahui masalahnya
• pembuatan dan penegakan aturan tanpa pembenaran yang baik
• rewrite from scratch mentalitas

"Arsitek" terbaik yang pernah bekerja sama dengan saya:

• Pertanyaan yang mengarah pada pemahaman yang lebih baik tentang masalah dan solusi potensial.
• Opsi desain / teknologi dan pengorbanannya.
• Penjelasan yang jelas dan rasional baik untuk kecaman maupun pengesahan desain dan teknologi.

Masalahnya bagi saya adalah "Arsitek" terbaik yang pernah bekerja sama dengan saya, tidak memiliki "Arsitek dalam judul mereka. Mereka paling sering adalah Insinyur Perangkat Lunak yang didasarkan pada masalah dan proyek tertentu. Mereka mengerti bahwa di sebagian besar bisnis bukan t praktis untuk menulis ulang basis kode yang berfungsi dari awal. Mereka membuat keputusan desain atau memberikan opsi dan alasan atau pembenaran mereka. Mereka memetakan bagaimana cara mengembalikan basis kode ke arsitektur baru dari waktu ke waktu dan tetap menjaga semuanya berfungsi. Mereka memberikan rekomendasi konservatif alih-alih merekomendasikan apa pun yang kurang menyenangkan atau familier, mereka akan mengomunikasikan visi yang kohesif tentang bagaimana hal-hal harus bekerja dan mengapa, TETAPI yang lebih penting mereka akan memetakan bagaimana menuju ke sana dan biaya.

1 Apa yang harus dibawa SA ke meja?

• Kulit yang tebal
• Keterampilan negosiasi yang baik
• Pemahaman yang baik tentang berbagai tingkatan perangkat lunak (mulai dari kebaikan AJAX yang hebat hingga I / O jaringan tingkat rendah). Anda tidak perlu menjadi ahli, tetapi Anda harus membuat keputusan penting tentang perangkat lunak apa yang harus dieksekusi di lapisan mana.
• Kesediaan untuk membuat tangan mereka kotor dalam kode, desain kertas putih tidak memotongnya.
• Mendorong pengerjaan perangkat lunak - jadilah pemandu sorak untuk melakukan hal-hal dengan cara yang benar bila memungkinkan dan cara terbaik mengingat keterbatasan dalam kasus-kasus lain. Jadi hal-hal seperti kontrol sumber, TDD, build dan CI, pengkodean DOJO, ulasan kode, sistem pelacakan masalah yang baik, dll

2 Bagaimana mereka bisa mencapai keseimbangan dalam pengambilan keputusan?

• Sebagian besar tergantung pada tim Anda dan seberapa mampu mereka.
• Lingkungan Anda (misalnya, Anda mungkin terpaksa menggunakan produk vendor tertentu)
• Secara keseluruhan, yang terbaik adalah tidak menjadi arsitek menara gading, jaga tangan, menjadi bagian dari tim - orang akan memahami keputusan Anda seperti itu.

3 Haruskah seseorang mendekati pekerjaan SA (sebagaimana didefinisikan sebelumnya) dengan mentalitas bahwa mereka harus menegakkan aturan-aturan dasar tertentu?

• Ya, hal-hal seperti kontrol versi dan sistem build sangat penting dan pengembang perlu menggunakannya. Namun sebaiknya untuk menjadikan mereka bagian dari solusi.

Ada banyak lagi, saya pikir akan ada beberapa jawaban yang sangat bagus untuk yang satu ini.

1. Apa yang harus dibawa SA ke meja?

"Haruskah mereka datang dengan mentalitas 'meletakkan hukum' ... Atau haruskah mereka menentukan arah dan strategi awal kemudian diletakkan kembali dan melompat sesuai kebutuhan untuk memperbaiki arah kapal?"

Kombinasi keduanya akan saya katakan. Saat memutuskan teknologi dan proses, bersikap terbuka terhadap pendapat dan saran dapat memberikan umpan balik / masukan yang berharga tentang keputusan dan membuat Anda belajar dari orang lain. Tim Anda (semoga) pintar; manfaatkan itu. Tapi begitu keputusan (keputusan Anda) dibuat, hukum telah ditetapkan. Identifikasi mereka yang akan mengeluh tentang apa pun yang bukan pilihan mereka, dan mereka yang hanya akan memilih apa saja dan tidak peduli - dan kemudian abaikan saja.

Sejauh teknologi: bekerja dengan apa yang Anda miliki, jika perusahaan menggunakan StarTeam maka itulah yang Anda gunakan. Menikahi diri Anda dengan produk / teknologi / proses tertentu tidak akan melakukan apa pun untuk Anda.

2. Bagaimana mereka bisa mencapai keseimbangan dalam pengambilan keputusan?

Mendengarkan tim dan mengetahui kapan mereka benar dan salah adalah penting, dan meminta cojones untuk mengatakan bahwa mereka salah dan tetap pada keputusan Anda. Tidak mendengarkan akan membawa kurangnya rasa hormat, seperti akan menjatuhkan keputusan Anda.

3. Haruskah seseorang mendekati pekerjaan SA (sebagaimana didefinisikan sebelumnya) dengan mentalitas bahwa mereka harus menegakkan aturan-aturan dasar tertentu?

Selalu. Jika tidak, maka narapidana akan menjalankan suaka, secara terbuka atau terselubung. Namun, memutuskan aturan-aturan dasar tersebut dapat melalui pembicaraan dengan tim. Ingatlah bahwa tim mana pun mungkin tidak selalu memiliki anggota yang sama dengan yang dimiliki sekarang, jadi membuat konsesi untuk sekelompok kecil dari mereka dapat menghambat tim di masa depan begitu mereka pergi. Itu termasuk SA.

4.Ada hal lain untuk dipertimbangkan?

• Mengacu pada contoh kedua Anda: Tampaknya tim proyek membentuk ketergantungan yang erat pada subsistem internal. Fasad yang digabungkan secara longgar tidak hanya untuk kode pihak ketiga. Membuat abstraksi untuk subsistem itu bisa memungkinkan transisi yang lebih mudah untuk menggunakan perpustakaan itu jika solusi internal gagal. Ini adalah solusi logis untuk seorang arsitek perangkat lunak saja, tetapi juga menjadi bentuk Manajer Proyek dengan keprihatinan ekspresi tim, seharusnya dua kali lipat jadi solusi yang jelas.
• Mengacu pada contoh ketiga Anda: Bukan ide yang buruk untuk memiliki arsitektur atau proses yang dikenal untuk memproduksi perangkat lunak (meskipun, memang, Anda memang mengatakan 'semua proyek'). Ini melekat pada apa yang berhasil. Dengan itu, perlu ada peluang di mana teknik baru dapat dicoba untuk melihat apakah mereka membawa nilai tambahan. Perangkat lunak in-house-only, atau proyek dengan cakupan lebih kecil tempat teknologi ini dapat dicoba adalah tempat yang ideal. Perlu diingat, bahwa tanggung jawab juga ada pada pengembang untuk memberikan demonstrasi / argumen yang diteliti dan meyakinkan untuk mengadopsi teknologi. Dan SA tidak bisa diharapkan untuk mengetahui setiap ORM yang bersaing dan kekuatan dan kelemahannya dibandingkan dengan yang lain.