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


70

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.


27
terbiasalah. 90% dari kode penulisan adalah kode membaca.

7
tidak ada yang berubah karena alasan yang sama bahwa itu adalah kode yang buruk. Mereka berhenti membayar Booku $$$$ untuk siapa saja untuk bersenang-senang dulu.

11
Ini di luar topik. Tetapi jawaban singkatnya adalah: ekonomi. Berapa bulan pengembang untuk biayanya merapikan basis kode, dan berapa bulan pengembang akan menghemat basis kode?
Oliver Charlesworth

89
cara terbaik adalah keluar wawancara.
kylben

32
Tidak masalah bagaimana Anda berbicara kepada orang buta tentang warna. Mereka tidak akan mengerti Anda.
ThomasX

Jawaban:


68

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.


10
+1 untuk baris terakhir saja. Orang-orang biasanya tidak mau mendengarkan pendatang baru, bahkan jika pendatang baru itu memberikan pengalaman mereka sendiri dan sudut pandang yang berbeda sehingga orang lain terlalu tergenang untuk melihat budaya perusahaan. Orang-orang juga buta untuk mendengar kebenaran (yaitu "Semuanya buruk karena orang-orang yang mengaturnya adalah orang-orang idiot yang tidak tahu apa yang mereka lakukan") dan lebih suka turun dengan kapal daripada mengakui hal-hal buruk dan perlu diperbaiki. Kadang-kadang membingungkan bagaimana pemilik bisnis akan berisiko kehilangan segalanya daripada meluangkan waktu untuk memperbaiki hal-hal buruk.
Wayne Molina

2
Untuk melanjutkan poin terakhir itu, saya telah melihat banyak tempat di mana manajemen lebih suka menjalankan risiko keluar dari bisnis ketika sistem yang buruk runtuh dengan sendirinya daripada benar-benar menangani dan mengatasi masalah, bahkan jika masalah itu berarti menunda pada fitur baru.
Wayne Molina

5
Sayangnya, menggunakan semacam pendekatan 'perang gerilya' untuk re-factoring kadang-kadang dapat menyebabkan Anda menembak diri sendiri. Kecuali jika sistem memiliki set unit / tes integrasi yang baik yang ditulis menentangnya (yang jika buruk kemungkinan besar tidak akan) akan mengarah pada pengenalan bug yang akan membutuhkan seluruh pengujian sistem untuk dilewati melalui QA untuk menghindari.
aceinthehole

1
@aceinthehole: tepat sekali. Jika pengujian mahal, manajemen tidak akan mau mengambil risiko perubahan 'yang tidak perlu', meskipun tanpanya, sistem akan menjadi tidak dapat dipelihara di masa mendatang.
kevin cline

2
@WayneM, dan para idiot yang tidak tahu WTF yang mereka lakukan di awal proyek sekarang adalah manajer senior. Jangan pernah melupakan bagian itu!
HLGEM

58

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.


2
lucu ... saya ditolak karena menyarankan situs Joel :-)
Robert French

6
@Robert French: manajer Anda membaca posting Anda ...
Dave Markle

8
Tidak bercanda. Tidak menyenangkan mencoba berdebat untuk "Bisakah saya memiliki waktu pengembang selama 6 bulan untuk menulis ulang semuanya? Hasil akhirnya akan persis seperti yang kita miliki hari ini, tapi mungkin dengan beberapa bug baru. Oh, dan kita akan menggunakan banyak pengembang yang sama yang menciptakan tumpukan sampah saat ini untuk menulis ulang karena mereka tahu lebih baik sekarang. "
JohnFx

3
@ joshin4colours: <quote> Ya, saya tahu, ini hanya fungsi sederhana untuk menampilkan jendela, tetapi telah menumbuhkan sedikit rambut dan hal-hal di atasnya dan tidak ada yang tahu mengapa. Baiklah, saya akan memberi tahu Anda alasannya: itu adalah perbaikan bug . ... Masing-masing bug ini memakan waktu berminggu-minggu penggunaan di dunia nyata sebelum ditemukan. ... Ketika Anda membuang kode dan mulai dari awal, Anda membuang semua pengetahuan itu. </quote>
Martin York

4
Maaf tapi satu tahun pengalaman tidak memberikan kredibilitas untuk membuat klaim ini kepada manajemennya.
Jeremy

14

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.


3
"Pertama-tama, kamu akan menemukan barang-barang warisan konyol di mana pun kamu bekerja sebagai programmer kecuali jika kamu bekerja pada saat start-up dan kaulah yang menciptakan kode warisan konyol yang asli." Saya adalah programmer pertama di startup saya. Delapan yang terakhir saya sering menemukan diri saya berkata 'siapa yang menulis kode konyol ini?', Hanya untuk memeriksa dan mengetahui bahwa saya adalah pihak yang bersalah.
Jim In Texas

Kecepatan iterasi mengalahkan kualitas iterasi. Dengan kata lain, buat banyak perubahan kecil, sering, dan pada akhirnya Anda akan mencapai yang Anda inginkan.
jasonk

11

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


10
Secara teori, ini akan bagus. Dalam praktiknya, jawabannya akan menjadi sesuatu di sepanjang baris "Tidak, CEO ingin Another Big Projectdilakukan dalam X bulan." atau "Kami memiliki fitur baru yang perlu segera dilakukan, kami tidak punya waktu untuk memperbaiki apa yang sudah berfungsi"
Wayne Molina

2
Itu jarang (jika pernah) berhasil. Terutama jika Anda memiliki manajer yang sudah ada untuk sementara waktu, karena ia akan pernah mendengar kalimat ini sebelumnya hanya untuk melihatnya meledak.
taylonr

1
Ini hanya membuatku tertawa. Anda tidak akan pernah menulis ulang sepenuhnya ke dalam jadwal. Apa yang berpotensi Anda lakukan adalah memiliki tugas yang lebih kecil di setiap proyek yang akan datang untuk meningkatkan beberapa sub-sistem sehingga pada akhirnya (selama beberapa tahun) ia dibawa ke spec.
Martin York

Dalam pengalaman saya, pendekatan ini akan sering ditolak. Pendekatan alternatif adalah dengan beberapa perkiraan Proyek Besar sebesar 1,5 dan menghabiskan 1/3 waktu untuk membersihkan kode sepanjang jalan.
JBRWilkinson

2
Respons yang sangat sering adalah, "Siapa yang akan mendanai gaji Anda untuk melakukan ini?" Jika Anda tidak memiliki sponsor langsung untuk tugas itu, Anda harus meminta perusahaan melakukan investasi jangka panjang. Atau apakah Anda akan bekerja secara gratis saat melakukan ini?

7

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) ;-)


4
Saya tidak berpikir ini membahas bagaimana ia harus mendekati manajemen.
Pubby

3
Sepertinya Azbar tahu masalahnya dan tahu bagaimana cara memperbaikinya, tetapi dia tidak tahu bagaimana cara menggulirkan bola sehingga bisa diperbaiki.
Pubby

1
Ya ... Saya menyarankan menggunakan sudut pandang pihak ketiga saat mempresentasikannya. Saya tidak berpikir dia bertanya secara khusus bagaimana berbicara dengan bosnya.
Robert French

4
Jawaban ini sulit mendapatkan begitu banyak suara. Kalimat pertama layak +10. Masalah dengan mendekati manajemen adalah memahami apa yang penting bagi mereka, Joel, dan jawaban ini, mengatasi masalah semacam ini dengan melihat alasan mengapa, dan mengapa tidak, dari perspektif bisnis, kode harus ditulis ulang.
mattnz

1
@Robert French +1 untuk jawaban yang bagus. Penting bagi Azkar untuk memahami bisnis serta teknologinya. Menyarankan dia membentuk pendapatnya sendiri dari pengamatan orang ketiga yang berkualifikasi tinggi akan membantu dalam pengembangan Azkar sebagai pengembang, dan bukan hanya pembuat kode. Selain itu, kisah PB&J lucu.
bakoyaro

7

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.


pasti ide yang bagus dan juga sangat benar
sdm350

5
  • 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.


Tidak / Ya / Ya. Pilihan bahasa dan alat jarang merupakan pilihan yang dibuat karena alasan teknis. (lihat: parashift.com/c++-faq-lite/big-picture.html#faq-6.5 ) Mereka adalah alat yang dimiliki perusahaan sejak awal. Re-Tooling perusahaan atau tim tidak mungkin terjadi karena penurunan produktivitas.
Martin York

1
+1 untuk rencana dan implementasi secara bertahap. menulis ulang semuanya hanya meminta kegagalan. Kemenangan kecil seiring berjalannya waktu membangun kepercayaan diri. Adapun spesifikasi ... sebagian besar spesifikasi yang Anda dapatkan sebagai programmer akan kekurangan tugas kita untuk memperbaikinya. Sesekali Anda dimanjakan oleh seseorang yang menulis spesifikasi bagus. Biasanya pindah / dipromosikan / menemukan pekerjaan yang lebih baik dengan cepat sejauh programmer yang bersangkutan.
SoylentGray

@Loki Astari: Di ​​sebagian besar perusahaan yang pernah saya kunjungi, saya telah mendorong perubahan untuk mulai dari sistem kontrol revisi, kerangka kerja, proses pengembangan hingga bahkan bahasa. Yang Anda butuhkan adalah rencana yang masuk akal daripada menguraikan berapa biaya dan manfaat perubahan itu. Hanya karena jarang dilakukan, tidak berarti itu tidak dapat dilakukan.
dietbuddha

4

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.


2
Setuju dan "tidak dapat dipertahankan" juga hanya berfungsi sampai batas tertentu. Bagi banyak manajer (terutama tanpa latar belakang teknis) kode kerja sama dengan kode yang dapat dipelihara. Jika Anda mengklaim sebaliknya, Anda bahkan bisa dianggap tidak kompeten di mata mereka.
MaR

3

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


Baris pertama Anda benar-benar bias terhadap junior. Untuk satu, Anda tidak tahu pengalaman NYA sehingga Anda tidak bisa menyimpulkan jawaban atas pertanyaannya. Dan generalisasi seperti itu menjadi sangat bias terhadap junior! Saya telah melakukannya selama sekitar 20 tahun sekarang dan saya dapat menjamin bahwa saya telah melihat 'pemula' yang lebih berpengetahuan daripada 'orang bebal senior'.
Jeach

Tidak benar-benar bias terhadap junior, tapi, mungkin dia harus mengakui pengalaman dan pengetahuan superior rekan-rekannya yang telah bekerja selama beberapa waktu? Mereka semua tidak mungkin Wallies tua yang tidak kompeten.
James Anderson

2

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.


2

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


Pada akhirnya, ini adalah satu-satunya tindakan nyata. Saya sudah mengatakannya sebelumnya, saya akan mengatakannya lagi: Pengembang pintar bekerja untuk perusahaan pintar yang mengerti mengapa penting untuk SELALU menulis kode yang baik dan mencurahkan waktu yang diperlukan untuk memastikan kode yang baik. Pengembang yang buruk bekerja untuk perusahaan yang buruk di mana semua orang terlalu fokus pada "menyelesaikan tugas mereka" untuk peduli bahwa mereka hanya menambahkan lebih banyak lumpur ke tumpukan dan bahkan melihat kode refactoring yang tidak secara langsung terkait dengan tugas Anda saat ini untuk "membuang-buang" waktu". Tempat-tempat ini tidak layak digunakan jika Anda menganggap diri Anda cerdas.
Wayne Molina

1

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.


Saat Anda memberi petunjuk untuk ... Pasti ada sesuatu yang bisa dia lakukan untuk memperbaiki kode. Jika semua fungsi satu raksasa ada hal yang dapat Anda lakukan tentang itu. Fakta bahwa ia bahkan mengeluh tentang Source Safe agak lucu. Tidak ada yang salah dengan Source Safe, ini telah digunakan selama bertahun-tahun, mungkin ada beberapa hal yang tidak masuk akal di dunia saat ini tetapi di belakang.
Ramhound

Saya pikir SourceSafe sendiri bukan masalahnya, ia terus menggunakan SourceSafe ketika ada alat gratis yang lebih baik tersedia hanya berteriak "Kami tidak tahu apa-apa di luar kotak" dan "Mediocrity adalah aturan hari ini karena kami akan tetap dengan yang lebih rendah produk daripada belajar yang unggul ". Ini adalah sikap yang dimiliki sebagian besar pengguna SourceSafe.
Wayne Molina

"merapikan kode tanpa izin" - terdengar seperti memperbaiki sesuatu yang tidak rusak.
James Anderson

1
Ruang tamu saya bukan bahaya kesehatan tetapi saya masih memastikan saya membersihkannya secara teratur. Bukan masalah memperbaiki sesuatu yang tidak rusak, tetapi melakukan tugas yang diperlukan.
Nicholas Smith

0

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.


0

Jangan lakukan itu.

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


Besar itu relatif.
Luca

1
Definisi saya adalah: Jika Anda tidak dapat menulis ulang sendiri dalam 5 hari maka itu besar.
Cesar Canassa

-1

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.


-3

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.


+1 pada "manajer semuanya pembohong sehingga mereka memiliki
kecenderungan yang

-1 pada yang sama; keduanya tidak benar dan tidak membantu
Jaap

@ Jaap ada banyak penelitian yang menghubungkan kekuatan dan kelas sosial dengan ketidakjujuran. Apakah itu berarti Anda akan menarik -1 Anda? Contoh: msnbc.msn.com/id/35836844 blogs.discovermagazine.com/notrocketscience/2010/04/27/... news.sciencemag.org/sciencenow/2012/02/shame-on-the-rich.html
Joe

Penelitian kedua terutama membuktikan kebenaran poin saya.
Joe

1
@ Jo: link Anda tidak (mulai) membuktikan klaim Anda bahwa "manajer semuanya pembohong".
Jaap
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.