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:
- 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 ...
- 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.
- 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?
- Dapatkah praktik atau kebiasaan yang lebih baik diperkenalkan dan diajarkan sehingga Anda tidak harus terus-menerus memantau? - Ternyata bagian ini tidak begitu mudah.
- 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 .
- 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.
- 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.
- 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?
- 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.