Sebagai seorang arsitek perangkat lunak, apakah saya harus fokus pada analisis log dan memperbaiki bug orang lain?

Sejak lulus saya (akhir 2005) saya bekerja di perusahaan yang sama dengan insinyur perangkat lunak c ++. Setahun yang lalu saya dipromosikan sebagai arsitek perangkat lunak tetapi saya semakin terlibat dalam kualifikasi dan memperbaiki bug, dukungan level 2.

50% dari waktu saya dihabiskan di Notepad ++ menganalisis log perangkat lunak dan mencoba mencari tahu apa yang salah. 30% memperbaiki bug orang lain dan sisanya (jika ada) meninjau kode spaghetti pengembang.

Saya mulai membenci produk ini dan berpikir tentang strategi keluar dari perusahaan ini.

Menurut Anda apa yang dapat saya lakukan dalam situasi ini? apakah Anda arsitek perangkat lunak lain masih memperbaiki bug dalam kode?

Kebanyakan orang umumnya setuju bahwa Arsitek Perangkat Lunak sebagian besar harus terlibat dalam desain tingkat tinggi, menetapkan standar, memilih alat atau kerangka kerja, mengevaluasi produk, mengimplementasikan prototipe dan Bukti Konsep, dan melatih dan membimbing pengembang

Kenyataannya adalah bahwa gelar tersebut seringkali dapat berupa penunjukan politis bagi pengembang, gelar khusus yang diberikan untuk memimpin pengembang proyek, atau bahkan sesuatu yang sederhana seperti solusi manajemen-SDM untuk menyewa pengembang yang sangat dibutuhkan dengan gaji atau tarif yang SDM atau manajemen tingkat atas akan merasa tidak dapat diterima untuk judul Pengembang Perangkat Lunak atau Insinyur Perangkat Lunak.

Dengan kata lain, sebagian besar judul tidak ada artinya.

Artikel Wikipedia mendefinisikan arsitek perangkat lunak sebagai:

seorang programmer komputer yang membuat pilihan desain tingkat tinggi dan menentukan standar teknis , termasuk standar pengkodean perangkat lunak, alat, atau platform ...

Yang diberikan di atas, perkiraan Anda "50% dari waktu saya dihabiskan ... menganalisis log software ... 30% memperbaiki lain bug" membuat Anda jauh jauh dari apa software arsitek yang biasanya diharapkan untuk melakukan.

• Saya akan mengatakan di atas membuat judul yang mereka berikan tentang 50+30=80%palsu.

Perhatikan bahwa kegiatan seperti menganalisis log atau memperbaiki bug orang lain dapat secara sah mengisi sebagian waktu arsitek - asalkan ini melayani tujuan utama dari peran ini - yaitu, membuat pilihan desain tingkat tinggi dan menetapkan standar teknis. Sebenarnya, ini adalah kasus untuk semua jenis pengembangan perangkat lunak / pemeliharaan / kegiatan pengujian.

Misalnya, jika menganalisis log menuntun Anda ke wawasan tentang bagaimana membuatnya lebih mudah - dengan meningkatkan desain, atau tooling, atau standar pengkodean - ini akan menjadi upaya yang dapat dibenarkan secara sempurna untuk seorang arsitek. Demikian pula, itu bisa sepenuhnya OK untuk arsitek untuk mendapatkan tangan mereka kotor memperbaiki bug (s) - selama ini akan menghasilkan perbaikan desain / proses spesifik yang mengarah ke tingkat bug yang lebih rendah, dll.

_{Pada catatan yang sedikit lebih positif, pertanyaan Anda menunjukkan setidaknya satu keterampilan yang cukup penting bagi arsitek: kemampuan untuk mengklasifikasikan berbagai jenis kegiatan dan melacak upaya yang dihabiskan untuk ini. Pertimbangkan untuk menambahkan keterampilan pelengkap "kotak peralatan" Anda untuk meringkas pengamatan dan perkiraan Anda dan mengomunikasikannya dengan jelas, terutama menaiki tangga manajemen. :)}

Sebagai seorang arsitek perangkat lunak, apakah saya harus fokus pada analisis log dan memperbaiki bug orang lain?

Seharusnya? iya dan tidak. Anda bertanggung jawab atas totalitas kualitas produk dan jalur evolusi - membuatnya bekerja besok, tetapi juga membuatnya bekerja tahun depan.
Apakah itu berarti memberikan bantuan untuk menyelesaikan masalah sulit? Tentu - setidaknya saya tahu. Anda tidak dapat membuat produk berfungsi besok jika pelanggan meninggalkan Anda.
Apakah itu berarti Anda harus mencurahkan SEMUA waktu Anda untuk itu? Benar-benar tidak. Anda bertanggung jawab atas TOTALITAS kualitas dan evolusi. Mengabdikan banyak waktu untuk mengejar masalah tidak produktif.

Anda seharusnya proaktif:

1. Memulai rencana pendidikan sehingga orang lain (dev / support) dapat mengangkat beban. "Mengajari manusia memancing" dan semua musik jazz itu.
2. Temukan cara dan kembangkan alat untuk mendukung analisis cacat yang lebih cepat dan lebih mudah dan isolasi penyebab utama. Jika Anda menemukan ini membosankan, yang lain, mungkin pengembang yang kurang berbakat atau berpengalaman menemukan ini tidak hanya membosankan, tetapi juga sulit dan mungkin bahkan menakutkan. Bantu mereka mengatasinya dengan teknologi.
3. Mulailah upaya untuk meningkatkan kualitas produk - sederhanakan, modulasi, buat kerangka kerja pengujian - pimpin dengan contoh, bukan dengan merengek dan mengancam untuk berhenti.
4. Pastikan pengembang tahu apa yang Anda lakukan - tetapi juga manajer Anda. Peran arsitek lebih banyak tentang hubungan dengan orang lain daripada tentang pengkodean dan analisis. Sebanyak mungkin Anda membenci ini, politik memainkan kunci di sini. Pastikan teman-teman Anda melihat prestasi Anda membuatnya lebih mudah untuk meyakinkan mereka nanti bahwa Anda benar. Jika Anda belum ada di sana, kembalikan klaim Anda dengan penelitian dan POC.
5. Jika semuanya gagal, dan hanya setelah menghabiskan waktu untuk mencoba memperbaiki keadaan, bicarakan dengan manajer Anda. Katakan bahwa keterampilan Anda lebih baik digunakan dalam fase perencanaan dan desain dan lihat apa yang dapat dilakukan untuk mengubah situasi saat ini. Produk Anda mungkin dalam keadaan darurat dan jawaban manajer Anda mungkin "kami membutuhkan Anda untuk hal ini di sini, saat ini". Saya akan bersikeras pada rencana jangka panjang - bagaimana kita akan mengubah situasi saat ini.

Saya melihat peran seorang arsitek sebagai hak istimewa. Anda dapat mempengaruhi produk dengan cara yang tidak banyak orang lain - satu-satunya yang secara teoritis lebih berpengaruh daripada Anda adalah dia manajer R&D produk (dan, mungkin, pemasaran) - tetapi dia cara untuk sibuk mengelola.

Peran seorang Arsitek Perangkat Lunak secara tradisional tidak meminta mereka memperbaiki bug. Arsitek Perangkat Lunak memang membantu memperbaiki masalah desain dalam perangkat lunak sehingga jika dengan bug yang Anda maksud, inti cara perangkat lunak itu dirancang cocok untuk kerapuhan atau kesulitan dalam memperluas / memelihara maka akan menjadi tugas SA untuk mengusulkan atau mendesain ulang aspek-aspek dari perangkat lunak tersebut. perangkat lunak untuk menyelesaikan masalah itu.

Mengingat apa yang Anda katakan:

50% dari waktu saya dihabiskan di Notepad ++ menganalisis log perangkat lunak dan mencoba mencari tahu apa yang salah. 30% memperbaiki bug orang lain dan sisanya (jika ada) meninjau kode spaghetti pengembang.

Itu bukan peran SA sejati dan sebaliknya lebih dari apa yang saya inginkan untuk programmer 1 dan pengembang 2 level kami mulai bersama dengan pengembang senior. Saya mengatakan itu secara khusus karena saya merasa ini sangat membantu pengembang baru di perusahaan kami masuk ke produk dan kode dengan bekerja pada level itu pada masalah kualitas kode. Apakah Anda SA baru di perusahaan Anda dan mereka meminta Anda melakukan pekerjaan ini untuk masuk ke sistem? Jika demikian maka mungkin itu OK untuk waktu yang singkat. Jika ini adalah pekerjaan harian Anda dan telah berlangsung lebih dari satu tahun, maka sangat mungkin inilah saatnya untuk mencari peran lain.

Saya memahami frustrasi Anda, tetapi mengerti jika Anda menulis kode atau yang terakhir menyentuhnya, waktunya singkat, dan mereka dapat menjangkau Anda, banyak manajer akan mendatangi Anda untuk memperbaikinya, terlepas dari judul Anda.

Mengira bahwa Anda masih memiliki teman di grup pengembangan yang sedang dalam krisis, Anda akan membantu. Masalahnya adalah ketika mereka, dan yang lebih penting manajemen mereka terbiasa membantu Anda, mereka terus datang kembali. Seperti kata "tidak ada perbuatan baik yang tidak dihukum." Jika mereka dapat mengandalkan Anda untuk memperbaiki masalah, terlepas dari judul Anda, Anda hanyalah pengembang lain, dan orang lain yang dapat mereka gunakan.

Ini adalah masalah yang sulit untuk dipecahkan, tetapi saran saya adalah:

1. Mintalah nomor tagihan untuk proyek ini, waktu proyek arsitek non-perangkat lunak. Saya menemukan manajer proyek tidak bersemangat untuk meminta waktu Anda, jika mereka harus bertanggung jawab untuk itu.

2. Bicaralah dengan manajer Anda tentang berapa banyak waktu yang hilang dan kepada kelompok atau proyek apa. Manajer Anda mungkin memberi tahu Anda untuk tidak membantu mereka, dan tetap fokus pada proyek-proyeknya. Jika demikian, maka kelompok lain datang dan meminta bantuan, Anda memberi tahu mereka bahwa bos Anda juga mengatakan tidak.

3. Atur pekerjaan Anda, jaga prioritas Anda, dan jangan terlalu responsif terhadap proyek arsitektur Anda.

4. Bertindak seperti seorang arsitek, buat rekan-rekan Anda melihat Anda sebagai seorang arsitek, bukan sebagai pengembang yang sama seperti yang Anda alami selama ini. Anda telah mematahkan kebiasaan orang lain untuk memperlakukan Anda sama seperti pengembang.

Semoga berhasil.

Tidak, Anda di sini untuk mengelola gambaran besar.

Anda memiliki masalah manajemen: memperbaiki bug dan meningkatkan kualitas kode adalah tugas pengembang, sebagai arsitek Anda harus mengeluarkan pedoman dan arsitektur aktual (UML atau apa pun yang mengapung perahu Anda), kemudian memberikan ulasan kode reguler untuk memastikan pedoman ini diikuti dengan benar .

Namun, Anda dapat menerapkan dan memperbaiki bug pada arsitektur inti.

Contoh: Anda akan bekerja pada PRISM, MEF dll dalam proyek WPF / C #, tetapi Anda tidak akan bekerja pada XAML untuk menampilkan splashscreen.

Anda akan bekerja pada desain DB tetapi Anda tidak akan menulis prosedur tersimpan untuk operasi CRUD.

dll.

Sebagian dari jawabannya adalah menemukan seorang insinyur yang bersedia mengambil beban ini.

Tentu saja, alasan masalah ini adalah karena Anda menemukan pekerjaan ini tidak diinginkan, yang tidak mengirimkan pesan bahwa itu menarik bagi para insinyur lain, sehingga mereka juga tidak ingin mengambilnya.

Saya melihat dua kemungkinan.

1. Anda diberi posisi arsitek sehingga Anda dapat mengerjakan item gambar yang lebih besar.
   Dalam hal ini, Anda harus menyebutkan kepada manajemen bahwa Anda tidak dapat mengerjakan item gambar yang lebih besar ini karena tidak ada yang melangkah untuk mengambil peran dukungan tingkat rendah. Itulah masalah mereka untuk dipecahkan.

2. Judulnya sebagian besar seremonial - tulang yang dilemparkan kepada Anda untuk membuat Anda tetap ada.

Dalam hal ini, manajemen mungkin tidak terlalu tertarik untuk meringankan beban dukungan Anda.

-

Satu hal yang pasti tidak akan membantu tujuan Anda adalah mengadopsi sikap penghinaan terhadap pengembang dan insinyur lain yang saya lihat bocor dalam pertanyaan Anda. Anda ingin orang-orang ini melangkah dan dengan percaya diri menangani masalah ini sehingga Anda tidak perlu (mungkin membuat beberapa kesalahan di sepanjang jalan). Jika mereka tahu bahwa Anda hanya akan mengomel solusi mereka dan memperbaikinya untuk mereka setelah itu, mereka mungkin tidak akan pernah melangkah.

50% dari waktu saya dihabiskan di Notepad ++ menganalisis log perangkat lunak dan mencoba mencari tahu apa yang salah. 30% memperbaiki bug orang lain dan sisanya (jika ada) meninjau kode spaghetti pengembang.

Ini jelas merupakan jenis pekerjaan yang TIDAK seharusnya Anda lakukan, untuk peran ini. Menurut pengalaman saya / pengamatan, arsitek harus terlibat dalam desain aplikasi, perbaikan, klarifikasi persyaratan teknis dan masalah kinerja potensial (tidak memeriksa log setiap hari, tetapi terutama menganalisis beberapa masalah / kesalahan) yang perlu ditangani atau dihindari.

Dengan kata lain, poin saya nomor 1 adalah - arsitek adalah desainer tingkat tinggi dan integrator sistem dengan pengalaman langsung tentang bagaimana kerja teknologi dalam bekerja / menerapkan dan perlu digunakan.

Jika Anda memiliki kesempatan untuk menetapkan dan mengelola kualitas kode maka keterampilan manajemen kerja Anda perlu ditingkatkan. Dengan demikian, pekerjaan perencanaan harus menjadi prioritas Anda pada pendekatan "bagaimana melakukan pekerjaan".

Poin # 2 : jika Anda salah satu dari sedikit pengembang dalam aplikasi ini - maka judul ini hanyalah lapisan gula lain oleh manajemen perusahaan untuk membuat Anda tetap dalam peran "perbaiki" yang sama dengan judul mewah yang baru .

Peran seorang Arsitek Perangkat Lunak jauh lebih dari apa yang Anda lakukan di perusahaan Anda saat ini. Dia bertanggung jawab untuk menentukan standar desain perangkat lunak, membuat desain tingkat tinggi, standar untuk pengkodean dll., Dan memperbaiki bug dapat dianggap hanya sebagian kecil dari yang dianggap sebenarnya bukan. Tetapi seperti yang telah Anda katakan, Anda sedang mengerjakan suatu produk, itu artinya, menjadi seorang arsitek Perangkat Lunak, harapan dari Anda untuk keandalan produk akan sangat tinggi, dan dalam kasus seperti itu, keterlibatan Anda dalam hal-hal seperti itu tidak hanya akan membantu produk tetapi juga perusahaan, karena Anda cukup berpengalaman dalam hal itu. Tetapi Anda juga harus diberikan beberapa paparan pengembangan fitur baru dan tugas-tugas baru, yang akan menanamkan minat Anda pada organisasi Anda saat ini.

Sebagai seorang arsitek perangkat lunak, apakah saya harus fokus pada analisis log dan memperbaiki bug orang lain?

Dalam masalah berbicara, 'Ya'.

Begini cara saya memenuhi syarat jawaban saya:

1. Secara default, Anda harus membiarkan pengembang perangkat lunak menganalisis log dan memperbaiki bug.
2. Namun ... Anda harus mewaspadai cacat yang menyebabkan hilangnya data, memerlukan pengembalian basis data yang berat, membutuhkan waktu lama bagi pengembang untuk menyelesaikannya, atau memerlukan permintaan maaf pelanggan.
   1. Sebagai aturan, laporan langsung Anda harus memberi tahu Anda tentang kerusakan tersebut.
   2. Anda harus membuat budaya di mana laporan langsung Anda merasa diberdayakan untuk memberi tahu Anda tentang cacat tersebut, tetapi tidak dipaksa untuk memberi tahu Anda tentang yang sepele.

Lebih lanjut tentang # 2:

1. Jenis cacat ini umumnya menyiratkan kegagalan arsitektur. Ketika mereka melakukannya, Anda harus memahami sifat yang tepat dari cacat dan arsitek memperbaiki.
   1. Jadi, dengan ekstensi, Anda harus siap, mau, dan mampu menyaring log dan memperbaiki bug orang lain (bahkan jika Anda tidak secara langsung melakukan kode ke repositori kode sumber).

Jawabannya mungkin tidak. Mengapa Anda menghabiskan begitu banyak waktu untuk debugging dan mendukung masalah? Apakah seseorang menugaskan itu bekerja untuk Anda?

Sepertinya Anda perlu mengklarifikasi apa yang seharusnya Anda lakukan. Anda mungkin perlu memperbaiki bug; yang mungkin seharusnya tidak menjadi mayoritas waktu Anda.