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


9

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.


5
Berapa banyak pengalaman yang Anda miliki dengan ASP.NET? (selain kredensial MCPD Anda).
Marcie

11
Selamat datang di produk yang sukses. Kode 'lawas' selalu omong kosong.
Steven Evers


Saya cukup yakin saya melihat pertanyaan serupa di stackoverflow. Tidak mungkin saya pikir seorang insinyur dapat memindahkan tumpukan kode raksasa dengan sekop kecil. Saya kira Anda bisa mulai mengajar rekan kerja Anda melakukan refactoring.
Reno

Saya meninggalkan pekerjaan karena menemukan situasi ini, dan saya bahkan bukan seorang programmer, saya seorang administrator sistem tetapi cukup melihat kode, dan prinsip-prinsip pengkodean untuk tahu itu akan KO perusahaan, (yang memang). Yang terbaik yang bisa saya lakukan, yang membantu mereka sekarang, adalah menjelaskan bahwa pembersihan tiga minggu, dan menulis ulang modul inti akan menghemat waktu berbulan-bulan dalam pengembangan di masa depan - Butuh aplikasi meltdown, sebelum mereka mulai mempertimbangkannya, pada saat mana CV saya memiliki menemukan jalan online! Berdiri tegak, dan buktikan poin Anda jika Anda bisa, kemudian serahkan keputusan kepada manajemen itu akan membuat hidup Anda lebih mudah.
Tuan IT Guru

Jawaban:


16

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


Bukti puding ada pada saat makan. Jika yang Anda lihat sebenarnya membutuhkan perbaikan, perbaiki - dan orang-orang di sekitar Anda akan segera menyadarinya.
blueberryfields

1
Yah, aku sudah berniat untuk memperbaiki hal-hal kecil seiring berjalannya waktu. Tapi, misalnya ... bagaimana tim melakukan popup windows pada formulir mereka adalah salah . Ini adalah sesuatu yang dibuat khusus, dan digunakan di seluruh aplikasi. Saya tidak berpikir saya bisa lolos dengan menulis ulang tanpa ada yang memperhatikan, mengajukan pertanyaan, atau mengembalikan perubahan saya.
Adam Maras

11
Saya menggunakan istilah yang disebut "refactoring oportunistik". (Ini sebenarnya berlebihan karena semua refactoring bersifat oportunistik). Kita semua harus bekerja pada basis kode yang merusak. Mencoba mengubah sesuatu dengan kata-kata hanya membuat tim menjadi defensif. Ubah dengan melakukan (kode adalah mata uang Anda) dan ketika seseorang bertanya mengapa, jelaskan alasan Anda kepada mereka (dengan kata-kata yang lebih baik daripada "cara lama mengisap").
Michael Brown

2
Jika salah, tambahkan juga test case ke test suite yang gagal jika mereka mengembalikan kode.
blueberryfields

5
BTW, sampai Anda benar-benar membuktikan diri dengan kode Anda, Anda tidak akan dianggap serius. Jangan menjadi anak yang sombong mencerca orang-orang tua. Saya tidak mengatakan persepsi Anda tentang kode itu tidak benar, saya benar-benar mengatakan bahwa posisi sosial Anda memengaruhi pesan Anda. Sukses dengan kesuksesan.
Hack Saw

11

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.


9

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.


Alasan saya menyebutkan sertifikat MCPD saya adalah karena ada penekanan kuat pada praktik terbaik yang terbukti. Terkadang, dalam kerangka kerja seperti ASP.NET, benar -benar ada cara yang benar dan cara yang salah untuk melakukan sesuatu.
Adam Maras

Tidak diragukan lagi ada jalan yang benar! Tetapi beberapa pria baru datang melambaikan sertifikat bukan cara untuk pergi tentang hal itu. Pengalaman penawaran, lebih kredibel!
ozz

1
@ Adam: hanya sebuah pemikiran, tetapi sebagian besar contoh yang saya lihat - terutama dengan ASP.Net dan bahkan lebih dengan MVC - menunjukkan cara-cara mengerikan untuk melakukan sesuatu, sambil mengklaim itu adalah praktik "terbaik". Pandangan sederhana tentang berapa banyak contoh yang menggunakan kelas EF atau L2S dalam ViewModels adalah ilustrasi.
quentin-starin

8

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.


Ini! Begitu banyak ini. Itu satu hal jika itu menciptakan bug, tetapi jika itu hanya ANDA mencoba untuk memaksa masalah OCD nitpicky Anda ke tenggorokan orang lain maka dengan segala cara turun dari tim saya!
Glstunna

6

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?

1
1) No. 2) Tidak juga. 3) Sebagian besar waktu? 4) Terkadang. 5) YA.
Adam Maras

6

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.


6

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.


5

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.


1
Percayalah, saya ingin mengusulkan penulisan ulang. Saya hampir tergoda untuk pulang dan memulai basis kode baru di ASP.NET MVC 3 hanya untuk menunjukkan kepada mereka betapa jauh lebih baik itu. Saya hanya berpikir itu tidak akan diterima dengan baik, karena saya baru di tim.
Adam Maras

3

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.


3

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.


3

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."


+1: Kanan - Minta maaf, bukan izin.
Jim G.

1
Baik jika Anda mengikuti panduan gaya dan Anda tidak ketinggalan pada tugas yang ditugaskan, buruk jika Anda melakukan ini sebelum tugas yang diberikan atau mengubah ke gaya yang belum ditentukan oleh organisasi.
HLGEM

3

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.


+1 untuk yang parah tahu semuanya. Saya mengikuti seorang mantan pria MS di twitter dan dia melakukan hal yang sama persis di peran baru & tweet tentang hal itu, kesalahan besar!
ozz

2

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.


1

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.

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.