Apa yang harus dilakukan ketika rekan kerja Anda tidak mengerti desain yang berusaha dipertahankan [ditutup]

Proyek perangkat lunak yang sedang saya kerjakan melibatkan saya dan programmer lain. Proyek ini melibatkan backend mesin dengan front end MVC. Awalnya saya melakukan banyak pekerjaan pada proyek dan karenanya menyiapkan beberapa metodologi desain sederhana terutama seputar strategi abstraksi dan template.

Sudah cukup lama saya mematikan mesin dan mengerjakan situs web. Namun saya masih mempertahankan minat pada mesin karena saya diberitahu bahwa saya mungkin akan kembali di beberapa titik.

Proyek ini berada di bawah tenggat waktu yang sangat ketat sehingga kita semua bergegas ingin menyelesaikannya di bagian depan dan belakang.

Saya tidak menganggap diri saya sebagai seorang programmer yang hebat dan karenanya saya tidak pernah mencoba dan memaksakan desain atau set metodologi tertentu pada orang-orang karena saya tidak selalu yakin saya benar dan ingin orang lain menawarkan pendapat mereka untuk mencoba dan datang dengan solusi yang lebih baik. Namun saya telah memperhatikan perubahan yang dilakukan pada kode mesin ini yang benar-benar mulai mengganggu saya. Ketika saya berhadapan dengan pengembang untuk menyarankan dia melakukan pekerjaan dengan cara lain dia mengatakan dia tidak melihat intinya karena tampaknya ada sedikit manfaat mengingat tenggat waktu yang ketat.

Saya harus mencoba dan menjelaskan bahwa haack yang dia masukkan dapat berarti pengembangan lebih lanjut setelah rilis dan saya tidak berpikir adil untuk membuat orang lain mengambil slack ketika kita bisa memperbaikinya sekarang. Saya menghabiskan sekitar 30 menit untuk melakukan apa yang telah saya lakukan dan pada akhirnya dia meminta saya untuk menulis kode sehingga dia bisa menyalinnya.

Dasar dari apa yang saya awalnya setup adalah:

• Kelas abstrak x
• Kelas pabrik abstrak untuk membuat instance konkret x

Apa yang terjadi adalah dia telah meletakkan beberapa pernyataan if yang dapat dengan mudah dimasukkan sebagai metode virtual / abstrace pada kelas abstrak dan kemudian diimplementasikan sesuai dengan perubahan baru mengikuti prinsip yang sama dari metode lain pada kelas abstrak.

Ini tampaknya sepele bagi saya, namun dia bahkan tidak bisa memahami ini bahkan ketika saya menunjukkan kepadanya kelas-kelas yang terlibat.

Sekarang pertanyaan saya adalah:

1. Apakah ini tidak adil untuk berasumsi bahwa ia seharusnya memahami konsep ini. Saya menyadari bahwa kami berada di tenggat waktu yang ketat, tetapi saya pikir itu sepele. Programmer seharusnya setidaknya tingkat menengah.
2. Ini telah terjadi di sejumlah tempat dan saya terus berusaha membuatnya berubah tetapi sepertinya tidak. Haruskah saya mengabaikannya saja?
3. Haruskah saya mengangkat masalah ini di tempat lain, atau hanya menghisapnya dan ketika saya mengembalikan proyek hanya berkeliling mengubah semua hal ini.

Bagiannya dari proyek ini tidak akan selesai yang mengapa saya harus kembali dan membantunya. Saya benar-benar tidak mau juga, karena ia telah mengambil proyek dengan tidak hebat, tetapi arsitektur ok dan benar-benar memasukkan banyak kode berantakan yang lebih sering tidak mengikuti apa yang sedang berusaha dicapai.

Jika pertanyaannya terlalu kabur atau ranty, harap beri tahu saya dan saya akan mencoba dan mengeditnya.

Diedit: Proyek ini diperkirakan akan berlanjut setelah tenggat waktu awal karena sudah ada pekerjaan lanjutan yang direncanakan dan pekerjaan yang kami tidak cocok dan telah disepakati untuk dilaksanakan nanti.

Dari mengawasi mungkin lebih dari 200 pengembang selama 25 tahun terakhir, saya rasa - proporsi pengembang yang secara intuitif nyaman dengan jenis abstraksi desain yang Anda bicarakan - adalah sekitar sepertiga. Pendekatan saya telah berevolusi dari mengharapkan untuk memperbaikinya dengan pembinaan, pelatihan dan dorongan, untuk masih bekerja pada pembinaan dll - tetapi mengakui bahwa kenyamanan ini memiliki kualitas bawaan untuk itu, dan Anda sering tidak dapat mengubahnya. Anda bertanya apakah itu adil. Saya pikir bagian yang tidak adil bagi manajemen Anda adalah mengharapkan anggota tim pengembangan untuk memikul tanggung jawab atas ketegangan ini dan dampaknya. Jika Anda memiliki seorang pemimpin di sekitar - cobalah menjelaskan ketegangan kepada mereka dalam istilah MEREKA bukan milik Anda. Ini bukan tentang pengembang lain - ini tentang efisiensi, dampak dan risiko di masa depan = garis bawah dan karenanya tanggung jawab manajemen yang jelas. Cari solusi organisasi yang mengeksploitasi keterampilan Anda yang relevan. Bisakah Anda mengambil lebih banyak pekerjaan bimbingan desain, dan orang lain melakukan lebih banyak penyelesaian. Jangan berasumsi bahwa semua pengembang tidak menginginkan peran ini - banyak pengembang senang pandai menyelesaikan hal-hal untuk memuaskan pelanggan dengan cepat - dan berterima kasih atas lingkungan desain berkualitas yang disediakan oleh orang lain.

Terkadang ini bukan konsepnya tetapi waktu yang dibutuhkan untuk mengonsumsinya. Orang tidak mendapatkan sesuatu ketika dijelaskan dengan cepat oleh seseorang, tetapi memberi mereka waktu untuk mencari diri sendiri dan kemudian mereka akan mendapatkannya. Terkadang butuh sedikit waktu agar konsep ini bisa diterima.

Saya memahami tenggat waktu sangat ketat, dan pengetahuan terbatas yang mungkin memiliki dampak lebih dari yang Anda inginkan, tetapi dalam kasus ini (dan saya membuat asumsi di sini), apakah Anda mengarahkannya ke dokumen pola desain pabrik , atau apakah Anda hanya mengharapkan dia untuk memahami kode Anda dengan melambaikannya di bawah hidungnya sambil berteriak "Anda hanya tidak mengerti, Anda hanya tidak mengerti" :)

Saya mungkin bahkan telah melakukan hal yang sama pada diri saya sendiri - menunjukkan kepada orang-orang kode itu, mengharapkan mereka untuk langsung mengerti, frustrasi ketika mereka terlihat kosong, memperbesarnya dengan sia-sia untuk membuat mereka mengerti, merasa kesal ketika mereka menjadi semakin bingung, lalu baik menyikut mereka keluar dari jalan dan melakukannya sendiri atau diminta untuk merumput dan melakukannya sendiri jika aku sangat pintar. Semua itu merupakan reaksi yang dapat dimengerti atas upaya saya yang buruk sebagai seorang guru.

Kelas abstrak, pabrik kelas, jangan salah paham, tetapi terdengar seperti artileri untuk membunuh burung. Pola ada untuk memecahkan masalah bukan untuk membuatnya. Anda mengakui bahwa proyek ini adalah proyek 2 orang.

Namun, apa yang dilakukan kolega Anda salah, adalah bahwa ia tidak mengikuti pedoman. Ini akan menyebabkan kekacauan di hilir. Jika proyek itu diabstraksikan dengan segala cara, maka ia harus berusaha mengikuti.

Anda tidak ingin memaksakan pola padanya sejak awal, tetapi Anda bisa melakukan diskusi singkat tentang beberapa hal yang Anda lakukan. Di bawah batasan waktu, saya ragu dia akan dapat memahami konsep Anda cukup untuk dapat mengimplementasikannya secepat 'hack'-nya. Anda ingin dia memperbaiki hal-hal sekarang untuk mencegah orang lain / Anda harus memperbaikinya nanti, tetapi proyek tidak akan selesai tepat waktu. Entah dia tidak mengerti apa yang Anda lakukan atau merasa itu akan memakan waktu terlalu lama dan tidak ada gunanya mengambil risiko penundaan.

Biarkan diketahui saat proyek dapat diselesaikan dan menyampaikan kekhawatiran atas keterbatasan ini di masa depan dan kebutuhan akan waktu tambahan. Anda akan mengalami kesulitan membuat semua orang melihatnya dengan cara Anda jika klien puas. Ini mungkin tidak benar, tetapi itu adalah kenyataan.

Mungkin bukan masalah teknis, jelas bukan masalah pemrograman. Kedengarannya tidak lebih dari debat tradisional "pemrograman untuk kemungkinan masa depan vs tenggat waktu rapat hari ini", yang merupakan kasus khusus "Saya tidak suka cara orang lain melakukan pekerjaannya, saya ingin dia melakukannya dengan cara saya ". Terjadi setiap hari di setiap tempat kerja dengan lebih dari 1 anggota staf.

Keterampilan manajemen dan penjual Anda akan lebih penting daripada superioirty teknis dalam desain Anda jika Anda ingin "memenangkan" yang ini.

Saya sarankan membaca buku-buku seperti "Cara memenangkan pertengkaran dan memengaruhi orang" dan "Apa warna parasut Anda" dan buku keterampilan orang lain.