Bagaimana cara mengubah seorang programmer copy / paste / spaghetti untuk melihat cahaya?

Pertanyaan ini terinspirasi oleh pertanyaan ini . Sementara pertanyaan lain itu dianggap terlokalisasi, saya percaya masalah mendasarnya adalah sesuatu yang sangat umum di industri kami. Saya tahu ada beberapa pengembang, yang akan membaca ini dan berpikir saya membuat hal ini dan kemudian mereka mungkin menjawab bagaimana semua orang peduli dengan pekerjaan mereka dan ingin belajar, tetapi hanya melihat posting Programmer SE lainnya ( contohnya ), Saya tahu itu tidak benar secara universal.

Jadi katakanlah Anda memiliki seseorang di tim Anda (atau mungkin mayoritas) yang prosedur operasi standarnya adalah untuk menyalin / menempel dan yang percaya bahwa semuanya dapat diselesaikan jika hanya Anda menambahkan cukup panggilan fungsi dan variabel. Orang ini tidak pernah mendengar TDD, KERING atau SOLID dan di luar 40 jam di tempat kerja ketika mereka sibuk bekerja, mereka tidak pernah membaca satu metodologi / praktik / buku desain.

Di masa lalu saya (dan yang lainnya) bertanya, bagaimana Anda mengajar OOD . Tapi sekarang saya berpikir itu bukan pertanyaan yang tepat. Pertanyaan sebenarnya adalah bagaimana Anda mendekati orang / tim tersebut dan membuat mereka ingin tahu tentang cara yang lebih baik dalam melakukan sesuatu? Bagaimana Anda menginspirasi mereka untuk belajar? Tanpa itu, tampaknya semua pengajaran, pertemuan, ceramah, diskusi tidak berguna jika mereka benar-benar bahagia kembali ke meja mereka dan melakukan apa yang selalu mereka lakukan.

Saya bekerja dengan banyak orang seperti itu. Mereka sebenarnya adalah individu yang cukup cerdas, tetapi saya benci ketika saya mendengar, "Saya selesai mengkode, hanya perlu refactor dan dibagi menjadi beberapa kelas untuk membuat DXM bahagia". Mereka tidak melakukan refactor untuk kode yang lebih bersih, mudah dibaca, dapat dipelihara, tetapi hanya karena jika tidak mereka akan dimarahi. Saya tahu mereka mampu belajar, sepertinya ada sedikit motivasi.

Ketika saya memberikan pekerjaan, umumnya bug memiliki cara yang lebih sedikit dan pekerjaan yang saya miliki tidak pernah menjadi 5.000 baris kelas. Yang lain akan membuat komentar seperti, "kode Anda jauh lebih bersih dan mudah dibaca daripada barang-barang kami", sehingga mereka melihat perbedaannya. Tetapi pada saat yang sama, saya merasa mereka percaya bahwa mereka dibayar selama 40 jam terlepas dari apa yang mereka lakukan, jadi mereka sebenarnya tidak keberatan jika mereka menghabiskan 3 hari penuh di QA mencari bug yang seharusnya tidak diperkenalkan di posisi pertama. Atau mereka membutuhkan waktu satu minggu untuk memodifikasi satu kelas karena ada begitu banyak dependensi yang akhirnya mereka sentuh. Namun, "mungkin kelas itu seharusnya ditulis secara berbeda" sepertinya tidak pernah muncul.

Adakah yang bisa dilakukan dalam situasi ini? Adakah yang berhasil? Atau yang terbaik adalah mengisolasi pola pikir seperti itu ke bagian-bagian proyek yang tidak kritis dan meminimalkan kerusakan?

CATATAN: Ketika saya mengatakan "kurangnya motivasi". Saya tidak berpikir itu kurang motivasi untuk bekerja atau melakukan pekerjaan dengan baik karena mereka hanya berhenti peduli. Sebagian besar tim kami sebenarnya justru sebaliknya. Mereka pasti peduli dengan produknya. Kami memiliki orang-orang yang akan bekerja malam dan akhir pekan. Bagian yang saya coba lalui adalah dengan kebiasaan dan keterampilan yang lebih baik, mereka sebenarnya tidak perlu bekerja terlalu banyak. Saya kira "40 jam" membuat pos ini terdengar agak terlalu negatif.

Anda mendapati diri Anda alasan: "Saya tahu mereka mampu belajar, sepertinya ada motivasi yang kurang."

Ada orang yang bersemangat dengan pekerjaan mereka. Dan ada orang lain yang, kadang-kadang cukup kompeten, bekerja hanya demi uang . Mereka tahu barang-barang mereka, tetapi mereka tidak menikmati pekerjaan mereka. Mereka tidak akan menghabiskan waktu ekstra melakukan refactoring tambahan untuk membuat kode dapat dibaca atau memecahkan masalah yang menarik ketika peretasan cepat dan jelek dapat melakukan pekerjaan.

Fenomena ini ada di setiap pekerjaan. Hanya saja beberapa pekerjaan tidak terlalu menarik (pernahkah Anda melihat seorang akuntan yang mencintai pekerjaannya dan sudah memimpikannya ketika ia masih kecil?), Tetapi dalam pemrograman, ada banyak orang yang benar-benar mencintai apa yang mereka lakukan (jika tidak Programmer.SE akan sangat kosong). Ini berarti bahwa sebagai pengembang yang bersemangat, yang berbicara setiap hari dengan pengembang yang bersemangat lainnya, kami memiliki lebih banyak peluang untuk terkejut melihat seseorang yang melakukan pemrograman hanya demi uang.

Apa yang bisa kita lakukan? Tidak terlalu banyak. Dalam semua kasus, itu bukan untuk Anda, tetapi untuk sumber daya manusia untuk memilih orang yang benar-benar termotivasi motiv. Dan memecat orang yang tidak.

Anda dapat mencoba memotivasi rekan Anda sendiri, tetapi itu sangat sulit. Jika Anda memberi mereka buku untuk dibaca, mereka akan mengembalikannya tanpa dibuka beberapa minggu kemudian. Jika Anda memberi mereka saran, mereka tidak akan mendengarkan, karena mereka tidak peduli².

Kamu bisa:

• Meyakinkan atasan Anda untuk menetapkan sejumlah aturan ketat di perusahaan Anda: pedoman gaya , dll. Ini tidak akan memotivasi orang-orang itu untuk melakukan pekerjaan yang lebih baik, tetapi setidaknya mereka tidak akan dapat melakukan kode sumber yang tidak sesuai dengan persyaratan .

• Bekerja pada persyaratan, terutama persyaratan non-fungsional . Bagaimana dengan persyaratan yang mengatakan bahwa suatu proyek tertentu harus mengandung kurang dari 5.000 baris kode IL (tidak, saya tidak berbicara tentang LOC yang tidak berarti ) ³? Bagaimana dengan keharusan untuk mendapatkan hasil spesifik pada kompleksitas siklomatik atau kopling kelas ?

• Tingkatkan jumlah jam yang Anda habiskan di perusahaan Anda untuk melakukan tinjauan kode . Tentukan apa yang ditinjau: jika Anda memiliki daftar periksa, tambahkan poin yang terkait dengan refactoring, keterbacaan, komentar yang bersih dan berguna, dll. Jika Anda tidak memiliki daftar periksa, Anda harus.

• Gunakan pemrograman pasangan [lebih] . Ini dapat membantu meningkatkan kualitas kode dan memotivasi rekan kerja yang kurang termotivasi.

• Gunakan sistem kompensasi yang mirip dengan apa yang digunakan di Fog Creek.

^{¹ Tentang wawancara: sebelum mempekerjakan Anda, sumber daya manusia harus memiliki aset tidak hanya tingkat teknis Anda, tetapi juga motivasi Anda . Sayangnya, beberapa perusahaan melupakan bagian kedua dari wawancara ini, dan merekrut orang-orang yang tidak terlalu menikmati pemrograman. Untungnya, dalam kebanyakan kasus, pekerjaan di mereka perusahaan tidak pernah menyenangkan, dan uji Joel jarang melebihi 2.}

^{² Mereka benar - benar tidak peduli, bahkan jika mereka mendapat lebih sedikit uang. Saya cukup dekat dengan salah satu pelanggan saya (saya seorang freelancer) yang percaya bahwa pekerjaannya adalah mengembangkan situs web untuk pelanggannya sendiri. Dia juga punya desainer. Saya memberi tahu mereka berkali-kali tentang cara mereka dapat meningkatkan produktivitas mereka sebesar 2 atau lebih. Jika mereka hanya mempekerjakan seseorang yang kompeten, mereka akan meningkatkan pendapatan mereka setidaknya 3. Namun mereka memiliki cukup uang, dan tidak peduli dengan kualitas atau berapa biayanya bagi pelanggan yang tidak tahu, dibandingkan dengan seseorang yang produktif.}

^{³ Yang saya maksud adalah jumlah baris kode IL yang Anda lihat di Kode Metrik dalam Visual Studio , metrik yang sebenarnya berarti sesuatu. The nyata LOC tidak masalah dan Anda tidak perlu mengukurnya; itu salah satu metrik paling bodoh yang pernah ada. Menegakkan garis-garis kode IL berarti bahwa pengembang akan dipaksa untuk benar-benar memperbaiki kode, dan tidak hanya menutup sepuluh baris kode dalam satu baris yang tidak dapat dibaca.}

"Saya sudah selesai coding, hanya perlu refactor dan dibagi menjadi beberapa kelas untuk membuat DXM senang".

Cara berpikir seperti itu ada kanker pada tim mana pun dan akan mematikan motivasi seluruh tim jika tidak segera diurus. Tentu saja saya merujuk pada fakta bahwa dengan senioritas dan / atau prestasi Anda berada pada posisi otoritas teknis, memberi Anda kekuatan untuk membantu mempengaruhi dan membawa praktik-praktik baik ke dalam tim Anda.

Ini semua baik dan bagus, namun jika tim Anda jelas dijual pada proses ini, mereka tidak akan memilih Anda dalam pernyataan seperti ini satu sama lain yang jelas menunjukkan kurangnya rasa hormat terhadap proses dan kurangnya rasa hormat pada Anda. Mereka masih melihat praktik terbaik ini sebagai penghalang yang disebabkan oleh Anda dan bukan proses yang dimiliki oleh tim yang tim Anda akan pertahankan dengan kemampuannya sendiri.

Anda menyebutkan dalam komentar sebelumnya bahwa anggota tim lain memang mengikuti praktik dan standar ini dengan baik dan menerapkannya dengan benar. Pertama-tama fokuskan perhatian pada dukungan dari mereka, tanyakan pada mereka apa yang berhasil, apa yang tidak berhasil, apa yang mereka sukai dan apa yang ingin mereka lihat berubah. Jika Anda melakukan ini dan menanggapi pendapat mereka dengan serius, mereka akan merasa sangat berbeda tentang standar seolah-olah itu adalah keputusan masyarakat alih-alih prosedur yang diturunkan kepada mereka dari atasan.

Anda mendukung dukungan untuk praktik terbaik dan standar dengan menunjukkan kepada tim bagaimana mereka telah meningkatkan proses pengembangan perangkat lunak atau kualitas perangkat lunak.

Berikan suara pada masalah untuk diskusi dan dokumentasikan hasilnya, idealnya setiap keputusan harus bulat demi legitimasi tetapi jika Anda berurusan dengan penyumbat garis keras ini mungkin tidak mungkin dan bisa menghentikan setiap masalah. Gunakan suara mayoritas dalam situasi ini. Jika mayoritas bertentangan dengan standar dan praktik yang Anda usulkan maka Anda sudah kehilangan ruang itu, menyerah saja pada saat itu.

Mereka akan memiliki standar dan prosedur itu dan akan menegakkannya sehingga Anda tidak perlu melakukannya. Sebagai pemimpin teknologi Anda tidak harus mendeklarasikan dekrit dan dekrit, itu adalah cara yang buruk untuk menjadi seorang pemimpin.

Begitu tim merasa seolah-olah mereka memiliki prosedurnya maka anggota tim yang mulai memberi label Anda pada prosedur tertentu dan praktik terbaik akan menjadi tidak sah untuk berpikir demikian. Tim Anda akan membantu memperbaiki sikap ini pada orang lain.

Pertanyaan bagus! Saya pikir jawabannya tergantung pada mengapa orang tidak ingin meningkatkan keterampilan mereka. Kemungkinan jawaban adalah:

• Mereka pikir mereka terlalu sibuk untuk mempelajari sesuatu yang baru atau mereka berpikir cara baru dalam melakukan sesuatu (seperti menulis semua tes) akan memakan waktu lebih lama dan mereka tidak punya waktu untuk itu. Maka jawaban yang jelas adalah: beri mereka lebih banyak waktu. Mempelajari sesuatu atau mencoba sesuatu seperti TDD ketika Anda selalu melakukan hal-hal yang berbeda akan membutuhkan lebih banyak waktu beberapa kali pertama. Jika programmer Anda tidak punya waktu, Anda tidak dapat menyalahkan mereka karena tidak mencoba.
• Mereka memiliki persepsi yang berbeda tentang keterampilan mereka sendiri, yaitu mereka pikir mereka adalah programmer yang sangat baik menghasilkan kode berkualitas tinggi. Ini adalah medan psikologis yang sulit, karena menghancurkan kepercayaan itu bisa sangat melemahkan semangat. Mungkin beberapa jenis kompetisi informal dapat membantu (siapa yang menghasilkan cacat / fitur paling sedikit? Kode terpendek? WTF paling sedikit / menit dalam tinjauan kode?).
• Mungkin ada masalah motivasi yang sebenarnya (yaitu mereka hanya ingin "melakukan waktu dan dibiarkan sendiri" sampai waktu penutupan). Untungnya, ini terlalu umum / tidak berhubungan dengan pemrograman, karena saya benar-benar tidak punya jawaban untuk itu.
• Mereka pemula dan mereka tidak tahu yang lebih baik. Dalam hal itu, pelatihan, ulasan kode mungkin membantu, atau "klub buku" di mana anggota tim harus mendiskusikan buku teknis baru setiap bulan.
• Mereka telah melihat peluru perak sebelumnya, (dan sangat kecewa) dan mereka berpikir apa pun yang Anda coba jual adalah hanya kata kunci baru yang terdengar bagus secara teori dan jarang digunakan dalam praktik. Dalam hal itu, mendemonstrasikan keuntungan selama ulasan kode dan sesi pemrograman pasangan mungkin bekerja. Usahakan untuk tidak sepenuhnya tahu segalanya saat Anda melakukannya.

Solusi terbaik benar-benar tergantung pada masalah root: Misalnya, pedoman pengkodean formal, metrik dan ulasan dapat bekerja untuk pemula, tetapi orang-orang di "persepsi yang salah tentang keterampilan mereka sendiri" -crowd mungkin berjuang melawan mereka atau memainkan metrik karena mereka melihat mereka sebagai penghalang birokrasi yang kontraproduktif untuk menyelesaikan pekerjaan mereka.

Pertanyaan sebenarnya adalah bagaimana Anda mendekati orang / tim tersebut dan membuat mereka ingin tahu tentang cara yang lebih baik dalam melakukan sesuatu? Bagaimana Anda menginspirasi mereka untuk belajar? Tanpa itu, tampaknya semua pengajaran, pertemuan, ceramah, diskusi tidak berguna jika mereka benar-benar bahagia kembali ke meja mereka dan melakukan apa yang selalu mereka lakukan.

Itu dia! Ini memang pertanyaan nyata.

Untuk memberikan backgound, Kami hanya tidak punya waktu untuk melakukan banyak pelatihan formal - tetapi kadang-kadang jika saya lakukan - itu masih tidak melihat cahaya. Saya juga telah menjadi bagian dari perusahaan di mana pelatihan formal menjadi proses itu sendiri tetapi dan Saya sering menjadi saksi bahwa mereka jarang mengajar mereka cara berpikir.

Jadi pertanyaan yang saya ajukan kepada mereka bukanlah bagaimana mengajar mereka - tetapi bagaimana membuat mereka belajar? Perbedaannya halus tetapi apa yang akan membuat semua perbedaan.

Saya tidak tahu apakah saya benar; tetapi sering saya percaya pada dialog dari Matrix film - "Ini pertanyaan yang mendorong kita!" Yang paling penting adalah membuat mereka berpikir, membuat mereka bertanya mengapa! Dan tentu saja, sebagian besar yang berpikir mereka sudah tahu segalanya tentang beberapa pola desain karena mereka mendapat nilai bagus di program universitas - adalah yang paling sulit di sana.

Bagaimana Anda membuatnya menjadi pertanyaan seperti itu? Pendekatan umum saya adalah "yang melemparkan mereka ke dalam kolam jika Anda ingin mereka belajar berenang" . Saya setuju bahwa orang mungkin tidak setuju; dan saya dengan senang hati akan setuju untuk tidak setuju dengan mereka. Ketika Anda melemparkannya ke kolam - mereka sebenarnya tidak belajar berenang secara otomatis; tetapi itu memunculkan naluri bertahan hidup yang membuat mereka berpikir - begitu itu terjadi mereka secara alami akan memikirkan BAGAIMANA dan MENGAPA.

Sebuah contoh praktis yang saya berikan kepada orang-orang adalah menempatkan mereka dalam proyek yang sangat kompleks daripada apa yang mereka harapkan untuk mendapatkannya dan membiarkan mereka bertarung dalam pertempuran mereka sendiri. Ketika mereka mulai mengurai kode dan merasa sulit untuk melacaknya - Anda menyadari bahwa mereka mulai mengajukan pertanyaan yang bagus.

Ini mungkin terdengar agak ekstremis, ini mungkin terdengar pemborosan sumber daya . Dan saya yakin, ada banyak orang lain yang akan memberi saya saran untuk tidak melakukan ini. Tetapi ini berhasil bagi saya!

Tidak peduli apa paket pembayaran dan tag SDM yang Anda tetapkan tidak akan menyelesaikan masalah motivasi dasar . Untuk itu satu-satunya jalan adalah mereka ditantang; Jika Anda mencetuskan semangat dasar manusia ini - segalanya berfungsi. Jika Anda tidak bisa, itu adalah permainan longgar.

PS: Hanya kebetulan saya memposting jawaban di sini https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034 - dan saya mendapatkan semua bashing; terutama kebanyakan orang percaya bahwa entah bagaimana bisnis tidak mampu membuang sumber daya! Saya yakin, jawaban ini mungkin mendapatkan perlakuan serupa di sini. Tetapi kebenarannya adalah, membuat orang untuk bekerja dan membuat mereka percaya dalam melakukan pekerjaan yang baik adalah subjek psikologi manusia tentang bagaimana menyusun silabus kursus.

Bagaimanapun, tugas yang Anda gambarkan di sini sama saja dengan memicu hasrat batin untuk melakukan perubahan besar. Dan semakin besar sistem semakin sulit. Mulailah dengan orang yang lebih muda yang masih terbangun dengan semangat saya-tidak-akan-melakukan-pekerjaan-baik dan menantang status quo.

Seperti yang Anda tunjukkan, motivasinya. Jangan salah mengira mereka tidak mempedulikan mereka yang tidak tahu. Mereka jelas tahu apa yang harus dilakukan. Mereka hanya tidak peduli . Jika itu masalahnya, pertanyaan sebenarnya di sini adalah ... apa kesalahan manajemen Anda yang membuat mereka tidak termotivasi? Apakah Anda anggota terbaru tim? Mungkin mereka sudah pernah mengalami semua ini sebelumnya, dengan itu hanya menyebabkan masalah dari manajemen mereka. Jadi mereka hanya melakukan pekerjaan paling rendah yang diperlukan untuk mempertahankan pekerjaan mereka karena mereka tidak berpikir melakukan lebih banyak akan ditanggapi oleh majikan.

Menurut saya ini adalah masalah manajemen dan kepemimpinan - jika ini adalah tim Anda maka Anda dapat bekerja untuk membuat peningkatan (pribadi dan kode) atribut inti dari tim Anda, pertanyaannya adalah apakah kehendak yang didukung oleh manajemen Anda - karena Anda akan ingin melakukan hal-hal yang akan memakan waktu (mereka akan mendapatkan kemenangan bersih karena Anda harus mengurangi utang teknis baru dan akan membayar utang teknis yang ada).

Jadi, Anda menegaskan bahwa Anda ingin tim untuk meningkatkan, Anda mendapatkan persetujuan mereka bahwa ini adalah hal yang baik (bahwa tim, secara keseluruhan, bekerja untuk meningkatkan kualitas kode-kodenya) dan Anda kemudian memulai program untuk membuat ini terjadi - kedengarannya sangat mudah ... Saya sadar itu tidak!

Saya pikir ada dua bagian untuk ini - pendidikan dan praktik kerja.

• Edukasi Anda bisa memulai satu kali makan siang seminggu - semua orang makan bersama, Anda menjalankan presentasi 20 ~ 30 menit dengan Q&A. Anda mulai dengan dasar-dasar yang Anda inginkan - SOLID dapat menempati 2 ~ 4 minggu pertama - seiring waktu Anda membuat tim untuk berbicara secara bergilir dan Anda dapat mencari cara untuk memutuskan siapa yang berbicara tentang apa di antara Anda. Izinkan speaker beberapa waktu persiapan dalam bekerja. Di luar itu, dorong kehadiran kelompok pengguna lokal (dengan membuatnya setidaknya sebagian sebagai kegiatan sosial jika memungkinkan)
• Praktik kerja ... baik itu tergantung pada apa yang Anda lakukan sekarang dan alat apa yang Anda miliki, tetapi Anda mungkin ingin melihat menyetujui standar pengkodean, memperkenalkan ulasan kode rekan (apakah itu solid), pengujian unit (belum tentu menguji dulu) , menjalankan server integrasi berkelanjutan dan melihat lebih banyak pengujian otomatis (selain pengujian unit). Tetapi ini secara substansial harus diperkenalkan dengan persetujuan / persetujuan (bukan server build / CI!) Dan Anda harus ingin meningkatkan kualitas sebagai sebuah tim. Selalu ada hal yang bisa ditingkatkan (Kaizen)

Layak juga melihat Kanban (yang dilihat sebagai driver untuk perubahan / peningkatan).

Satu pemikiran terakhir - saya seorang programmer kejuruan, dan saya ingin tim saya tetap sama tetapi bekerja lebih dari 40 jam seminggu sebenarnya bukan hal yang baik sehingga tujuan seseorang adalah memiliki tim yang menyelesaikan pekerjaannya efektif dan baik dalam minggu kerja normal dan dalam hal ini argumen untuk meningkatkan praktik kerja adalah bahwa itu lebih mungkin misalnya: menambahkan unit test untuk mendemonstrasikan kasus gagal ketika (sebelum) perbaikan bug memberi Anda keyakinan bahwa itu adalahtetap; memiliki build server memberi Anda kepercayaan diri pada kemampuan Anda untuk membangun solusi Anda dengan bersih - jika build itu juga menghasilkan paket penyebaran, itu berarti bahwa penyebaran disederhanakan secara dramatis; Kode SOLID, menurut definisi, lebih mudah untuk dimodifikasi; dan secara keseluruhan, semakin sedikit utang teknis yang Anda keluarkan, semakin sedikit Anda harus membayar kembali ...

Saya jatuh ke pemrograman secara tidak sengaja ~ 30 tahun yang lalu. Saya termotivasi untuk mempelajari prinsip-prinsip rekayasa perangkat lunak dasar dengan ditugaskan untuk memelihara / mendukung kode orang lain. Dalam tugas-tugas ini, saya belajar bagaimana pembaca kode mengalami kode - bagaimana berempati dengan pembaca kode. Saya tidak ingin menimbulkan rasa sakit karena kode saya yang buruk pada orang lain!

Praktek menugaskan pemrogram baru ini untuk mempertahankan / mendukung kode orang lain bukanlah suatu keajaiban, dan tampaknya memberikan motivasi untuk belajar bagaimana menghasilkan kode yang solid lebih sering daripada tidak.