Bagaimana cara meyakinkan tim saya untuk menggunakan kelas / metode yang lebih kecil?

Penafian: Saya pendatang baru (ini adalah hari kerja ketiga saya), dan sebagian besar rekan satu tim saya lebih berpengalaman daripada saya.

Ketika saya melihat kode kami, saya melihat beberapa bau kode dan praktik rekayasa yang buruk, seperti berikut:

• Agak penamaan pedoman yang tidak konsisten
• Properti tidak ditandai sebagai hanya dapat dibaca bila memungkinkan
• Kelas besar - Saya memperhatikan kelas utilitas yang terdiri dari ratusan metode ekstensi (untuk banyak jenis). Itu lebih dari 2500 baris!
• Metode besar - Saya mencoba memperbaiki metode yang panjangnya 150 baris.

Dua yang terakhir tampaknya menjadi masalah nyata. Saya ingin meyakinkan rekan tim saya untuk menggunakan kelas dan metode yang lebih kecil. Tetapi haruskah saya melakukan itu? Jika ya, lalu bagaimana?

Tim saya mendapat mentor dari tim utama (kami adalah tim satelit). Haruskah saya pergi ke dia dulu?

UPDATE : Karena beberapa tanggapan bertanya tentang proyek, harap diketahui bahwa ini adalah proyek yang berfungsi. Dan IMHO, kelas besar / metode ukuran itu selalu buruk.

Ngomong-ngomong, aku tidak pernah ingin mengecewakan timku. Itu sebabnya saya bertanya - Haruskah saya melakukan itu, dan jika ya, lalu bagaimana saya melakukannya dengan lembut?

UPDATE : Saya memutuskan untuk melakukan sesuatu berdasarkan jawaban yang diterima: karena saya pendatang baru, jadi saya melihat semuanya dalam "mata segar" Saya akan mencatat semua kode bau yang saya temukan (posisi, mengapa buruk, bagaimana kita bisa melakukannya) lebih baik, ...), tetapi pada saat ini, saya hanya berusaha keras untuk mengumpulkan penghormatan dari tim saya: menulis "kode yang lebih baik", tahu orang-orang, tahu mengapa kami melakukan itu ... Ketika waktunya tepat, saya akan mencoba untuk bertanya kepada tim saya tentang beberapa kebijakan kode baru (pedoman penamaan, kelas yang lebih kecil, metode yang lebih kecil, ...), dan jika mungkin, perbaiki beberapa kode lama. Seharusnya bekerja, IMHO.

Terima kasih.

Anda mendapat manfaat melihat kode dengan mata segar. Buat catatan untuk mendokumentasikan apa yang Anda temukan dari praktik buruk. Kemudian, ketika Anda sudah terbiasa dengan tim, tarik catatan Anda pada saat yang tepat, seperti ketika saatnya untuk refactoring.

Kode Lengkap, oleh Steve McConnell, memiliki banyak statistik bagus tentang topik yang sedang Anda bicarakan. Saya tidak ingat semua angka, tetapi ia berbicara tentang bagaimana jumlah bug meningkat dengan metode / kelas yang lebih lama, berapa lama lagi untuk debug, dll

Anda bisa membeli salinan buku itu, dan menunjukkan kepada teman Anda beberapa studi ... statistik (meskipun mereka berbohong setiap saat) cenderung meyakinkan orang.

Penafian: Saya pendatang baru (ini adalah hari kerja ketiga saya), dan sebagian besar tim saya lebih berpengalaman daripada saya.

Anda mungkin ingin sedikit melambat, mendengarkan, dan belajar dari tim Anda sebelum menyarankan terlalu banyak perubahan. Mungkin ada atau tidak ada alasan bagus mengapa kode ini disusun sebagaimana adanya, tetapi bagaimanapun juga meluangkan waktu untuk mendengarkan dan belajar terlebih dahulu hanya dapat membantu.

Setelah itu setiap saran yang mungkin Anda buat pasti akan dilihat lebih positif dan disambut dengan sedikit perlawanan.

Anda kemungkinan berhasil memperkenalkan perubahan sangat ditingkatkan jika Anda mendapatkan rasa hormat, atau setidaknya tidak kehilangan rasa hormat, dari rekan kerja Anda terlebih dahulu.

Bagaimana hasilnya? "Ukur dua kali potong sekali .." Sesuatu seperti itu.

Kecuali jika Anda dipekerjakan dengan maksud khusus untuk merombak cara tim Anda menulis kode, Anda mungkin ingin memoderasi antusiasme Anda untuk perbaikan drastis. Kebanyakan kode yang berfungsi bekerja karena suatu alasan :) tidak peduli seberapa sampah itu, dan kadang-kadang perombakan drastis membuat kasus sudut yang menjengkelkan itu bahkan lebih jelek.

Saya pikir tuas termudah untuk menulis kode yang lebih kecil akan meminta pengembang untuk fokus pada pengujian unit . Tidak ada yang memaksa kode ringkas seperti diminta untuk mengujinya ; Sungguh menakjubkan bagaimana pengembang tiba-tiba memiliki keengganan pada struktur data global, melewati terlalu banyak objek terlalu banyak lapisan, ketika mereka tahu mereka harus menulis tes untuk itu semua.

Aku bukan penggemar berat TDD tapi saya tidak menyukai kenyataan bahwa hal itu memaksa pengembang untuk mempertimbangkan bagaimana mereka akan menulis tes. Dan yang sering sebabnya kode ini lebih baik, bukan sihir tentang benar-benar memiliki tes. (Meskipun itu pasti berguna ketika Anda melakukan perubahan nanti.)

Semoga berhasil.

Anda seharusnya tidak meyakinkan tim Anda. Sebagai pendatang baru, Anda tidak akan dianggap serius - karenanya membuang-buang waktu.

Alih-alih, silakan tulis kode yang ringkas dan bersih sendiri. Maka mudah-mudahan, setelah beberapa saat dan beberapa ulasan kode, beberapa rekan tim mungkin mulai meniru gaya Anda.

Jika tidak, Anda masih akan lebih produktif dan kerja keras Anda pada akhirnya akan membawa Anda ke posisi yang lebih tinggi di mana Anda dapat mulai menegakkan beberapa aturan ini.

Dan ya tentu saja menunjukkan hal-hal dari Kode Lengkap kepada semua orang.

Berikut beberapa trik:

• Pelajari keadaan dan sejarah tim saat ini - sepertinya mereka memiliki seorang mentor, seberapa besar pengaruh yang dimiliki sang mentor? Juga, seberapa baru mentor itu dan apakah ada waktu yang lama tanpa mentor? Kapan kode masalah berasal? Mengkritik bayi tim saat ini bisa sangat berbeda dari mengkritik beberapa kode lama yang tidak ada yang ingat menulis.

• Satu hal pada satu waktu - jangan menjatuhkan bom pada semua pikiran Anda di rapat tim. Mulailah dengan beberapa pertanyaan tentatif yang datang dari perspektif spesifik Anda. Misalnya - "Hei, sebagai cowok baru, saya perhatikan bahwa beberapa kelas utilitas sangat besar, apakah ada alasan untuk itu?"

• Sarankan langkah kecil - hampir tidak mungkin untuk melakukan perombakan total segera, jadi cari tahu beberapa langkah awal untuk menyarankan jika semua orang setuju bahwa ini adalah rencana yang baik.

• Sarankan mekanisme pencegahan di masa depan - misalnya, tim dapat menyetujui tujuan yang tidak akan pernah ditambahkan ke beberapa kelas terbesar teratas, tetapi akan melakukan refactor ketika ada kebutuhan untuk mengembangkan mereka lebih lanjut.

• Dengarkan kekhawatiran tentang risiko. Jika ini benar-benar kode lama, mungkin ada cukup banyak hal yang tidak diketahui dan ketergantungan yang refactoring sangat berisiko. Itu mungkin bukan alasan untuk menghindari refactoring, tetapi itu mungkin berarti Anda memerlukan beberapa strategi pengujian yang lebih baik atau cara lain untuk mengurangi risiko sebelum Anda menangani pengerjaan ulang yang sebenarnya.

• Waspadai bahasa tubuh dan lakukan dengan lambat. Anda memunculkan masalah dalam basis kode yang belum memiliki banyak pengalaman. Anda memiliki jendela orang baru sekarang, di mana Anda dapat mengajukan beberapa pertanyaan naif dan mendapatkan jawaban yang bermanfaat, dan Anda dapat menggunakan pertanyaan itu untuk menyelidiki tim untuk mempertimbangkan pilihan desain mereka sendiri. Tapi itu berjalan dua arah - sebagai pria baru, Anda juga belum memiliki banyak "kepercayaan", jadi lambatlah dan waspadai wajah atau postur tertutup. Jika orang-orang mulai tutup, sarankan cara untuk menunda keputusan dan mencari cara untuk memenangkannya.

Saya bisa katakan sebagai manajer dan anggota tim, saya senang untuk New Guy Insights. Saya tidak menerima setiap komentar konstruktif yang diberikan oleh anggota tim baru kepada saya, tetapi saya umumnya bersedia mendengarkan jika kritik tersebut disuarakan sebagai kekhawatiran dan rasa ingin tahu yang jujur ​​dan tidak disampaikan sebagai kuliah. Tanda penghormatan terhadap orang baru itu berlaku ketika dia bisa memberikan wawasan dan kemudian mundur dan menangani apa pun yang datang - mudah untuk merasa baik ketika keputusan Anda didengar dan diambil, lebih sulit ketika tim mengatakan kepada Anda "tidak". Anda mungkin masih benar, triknya adalah mencari tahu apa yang harus dilakukan selanjutnya ... biasanya menunggu sedikit dan mencari informasi lebih lanjut adalah langkah selanjutnya yang baik dalam kasus tersebut.

Bagaimana cara meyakinkan tim saya untuk menggunakan kelas / metode yang lebih kecil?

Jangan.

Beli sendiri lisensi Resharper dan pimpin dengan memberi contoh. [Bersandarlah pada refactoring ' Metode Ekstrak '.]

Seiring waktu, orang lain harus menghargai kode Anda yang lebih mudah dibaca dan dibujuk untuk melakukan hal yang sama. *

• Ya - Ada kemungkinan bahwa mereka tidak akan dibujuk; tapi itu masih taruhan terbaikmu.

IMO - Tidak sepadan dengan suku kata Anda untuk mencoba membujuk teman satu tim Anda untuk menjadi pemrogram yang lebih baik, baca ' Kode Lengkap ', ikuti @Uncle Bob. Prinsip SOLID, dan menjadi pemrogram yang lebih baik jika belum dibujuk.

Ingat: Anda tidak dapat menggunakan logika untuk berdebat dengan seseorang tentang posisi yang tidak mereka gunakan untuk memulai.

Ini tampaknya lebih merupakan pertanyaan manajemen daripada pertanyaan teknis. Semua yang Anda katakan valid, yang benar-benar dibutuhkan tim Anda adalah arsitek yang baik yang dapat memastikan semua orang beradaptasi dengan pola desain tunggal dan menegakkannya, tim harus terus-menerus dan secara teratur memperbarui kode.

Namun, ada prinsip "kamu tidak akan membutuhkannya", jika apa yang pernah ada bekerja untuk waktu yang cukup lama, tidak peduli seberapa jeleknya, mengubahnya selalu bukan ide yang baik. Alih-alih jika tim Anda perlu membangun kembali semuanya atau membangun kembali sebagian, kumpulkan dokumen praktik buruk dan masalah sebelum melakukan pengkodean.

Beberapa tim tidak melakukan kontrol kualitas apa pun untuk kode karena mereka tidak tahu alat yang tepat untuk itu. Ada banyak alat yang dapat membantu kode tim lebih baik.

Visual Studio memiliki "Analisis Kode" yang dapat membantu dengan konvensi penamaan.

Juga metrik kode dapat digunakan, seperti kompleksitas siklomatik. Ini membantu menunjukkan kelas dan metode yang terlalu rumit.

Menyimpan catatan juga merupakan ide bagus. Jika anggota tim hanya mengungkapkan secara verbal apa yang perlu dilakukan, maka orang-orang pasti lupa. Manusia memiliki ingatan yang sangat lemah! =)

Saya tidak akan membuat banyak keributan tentang ini ... Tim pengembang programmer seperti keluarganya sendiri ... Jika Anda menunjukkan kesalahan, orang-orang bisa marah kepada Anda. Perubahan budaya semacam ini tidak hanya membutuhkan banyak pengkodean, tetapi juga membutuhkan sentuhan yang halus dengan manusia.

Sebagai seorang manajer saya hanya ingin menambahkan, bahwa saya ingin tim saya menulis kode yang baik pertama kali. Ulasan kode, TDD dan semua itu. Tapi begitu itu dalam produksi dan berhasil, Anda harus membuat kasus yang kuat untuk meminta kami kembali.

Saya memang mengikuti saran Paman Bob untuk selalu meninggalkan kode lebih baik daripada yang Anda temukan. Jadi jika kita memiliki bug untuk diperbaiki atau perangkat tambahan kecil, saya berharap kita melakukan beberapa pembersihan kemudian.

Tapi seperti berdiri, bisnis benar-benar jam tangan itu uang. Saya harus memberi alasan kepada mereka bahwa refactoring memberi manfaat cukup bagi mereka untuk memberi waktu dan sumber daya kepada tim saya. Hanya saja, tidak menyukai tampilan kode itu tidak cukup.

Jadi, jika itu berhasil, sebanyak yang Anda benci, Anda mungkin harus meninggalkannya sendirian.

Sekarang kode baru, itu berbeda. Itu seharusnya kode yang bagus.

Metode yang 150 baris ... Saya telah melihat metode dengan 10.000 baris kode.

Dua masalah Anda dapat diselesaikan dengan alat eksternal :

• Agak penamaan pedoman yang tidak konsisten
• Properti tidak ditandai sebagai hanya dapat dibaca jika memungkinkan

Di C # Resharper dapat memeriksa kedua masalah. Nama yang tidak mengikuti panduan Anda ditandai sebagai kesalahan. Properti yang tidak ditandai sebagai readonly juga ditampilkan sebagai kesalahan. FxCop mungkin juga bisa membantu.

Alat-alat ini juga dapat membantu untuk membagi metode besar menjadi beberapa metode yang lebih kecil berkat refactoring-nya.

Saya tidak tahu bahwa kelas besar selalu seburuk itu jika terstruktur dengan baik dengan metode yang baik. Saya menggunakan Eclipse sebagai IDE saya sehingga memiliki sesuatu yang disebut tampilan "outline", yang merupakan sesuatu yang dimiliki semua IDE hanya dengan nama yang berbeda, kemungkinan besar, yang menyediakan nama dan tautan ke setiap metode di dalam kelas, Anda dapat mengurutkannya berdasarkan abjad , dll. Ketika menggunakan ini mudah untuk menavigasi kelas besar, lebih dari itu memiliki metode yang sangat panjang akan buruk, saya pikir karena lebih sulit untuk menavigasi secara cerdas dalam metode itu kecuali Anda kebetulan benar-benar mengenalnya. Saya tidak menganjurkan kelas panjang tetapi saya pikir mereka dapat dikelola dalam beberapa kasus dan tidak perlu dibagi menjadi beberapa kelas.

Bawa subjek dengan beberapa anggota tim Anda dan dapatkan pendapat mereka tentang ukuran metode. Anda mungkin terkejut menemukan mereka setuju dengan Anda. Apa yang Anda lihat mungkin merupakan hasil dari praktik buruk sebelumnya, mantan pengembang tidak lagi bersama perusahaan, atau bagian itu adalah pekerjaan yang terburu-buru dan sekarang mereka telah merekrut seseorang dengan waktu untuk memperbaikinya;)

Anda masih cowok baru. Bangun reputasi dengan mengambil tugas yang menantang dan menyelesaikannya dengan cepat dan tanpa bug. Jika Anda mencoba untuk mulai mengubah hal-hal sebelum Anda mendapatkan rasa hormat dari rekan-rekan Anda, Anda mungkin memiliki waktu yang jauh lebih sulit untuk menerima (dan mungkin mengasingkan rekan kerja Anda).

Jika Anda dapat menemukan cara untuk memperkenalkan kebiasaan pengkodean yang lebih baik dalam pekerjaan Anda sendiri yang secara efektif menunjukkan bagaimana mereka mengurangi waktu pengembangan dan menghasilkan solusi yang lebih kuat, Anda mungkin bahkan meminta mereka datang kepada Anda untuk melihat bagaimana Anda mencapai ini.

Selanjutnya untuk semua jawaban hebat lainnya, mungkin Anda dapat membunuh dua burung dengan satu batu dan melakukan pembersihan kode sebagai proyek yang bertujuan untuk mendapatkan pemahaman tentang basis kode. Anda dapat menjualnya kepada tim / manajer Anda sebagai kesempatan belajar untuk Anda, dan Anda akan mendapatkan umpan balik dari rekan-rekan Anda ketika mereka melihat perubahan Anda yang akan memandu Anda dalam pendekatan terbaik Anda untuk menangani masalah desain yang buruk.