Berurusan dengan rekan kerja saat berkembang, butuh saran [ditutup]

Saya mengembangkan arsitektur proyek kami saat ini dan mulai mengembangkannya sendiri (mencapai sesuatu seperti, revision 40) .

Kami sedang mengembangkan kerangka kerja perutean kereta bawah tanah yang sederhana dan desain saya tampaknya dilakukan dengan sangat baik - beberapa model utama, pandangan yang sesuai, logika utama dan struktur data dimodelkan "sebagaimana mestinya" dan sepenuhnya terpisah dari rendering, bagian algoritmik juga diterapkan terlepas dari model utama dan memiliki sejumlah kecil titik persimpangan.

Saya akan menyebut bahwa desain scalable, dapat disesuaikan, mudah diimplementasikan, berinteraksi sebagian besar didasarkan pada "interaksi kotak hitam" dan, yah, sangat bagus.

Sekarang, apa yang dilakukan:

• Saya mulai beberapa implementasi dari antarmuka yang sesuai, porting beberapa perpustakaan yang nyaman dan menulis potongan implementasi untuk beberapa bagian aplikasi.
• Saya memiliki dokumen yang menjelaskan gaya pengkodean dan contoh penggunaan gaya pengkodean itu (kode tulisan saya sendiri).
• Saya memaksakan penggunaan C++teknik pengembangan yang kurang lebih modern , termasuk no-deletekode (dibungkus melalui smart pointer) dan lain-lain.
• Saya mendokumentasikan tujuan implementasi antarmuka konkret dan bagaimana mereka harus digunakan.
• Tes unit (kebanyakan, tes integrasi, karena tidak ada banyak kode "aktual") dan satu set ejekan untuk semua abstraksi inti.

Saya absen selama 12 hari .

Apa yang kita miliki sekarang (proyek ini dikembangkan oleh 4 anggota tim lainnya):

• 3 gaya pengkodean yang berbeda di seluruh proyek (saya kira, dua dari mereka sepakat untuk menggunakan gaya yang sama :) , sama berlaku untuk penamaan abstraksi kami (misalnya CommonPathData.h, SubwaySchemeStructures.h) , yang pada dasarnya adalah tajuk yang menyatakan beberapa struktur data.
• Tidak adanya dokumentasi untuk komponen yang baru-baru ini diterapkan.
• Apa yang baru-baru ini saya sebut sebagai single-purpose-abstractionsekarang menangani setidaknya 2 jenis acara yang berbeda, memiliki hubungan erat dengan bagian lain dan seterusnya.
• Setengah dari antarmuka yang digunakan sekarang berisi variabel anggota (sic!).
• Penggunaan pointer mentah hampir di mana-mana.
• Tes unit dinonaktifkan, karena " (Rev.57) They are unnecessary for this project".
• ... (itu mungkin bukan segalanya) .

Komit sejarah menunjukkan bahwa desain saya ditafsirkan sebagai sebuah pembunuhan berlebihan dan orang-orang mulai menggabungkannya dengan sepeda pribadi dan roda yang diimplementasikan kembali dan kemudian mengalami masalah dalam mengintegrasikan potongan kode.

Sekarang - proyek masih hanya melakukan sejumlah kecil dari apa yang harus dilakukan, kami memiliki masalah integrasi yang parah, saya berasumsi beberapa kebocoran memori.

Apakah ada yang bisa dilakukan dalam kasus ini?

Saya menyadari bahwa semua usaha saya tidak ada manfaatnya, tetapi tenggat waktunya segera dan kita harus melakukan sesuatu. Apakah seseorang memiliki situasi yang sama?

Pada dasarnya saya berpikir bahwa yang baik (baik, saya melakukan semua yang saya bisa) memulai untuk proyek mungkin akan mengarah pada sesuatu yang baik, namun, saya mengerti bahwa saya salah.

Refactor tanpa ampun untuk keluar dari kekacauan!

Ambil gaya pengkodean yang menyumbang sebagian besar gaya yang dapat digunakan dan gunakan untuk proyek ini.

Yang terburuk adalah, Anda harus kembali ke revisi 40, dan programmer Anda memiliki sesi pelatihan 12 hari, yang memberi mereka pemahaman yang lebih baik tentang subjek.

Jika programmer Anda memiliki banyak hal untuk belajar tentang coding bersih, dua belas hari adalah yang paling sedikit dari penundaan yang Anda miliki.

Parafrase pertanyaan Anda - "Saya pergi selama beberapa minggu dan tidak setuju dengan apa yang tim saya lakukan ketika saya pergi, bagaimana saya membuat mereka melakukan apa yang saya inginkan ketika saya tidak di sini?"

Saya katakan kepada Anda bahwa ini bukan masalah teknis, ini masalah manajemen. Pendapat saya (Maafkan saya jika saya salah) adalah Anda mendikte solusi teknis untuk pasukan antek, yang karena alasan tertentu tidak dapat atau tidak setuju dengan atau memahami solusi Anda.

Jika hanya perlu 12 Hari untuk merusak desain Anda, pasti ada alasannya. Apakah desainnya rapuh? Apakah sudah direkayasa? atau apakah tim hanya melakukannya karena dendam? Seperti apa tenggat waktu dan pengiriman Anda? Ketat? apakah mereka hanya mencoba bertemu satu?

Satu kasus saya telah melihat ini, keunggulan teknisnya jauh di depan permainan sehingga rata-rata pengembang (saya) tidak bisa mengikutinya. Pimpinan teknis gagal mendesain kode yang layak secara komersial, karena dialah satu-satunya yang bisa mempertahankannya. Jika pengembang lulusan tidak dapat mempertahankannya, itu terlalu rumit untuk dunia komersial. Semua kasus lain, itu hanya kurangnya keterampilan manajemen orang di sisi manajemen.

Dinamika tim rusak. Anda dapat (seperti yang disarankan oleh orang lain) menghabiskan waktu untuk memperbaiki kekacauan dan harus melakukan semuanya lagi lain kali saat Anda pergi. Anda mungkin perlu meningkatkan keterampilan anggota tim Anda, tetapi saya percaya Anda harus memperbaiki dinamika tim terlebih dahulu, karena mereka tampaknya memiliki keterampilan yang cukup untuk menyelesaikan pekerjaan, tidak peduli seberapa buruk Anda percaya itu.

Pasangan.

Apa yang Anda gambarkan adalah banyak melakukannya dengan benar, secara teknis, solo . Ya, Anda mencoba mendokumentasikan, mencoba untuk memaksakan standar - tetapi Anda (tampaknya) gagal berkomunikasi.

Ya, tim Anda baru saja berkomunikasi dengan Anda, dengan agak meyakinkan. Mereka berkata, "Hei, Yippie - Anda tidak berkomunikasi!" Bentuk komunikasi paling kuat yang saya tahu adalah berpasangan. Pasangan. Sampai mereka mendapatkannya, atau sampai mereka meyakinkan Anda untuk melakukannya secara berbeda.

Seperti yang dikatakan Brooks kepada kami selama 30 tahun terakhir, integritas konseptual adalah bagian terpenting dari setiap proyek. Untuk setiap subsistem nontrivial dan lengkap, harus ada satu orang, yang bertanggung jawab untuk desain dan memiliki wewenang untuk mengarahkan implementasinya. Ada yang salah dengan bagian ini di proyek Anda. Apa pun itu, satu-satunya solusi adalah mengembalikan ke kode dalam repositori yang ada sebelum itu terjadi. Kehilangan 12 hari tidak bisa dibandingkan dengan biaya pemeliharaan desain yang rusak. Saya juga akan memikirkan cara untuk menghapus orang yang terlibat dalam srewup ini dari pekerjaan lebih lanjut pada proyek ini, karena mereka terbukti tidak kompeten.

Satu hal yang akan saya lakukan sebagai permulaan adalah untuk mendapatkan alat peninjau kode yang baik, menggunakannya untuk menandai kode yang buruk dan mendokumentasikan mengapa itu buruk dan (secara konseptual) bagaimana hal itu harus dilakukan. Sekarang, untuk apa yang saya pahami ada banyak hal buruk yang dilakukan sehingga akan banyak pekerjaan untuk ditinjau; dengan asumsi Anda satu-satunya yang melihat sesuatu yang salah dengan kode, mungkin tidak layak untuk meninjau semuanya sendiri. Tapi Anda bisa menandai pelanggaran terburuk dan mengubahnya menjadi entri dalam sistem pelacakan masalah Anda, ditugaskan kepada orang yang menulis kode yang sesuai.

Insentif terbaik untuk menulis kode kualitas adalah mengetahui bahwa jika Anda tidak melakukannya, itu akan menghantui Anda di masa depan. Rekan kerja Anda tampaknya tidak peduli akan hal itu, jadi obat terbaik adalah membuat mereka memperbaiki bagian yang salah sendiri dan belajar.

Waktu yang diberikan, Anda dapat mengunjungi kembali bagian lain dari kode yang bermasalah dan kembali ditugaskan ke penulis asli (buruk). Setelah beberapa saat, mereka akan menyadari manfaat melakukan pekerjaan dengan baik pertama kali.

Saya berasumsi bahwa Anda tidak menganggap kemunduran ke versi asli Anda sebagai opsi - dengan kata lain, meskipun kode buruk rekan kerja Anda, mereka menambahkan beberapa fungsi dan nilai bersih dari versi saat ini lebih tinggi dari yang asli. Saya juga berasumsi bahwa meskipun bukan itu masalahnya, Anda tidak memiliki modal politik untuk melakukan kemunduran itu dan membuat mereka menulis ulang kode (karena sangat sedikit orang di planet ini yang memiliki modal seperti itu). Ini dan banyak lagi adalah kompleksitas menilai situasi yang tidak saya alami sendiri, tetapi saya berharap dua sen saya membantu.

Satu hal yang belum saya lihat disebutkan tetapi yang muncul baru-baru ini di mana saya bekerja adalah masalah "pengembang silo" dan "beli di".

Pada awal proyek saya saat ini, saya akhirnya merancang perpustakaan inti pada dasarnya sendiri. (Sama seperti Anda telah melakukan hingga rev. 40). Kemudian ketika saya selesai, saya mempresentasikan kepada seluruh anggota tim dan mengatakan kepada semua orang bahwa mereka dapat mulai menggunakannya. Apa yang terjadi di bulan-bulan berikutnya adalah orang-orang terus menerapkan hal yang sama yang sudah ada di perpustakaan ini di tempat lain. CTO (yang secara aktif memberi kode) menunjukkan bahwa tidak pernah ada dukungan dari anggota tim lainnya pada arsitektur / desain / antarmuka publik perpustakaan.

Yah, kami baru saja melalui penulisan ulang utama dari perpustakaan itu yang telah meningkatkan desain secara keseluruhan agar lebih sesuai dengan apa yang kami lakukan saat ini, tetapi sekali lagi pengembang mengambil perpustakaan sebagai satu-satunya proyek mereka, mengerjakannya selama beberapa minggu dan kemudian baru disajikan itu. "Voila! Ini dia! Bukankah cantik?"

Sekarang saya harus menggunakan versi baru dan masalah yang sama ada - saya benci cara dia melakukannya. Dan dia meninggalkan hal-hal yang perlu karena dia gagal berkolaborasi dengan orang lain ketika dia sedang mengerjakannya. Jadi sekali lagi, saya mulai menerapkan hal yang sama di tempat lain dan cara-cara bekerja untuk apa yang perlu saya lakukan.

Singkat cerita - Jika Anda ingin kualitas kode meningkat dan konsisten, saya sarankan agar Anda menyatukan seluruh tim untuk menetapkan standar, gaya, dll. Selain itu, kapan pun orang akan membangun bagian dasar atau inti dari kode Anda. aplikasi, saya akan menyarankan bahwa orang yang bertanggung jawab memimpin seluruh tim dalam merancang kelas, dll sehingga pada akhirnya, seluruh tim harus membeli ke dalam arsitektur aplikasi secara keseluruhan. Plus, jika mereka tahu cara kerja kode anggota tim lain, mereka akan cenderung menerapkannya lagi dengan cara yang berfungsi untuk mereka.

Apakah Anda pengembang senior (atau salah satu pengembang senior) di tim ini? Jika demikian, sepertinya Anda perlu mengadakan beberapa seminar pelatihan tentang praktik terbaik. Anda mungkin harus mengembalikan sebagian besar pekerjaan yang telah dilakukan, mengadakan pertemuan dengan tim Anda, dan menjelaskan cara yang tepat untuk mengimplementasikan fungsionalitas yang diperlukan dengan cara mempertahankan desain yang ada.

Mengingat Anda menghadapi tenggat waktu yang ketat, Anda mungkin harus mengirimkan kode apa adanya, dan refactor (menulis ulang?) Setelah rilis Anda.

Sepertinya Anda perlu mendefinisikan dan menerapkan beberapa praktik kode umum. Apakah Anda memiliki proses peninjauan kode pada pekerjaan Anda? Jika tidak, sepertinya sekarang saatnya menerapkannya. Omong-omong ulasan kode, cara yang bagus untuk mengajarkan praktik terbaik pengembang baru.

EDIT:

Saya mengalami situasi yang sama baru-baru ini. Manajemen di perusahaan saya bersikeras kami menggunakan pengembang kontrak untuk menulis banyak aplikasi kami. Kode yang mereka hasilkan sangat buruk, tetapi kami terpaksa menggunakannya. Sampai hari ini, saya telah menulis ulang 80% kode yang ditulis kontraktor untuk kami. Itu penuh dengan bug dan tidak mungkin diperluas dengan fitur baru. Dalam beberapa bulan lagi tim saya akan menulis ulang semuanya, secara efektif menjadikan uang yang diinvestasikan dalam pengembangan kontrak menjadi sia-sia.

Kode yang buruk benar-benar membutuhkan biaya, itu sesuatu yang Anda mungkin ingin bicarakan dengan manajer Anda, karena Anda mungkin akan membutuhkan bantuan mereka untuk menerapkan dan menegakkan standar pengkodean.

Anda berusaha, tetapi kenyataannya tidak ada yang bertanggung jawab . "Tapi saya lebih suka gaya pengkodean saya", tidak apa-apa. Saya ingin mengerjakan proyek pribadi saya sepanjang hari dan masih dibayar.

Mudah-mudahan, Anda bisa menyajikan ini kepada kekuatan yang ada dan menunjukkan kepada mereka apa yang bisa dilakukan sebagai lawan Wild West Show yang berlangsung selama dua minggu. Sepertinya Anda harus mendapatkan sesuatu dari pintu, tetapi terus menindaklanjuti masalah kurangnya kontrol dan konsistensi.

Fokus pada beberapa hal yang sesuai dengan rencana Anda dan lakukan apa pun yang Anda bisa untuk membuat mereka membantu memperbaiki kekacauan ini dan membawanya pada tim Anda dalam proyek-proyek masa depan. Anda mungkin harus menolak sisanya jika mereka tidak bisa bersama-sama.