Di ujung taliku [tertutup]


17

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?


1
Saya membuka pertanyaan untuk menjawab pertanyaan ini, yang menurut saya menggeneralisasi masalah sebenarnya yang dialami tim Anda: programmers.stackexchange.com/questions/127117/… . Sejauh memperkenalkan tes otomatis, saya sangat setuju dengan posting Martin Blore: martinblore.wordpress.com/2010/06/02/... - tanpa prinsip dan dasar yang baik, upaya TDD akan jauh sia-sia. Saya mencoba untuk menambahkan pada fondasi itu dalam posting saya karena saya juga ingin tahu.
DXM

masalah yang saya miliki adalah tes yang hanya memverifikasi fungsionalitas berfungsi. Mereka tidak membahas 7 item lain yang saya daftarkan.
hvgotcodes

1
Sudahkah Anda mencoba memasangkan pemrograman dengan orang-orang ini? mereka akan melihat poin Anda dan Anda akan melihat poin mereka jika Anda duduk di satu mesin dan mengembangkan satu fungsi. Lakukan selama sebulan, 3 hari seminggu, 3 jam sehari. Ini mungkin membantu. Juga buat CI dan publikasikan cakupan kode dan metrik angka lulus uji kasus. Biarkan bangunan gagal jika ada yang dilanggar.

Jawaban:


7

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.


5
masalahnya di sini (dan saya tidak yakin apakah pertanyaan ini terlalu terlokalisasi karena penyebab mendasar yang menurut saya sangat umum) adalah bagaimana Anda menginspirasi para pengembang untuk belajar dan tumbuh alih-alih mengandalkan praktik penyalinan yang "benar dan telah dicoba". Aku menempel dan terus melakukan hal-hal spageti. Jika OP pindah ke peran pengawas / peninjau / pemberi persetujuan, itu akan memotong waktu sendiri secara signifikan. Pada saat yang sama, orang yang menulis kode buruk, menulis tes unit yang lebih buruk. Mereka akan berjalan lebih lambat, menulis tes yang tidak dapat dipelihara, dan kemudian mereka akan menunjukkan bahwa pengujian unit tidak bekerja dan menyalahkan Anda karena menyarankannya
DXM

dxm, ya ini masalah. Inti dari pertanyaan saya adalah bagaimana membawa masalah ini ke manajemen, walaupun saya akui itu mungkin tidak terlalu jelas.
hvgotcodes

2
Saya pikir pilihan terbaik untuk membawa ini ke manajemen adalah untuk menunjukkan berapa banyak pengerjaan ulang kode mereka membutuhkan dan berapa banyak momen yang terbuang untuk ini.
Maurício Linhares

7

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.

1
ini bagus, terima kasih. Saya telah mencoba sebelum beberapa teknik ini (Jen *, mengapa Anda tidak mengubah formatter kode Anda untuk melakukan x, y, z, butuh 2 menit) sebelumnya, dan saya selalu mendapatkan layanan bibir dan tidak ada yang terjadi. Juga, salah satu kolega saya jelas lebih kuat dari yang lain; pada baris di mana dia bisa sangat baik, tetapi gagal mengeksekusi. Saya mendengar dia berbicara tentang kualitas kode sepanjang waktu, tetapi juga semacam kembali ke shell ketika saatnya untuk mengambil tindakan: "kami hanya memiliki 5 minggu untuk rilis, saya tidak ingin memperbaiki apa pun sekarang". Dan saya facepalm. * nama berubah
hvgotcodes

bagaimana jika Anda tidak fokus pada pemformat kode (atau yang spesifik lainnya). Alih-alih hanya berbicara dengan Jen dan mengemukakan beberapa masalah sebagai masalah tim (mis. "Saya perhatikan beberapa kode kami tidak terlalu mudah dibaca, saya pikir itu menyebabkan kami membuat kesalahan yang bisa dihindari"). Jangan menyarankan apa pun, tetapi biarkan Jen memikirkan solusi yang mungkin. Saya juga menemukan bahwa itu membantu ketika Anda membuat cadangan saran Anda dengan sumber. Alih-alih mengatakan, "Saya pikir kita perlu bekerja pada penamaan variabel yang lebih baik", bagaimana jika Anda mengatakan, "Saya membaca Kode Bersih dan saya pikir penulis memiliki poin yang sangat baik, mari kita coba ..." Untuk berdebat ...
DXM

... dengan itu Jen harus menemukan buku yang menunjukkan penamaan itu tidak penting. Dan saya tahu apa yang Anda maksud tentang orang-orang yang kembali, itu wajar dan alasannya adalah bahwa ketika Anda berada di bawah tekanan, Anda kembali ke zona nyaman Anda untuk membebaskan upaya Anda untuk hal-hal "penting". Sekalipun Anda berhasil meningkatkan kualitas dan pembelajaran tim Anda, dibutuhkan beberapa rilis sebelum mereka mulai kembali ke kebiasaan yang baik. Hanya perlu bersabar, pilih pertempuran Anda dan biarkan beberapa hal meluncur
DXM

2

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.


1
Saya tidak menyebutkan bahwa ini adalah pekerjaan sisi klien. tes fungsional otomatis adalah pipeline, tetapi mereka bukan unit test sehingga umpan baliknya akan harian, tidak langsung.
hvgotcodes

2
@ hvgotcodes: Saya tidak mengerti mengapa hal itu mencegah Anda membuat unit test untuk dijalankan pada setiap checkin.
Marcin
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.