Apa itu / Apakah ada cara yang tepat untuk memberi tahu manajemen bahwa kode kita payah?

Kode kita jelek. Itu mungkin tidak selalu dianggap buruk, tetapi itu buruk dan hanya menurun. Saya mulai baru keluar dari perguruan tinggi kurang dari setahun yang lalu, dan banyak hal dalam kode kami membuat saya bingung. Pada awalnya saya berpikir bahwa sebagai orang baru saya harus tutup mulut sampai saya belajar sedikit lebih banyak tentang basis kode kami, tetapi saya telah melihat banyak yang tahu bahwa itu buruk.

Beberapa hal penting:

• Kami masih menggunakan bingkai (coba dapatkan sesuatu dari querystring, hampir tidak mungkin)
• VBScript
• Sumber Aman
• Kami 'menggunakan' .NET - maksud saya, kami memiliki pembungkus .net yang memanggil COM DLL sehingga hampir tidak mungkin melakukan debug dengan mudah
• Semuanya pada dasarnya adalah satu fungsi raksasa
• Kode tidak dapat dipelihara. Setiap halaman memiliki banyak file yang dibuat setiap kali halaman baru dibuat. Halaman utama pada dasarnya melakukan Response.Write () beberapa kali untuk merender HTML (runat = "server"? Tidak mungkin). Setelah itu bisa ada banyak logika di sisi klien (VBScript), dan akhirnya halaman mengirimkan ke dirinya sendiri (sering kali menyimpan banyak hal di bidang tersembunyi) di mana ia kemudian memposting ke halaman pemrosesan yang dapat melakukan hal-hal seperti menyimpan data ke database.
• Spesifikasi yang kami dapatkan menggelikan. Sering kali mereka memanggil hal-hal seperti "bidang isian otomatis X dengan bidang Y atau bidang Z" tanpa indikasi kapan harus memilih bidang Y atau bidang Z.

Saya yakin beberapa di antaranya adalah akibat tidak dipekerjakan di perusahaan perangkat lunak, tetapi saya merasa seolah-olah orang yang menulis perangkat lunak setidaknya harus peduli dengan kualitas kode mereka. Saya bahkan tidak dapat membayangkan bahwa jika saya mengemukakan sesuatu yang akan segera dilakukan, karena ada tenggat waktu yang besar, tetapi kami terus menulis kode buruk dan menggunakan praktik buruk.

Apa yang dapat saya? Bagaimana saya mengangkat masalah ini? 75% dari tim saya setuju dengan saya dan telah mengemukakan masalah ini di masa lalu, namun tidak ada yang berubah.

Pastikan Anda tidak bereaksi berlebihan. Anda masih segar, mungkin belum pernah bekerja di banyak tempat (mana?), Dan karenanya tidak siap untuk dunia "kode kehidupan nyata". Kode kehidupan nyata adalah hal yang mengerikan. Ini seperti kode sekolah Anda yang bagus dan kode proyek pribadi obsesif Anda yang berhubungan seks di ruang bawah tanah reaktor nuklir dan bayi itu tumbuh di selokan limbah beracun; itu adalah mutan yang mengerikan.

Tetapi dengan asumsi Anda benar, dan kodenya sama buruknya dengan yang Anda katakan (yaitu lebih buruk dari sekadar kode yang biasanya buruk), maka Anda benar untuk khawatir. Bicaralah dengan tim Anda, dan tentukan apakah orang lain ada di pihak Anda. Butuh kerja keras untuk memperbaiki situasi - jika anggota tim lainnya mengenali masalah tetapi tidak peduli maka Anda membuang-buang waktu.

Menjadi junior, Anda mungkin tidak dalam posisi untuk memimpin. Jika Anda pergi ke manajemen sendiri, sebagai karyawan baru yang juga junior, pendapat Anda mungkin akan diabaikan. Dapatkan pengembang pemimpin Anda atau salah satu dari orang paling senior yang terlibat. Sekali lagi, jika tidak ada orang senior yang tertarik maka Anda membuang-buang waktu.

Dengan asumsi Anda bisa membuat beberapa orang teknis senior tertarik, saya akan berupaya mengidentifikasi bidang-bidang masalah dan kemungkinan solusi. Misalnya, jika "semuanya pada dasarnya adalah satu fungsi raksasa" maka lain kali Anda bekerja di 'fungsi raksasa' itu mungkin Anda harus sedikit refactor. Sekali lagi, Anda perlu membuat semua orang tertarik. Jika Anda memilah-milah sedikit masalah Anda & meningkatkan sepotong demi sepotong akhirnya mereka akan menjadi jauh lebih sedikit dari masalah. Setiap kali Anda menyentuh sepotong kode pertimbangkan apakah itu dapat diperbaiki.

Anda tidak akan duduk dengan manajemen dan mengatakan 'semuanya buruk dan perlu ditulis ulang'. Itu tidak masuk akal bagi mereka - biaya banyak dan berpotensi sangat berisiko. Alih-alih, mereka harus disadarkan bahwa ada masalah, dan bahwa ada rencana untuk perlahan-lahan membaik ketika perubahan dilakukan. Mereka harus dididik tentang manfaat kode yang dapat dipelihara. Ini harus berasal dari orang senior yang mereka percayai secara teknis dan profesional - bukan dari Anda.

Lengkap menulis ulang? Hampir selalu merupakan ide yang buruk.

Pada akhirnya tidak banyak yang dapat Anda lakukan karena Anda baru. Jika tidak ada yang ingin memperbaiki keadaan, maka Anda mengumpulkan pengalaman Anda dan pindah ke tempat berikutnya.

Baca Joel On Software - hal-hal yang tidak boleh Anda lakukan. Pahami alasannya, lalu baca beberapa artikel lain tentang perangkat lunak buruk dan cara memperbaikinya, ditulis oleh manajer, bukan programmer. Berbekal informasi ini, Anda akan dapat mengajukan kasus untuk memperbaikinya, dalam hal yang dipahami dan dipedulikan manajer. Petunjuk: Manajer yang baik tidak menghabiskan waktu dan uang hanya berdasarkan pendapat dan perasaan programmer tentang apa yang harus dilakukan.

"Kode ini omong kosong dan perlu ditulis ulang" tentu akan dilemparkan kembali kepada Anda, bahkan jika Anda secara teknis benar.

"Kita dapat mengambil bulan dari jadwal proyek saat ini, lebih murah dan membuatnya lebih dapat diandalkan." akan mendapatkan perhatian mereka (perhatikan kurangnya menyebutkan BAGAIMANA Anda bermaksud untuk melakukan ini di panggungnya.

Apa pun yang Anda katakan, pastikan Anda benar. Jika Anda mengatakan itu buruk, penulisan ulang Anda harus sangat bagus. Jika Anda mengatakan itu akan memakan waktu seminggu, Anda sebaiknya memastikan itu akan menjadi seminggu, dan menjadi baik. Kerusakan dalam kode ulang akan dikenakan biaya, secara pribadi, mahal, terlepas dari apa yang mungkin terjadi seandainya Anda tidak melakukan pengerjaan ulang. Jika seseorang telah ada di sana sebelum Anda dan mengacaukan atau menjual kembali penulisan, menyerah, manajer tidak suka dipermainkan dan tidak akan membiarkan hal itu terjadi dua kali. Dengan token itu, jangan mengacaukannya untuk orang-orang yang mengikuti, Anda hanya mendapatkan satu kesempatan di ini ...

Temukan cara untuk menyebarkan biaya selama periode waktu tertentu atau sejumlah proyek. Manajer membenci risiko, investasi spekulatif, dan arus kas negatif - bekerjalah dalam toleransi manajer Anda terhadap hal ini. Mulailah dengan saran kecil, risiko rendah, biaya rendah. Setelah terbukti benar, Anda bisa mencari ikan yang lebih besar.

Pertama-tama, Anda akan menemukan barang-barang warisan konyol di mana pun Anda bekerja sebagai programmer kecuali Anda bekerja pada saat start-up dan Andalah yang menciptakan kode warisan konyol asli. Anda harus bisa bermain dengan pukulan ini jika Anda berencana memiliki karir dalam pemrograman.

Kedua, seringkali ada pertimbangan biaya untuk memperbaiki sistem lama. Sebagai contoh, saya telah melihat lebih dari satu perusahaan yang memiliki VB6 berusia 10 tahun dan aplikasi ASP klasik masih beroperasi. Dalam beberapa kasus, ini karena proyek besar untuk memindahkan .NET gagal parah. Dalam kasus lain, alasannya adalah "jika tidak rusak, jangan perbaiki". Tetapi, pada orang lain, biaya perpindahan itu dapat dibenarkan karena masalah yang disebabkan oleh sistem warisan terlalu besar untuk diabaikan.

Dalam situasi di mana ada kegagalan besar di masa lalu, hampir tidak mungkin menghasilkan perubahan. Jika demikian, semir resume Anda dan mulailah mencari pekerjaan baru. Jika tidak rusak, Anda mungkin tidak akan memiliki alasan untuk mengeluh tentang kode itu sendiri tetapi Anda tidak berada di jalur karir yang memuaskan dan berkembang. Jika rusak, dan sepertinya ada dalam kasus Anda, saat itulah Anda memiliki kesempatan untuk berubah.

Pendekatan terbaik yang saya lihat adalah tidak menggigit terlalu banyak tetapi untuk memulai dengan perubahan bertahap yang akan memiliki dampak paling positif. Berdasarkan uraian Anda, mengelola permintaan perubahan yang lebih baik akan menjadi tempat untuk memulai. Setelah itu terkendali, Anda dapat mulai membuat kerangka layanan atau peningkatan desain / kode tambahan lainnya.

Pendekatan terburuk yang pernah saya lihat adalah mencoba membuat lompatan besar langsung dari sistem legacy ke sistem terbaru dan terhebat, misalnya, melompat dari sistem VB6 / Classic ASP / COM + yang bekerja dengan kikuk ke sistem MVC / Entity Framework.

"Hei Boss, setelah Proyek Besar saya dan tim ingin beberapa waktu, idealnya X bulan, untuk mengatur kode kita. Hal-hal yang seharusnya dapat dilakukan dalam hitungan menit membutuhkan waktu berjam-jam karena semuanya sangat tidak teratur. Jika tidak mungkin dilakukan tepat setelah Big Project, kami ingin merencanakan jadwal yang realistis. "

(sebagian diparafrasekan dari komentar Azkar pada pertanyaan)

Mulai membaca Joel di Perangkat Lunak (Joel Spolsky / Pendiri Stack Exchange) ...

Hal pertama yang akan saya lakukan adalah melakukan Tes Joel .

Ini akan memungkinkan Anda untuk mempresentasikannya sebagai "Saat saya mencari cara untuk meningkatkan sebagai pengembang ... saya tersandung pada 12 pertanyaan tes tentang lingkungan pengembangan ini, jadi untuk bersenang-senang saya menjawab mereka tentang tempat saya bekerja." ... Ini pada gilirannya menjadikannya pihak ketiga yang menguraikan apa yang salah dengan kode Anda dan bukan Anda secara pribadi.

Ketika Anda membaca lebih lanjut tentang Praktik Pragmatis Anda akan meningkatkan diri sendiri dan menerapkan hal-hal seperti merah / hijau / refactor dan ini pada gilirannya akan memungkinkan Anda untuk membersihkan basis kode sehingga menjadi terpelihara. (lembur)

Semoga itu bisa membantu! Selamat datang di Pemrograman (kode kemarin biasanya payah) ;-)

Kiat cepat: jika Anda mengusulkan manajemen dengan daftar alasan mengapa Anda harus membuat kode berbeda, sertakan sebagai argumen "Peningkatan moral / kondisi kerja untuk para programmer".

Jelaskan bahwa tim teknologi akan lebih banyak menulis konten dan menjaga kode bersih daripada kekacauan saat ini, dan ini tentu saja dapat meningkatkan sikap Anda terhadap pekerjaan. Bisa jadi argumen yang bermanfaat.

• Apakah manajemen benar-benar mendikte desain? Jika Anda memiliki sebagian besar tim di belakang Anda, apa yang menghentikan Anda? Jadilah proaktif dan putuskan sebagai kelompok. Munculkan rencana untuk mengimplementasikannya secara bertahap . Maka lakukanlah.
• Apakah manajemen menentukan alat pengembangan yang Anda gunakan? Kecuali ada biaya waktu untuk mengganti manajemen alat biasanya tidak peduli. Jadilah proaktif dan putuskan sebagai kelompok alat pengembangan apa yang ingin Anda gunakan. Jika Anda perlu membeli dari manajemen, maka tunjukkan rencana migrasi dan analisis manfaat biaya. Maka lakukanlah.
• Apakah manajemen menentukan bahasa yang Anda gunakan? Jadilah proaktif dan putuskan sebagai grup apa yang akan digunakan daripada VBScript. Munculkan rencana untuk mengimplementasikannya secara bertahap dan melakukannya. Jika Anda perlu manajemen, beli, tunjukkan rencananya. Maka lakukanlah.
• Saya tidak punya apa-apa untuk spesifikasi. Itu biasanya sangat tergantung pada orang dan proses di tempat kerja Anda. Mengidentifikasi apa yang rusak dan perubahan minimal yang diperlukan untuk memperbaiki proses membutuhkan waktu, analisis dan pemahaman tentang bagaimana hal-hal saat ini bekerja dan bagaimana mereka seharusnya bekerja. Jika Anda tahu bahwa Anda dapat membuat rencana dan mencoba meyakinkan manajemen.

Anda mendapatkan lebih banyak perubahan dan rasa hormat jika mengusulkan cara perubahan yang tidak melibatkan banyak waktu khusus tanpa nilai bisnis (atau lunak) untuk ditunjukkan.

Berbicara dari pengalaman: Tidak mudah. Hampir mustahil. Manajemen tidak peduli bahwa kode itu menyebalkan dan kemungkinan besar sama sekali bodoh dan / atau tidak mengerti masalah yang sedang dihadapi, atau mereka akan memperbaikinya sejak lama dan Anda tidak akan terjebak dengan hal itu hari ini. Hal terbaik yang dapat Anda lakukan adalah membuat daftar alasan kode itu menyebalkan, dan kemudian alasan mengapa hal itu menyebalkan untuk menunjukkan nilai bisnis aktual dalam refactoring / penulisan ulang.

Contoh mungkin untuk "Kode tidak dapat dipertahankan":

Kode saat ini tidak dapat dipelihara karena X , Y dan Z (cantumkan alasan mengapa itu tidak dapat dipelihara). Ini membuat permintaan perubahan dan fitur baru sangat sulit untuk dilakukan, karena X , Y , Z (alasan mengapa membuat perubahan itu sulit). Karena perubahan itu sulit, tim pengembang tidak dapat dengan mudah menanggapi perbaikan dan peningkatan bug.

Satu-satunya harapan Anda adalah bahwa atasan dan manajemen senior Anda tidak terlalu bodoh untuk memahami konsekuensi apa yang dimiliki kode ini, dan bersedia berhenti mengeluarkan permintaan fitur baru untuk mengatasi masalah tersebut, jika tidak, upaya Anda akan sia-sia. . Berbicara dari pengalaman masa lalu, sangat mungkin bahwa mereka tidak akan melihat ada yang salah dengan kode, dan / atau rekan kerja Anda terlalu ceroboh untuk membawa masalah mereka ke manajemen.

Semoga berhasil. Anda akan membutuhkannya.

"Saya mulai baru lulus dari perguruan tinggi" - harus menjawab pertanyaan Anda.

Manajemen mungkin tahu ada kode yang kurang optimal. Kebanyakan kode kecuali Anda menyewa Ray Gosling, Guido Van Rossum atau orang lain yang benar-benar bagus dan mahal untuk menulisnya.

Manajemen juga tahu itu berfungsi menggunakan definisi "karya" apa pun yang berlaku untuk perusahaan Anda (Tidak macet, menjual, menyampaikan laporan, atau apa pun).

Mereka ingin Anda menjaga kode "berfungsi" dengan biaya minimal. Mereka tidak ingin proposal untuk proyek mahal menulis ulang semuanya.

Kasus bisnis hampir tidak mungkin dibuat karena hasil kerja Anda adalah perangkat lunak yang berfungsi (apa yang sudah mereka miliki) bukan kode yang elegan.

Tambahkan fakta bahwa dalam perangkat lunak ada biaya peluang besar dari mendapatkan ke pasar dengan fitur terlebih dahulu. Jika Anda benar-benar memikirkannya, pengembalian jangka panjang atas investasi waktu tidak dijamin.

Yang mengatakan, itu masih rencana yang baik untuk refactor dan memperbaiki hal-hal kecil (seperti mendapatkan VSS yang baik) di sepanjang jalan dalam gigitan yang dikelola. Pada akhirnya ini adalah masalah teknis bukan masalah manajemen. Lakukan saja apa yang perlu dilakukan sambil tetap memenuhi apa yang Anda janjikan dan Anda akan baik-baik saja. Manajemen mungkin tidak akan tertarik pada detail rumit dari kualitas kode bahkan jika Anda membuat kasus yang kuat.

Tinggalkan saja sesegera mungkin (mungkin jangan pergi terlalu cepat karena Anda tidak ingin terlihat seperti seorang hopper pekerjaan). Fakta bahwa kode mereka berantakan dan orang-orang tetap di sana berarti Anda kemungkinan bekerja dengan pengembang yang buruk. Setiap pengembang yang layak yang peduli dengan pekerjaan mereka tidak akan tinggal lama mengerjakan omong kosong seperti itu.

Kesempatan penulisan ulang terjadi sangat rendah kecuali jika Anda dapat dengan jelas menunjukkan itu akan bernilai investasi $$$.

Manajemen tidak peduli dengan kode tersebut. Mereka peduli tentang memiliki produk untuk dijual.

Jika sistem warisan benar-benar buruk dan itu menambah jumlah overhead konyol untuk sebagian besar tim (saya katakan mayoritas karena selalu ada orang yang baik kode potongan besar atau semua itu dan tahu itu seperti bagian belakang tangannya) kemudian mendekati mereka dan mengatakan itu adalah biaya uang bisnis dalam waktu pengembangan, dan itu akan berpengaruh pada kepuasan pelanggan.

Tetapi sekali lagi, mereka masih tidak peduli tentang kode, mereka peduli pada suatu produk, jadi sementara jawaban itu mungkin membuat mereka pergi "Ya mari kita lakukan", Anda mungkin juga merapikan kode tanpa meminta izin manajer. Jangan berlebihan, pastikan Anda berbicara dengan tim terlebih dahulu, tidak ada yang suka datang dan coba gunakan fungsi yang membuat Anda 3 bulan untuk menulis dan sekarang tampaknya tidak berfungsi karena sudah diretas.

Pendekatan manajemen sedemikian rupa sehingga Anda menunjukkan bahwa Anda memahami dampak anggaran dari membuat perubahan besar pada kode dan dampak anggaran TIDAK membuat perubahan. Saya menyukai kata-kata Emilio.

Penting untuk diingat bahwa kode "lama" akan selalu mengerikan. Maksud saya, kita semua tumbuh sebagai pengembang terus-menerus. Kami menulis kode yang baik, kemudian belajar menulis kode yang lebih baik nanti dan kode "baik" sebelumnya tampak mengerikan. Terlalu banyak pengembang yang terus-menerus berusaha membuatnya lebih baik dan membuang lebih banyak uang dalam jangka panjang. Itu tindakan penyeimbangan. Yang sedang berkata, itu selalu bagus jika Anda bisa membuatnya lebih baik saat Anda pergi. Ketika Anda pergi untuk memodifikasi fungsi raksasa itu, bagilah! Akhirnya Anda akan sampai di suatu tempat.

Jangan lakukan itu.

Menulis ulang proyek besar dari awal adalah kesalahan besar sebagian besar kali.

Saya tidak pernah berpikir mudah untuk memberi tahu manajer terutama Manajer Proyek tentang kode buruk dan refactoring. Pertama, mereka harus mempercayai Anda, bahkan jika Anda adalah pria senior, Anda masih perlu waktu untuk dipercaya. Kedua, mereka tidak mengerti seberapa buruk masalahnya. Jika hari ini adalah hari terakhir untuk merilis build baru, dan build gagal. Mereka tahu betapa seriusnya itu, tetapi mereka tidak pernah tahu pembangunannya gagal karena banyak masalah seperti kode yang buruk, pengujian yang tidak memadai, dll.

Saya telah melakukan tugas konfigurasi dan penerapan dalam proyek web. Sering kali dibutuhkan banyak waktu untuk memperbaiki masalah yang tidak terduga setiap kali saya menggunakan bangunan baru. Sebagian besar masalah adalah keamanan dan integrasi (antara beberapa aplikasi web / Windows). Kode kita payah, kode orang lain payah, kode mereka sepenuhnya spageti.

Kami sedang merencanakan untuk versi baru dan saya sangat meminta beberapa refactoring, cukup tambahkan log detail ke kode login / otentikasi di mana bug sering terjadi. Para manajer setuju, tetapi kemudian dimasukkan ke dalam daftar barang yang harus dimiliki dan saya tidak tahu apakah itu akan dilakukan karena kami sudah memiliki daftar besar fitur dan kerangka waktu yang ketat.

Ada dua jenis manajer: yang berpura-pura mengerti apa yang Anda lakukan dan yang tidak. Orang-orang yang berpura-pura memahami perangkat lunak akan memusuhi Anda. Orang-orang yang tidak hanya terganggu oleh Anda.

Bagaimanapun, manajer semua pembohong sehingga mereka memiliki kecenderungan yang kuat untuk menganggap semua orang lain.

Maksud saya adalah, jika Anda mengatakan perangkat lunak sudah ketinggalan zaman, mereka hanya akan menganggapnya sebagai alasan. Mereka tidak peduli.