Bagaimana saya (dengan bijaksana) memberi tahu manajer proyek atau pengembang utama saya bahwa basis kode proyek perlu kerja serius?

Saya baru saja bergabung dengan tim pengembangan (relatif) kecil yang telah mengerjakan proyek selama beberapa bulan, jika tidak satu tahun. Seperti kebanyakan pengembang yang bergabung dengan suatu proyek, saya menghabiskan beberapa hari pertama saya meninjau basis kode proyek.

Proyek (jalur internal aplikasi bisnis ASP.NET WebForms berukuran sedang hingga besar), karena kurangnya istilah yang lebih deskriptif, merupakan bencana. Ada tiga masalah langsung dengan standar pengkodean:

1. Standarnya sangat longgar. Ini menjelaskan lebih banyak tentang apa yang tidak boleh dilakukan (jangan menggunakan notasi Hongaria, dll.) Daripada apa yang harus dilakukan.
2. Standar tidak selalu diikuti. Ada ketidakkonsistenan dengan pemformatan kode di mana-mana .
3. Standar tidak mengikuti pedoman gaya Microsoft. Menurut pendapat saya, tidak ada nilai menyimpang dari pedoman yang ditetapkan oleh pengembang kerangka kerja dan kontributor terbesar untuk spesifikasi bahasa.

Adapun poin 3, mungkin itu lebih mengganggu saya karena saya telah mengambil waktu untuk mendapatkan MCPD saya dengan fokus pada aplikasi web (khususnya, ASP.NET). Saya juga satu-satunya Microsoft Certified Professional di tim. Karena apa yang saya pelajari di semua sekolah, belajar mandiri, dan belajar sambil bekerja (termasuk persiapan saya untuk ujian sertifikasi), saya juga melihat beberapa contoh dalam kode proyek di mana hal-hal tidak dilakukan di Cara terbaik.

Saya hanya berada di tim ini selama seminggu, tetapi saya melihat begitu banyak masalah dengan basis kode mereka sehingga saya bayangkan saya akan menghabiskan lebih banyak waktu berjuang dengan apa yang sudah ditulis untuk melakukan sesuatu dengan "cara mereka" daripada saya jika mengerjakan proyek yang, misalnya, mengikuti standar pengkodean yang lebih banyak diterima, pola arsitektur, dan praktik terbaik. Ini membawa saya ke pertanyaan saya:

Haruskah saya (dan jika demikian, bagaimana saya) mengusulkan kepada manajer proyek dan pimpinan tim saya bahwa proyek tersebut perlu direnovasi secara besar-besaran?

Saya tidak ingin masuk ke kantor mereka, melambaikan MCTS dan sertifikat MCPD saya sekitar, mengatakan bahwa basis kode proyek mereka adalah omong kosong. Tetapi saya juga tidak ingin harus tetap diam dan harus menulis kode kludgey di atas kode kludgey mereka , karena saya sebenarnya ingin menulis perangkat lunak yang berkualitas dan saya ingin produk akhir menjadi stabil dan mudah dirawat.

Anda dapat menghabiskan waktu untuk berdebat tentang kasus Anda; atau Anda bisa menghabiskan waktu Anda membersihkan sambil berjalan.

Ambil Kode Bersih dan Prinsip, Pola, dan Praktik Pengembangan Perangkat Lunak yang Tajam dan terapkan apa yang Anda pelajari di sana saat Anda mengerjakan sistem. Akhirnya, orang akan memperhatikan (lebih baik, atau lebih buruk).

Sunting Juga periksa Bekerja Secara Efektif dengan Kode Legacy

Dari apa yang Anda jelaskan, tampaknya masalah sebagian besar tentang tidak mengikuti standar pengkodean dan masalah penamaan. Itu bukan bencana , sejauh ini. Sebagai perbandingan, ini adalah bencana, nyata.

Mungkin Anda sudah terbiasa dan membutuhkan standar tinggi? Dalam hal itu penyimpangan dari kesempurnaan dapat dianggap sebagai kegagalan. Itu adalah jebakan yang mudah jatuh ke dalam ketika tuntutan Anda tinggi, tetapi penting untuk menjaga perspektif pada hal-hal.

Saya sarankan Anda membicarakan hal ini sebagai peningkatan, dan membantu tim untuk memperbarui pedoman mereka dan melatih mereka untuk mulai menggunakannya secara nyata. Saya benar-benar suka menggunakan Definition of Done sebagai tolok ukur kualitas dan membuatnya adalah pengusiran tim yang hebat dengan sendirinya. Tapi saya tidak berpikir Anda harus membuat lebih dari itu, setidaknya bukan sebagai anggota tim baru.

Tentunya jangan pergi melambai MCSD Anda di sekitar, orang-orang hanya akan menertawakan Anda terus terang, sertifikat MS bagus untuk dimiliki tetapi mereka sama sekali tidak kualifikasi profesional!

Langkah ringan bergabung dengan tim baru, mencari peluang untuk menyarankan perubahan saat Anda pergi.

Tunggu sampai Anda mendapatkan lapisan tanah sebelum mengeluarkan kode tim.

Anda mungkin menganggap bahwa masalahnya adalah Anda. TIDAK satu pun dari tiga hal yang Anda sebutkan yang layak untuk dilakukan pengerjaan ulang aplikasi secara lengkap. Mereka hanyalah detail yang sangat menarik.

Ingatlah bahwa tujuan dari aplikasi ini bukan untuk memiliki kode yang indah, itu adalah untuk memecahkan masalah bisnis. Tentu menyenangkan memiliki kode yang konsisten dan mengikuti standar yang baik, tetapi kekurangannya tidak ada alasan untuk membuang seluruh basis kode. Hanya karena mesinnya berminyak bukan berarti harus dibangun kembali.

Lihat, semua orang membenci setiap basis kode yang tidak mereka tulis. Bahkan, jika Anda menunggu tiga tahun dan melihat kode Anda sendiri, Anda akan membencinya juga dan berpikir itu membutuhkan penulisan ulang yang lengkap. Yang benar adalah, tidak. Kecuali jika Anda dapat membuat kasus yang menghabiskan waktu berbulan-bulan untuk membuat kode menyenangkan bagi Anda alih-alih membangun fitur untuk menambah nilai bisnis Anda mungkin menggonggong pohon yang salah.

Tidak ada yang mengatakan Anda harus menulis kode kludgy hanya karena mungkin ada beberapa di basis kode. Dan tidak ada yang mengatakan kode itu Kludgy hanya karena tidak mematuhi gaya hewan peliharaan Anda. Hanya refactor saat Anda mengerjakan bagian yang Anda kerjakan dan menulis kode yang baik ketika Anda mengerjakan hal-hal baru.

Hal-hal ini OK untuk dikhawatirkan, tetapi jika Anda baru di tim, jangan goyang dulu, sampai Anda membangun kredibilitas dengan mereka.

Tampaknya Anda telah memilih tiga (relatif) hal-hal kecil untuk dikhawatirkan. Ada hal-hal lain yang saya khawatirkan:

• Apakah kode didokumentasikan dengan baik?
• Apakah kode mematuhi spesifikasi / dokumen desain?
• Apakah kodenya berfungsi?
• Apakah mudah untuk memahami apa yang dilakukan kode?
• Apakah Anda mempertimbangkan untuk mengirimkan potongan besar basis kode ini ke TheDailyWTF?

Anda sudah berada di sana selama seminggu? Saya tidak yakin Anda cukup tahu untuk membuat proposal kepada manajer proyek. Bahkan jika Anda curiga bahwa kode dan praktik tim ini "buruk", cara terbaik untuk memengaruhi hal-hal ini dari waktu ke waktu adalah secara bertahap mendapatkan kepercayaan dan rasa hormat mereka. Datang ke proyek dan setelah satu minggu memberitahu tim bahwa kode mereka perlu ditulis ulang bukan cara yang baik untuk mendapatkan kepercayaan dan rasa hormat.

Untuk beberapa bulan pertama Anda, fokuslah pada memberikan contoh yang lebih baik, dan mengajukan pertanyaan tentang mengapa mereka melakukan hal-hal dengan cara tertentu. Berhati-hatilah dengan nada bicara Anda saat mengajukan pertanyaan ini. Jika Anda tampil sebagai pria baru yang "tahu segalanya", tidak ada yang akan mendengarkan pendapat Anda nanti ketika Anda benar-benar berada dalam posisi untuk memengaruhi cara melakukan sesuatu.

Seiring waktu, jika kode Anda benar-benar "lebih baik", pengembang lain akan melihatnya. Mereka akan mulai mendatangi Anda sebagai sumber daya untuk membantu mereka memperbaiki barang mereka, dan kemudian meminta nasihat Anda tentang bagaimana mereka seharusnya melakukan sesuatu. Pada titik itu, Anda akan berada dalam posisi yang bagus untuk memberi tahu tim (dan manajemen) pendapat Anda tentang standar pengkodean dan sejenisnya. Berapa lama proses ini akan berbeda di setiap organisasi. Bisa jadi hanya beberapa minggu di lingkungan yang sangat mudah beradaptasi, atau berbulan-bulan hingga bertahun-tahun dalam budaya yang lebih tabah. Bangun pengaruh Anda satu orang pada satu waktu.

Anda tidak akan pernah masuk ke pekerjaan baru di mana Anda akan berpikir basis kode sempurna dan semuanya telah dilakukan dengan cara yang "benar". Belajarlah untuk menerima ini. Yang dapat Anda lakukan dengan kode lawas adalah refactor dan bergerak maju sedikit demi sedikit. Beberapa hal yang Anda tidak ingin refactor sampai Anda lebih memahami mengapa mereka melakukan apa yang mereka lakukan. Juga, tidak ada seorang pun dalam bisnis akan membayar Anda untuk memperbaiki kode kerja, jadi Anda harus membuat alasan bisnis mengapa itu perlu bekerja sebelum meningkatkan dan menghabiskan waktu. Anda lebih baik menunggu kode refactor ketika ada perubahan yang perlu Anda lakukan untuk itu. Anda mungkin tidak memilih metode yang mereka lakukan untuk beberapa hal, tetapi jika berhasil, berhati-hatilah untuk mengubahnya dan memperkenalkan bug baru. Terutama ketika Anda belum diminta untuk mengubahnya.

Setelah satu minggu, Anda tidak memiliki kredibilitas untuk membuat saran utama tentang bagaimana mereka melakukan bisnis. Jika Anda membicarakannya sekarang, orang-orang akan menertawakan Anda dan tidak akan pernah menganggap Anda serius. Buktikan diri Anda dengan beberapa kode yang baik terlebih dahulu dan kemudian orang akan lebih cenderung mendengarkan.

Dan terus terang tidak ada yang peduli bahwa Anda adalah Microsoft Certified Professional. Siapa pun yang memiliki banyak pengalaman telah melihat sebanyak mungkin programmer buruk yang memiliki sertifikasi itu sebagai orang baik. Saya tidak mengatakan itu membuat Anda terlihat buruk untuk memiliki sertifikasi, saya mengatakan kami tidak menaruh kepercayaan banyak pada mereka karena kami belum melihat di mana mereka efektif menunjukkan kepada kami yang merupakan programmer yang baik.

Saya mungkin akan mencoba mencari cara untuk mempresentasikan proposal dengan maksud agar Anda akhirnya tidak dapat membenarkan posisi Anda secara memadai. Beberapa pertanyaan untuk direnungkan dalam membuat proposal itu:

• Berapa nilai bisnis yang diperoleh dengan membuat jenis perubahan yang Anda jelaskan di sini?
• Sudahkah Anda mempertimbangkan opsi seperti menulis ulang aplikasi dari awal, memodifikasi kode yang ada untuk menghentikannya, atau hanya melakukan sedikit perubahan dari waktu ke waktu?
• Apakah Anda tahu fitur dan bug apa yang diinginkan sekarang yang akan mencegah Anda membuat perubahan yang Anda inginkan?

Meskipun saya dapat menghargai keinginan untuk memperbaiki basis kode yang buruk, ini harus ditimbang sehingga masuk akal dari pandangan bisnis untuk melakukannya.

Saat ini Anda tidak dalam posisi untuk mencegah kode yang buruk, jadi Anda harus mencari tahu bagaimana cara menyimpannya.

PM dan pemimpin tim hanya akan peduli kalau itu tidak berhasil. Kekhawatiran mereka berikutnya adalah ketika mereka meminta Anda untuk melakukan perubahan dan bertanya-tanya mengapa hal-hal 'sederhana' begitu lama. Di situlah Anda akan masuk.

Mulai sekarang dengan masalah konsistensi. Apa pun metode standar potensial saat ini, cobalah untuk mengidentifikasi dan melihat apakah Anda tidak dapat menerapkannya. Jika Anda mulai dengan metodologi yang tidak dikenal orang lain, Anda akan mendapat banyak dorongan.

Anggota tim lain mungkin ingin mendapatkan sertifikasi dan Anda akan menjadi sumber yang bagus. Semoga mereka setidaknya ingin meningkatkan dan melihat Anda untuk menunjukkan jalan kepada mereka.

Mengeluh tentang Notasi Hongaria akan membuat Anda tidak simpati dan mungkin salah satu pertempuran terakhir dalam daftar prioritas.

Saya setuju bahwa Anda perlu berhati-hati tentang hal ini. Anda perlu membangun reputasi di dalam tim sebelum Anda dapat menyatakan kritik dan mengusulkan perubahan besar dalam kode atau proses. Saya hanya akan mencatat tentang temuan & saran saya untuk saat ini, dan mengambil kesempatan untuk berkenalan dengan anggota tim dan manajemen, mengadakan diskusi gratis tetapi tidak menolak jika pembicaraan beralih ke masalah kualitas, mengkode pertanyaan dll, kadang-kadang bahkan melempar beberapa pertanyaan saya sendiri ke kolam (tetapi dalam bentuk umum, tidak terlalu menunjuk ke masalah konkret yang saya lihat dalam basis kode ini). Dengan cara ini saya bisa mengetahui pendapat anggota tim dan menemukan sekutu potensial.

Dalam kasus terbaik, Anda mungkin menemukan bahwa sebagian besar tim (dan / atau manajemen) melihat masalah yang sama dengan Anda, hanya saja belum ada inisiatif untuk melakukan sesuatu tentang mereka, atau tidak ada sumber daya yang diberikan kepadanya oleh manajemen. Bersama Anda memiliki lebih banyak suara untuk meyakinkan manajemen jika diperlukan.

Seperti yang disarankan @Mike, melakukan beberapa pembersihan sendiri sangat diperlukan, tapi sekali lagi, lebih baik bersabarlah. Jika Anda memulai terlalu cepat, Anda dapat mengasingkan anggota tim lain yang mungkin menganggapnya sebagai kritik pribadi. Juga memasukkan pembersihan kode / refactoring yang luas dapat diambil oleh manajer Anda sebagai tanda bahwa Anda tidak cukup fokus pada tugas yang sebenarnya. Jadi, Anda harus mendapatkan mandat untuk refactor sebelum memulai pada tingkat yang lebih serius. Perubahan lokal kecil mungkin baik-baik saja.

Juga, untuk meyakinkan manajemen, Anda perlu alasan bisnis. Manajemen jarang dipindahkan oleh deskripsi tentang bagaimana gaya pengkodean yang tidak konsisten. Anda perlu menunjukkan kepada mereka nilai apa yang dapat diajukan oleh perubahan yang diajukan kepada perusahaan - intinya adalah uang tunai. Jika Anda dapat mengumpulkan perhitungan yang meyakinkan tentang biaya dan manfaat jangka panjang dari berbagai perubahan yang diajukan, dan menunjukkan bahwa saldo keseluruhan jelas di sisi positifnya, Anda telah meningkatkan peluang Anda secara nyata.

Lakukan sendiri. Jika Anda menghargai gaya pengkodean tertentu, maka kerjakan kode yang melanggar gaya pengkodean . Periksa sepotong kode yang menyinggung dari kontrol sumber, format ulang kode ke persyaratan spasi putih gaya (sebagai contoh), dan komit kode diperbarui dengan pesan "Sesuai dengan aturan panduan gaya di spasi putih."

Setelah seminggu, hal terburuk yang mungkin dapat Anda lakukan adalah pergi langsung ke manajemen dengan ini. Kemungkinan besar mereka telah memasukkan banyak waktu ke dalam kode dan memiliki tingkat kebanggaan di dalamnya. Anda mungkin akan dianggap sebagai "tahu semuanya."

Apa yang akan saya lakukan jika saya adalah Anda adalah untuk memperbaikinya seiring berjalannya waktu. Ketika Anda menjadi lebih terbiasa dengannya dan saat Anda mengerjakannya lebih banyak, Anda akan memiliki kesempatan untuk memperbaikinya. Pada titik itulah saya akan mulai menunjukkan manfaat dari apa yang Anda lakukan kepada rekan kerja lainnya. Setelah itu, ketika rapat desain mencari modul baru, berikan argumen untuk apa yang Anda anggap sebagai cara terbaik.

Dan sejujurnya, standar ada karena suatu alasan tetapi, jika itu berhasil dan berfungsi dengan baik itu bernilai 100 kali lebih banyak dalam buku saya (terutama setelah seminggu di). Saya akan lebih khawatir jika Anda membuka kode dan melihat banyak kesalahan logika atau semacamnya.

Jangan langsung ke manajemen dengan 'masalah' ini.

Pertama, bicarakan dengan rekan kerja Anda dan cari tahu dari mereka mengapa semuanya demikian. Kemudian Anda dapat membuat penilaian yang lebih baik apakah ada masalah atau tidak. Anda mungkin terkejut dengan apa yang Anda pelajari. Anda juga dapat menemukan sekutu dalam menginginkannya dibersihkan.

Jika Anda tidak tahu bagaimana Anda sampai di tempat Anda berada di tempat pertama, itu membuat jauh lebih sulit untuk keluar.

Sudah banyak saran yang bagus di sini, dan saya adalah pendapat jangan-bakar-jembatan-Anda-sampai-Anda-sudah terbukti-sendiri-pertama seperti yang lainnya. Apa yang akan saya tambahkan adalah membahas hal-hal dengan rekan tim Anda jauh sebelum mengalienasinya dengan pergi ke manajer proyek atau pimpinan tim terlebih dahulu. Dan jelas tunjukkan pada mereka sebelum itu, bahwa Anda harus dianggap serius.

Kedengarannya juga bahwa itu lebih merupakan masalah gaya Anda dengan kode. Mengambil alih kode orang lain dan memegang hidung Anda sementara terbiasa dengan cara mereka menulis itu hanya bagian dari pekerjaan, bahkan jika itu adalah hal sepele seperti cara mereka memformatnya. Menyerahkan salah satu dari 'bayi' Anda kepada orang lain agar mereka bisa menanganinya dengan tangan kotor mereka bahkan lebih buruk ...

Jika pada akhirnya lebih dari itu - dan masalahnya lebih fungsional dari sekedar gaya - jika Anda akan memimpin tim / pm yang terbaik adalah melengkingkan kebutuhan untuk pengerjaan ulang dalam hal di mana ia akan menghemat uang dan upaya di masa depan proyek pengembangan. Refactoring lama yang bagus.