Di ujung taliku [tertutup]

Saya seorang kontraktor untuk sebuah perusahaan besar. Saat ini, ada tiga pengembang di proyek, termasuk saya sendiri.

Masalahnya adalah 2 pengembang lainnya tidak begitu mengerti. Maksud saya adalah:

• Mereka tidak memahami praktik terbaik untuk teknologi yang kami gunakan. Setelah 6 bulan saya dan orang lain memberi mereka contoh, ada anti-pola yang digunakan.
• Mereka adalah pemrogram "salin dan tempel" yang terutama menghasilkan kode spageti.
• Mereka terus - menerus memecahkan berbagai hal, menerapkan perubahan tetapi tidak melakukan tes asap dasar untuk melihat apakah semuanya baik
• Mereka menolak / jarang meminta ulasan kode.
• Mereka menolak / jarang bahkan melakukan hal-hal dasar seperti memformat kode.
• Tidak ada dokumentasi tentang kelas apa pun (jsdocs)
• Takut menghapus kode yang tidak melakukan apa-apa
• Tinggalkan blok kode yang dikomentari di mana-mana meskipun kami memiliki kontrol versi.

Saya merasa semakin frustrasi ketika saya memformat kode orang lain, memperbaiki bug, menemukan fungsionalitas yang rusak, dan membuat abstraksi untuk menghapus spageti.

Saya benar-benar tidak tahu harus berbuat apa. Saya mencoba untuk tidak frustrasi, tetapi itu hanya berantakan. Saya suka orang-orang ini, tetapi saya merasa situasi pengkodean begitu buruk sehingga saya bisa bergerak lebih cepat jika mereka hanya melihat-lihat web sepanjang hari.

Apakah akan keluar dari jalur untuk meminta manajer kami untuk meninjau orang lain yang melakukan akses; melakukan hanya dapat dilakukan setelah review oleh seseorang yang memiliki pengetahuan tentang apa yang kita lakukan? Sebagai kontraktor, saya tidak yakin apakah itu langkah terbaik.

Apakah ada cara halus / tidak begitu halus untuk menjelaskan berapa banyak hal yang saya perbaiki?

Saya memiliki sesuatu seperti ini di tim saya. Saya berusaha keras untuk membuat orang melakukan hal yang benar dan itu tidak berfungsi seperti yang diharapkan jadi saya pindah ke solusi yang berbeda.

Pertama, saya pergi ke manajer saya dan kami berhasil membuat kesepakatan, tidak ada kode apa pun yang masuk ke kontrol sumber kecuali jika dicakup oleh unit test. Jika kode masuk tanpa tes unit, saya memiliki hak veto untuk membatalkan komit segera dan melakukan ping siapa pun yang bertanggung jawab untuk mereka dapat mengerjakan tes dan kemudian mendorong kode.

Dengan aturan ini di tempat, saya secara teratur menjalankan alat cakupan kode (dalam hal ini, jacoco di build sbt kami ) untuk memastikan potongan tertutup dengan benar dan saya juga melakukan refactoring dan ulasan kode secara konstan dalam kode apa pun yang didorong oleh mereka. Karena ini adalah proyek Java dan Scala, saya memiliki banyak alat untuk membantu saya menangkap hal-hal yang seharusnya tidak ada di sana atau tidak berfungsi seperti yang kami pikir seharusnya, tidak yakin bagaimana Anda dapat melakukan hal yang sama dengan JavaScript tetapi mungkin ada sebuah solusi.

Hal utama yang saya yakini membantu saya untuk mengikuti ini adalah bahwa saya memiliki pandangan yang jelas tentang apa yang saya harapkan dari proyek dan arsitektur utamanya, jadi setiap kali saya melihat sesuatu yang tidak mencerminkan pandangan ini, saya bisa pergi ke sana dan memperbaikinya. Anda harus melakukan hal yang sama, mendefinisikan pandangan Anda, pola-pola yang harus digunakan, cara kode harus ditulis dan menjaga diri Anda di atas ini, selalu membiarkan mereka (dan manajemen Anda) tahu apa yang terjadi dan apa yang membuat proyek tidak bergerak terus lebih cepat.

Pasti akan ada saat di mana mereka menyerah dan melakukan hal yang benar atau manajemen mendapatkan pesan dan memindahkan mereka dari proyek.

Saya yakin sekarang Anda telah melihat komentar saya dan posting saya yang lain, jadi saya tidak akan berpura-pura tahu jawabannya. Yang terbaik yang bisa saya tawarkan adalah ringkasan dari apa yang saya dengar / baca dari orang lain dan menambahkan beberapa pengalaman saya sendiri ke dalam campuran.

Pertama, saya ingin mengatakan bahwa beberapa waktu yang lalu saya menemukan sebuah blog yang dimiliki oleh salah satu anggota Programmer SE kami, Martin Blore dan IMO ini satu posting khusus tentang aktualisasi diri TDD sangat akurat. TDD adalah level tertinggi dan terakhir yang menyatukan semuanya tetapi tanpa level sebelumnya, terutama yang terbesar, prinsip dan praktik menghasilkan kode yang jelas dan mudah dibaca, akan sangat sulit jika bukan tidak mungkin membuat TDD berfungsi.

Di perusahaan saya, Agile dan TDD dikenakan pada kami oleh manajemen, dan pada awalnya kami melakukannya karena kami diberitahu (yang merupakan kebalikan dari agile). Kami telah mencoba TDD dua kali dan sementara saya pendukung besar menggunakan tes otomatis, saya pribadi membuang semua yang ditampar bersama tim di rilis terakhir. Mereka rapuh, raksasa, menyalin / menempel wazoo dan penuh dengan pernyataan tidur yang membuat mereka berjalan sangat lambat dan tak terduga. Saran saya untuk tim Anda: JANGAN LAKUKAN TDD ... belum.

Saya tidak tahu bagaimana situasi Anda karena Anda menyebutkan bahwa Anda baru bergabung dengan perusahaan selama 6 bulan dan Anda adalah seorang kontraktor. Apakah tujuan jangka panjang Anda untuk tetap bersama perusahaan ini atau apakah kontraknya akan habis? Saya bertanya karena walaupun Anda melakukan sesuatu, mungkin perlu beberapa waktu untuk benar-benar melihat hasilnya.

Juga ketika Anda bergabung dengan tim, biasanya perlu waktu sebelum Anda mendapatkan kredibilitas dan rasa hormat yang cukup dari tim Anda di mana mereka (pengembang dan manajemen) bahkan akan mempertimbangkan apa pun yang Anda usulkan. Dalam pengalaman saya, akan membantu jika Anda memadamkan beberapa kebakaran dan menunjukkan bahwa Anda memiliki keterampilan dan pengetahuan yang dapat diandalkan orang lain. Tidak yakin apakah 6 bulan sudah cukup. Cukup sering orang yang baru dan ambisius bergabung dengan tim, lalu membuat posting di sini menanyakan bagaimana mereka dapat mengubah dunia. Kenyataan yang menyedihkan adalah mereka tidak bisa melakukannya.

Jadi anggaplah Anda memiliki rasa hormat dan perhatian tim Anda. Sekarang apa?

Pertama, baik manajemen maupun pengembang perlu menyadari bahwa ada masalah. Tindakan manajemen menghasilkan hasil dalam hal pekerjaan yang disampaikan. Jika mereka senang dengan kuantitas dan kualitas fitur saat ini, maka kenyataan yang menyedihkan adalah bahwa mereka tidak akan mendengarkan. Seperti yang telah ditunjukkan orang lain, tanpa dukungan manajemen, akan sangat sulit untuk memperkenalkan segala jenis perubahan.

Setelah Anda mendapatkan dukungan manajemen, langkah selanjutnya adalah menggali lebih dalam dan mengidentifikasi akar penyebab mengapa tim beroperasi seperti itu. Topik selanjutnya ini adalah sesuatu yang menjadi pencarian pribadi saya beberapa saat sekarang. Sejauh ini perjalanan saya:

1. Setelah Anda mendapat dukungan manajemen. Anda dapat mulai memperkenalkan banyak praktik / proses yang didikte pusat yang disarankan MainMa sebagai jawaban atas pertanyaan saya . Kami telah melakukan banyak hal (kecuali untuk pemrograman berpasangan) dan Anda pasti melihat manfaatnya. Ulasan kode terutama membantu untuk menstandarisasi gaya, dokumentasi dan juga memungkinkan kami untuk berbagi pengetahuan / teknik di antara tim. Meskipun, ulasan kode ditentukan, tim sebenarnya menyukainya dan kami meninjau setiap bagian dari fungsi yang diperiksa. Namun ...
2. Anda perhatikan bahwa kode yang umumnya ditulis masih terlalu berpasangan, desainnya buruk atau sama sekali tidak ada. Ulasan kode menangkap sebagian, tetapi hanya ada begitu banyak yang dapat Anda tulis ulang. Mengapa desain buruk di tempat pertama? - Banyak pengembang tidak pernah diperkenalkan dengan praktik yang baik dan sejak awal tidak pernah diajarkan OOD. Banyak orang "hanya memberi kode" tugas apa pun yang diberikan kepada mereka.
3. Dengan dukungan manajemen, Anda dapat memperkenalkan lebih banyak proses, seperti mendiskusikan desain sebelum pengkodean dilakukan. Tapi Anda hanya satu orang dan tampaknya begitu Anda tidak memperhatikan tim kembali ke apa yang selalu mereka lakukan. Mengapa?
4. Dapatkah praktik atau kebiasaan yang lebih baik diperkenalkan dan diajarkan sehingga Anda tidak harus terus-menerus memantau? - Ternyata bagian ini tidak begitu mudah.
5. Mengapa anggota tim lain enggan belajar dan mengambil praktik baru dan mengapa mereka begitu resisten terhadap SOLID atau KERING ketika sudah begitu banyak ditulis dalam literatur metodologi perangkat lunak modern? Dengan semua perubahan positif yang kami miliki di tim saya, 2 minggu yang lalu saya berargumen bahwa saya refactored 2 fungsi yang identik 15 baris kode dan peninjau menyebutnya heroik, upaya yang tidak perlu karena tidak ada yang salah dengan copy / paste saja 15 baris. Saya sangat tidak setuju dengan pandangan seperti itu tetapi untuk saat ini kami telah sepakat untuk tidak setuju. - Jadi sekarang bagaimana? Sekarang kami telah mencapai topik posting saya yang lain .
6. Seperti yang ditunjukkan maple_shaft dan nikie dalam jawaban mereka (maaf, MainMa , Anda mendapat suara terbanyak, tetapi Anda berada 5 langkah di belakang :)), Anda telah mencapai tahap di mana "proses" tidak dapat lagi membantu Anda dan tidak seorang pun di forum ini dapat memberi tahu Anda apa "perbaikan" itu. Langkah selanjutnya adalah mendekati individu, mungkin satu lawan satu, mungkin sebagai tim, mungkin keduanya pada satu waktu atau yang lain dan berbicara dengan mereka. Tanyakan kepada mereka, apa yang berhasil dan yang tidak. Satu-satunya cara untuk mengidentifikasi akar penyebab dari apa yang mendorong mereka sekarang adalah berbicara dengan mereka secara individu dan mengetahuinya. Sebagai bagian dari langkah ini, saya baru-baru ini menemukan masalah tim yang sama sekali berbeda, tetapi saya pikir jawaban Joel di sini, yang sangat rinci dan berwawasan luas, akan berlaku untuk kasus ini juga. Singkatnya, sementara menggunakan manajemen sebagai "tali pendek" adalah pendekatan yang mungkin untuk hampir semua hal, kita perlu ingat bahwa kita berurusan dengan manusia sehingga untuk benar-benar memahami motivasi kita harus menyeberang ke psikoanalisis daripada manajemen murni atau kepemimpinan teknis.
7. Jadi sekarang Anda berbicara dengan rekan tim Anda? Apa yang kamu tanyakan pada mereka? Saya tidak yakin tentang bagian selanjutnya ini karena saya belum pernah ke sini. Berikut skenario yang mungkin: T: Kenapa tidak SOLID? A: Saya tidak membutuhkannya. T: Mungkin membantu. A: Saya baik-baik saja. - entah bagaimana Anda perlu menghasilkan serangkaian suara yang akan meninggalkan mulut Anda dan membuat pendengar menyadari bahwa segala sesuatu bisa lebih baik jika mereka memberikan apa pun yang Anda menjajakan kesempatan. Jika Anda gagal di sini, mereka tidak akan pernah yakin bahwa apa pun "proses" yang membuat mereka benar-benar memiliki nilai. Di sisi lain, jika Anda melewati titik ini, Anda mungkin akan menemukan Anda bahkan tidak perlu "proses" lagi.
8. IMO pada dasarnya, rekan tim Anda tidak akan belajar jika mereka tidak melihat ada yang salah dengan kebiasaan / praktik mereka saat ini. Jadi mungkin langkah selanjutnya dalam semua ini adalah menemukan cara untuk mengilustrasikan, menyoroti masalah dan membuatnya jelas. Bagaimanapun, kita tidak menulis kode yang dapat dibaca, menggunakan prinsip-prinsip SOLID / KERING atau memelihara dokumentasi hanya karena itu memberi kita perasaan hangat dan kabur. Kami melakukannya karena menghasilkan kode kualitas yang lebih baik dan terus terang membuat kami kode lebih cepat. Bisakah itu diukur? Mungkin ini tempat metrik perangkat lunak masuk?
9. Ini ide gila dan saya tidak tahu apakah itu akan berhasil (mungkin ini adalah praktik industri standar, atau mungkin benar-benar tidak valid. Saya baru mengada-ada dalam 24 jam terakhir), tetapi saya sangat tergoda untuk membawanya ke meja segera setelah tahun berikutnya dimulai:
   • Terhadap pendapat banyak orang lain , memperkenalkan gagasan Penulis / pemilik untuk semua file source. Seperti yang disarankan oleh Programmer Pragmatis, ini akan memberikan rasa memiliki dan tanggung jawab kepada satu orang yang akan bertanggung jawab atas sepotong kode sumber. Itu tidak berarti orang lain tidak dapat mengubah kode, kita semua bekerja sebagai sebuah tim, tetapi pada akhirnya, orang yang memiliki kode bertanggung jawab untuk meninjau perubahan.
   • Buat pemicu repositori sumber yang memonitor semua check-in dan secara khusus mencari yang merupakan perbaikan bug. Jadikan sebagai proses agar setiap perbaikan bug memiliki pengidentifikasi referensi di depan di deskripsi check-in. Sekarang tulis skrip yang akan mem-parsing daftar file yang diubah dan menghapus "Penulis" dari blok komentar header file. Buat database SQL yang akan melacak # kerusakan yang diperiksa dalam setiap file / per proyek / per penulis.
   • Setelah Anda memiliki statistik yang cukup, mudah-mudahan Anda akan melihat bahwa kode Anda memiliki lebih sedikit cacat / perubahan daripada beberapa kode lainnya. Ini adalah data sulit yang dapat Anda gunakan. Jika satu proyek memiliki tingkat cacat rata-rata secara signifikan di atas, angkat sebagai kandidat untuk upaya pembersihan / refaktor berikutnya untuk membayar kembali sejumlah utang teknis.
   • Jika suatu proyek atau file memiliki tingkat cacat rata-rata secara signifikan di atas dan memiliki satu pemilik, bicarakan satu lawan satu dengan orang itu. Tanyakan kepada mereka, dengan sangat sopan, non-konfrontatif apa yang dapat mereka lakukan untuk mengatasi hal ini. Karena mereka adalah pemilik, mereka harus mendorong perubahan, tetapi menawarkan bantuan apa pun dan semua dari pihak Anda. Mudah-mudahan, pemilik akan melacak banyak penyebab kode spaghetti mereka sendiri dan segera setelah mereka meminta bantuan, saat itulah Anda mulai bertindak dan meletakkan beberapa SOLID.

Saya menyarankan agar Anda berbicara dengan manajer Anda tentang masalah ini, tetapi ia hampir pasti tidak ingin meninjau setiap check-in.

Alih-alih, saya menyarankan Anda menyarankan serangkaian uji unit / regresi, untuk dihubungkan ke SVN, dan dijalankan untuk setiap checkin. Setidaknya itu akan membantu Anda menghindari bangunan yang rusak. Anda dapat secara bertahap menyarankan praktik terbaik lainnya.

Jika dia ternyata sama sekali tidak bisa menerima, mungkin Anda harus melupakannya. Jika Anda memutuskan untuk melakukan itu, Anda harus membawa permainan terbaik Anda. Anda pada dasarnya akan mengajukan kepada manajemen untuk dipekerjakan di tingkat yang lebih tinggi jika Anda melakukannya.