Manajer saya baru-baru ini mempromosikan saya menjadi "perancang perangkat lunak". Saya tidak tahu bahwa judul ini ada. Sejauh yang saya tahu SA menciptakan desain kode tingkat tinggi dan melakukan diagram.

Saya kesulitan memahami desain kode tingkat tinggi apa yang harus saya lakukan. Menurut manajer saya, saya harus merancang semua kelas dan semua metode di dalam kelas-kelas itu. Yaitu, saya akan merancang seluruh struktur kode, dan membiarkan tim saya mengimplementasikan fungsionalitas setiap fungsi atau kelas. Misalnya, dalam sistem CRUD saya harus dapat merencanakan fungsi apa yang harus digunakan atau kelas apa yang akan dibuat.

Mengingat pengalaman desain perangkat lunak saya, saya merasa ini sangat mustahil dilakukan. Sebagai seorang pengembang, saya selalu membuat kelas saya sendiri, mendefinisikan dan mengimplementasikan fungsi saya sendiri. Saya tidak pernah mengalami mendesain fungsi untuk orang lain.

Pertanyaan saya adalah:

• Apakah ini biasa? Untuk sistem yang sangat besar, bukankah basis kode selalu berubah?
• Bisakah ini dilakukan?

Saya menyadari bahwa saya mungkin mengajukan pertanyaan yang jelas dan bodoh di sini, tetapi saya selalu menjadi pengembang biasa sampai sekarang dan karenanya tidak memiliki pengalaman dalam mendesain seluruh sistem.

Catatan awal tentang judul:

• Terkadang, apa yang sebenarnya Anda lakukan tidak cocok dengan semua judul resmi Anda. Sebagai contoh, bertahun-tahun lalu, saya dipekerjakan sebagai "analis-programmer di departemen R&D"; Namun, tidak ada yang disewa melakukan analisis, pemrograman, penelitian, atau pengembangan. Apa yang saya (dan lainnya) lakukan adalah mengkode. Seekor monyet bisa melakukan setengah dari hal yang saya lakukan. Sarjana magang apa pun bisa melakukan setengah lainnya.

• Seringkali, judul tidak masalah. Di beberapa perusahaan, Anda mungkin akhirnya melakukan banyak tugas yang berbeda dan beragam, dan tidak ada judul yang menjelaskan semua itu. Di satu perusahaan, saya melakukan tugas seorang arsitek, seorang pemimpin tim, seorang manajer, seorang pria UX, seorang pembuat kode dan seorang spesialis produktivitas, dan saya memastikan dua tim berkomunikasi dengan benar satu sama lain. Tidak ada judul tunggal untuk itu.

• Akhirnya, judul mungkin memiliki arti yang berbeda di perusahaan yang berbeda, atau orang yang memberikan judul pada awalnya tidak memiliki gagasan sedikit pun tentang arti sebenarnya dari judul tersebut, jika ada. Dalam beberapa kasus, hanya ada judul dan buzzword yang modis. Anda tidak memerlukan administrator sistem — itu kuno. Anda memerlukan spesialis DevOps. Anda tidak berbicara tentang intelijen bisnis atau penggalian data ketika Anda mencoba mempekerjakan seseorang: Anda berbicara tentang Big Data!

Jadi lupakan judul, dan fokus pada apa yang sebenarnya Anda diminta lakukan. Untungnya, pertanyaan Anda tepat seperti itu.

Apakah ini biasa? Untuk sistem yang sangat besar, bukankah basis kode selalu berubah?

Saya belum melihatnya, dan saya tidak percaya itu bisa berkelanjutan.

Bisakah ini dilakukan?

Ya, tetapi dengan biaya orang normal meninggalkan tim.

Yang mungkin diingat manajer Anda adalah bahwa Anda melakukan desain dan menyajikannya dalam bentuk diagram UML. Itu kuno, tapi siapa yang peduli? Praktik ini cukup populer di beberapa perusahaan, dan masih berjalan dengan baik di perusahaan lain. Ini mungkin merupakan pendekatan yang cocok jika Anda sangat terampil, tetapi semua anggota tim Anda adalah programmer pemula: mereka tidak memiliki cukup pengalaman untuk melakukan desain yang tepat sendiri, dan Anda berada dalam posisi yang sangat baik untuk membantu mereka.

Jika saya jadi Anda, saya akan mulai dengan berbicara dengan manajer Anda, untuk menentukan apakah memang ini yang ada dalam pikirannya. Jika ya, mainkan permainan, dan coba pendekatan ini selama satu atau dua minggu . Apa yang mungkin terjadi?

Entah Anda akan menemukan bahwa pendekatan itu bekerja dengan baik untuk tim Anda, dalam hal ini, berterima kasih kepada manajer Anda untuk wawasannya, atau pendekatan itu tidak akan berhasil.

Dalam hal ini, bicarakan dengan tim Anda terlebih dahulu, untuk mengidentifikasi bersama mengapa tidak berhasil, dan apa yang harus dilakukan untuk meningkatkan proses (dengan kata lain, lakukan retrospektif). Kemudian, baik mengimplementasikan perubahan pada proses jika Anda berada dalam posisi untuk melakukannya, atau kunjungi manajer Anda dan diskusikan dengannya.

Lalu ulangi. Setiap dua minggu (atau apa yang tampaknya sesuai dengan konteks Anda).

Idealnya, Arsitek Perangkat Lunak adalah istilah lain untuk Insinyur Perangkat Lunak Senior , mungkin dengan beberapa tanggung jawab tambahan, atau sebagai cara memberikan pengakuan umum terhadap orang tersebut bahwa mereka adalah titik kontak resmi tentang masalah teknis dengan sistem yang mereka gunakan, atau bahwa anggota tim pengembangan yang kurang akrab dapat mengandalkan mereka ketika mereka tidak tahu mengapa beberapa bagian dari sistem telah dirancang dengan cara tertentu. atau sedang berjuang dengan masalah ketika mereka tidak dapat menemukan solusi yang baik / dapat diterima untuk suatu masalah.

Menurut pendapat saya, seorang Arsitek Perangkat Lunak tidak boleh menjadi seseorang yang bekerja di sebuah 'menara gading' pepatah membuat desain atau membuat keputusan sepihak untuk pengembang lain; keputusan desain harus masih bisa dihalau oleh orang-orang yang secara aktif terlibat dalam menulis dan memelihara kode, dan tim pengembangan harus memiliki tanggung jawab kolektif, dengan pengembang individu yang bertanggung jawab untuk kualitas kode mereka sendiri, untuk memahami desain sistem, dan untuk tidak memperkenalkan perubahan apa pun yang "merusak" arsitektur atau yang memperkenalkan tingkat utang teknis yang tidak dapat diterima.

Meskipun kadang-kadang bisa berharga untuk menangkap desain tingkat tinggi dari suatu sistem sebagai sarana membantu tim perangkat lunak mengkomunikasikan ide-ide dan berbagi pengetahuan (terutama kepada pendatang baru dan pengembang yang tidak berpengalaman), kegiatan utama desain adalah menulis kode itu sendiri (termasuk tes otomatis); Masuk akal bagi Arsitek Perangkat Lunak untuk mengambil 'kepemilikan' dari dokumentasi desain, meskipun itu tidak sama dengan mengatakan merekalah yang menulisnya; lebih dari itu mereka memastikan tim menciptakan dokumentasi yang diperlukan dan memadai, dan tersedia untuk memeriksanya untuk akurasi.

Untuk semua tujuan praktis, ada sedikit atau tidak ada nilai yang bisa didapat dalam mencoba memisahkan peran desain perangkat lunak dari pengembangan karena pada dasarnya hal itu sama - memang kenyataannya biasanya agak berbahaya karena cenderung mengarah pada mentalitas di mana pengembang diperlakukan sebagai "monyet kode" lini produksi yang dilarang berpikir untuk diri mereka sendiri.

Dengan uraian Anda, tampaknya manajer Anda ingin Anda mengambil posisi kepemimpinan dan tidak tahu bagaimana mengartikulasikan hal ini

Dia mempromosikan Anda dan ingin Anda merancang perangkat lunak dan membagi tugas. Kebingungannya tentang cara mengartikulasikan adalah wajar. Dia menempatkan Anda dalam posisi kepemimpinan yang dapat dengan mudah dikacaukan dengan perannya sebagai manajer.

Tim pengembang tradisional memiliki manajer tunggal yang terbagi antara kegiatan eksternal (mencari dana, politik, bakat berburu kepala, menjual ide dan produk, dll.) Dan kegiatan internal (mengkoordinasikan pengembangan). Tetapi kegiatan ini bertentangan dan membutuhkan keahlian yang berbeda. Biasanya "manajer" baik dalam kegiatan eksternal dan buruk pada internal.

Peran ini dapat dipisahkan. Sebenarnya adalah salah satu karakteristik utama dari Metodologi Scrum. Tim sukses dan produktif yang saya tahu memang memisahkan peran itu. Dan sebagian besar bahkan tidak tahu mereka melakukan itu: salah satu programmer mulai mengatur tim dan manajer membiarkannya.

Ini hanya berfungsi jika ada ikatan kepercayaan antara "manajer" dan "pengembang utama". Banyak tim gagal. Ketika salah satu pengembang mengambil kepemimpinan, manajer dapat merasa terancam atau cemburu. Tim dapat kehilangan rasa hormat dari manajer karena dia selalu absen dan mereka tidak mengerti betapa pentingnya kegiatan eksternal. Penting untuk menyadari hal itu dan menghindari masalah itu.

Cara membagi tugas

Untuk membagi tugas, Anda tidak perlu mengikuti teladannya.

Penting untuk penyalahgunaan bukti konsep, prototipe eksplorasi fungsional untuk membuat kemajuan tim lebih terlihat olehnya. Yang penting dia merasa perkembangan itu mengalami kemajuan.

Salah satu cara untuk mencapai itu adalah dengan membuat prototipe sql-only. Buat tabel, isi dengan data, buat hanya kasus uji sql yang menjalankan kueri yang akan dilakukan layar utama dan rutinitas. Ketika Anda yakin bahwa simulasi itu baik, bagi pekerjaan antara pengembang junior Anda untuk membangun layar dan rutinitas. Sementara pengembang junior Anda bekerja, Anda membuat prototipe untuk siklus pengembangan selanjutnya.

Semua orang sibuk, produktivitas tinggi, manajer senang.

Cobalah untuk melakukan beberapa sprint tetapi Anda akan benar-benar mengganggu pengembang yang Anda kelola dan mereka pada gilirannya akan mengerang kepada siapa pun yang mendengarkan.

Saya akan pergi dengan asumsi bahwa Anda menetapkan keputusan arsitektur umum (push vs pull; pola pesan; harus layanan x menjadi DDD atau baik-baik saja CRUD) untuk tim; kemudian menggunakan proses peninjauan kode dan memasangkan untuk menjaga semua orang di jalur dan membantu mereka keluar jika mereka macet.

Itu benar-benar tidak harus top down, kematian oleh UML. Apa yang Anda cari adalah kelas di tempat yang salah; logika bisnis tidak berada di tempat yang Anda harapkan dan seterusnya.

Jangan terlalu keras dalam tim jika mereka mempelajari sesuatu yang diketahui, kerjakan prinsip-prinsip baru terlebih dahulu kemudian bersihkan praktik buruk yang masih ada.