Saya tidak dapat memprogram karena kode yang saya gunakan menggunakan gaya pengkodean lama. Apakah ini normal bagi programmer?

29

Saya memiliki pekerjaan nyata pertama saya sebagai programmer, tetapi saya tidak dapat menyelesaikan masalah karena gaya pengkodean yang digunakan. Kode di sini:

  • Tidak punya komentar
  • Tidak memiliki fungsi (50, 100, 200, 300 atau lebih baris dieksekusi secara berurutan)
  • Menggunakan banyak ifpernyataan dengan banyak jalur
  • Memiliki variabel yang tidak masuk akal (misalnya .: cf_cfop, CF_Natop, lnom, r_procod)
  • Menggunakan bahasa lama (Visual FoxPro 8 dari 2002), tetapi ada rilis baru dari 2007.

Saya merasa seperti telah kembali ke tahun 1970. Apakah normal bagi seorang programmer yang akrab dengan OOP, kode bersih, pola desain, dll. Memiliki masalah dengan pengkodean dengan cara lama seperti ini?

EDIT : Semua jawaban sangat bagus. Untuk harapan saya, tampak bahwa ada banyak basis kode semacam ini di seluruh dunia. Poin yang disebutkan untuk semua jawaban adalah refactor kodenya. Ya, saya sangat suka melakukannya. Dalam proyek pribadi saya, saya selalu melakukan ini, tapi ... Saya tidak bisa memperbaiki kode. Pemrogram hanya diperbolehkan untuk mengubah file dalam tugas yang dirancang untuk mereka.

Setiap perubahan dalam kode lama harus tetap dikomentari dalam kode (bahkan dengan Subversion sebagai kontrol versi), ditambah informasi meta (tanggal, programmer, tugas) terkait dengan perubahan itu (ini menjadi berantakan, ada kode dengan 3 baris yang digunakan dan 50 komentar lama). Saya berpikir itu bukan hanya masalah kode, tetapi manajemen masalah pengembangan perangkat lunak.

coding-style Renato Dinhani
sumber
43
Ya tentu saja itu normal. Anda telah dilatih untuk bekerja dengan cara tertentu, dan sebagian besar pelatihan Anda tidak berguna ketika menghadapi basis kode yang diimplementasikan dengan cara yang sangat berbeda. Yang mengatakan prinsip-prinsip inti tidak banyak berubah, dan setelah kejutan awal Anda akan mulai menyesuaikan ...
yannis
12
Anda tidak kehilangan banyak dengan tidak menggunakan komentar. Jika ada orang yang menggunakannya secara berlebihan.
JohnFx
22
@JohnFx Tidak setuju dengan Anda, tetapi setelah menghadapi lebih dari beberapa omong kosong warisan komentar, saya akan mengatakan saya lebih suka komentar yang berlebihan / usang daripada tidak ada komentar sama sekali.
yannis
25
Ini akan tampak jahat - tetapi saya senang Anda merasakan rasa sakit semacam ini di awal karir Anda, karena akan menjadi motivasi yang hebat untuk tidak menulis kode seperti yang Anda pertahankan.
Bork Blatt
19
Salah satu keterampilan paling penting yang dapat Anda kembangkan sebagai programmer adalah untuk dapat memahami dan memperbaiki kode orang lain. Jika Anda tidak menguasainya, Anda tidak akan pernah menjadi programmer yang baik. Anda beruntung diberi kesempatan untuk mempelajari keterampilan.
Paul Tomblin

Jawaban:

0

Ok, saya akan berterus terang. Itu adalah tempat yang buruk untuk bekerja ... Saya sudah dalam situasi seperti itu, dan biasanya berakhir dengan Anda ditelan oleh kode ini. Setelah satu tahun atau lebih, Anda akan terbiasa dengan hal itu, dan Anda akan kehilangan pegangan tentang bagaimana alternatif modern dapat digunakan untuk mencapai tugas yang sama dengan lebih mudah, dengan cara yang lebih dapat dipertahankan, dan juga, lebih cepat saat dijalankan di Kebanyakan kasus.

Saya meninggalkan tempat kerja seperti itu, karena, setelah hanya satu bulan, saya merasa diseret ke dalam kode skool lama. Saya mencoba mencobanya, tetapi memutuskan untuk tidak melakukannya. Saya tidak bisa menggunakan kode bersih dan mulai kehilangan keterampilan karena tidak ada latihan sehari-hari. Setiap pendekatan modern harus disetujui oleh 3 lapis pengembang, yang tidak pernah terjadi, karena idenya adalah bahwa hal-hal mungkin rusak ketika pendekatan modern digunakan. Dan sifat rapuh dari kode yang keluar ketika Anda tidak menggunakan pendekatan modern cukup menakutkan.

Jangan salah, ada kasus di mana orang over-engineer solusi, dan saya menentangnya. Tetapi terseret ke konvensi dan gaya pengkodean '80 untuk waktu yang lama akan menghentikan kemajuan Anda, dan juga, saya pikir, peluang karier.

Kemudian lagi, Anda harus mendapatkan uang, jadi kadang-kadang Anda harus melakukan apa yang tidak Anda sukai. Mengawasi gejala kelelahan dan mengubah pengkodean menjadi tugas biasa dalam kasus tersebut.

Coder
sumber
1
Bagaimana Anda bisa mengatakan ini tempat yang buruk untuk bekerja? Tidak ada yang salah dengan kode inline lawas. Kode lama memiliki tempat di dunia ini tanpa kode lama kita akan memiliki eksploitasi baru dalam aplikasi yang kita gunakan setiap hari.
Ramhound
1
@Ramhound: Karena saya punya pengalaman langsung di tempat seperti itu. Anda tidak akan diizinkan untuk menggunakan wadah yang efektif, Anda tidak akan dapat menggunakan konstruksi yang aman, Anda tidak akan memiliki input pada arsitektur. Ketakutan akan perubahan menjadi alasan utama. Dan jika Anda tinggal di tempat seperti itu selama lebih dari satu tahun, Anda akan terseret ke dalamnya. Kode modern membuat desain Anda lebih sederhana, lebih cepat dan lebih aman! Saya cukup yakin tempat itu penuh dengan memori mentah twiddling, on the fly konstruksi query SQL, kemungkinan besar bahkan tidak parametrized, dan sebagainya.
Coder
1
@Ramhound Legacy kode ok. Menulis kode lama hari ini tidak baik.
Renato Dinhani
@Coder, ini adalah deskripsi pekerjaan yang sempurna, dan seperti Anda, saya meninggalkan pekerjaan setelah satu bulan dan beberapa hari. Hal terbaik yang saya lakukan, dan sekarang, di waktu senggang, saya belajar banyak hal berguna.
Renato Dinhani
Pembaruan setelah 6 tahun: Saya meninggalkan perusahaan itu beberapa hari setelah memposting pertanyaan ini dan menoleh ke belakang, itu adalah keputusan terbaik yang saya buat. Saya memiliki kesempatan untuk bekerja di banyak proyek lain di perusahaan lain dan tidak satupun dari mereka memiliki praktik buruk yang sama atau kurangnya kualitas yang saya temukan di pekerjaan pertama itu. Tinggal di rumah mempelajari keadaan pasar kerja saat ini memungkinkan saya untuk bekerja di proyek yang lebih menarik dan perusahaan yang lebih baik.
Renato Dinhani
35

Gaya pengkodean ini (jika Anda ingin menyebutnya gaya apa pun ) adalah gaya pengkodean yang buruk .

Seseorang dapat menulis fungsi pendek dengan nama variabel deskriptif dan kontrol aliran waras di sebagian besar bahasa modern (Visual FoxPro modern, ya).

Masalah yang Anda hadapi adalah dengan basis kode yang buruk , tidak lebih, tidak kurang.

Basis kode semacam itu ada dan banyak - fakta bahwa Anda mengalami masalah dengan mereka membuktikan betapa buruknya mereka (dan bahwa Anda memiliki pelatihan yang baik).

Apa yang dapat Anda coba dan lakukan adalah meningkatkan hal-hal di mana Anda dapat - mengganti nama variabel, mengekstrak persamaan dan membagi fungsi besar menjadi yang lebih kecil dll ... Dapatkan salinan Bekerja Secara Efektif dengan Kode Warisan ...

Saya berada di proyek C # dengan struktur yang sangat buruk, tidak jauh dari apa yang Anda gambarkan. Baru saja menggabungkan 12 fungsi terpisah (copy-paste yang jelas) menjadi satu yang mengambil satu parameter.

Oded
sumber
33
Pemrogram yang baik dapat menangani segala jenis cerita horor. Itu tidak akan menyenangkan, tetapi itu sebabnya mereka membayar Anda untuk melakukannya. Bekerja tidak seharusnya menyenangkan dan permainan.
tp1
9
@ tp1 - Yap, tetapi Anda harus mengakui bahwa basis kode pertama yang Anda temui bisa sangat mengejutkan sistem.
Oded
10
@ Renato: semua programmer bekerja pada pemeliharaan kode jauh lebih dari menulis / mendesain kode baru. Dan semua kode yang terus-menerus dimodifikasi semakin buruk seiring waktu kecuali Anda menghabiskan banyak upaya untuk mencegahnya. Pemrogram yang baik juga lebih baik dalam berurusan dengan basis kode yang buruk, apakah mereka suka melakukannya atau tidak, sehingga manajer akan sering memberi mereka tugas-tugas seperti itu, dan sedikit yang berada dalam posisi untuk sepenuhnya menghindari tugas-tugas seperti itu. Saya benar-benar berpendapat bahwa seorang programmer tidak dapat mengklaim dirinya benar-benar baik kecuali dia memiliki pengalaman berurusan dengan kode buruk (yang mungkin menjadi salah satu nya).
Michael Borgwardt
13
@ RenatoDinhaniConceição, saya tidak akan pernah mempertimbangkan untuk mempekerjakan seorang pengembang untuk melakukan desain asli yang belum menyelesaikan waktunya dalam pemeliharaan, Anda TIDAK BISA menjadi perancang yang baik tanpa pengalaman ini (gagal melakukan ini adalah salah satu penyebab utama dari desain yang buruk di pengalaman saya). Anda tidak bisa menjadi programmer yang baik dan buruk dalam pemeliharaan. Anda mungkin tidak menyukainya, tetapi perlu untuk memahami cara mendesain dengan baik. Dan kemampuan untuk melakukan pekerjaan keras perserver juga merupakan karakteristik dari seorang programmer yang baik. Jika mudah mereka tidak membutuhkan kita.
HLGEM
8
@ tp1 Kerja HIS seharusnya menyenangkan dan permainan, kalau tidak Anda salah melakukannya.
Kevin McCormick
18

Itu tidak benar-benar "kuno" kecuali dalam praktik desain yang baik (saat ini) tidak selalu sepopuler. Itu hanya kode yang buruk. Kode yang buruk memperlambat siapa pun. Anda akhirnya terbiasa, tapi itu hanya karena Anda terbiasa dengan kebiasaan khusus dalam sistem spesifik Anda. Diberikan proyek baru, Anda mungkin menemukan cara baru untuk menulis kode yang buruk. Hal yang baik adalah Anda tahu cara mengidentifikasi kode ini sudah bau.

Hal terbesar yang dapat Anda lakukan adalah jangan menyebarkan masalah . Jangan menganggap praktik buruk ini sebagai konvensi kecuali tim Anda. Tetap bersihkan kode baru dengan cara yang tidak memaksa refactor. Jika seburuk itu dan Anda punya waktu, pertimbangkan refactor besar ... tetapi dalam praktiknya Anda jarang memiliki kemewahan itu.

Pertimbangkan untuk menambahkan komentar saat Anda memikirkannya, dan ubah sedikit demi sedikit sebagai hal praktis. Kecuali jika Anda menulis solo, Anda perlu mengatasinya dengan tim Anda; jika tidak ada konvensi Anda harus meluangkan waktu untuk membuatnya, dan mungkin berkomitmen untuk perlahan-lahan meningkatkan basis kode jika Anda tetap mempertahankannya.

Jika Anda menemukan fungsi yang benar-benar terisolasi dengan nama-nama variabel buruk dan Anda tetap memperbaikinya, Anda mungkin juga membuat nama-nama variabel sesuatu yang berguna, refactor ifs. Jangan membuat perubahan pada fitur-fitur umum kecuali Anda akan memperbaiki sebagian besar dari itu.

Ben Brocka
sumber
4
"Praktik desain yang baik tidak selalu sepopuler" Ini belum tentu tentang popularitas. Apa yang dianggap desain yang baik atau praktik terbaik berkembang seiring waktu. Ini sesuatu yang perlu diingat ketika melihat kode lama.
Burhan Ali
@ BurhanAli, abosiolutely, apa yang merupakan praktik yang baik pada tahun 2000 ketika aplikasi kita awalnya dirancang belum tentu praktik yang baik sekarang. Pengembang yang lebih muda sering tidak tahu bahwa apa yang diajarkan kepada mereka sebagai praktik terbaik mungkin belum ada pada saat kode ditulis atau mungkin tidak berfungsi dengan bahasa yang lebih lama yang digunakan perangkat lunak.
HLGEM
2
Saya tidak berpikir fungsi 500-baris pernah dianggap "baik" ... buku utama yang saya pelajari tentang perakitan dari tahun 80-an menyebutkan bahwa Anda mungkin harus memecah hal-hal menjadi subrutin ketika mereka mulai terlalu besar untuk bercabang dari ujung belakang ke awal. Itu datang ke suatu tempat antara 40-120 baris pada prosesor itu (6502).
mjfgates
11
  • tidak punya komentar - perbaiki saat Anda mempelajarinya
  • tidak memiliki fungsi (50, 100, 200, 300 atau lebih baris dieksekusi secara berurutan)

Ini mungkin berasal dari iterasi kode sebelumnya. Pada titik ini, saya akan berhati-hati terhadap perbedaan halus antara blok kode yang mirip yang telah menjadi "fitur". Tetapi terlepas dari seberapa buruk ide jenis struktur ini, cukup sederhana untuk dipahami ... jadi saya tidak yakin di mana Anda akan mengalami kesulitan dengannya.

  • menggunakan banyak pernyataan if dengan banyak jalur - Saya tidak benar-benar yakin apa yang Anda maksud di sini
  • memiliki variabel yang tidak masuk akal (mis .: cf_cfop, CF_Natop, lnom, r_procod) -

Saya akan menekankan hati-hati dengan bit 'penggantian nama variabel'. Ada kesempatan yang adil untuk Anda belum memahami istilah tersebut, dan nama variabel akan lebih masuk akal setelah Anda berada di sana untuk sementara waktu. Bukan untuk mengatakan bahwa tidak mungkin ada nama variabel yang bermasalah juga, tetapi contoh Anda terlihat seperti ada logika untuk mereka, jika Anda tahu apa akronim umum di situs Anda. Ini jelas tidak terlalu penting jika Anda adalah tim dari 1.

  • menggunakan bahasa yang saya tidak kenal (Visual FoxPro 8 dari 2002) - Ini adalah masalah Anda, bukan kode
jkerian
sumber
7
+1: Ini adalah masalah Anda, bukan kode :)
aleroot
Poin terakhirnya secara tata bahasa salah; Saya tidak bisa mengerti arti aslinya. Saya menebak, dan saya mungkin menebak salah, jadi dia mungkin tidak bermaksud bahwa dia tidak terbiasa dengan Visual FoxPro.
Myrddin Emrys
Tentang FoxPro, pertanyaan saya telah diedit. Saya mengatakan itu adalah bahasa lisan dan bagi saya, ini tidak baik, tapi itu pendapat pribadi. Saya memahaminya, tetapi saya tidak suka, dan poin utamanya adalah usia bahasa. Itu tidak diperbarui di perusahaan saya, tetapi ada rilis baru (Visual FoxPro 9 dari 2007).
Renato Dinhani
3
@ RenatoDinhaniConceição, adalah umum untuk tidak memutakhirkan produk basis data karena pemutakhiran merusak hal-hal yang saat ini berfungsi dan tidak ada uang atau waktu untuk dihabiskan untuk melakukan perubahan yang tidak perlu dilakukan jika Anda mempertahankan versi yang lebih lama. Ini pilihan bisnis.
HLGEM
1
@renato, sebagian besar aplikasi database tidak mudah kompatibel.
HLGEM
11

Bagi saya ini kedengarannya seperti Peluang .

Sudah jelas bahwa Anda sudah dapat melihat banyak masalah dalam hal apa yang dilakukan dan dikelola. Anda dapat mengeluh bahwa itu semua sampah dan bahwa Anda tidak dapat melakukan apa pun, ATAU Anda dapat menggunakan ini sebagai kesempatan emas untuk benar-benar menunjukkan kepada majikan Anda nilai Anda.

Sekarang, itu tidak akan membantu Anda jika Anda berbaris ke majikan Anda dan katakan kepadanya bahwa semuanya perlu berubah. Jadi triknya adalah bermain bersama untuk sementara waktu, mengajukan banyak pertanyaan, dan ketika Anda diminta untuk menulis kode, Anda harus bermain sesuai aturan mereka dengan semua komentar, dll, karena Anda harus menyimpan pengembang lain diinformasikan menggunakan sistem apa pun yang mereka sukai saat ini, sementara pada saat yang sama Anda dapat memperkenalkan refactoring yang masuk akal yang tidak akan mengambil risiko apa pun dari Anda. Anda dapat mengekstrak beberapa metode, dan jika bahasa Anda mendukungnya, perkenalkan beberapa tes unit. Ketika ditanya mengapa Anda melakukannya dengan cara ini, atau jika mengatakan Anda melakukan sesuatu yang "salah", hindari bersikap defensif atau argumentatif sambil membuat presentasi yang bagus mengenai posisi Anda untuk gaya penulisan kode yang Anda sukai. Sebagai contoh, Anda dapat merujuk ke buku-buku seperti Bob Clean Code, atau Anda dapat merujuk ke buku-buku lain, artikel, atau bahkan pertanyaan dan jawaban yang Anda temui di Programmers.SE. Apa pun yang Anda temukan bermanfaat untuk mendukung posisi Anda dengan fakta-fakta yang mungkin berada di luar pengalaman Anda di mata orang-orang yang bekerja bersama Anda.

Sehubungan dengan komentar yang berlebihan, beberapa di antaranya dapat dihapus jika Anda menambahkan beberapa nama deskriptif untuk variabel dan metode, tetapi Anda mungkin juga dapat membuat kasus untuk sistem kontrol versi yang baik, dan menggunakannya untuk menyimpan catatan perubahan dan tanggal dll, dan untuk penggunaan alat untuk membandingkan berbagai versi file sumber Anda jika belum ada yang datang dengan VCS pilihan Anda.

Seperti saya katakan, ini adalah kesempatan untuk berkontribusi pada peningkatan tim pengembangan yang sepertinya seperti kehilangan arah untuk berbicara. Anda memiliki kesempatan untuk menonjol sebagai orang yang terampil dan berpengetahuan, dan sebagai seseorang yang dapat memimpin dengan memberi contoh. Ini semua adalah hal-hal baik untuk membantu Anda di kemudian hari saat karier Anda maju.

S.Robins
sumber
2
Pertama, semua jawaban di sini baik dan membantu saya. Jawaban ini tidak dipilih atau dikomentari, tetapi saya sangat menyukainya. Saya pikir titik mengajukan banyak pertanyaan dan tidak bersikap defensif sangat penting. Saya berbicara dengan bos saya tentang beberapa poin yang saya sebutkan di sini, dan seperti yang diharapkan, saya tidak memiliki kekuatan untuk melakukan perubahan besar, tetapi saya merasa bahwa sedikit akan berubah menjadi lebih baik setelah itu. Terima kasih, S. Robbins dan yang lainnya atas kata-kata bijaknya.
Renato Dinhani
1
Ya saya pernah melakukannya sekali, dan berhasil. Ini melelahkan. Saya tidak akan pernah melakukannya lagi. Ini sangat sulit: Anda tidak dapat bersatu SEBELUM refactoring, kode lemah sehingga cenderung meledak di wajah Anda setiap saat, dan Anda akan menghadapi perlawanan yang sangat penting karena kebiasaan kerja orang (di antara masalah lain). Saya tahu pekerjaan hanya untuk orang yang peduli dengan kualitas kode.
deadalnix
1
@deadalnix Pekerjaan pertama jarang menawarkan kesempatan untuk memilih orang yang bekerja dengan Anda. Seringkali Anda tidak akan tahu betapa orang-orang benar-benar peduli dengan kualitas kode sampai Anda pernah bekerja dengan mereka untuk sementara waktu. Jawaban saya membantu OP memahami ini. Pernyataan Anda tentang ketidakmampuan uji unit sebelum refactoring benar-benar salah. Mencoba refactor sebelum unit test meningkatkan risiko secara keseluruhan. Mengejar bug tanpa tes tidak efisien dan melelahkan. Orang-orang yang peduli dengan kualitas kode sangat berfokus pada tes dan teknik pengkodean yang bersih. Saya tidak mendapatkan keberatan tersirat Anda, senang mengobrol tentang offline ini :-)
S.Robins
@ S.Robins Mengejar bug tanpa tes tidak efisien dan melelahkan dan refactoring tanpa unittest sangat berisiko (dan keduanya bergabung dengan baik). Inilah sebabnya mengapa situasi seperti itu adalah mimpi buruk. Basis kode legacy besar-besaran biasanya tidak dapat diputuskan (penuh dengan negara-negara global, ketergantungan hardcod pada sistem produksi, atau pada sistem lain, tidak ada pemisahan kekhawatiran, pengulangan kode besar-besaran, dll ...). Anda harus membuang pass refactoring pertama untuk membuat kode unittestable. Saya pikir kita berdua sepakat pada aspek pengkodean masalah, tetapi salah paham satu sama lain.
deadalnix
1
Ini juga merupakan kesempatan untuk mengumpulkan konten untuk thedailywtf.com
Arkh
8

Selamat Datang di hutan !

Sayangnya, sering mulai bekerja di perusahaan berarti mulai menghadapi situasi seperti ini, kecuali jika Anda bekerja untuk perusahaan yang terstruktur dan terorganisir dengan baik, situasi ini sangat biasa ...

Saran saya adalah:

  1. Mulai belajar dan kenali: bahasa pemrograman yang digunakan (Clipper / dBase) dan lingkungan (Visual FoxPro)

  2. Baca dan Analisis basis kode dan mulai berkomentar

  3. mengatur / refactoring kode (mengatasi masalah terlalu banyak baris yang dieksekusi secara berurutan)

Memiliki masalah menghadapi basis kode yang sama itu normal, tetapi dapat menjadi tantangan besar mencoba untuk meningkatkan kualitas kode dan memberikan "sentuhan Anda" untuk program meningkatkan basis kode dan mungkin membuatnya menjadi program yang lebih baik ...

aleroot
sumber
7

Untuk menjawab pertanyaan Anda: Ya, orang / perusahaan di mana saja menggunakan infrastruktur yang dapat dibangun di atas kode jelek. Ketika mengintegrasikan diri Anda ke dalam situasi seperti itu, bisa sangat sulit untuk dihadapi.

Musim panas lalu, saya bekerja sebagai pekerja magang untuk mengembangkan aplikasi yang akan digunakan oleh tim QA yang melekat pada departemen tertentu. Tim QA menggunakan banyak skrip mandiri (VBScript, Perl, Bash) untuk menjalankan tes pada database dan semacamnya, dan mereka ingin menggabungkan semuanya menjadi satu aplikasi. Masalah dengan ini, bagaimanapun, adalah skrip-skrip tersebut digunakan di tempat lain di perusahaan (sehingga fungsi inti / nama variabel tidak dapat diubah), dan kode itu "ditambahkan ke" selama hampir 10 tahun; banyak omong kosong yang terbangun.

Inilah yang dapat Anda lakukan tentang itu:

  1. Mintalah bantuan: rekan kerja Anda yang harus melihat-lihat kode ini mungkin akrab dengan kekhasannya. Apa yang tumpul dan membingungkan Anda tidak masalah bagi mereka. Jadi mintalah bantuan!
  2. Refactor bila memungkinkan: jika Anda harus melihat / menjaga kode ini untuk jangka waktu yang lama, refactor kapan saja Anda bisa. Bahkan jika Anda menjalankan pencarian dan mengganti nama variabel, setiap bit membantu. Perusahaan yang saya magang selama musim panas lalu memiliki masalah yang sama dalam menggunakan nama variabel jelek. Setiap kesempatan saya dapat menjalankan kode mereka melalui sisir bergigi halus, mengubah nama variabel, mengoptimalkan logika (mengelompokkan berbagai fungsi menjadi 1, misalnya), dll. Lakukan hal yang sama setiap kali Anda memiliki kesempatan!

Seperti halnya di mana-mana, selama fitur eksternal kode berfungsi dengan benar, tidak masalah bagaimana internal bekerja.

Zach Dziura
sumber
+1 untuk "minta bantuan". Bekerja dalam tim menambah biaya tetapi juga membawa manfaat.
7

Saya akan membuat beberapa komentar yang berbeda dari banyak responden di sini. Banyak komentar saya mungkin jelas bagi Anda, tetapi tetap perlu diucapkan.

  • Berhati-hatilah dalam mengubah kode yang tidak Anda mengerti, sampai Anda memahaminya.
  • Jika Anda bekerja di lingkungan tim, dengan kode yang digunakan rekan setim Anda, diskusikan perubahan Anda dengannya sebelum membuat perubahan. Tidak ada yang suka "penembak sendirian" untuk masuk dan mengubah kode yang orang lain kenal. Ini bukan untuk mengatakan bahwa perubahan Anda tidak dijamin atau hal yang "benar" harus dilakukan.
  • Dapatkan adopsi untuk ide-ide Anda. Dapatkan semua orang di papan dengan ide-ide Anda, maka Anda dapat menggunakan keterampilan tim Anda untuk refactor, alih-alih membebani diri Anda dengan seluruh beban kerja.
  • Dapatkan dukungan manajemen. Mereka mungkin dapat mengalokasikan dana untuk Anda pergi dan faktor ulang kode.
  • Berbicaralah dengan manajemen dalam hal mereka memahami tentang manfaat re-factoring basis kode mereka. Kode yang lebih dapat dirawat berarti lebih sedikit waktu yang dihabiskan untuk menyelesaikan bug, menambahkan fitur, dll. Yang berarti pengembangan yang hemat biaya. Waktu putaran yang lebih cepat dll.

Sangat mudah untuk menambahkan kode murni, saran praktik terbaik tanpa memahami politik lingkungan Anda. Orang-orang yang bekerja dengan Anda mungkin tidak ingin mengubah, atau mengalokasikan waktu untuk mengubah basis kode Anda, tetapi cobalah untuk menjual ide itu kepada semua orang sebelum melompat dan mengubah segalanya (yang memiliki risiko yang melekat pada dan dari dirinya sendiri)

Semoga ini membantu.

funkymushroom
sumber
1
Juga: Uji, buat cadangan, gunakan kontrol versi. Jika Anda baru, ada hal-hal yang terjadi di sumber yang Anda tidak akan mengerti, dan apa yang tampak seperti perubahan tidak berbahaya dapat menyebabkan masalah yang tidak Anda perkirakan.
Scott C Wilson
Saya akan menambahkan lebih lanjut. Jangan mengubah apa pun sampai Anda memiliki tes gagal yang menuntut tindakan . Mulai tes menulis. Ketika Anda memiliki tes yang gagal, pastikan itu penting. Maka Anda memiliki mandat yang kuat untuk berubah. Itupun menunggu hingga sistem jenuh dengan tes. Selalu berusaha untuk meninggalkan sistem sebagai baik atau lebih baik (tidak pernah lebih buruk) daripada yang Anda temukan.
emory
5

Salah satu hal yang menonjol adalah komentar Anda yang diedit

Setiap perubahan dalam kode lama harus tetap dikomentari dalam kode, ditambah informasi meta (tanggal, programmer, tugas) terkait dengan perubahan itu (ini menjadi berantakan, ada kode dengan 3 baris yang digunakan dan 50 baris lama yang dikomentari). Saya berpikir itu bukan hanya masalah kode, tetapi manajemen masalah pengembangan perangkat lunak.

Saya juga punya proyek di mana saya mewarisi basis kode FoxPro warisan dengan banyak masalah yang Anda uraikan. Salah satu hal pertama yang saya perkenalkan kepada proyek adalah repositori kode sumber yang baik. FoxPro dapat berintegrasi dengan SourceSafe, tetapi produk itu menyakitkan untuk digunakan.

Saya mengambil salinan alat scx Paul McNett http://paulmcnett.com/scX.php dan mengintegrasikannya ke dalam siklus pengembangan saya. Ia melakukan pekerjaan yang cukup bagus untuk mengekstraksi kode biner FoxPro ke format teks yang kemudian dapat dimasukkan ke dalam repositori sumber, seperti Subversion, Mercurial, atau bahkan git. (Anda mungkin menemukan proyek SubFox di http://vfpx.codeplex.com bermanfaat.

Alat-alat ini menyediakan Sejarah dan memungkinkan programmer untuk melanjutkan pekerjaan mempertahankan kode. Jelas butuh waktu untuk belajar menggunakan alat ini, tetapi karena semuanya gratis, tidak masuk akal untuk tidak menginvestasikan waktu untuk menggunakannya. (Bahkan jika Anda tidak bisa membuat proyek-proyek Pekerjaan bergerak seperti itu).

scott-pascoe
sumber
4

Saya akan sangat setuju dengan jawaban funkymushroom. Jika Anda adalah lingkungan tim, pastikan orang lain tahu bahwa Anda adalah refactor atau reorganisasi kode, jika Anda pernah berencana untuk mendapatkan tugas yang baik di masa depan.

Dari pengalaman pribadi saya tahu, walaupun bukan gaya pengkodean Anda, jika Anda memelihara kode, yang juga dimodifikasi dan dipelihara, tetaplah dalam gaya kode yang ada. Menambahkan komentar dan klarifikasi baik-baik saja, tetapi tata letak dan konvensi dasar harus tetap ada. Guru / senjata tua di proyek mengharapkan kode untuk menjadi serupa dengan apa yang telah mereka lihat selama bertahun-tahun.

Ketika seorang pelanggan berteriak tentang bug, manajemen Anda akan pergi ke senjata lama untuk memperbaiki masalah secepat mungkin. Jika senjata lama ini, ketika berada di bawah tekanan, menemukan Anda "membersihkan kode" dan karenanya mereka sekarang harus menghabiskan waktu mencari tahu di mana Anda pindah atau mengganti nama bahwa satu variabel yang mereka tahu perlu diubah, nama Anda di perusahaan akan diubah menjadi " lumpur".

Setelah krisis berakhir, pertama-tama senjata lama akan menyalahkan Anda secara perlahan dalam pembaruan penting. Selanjutnya Anda akan menemukan bahwa Anda bisa menjaga kode yang telah dibersihkan selama Anda di perusahaan. Akhirnya, ketika proyek-proyek baru yang menarik tersedia, manajer Anda akan bertanya kepada guru tentang siapa yang harus mengerjakan proyek, dan jika Anda pernah mengacaukannya sekali, Anda tidak akan pernah berhasil mencapai proyek baru, sampai makanan ternak Anda dilemparkan pada akhirnya untuk memenuhi tenggat waktu.

Jika Anda belajar di perguruan tinggi cara kode yang "benar", dan sekarang Anda berada di dunia kerja, lupakan cara "benar" itu. Ini bukan tugas perguruan tinggi, proyek-proyek ini tidak berlangsung hanya satu semester, mereka dapat hidup selama bertahun-tahun, dan harus dikelola oleh sekelompok orang dengan tingkat keahlian yang berbeda dan tingkat minat yang berbeda dalam tren CS terbaru. Anda harus menjadi pemain tim.

Anda bisa menjadi program hot shot terbesar di sekolah, tetapi di tempat kerja, pekerjaan pertama Anda, Anda seorang pemula dengan kredibilitas nol jalanan. Orang-orang yang telah pemrograman selama bertahun-tahun tidak peduli dengan sekolah atau nilai Anda, itu adalah seberapa baik Anda bermain dengan orang lain dan berapa banyak gangguan yang Anda bawa dalam hidup mereka.

Dalam 20 tahun saya, saya tampaknya beberapa programmer ace dipecat, terutama karena mereka menuntut untuk melakukan hal-hal dengan cara "benar". Kecuali jika Anda membawa sesuatu yang sangat, sangat, sangat unik untuk pekerjaan itu, Anda dapat diganti. Anda mungkin berada di atas kelas Anda, tetapi tahun depan, orang lain akan berada di atas kelas mereka, dan mencari pekerjaan.

Saya melihatnya sebagai pekerjaan utama Anda, adalah mempertahankan pekerjaan Anda, sampai Anda memutuskan untuk berganti pekerjaan. Untuk mempertahankan pekerjaan Anda berarti Anda harus bermain bagus di taman bermain yang dibangun dan dibayar orang lain.

Saya tahu saya terdengar negatif, tetapi selalu ada harapan. Ketika Anda mendapatkan pengalaman, sukses, Anda akan mendapatkan pengaruh, dan dapat mengubah hal-hal menjadi lebih baik. Saat menulis kode baru atau pada proyek baru, dorong untuk perubahan yang Anda cari. Jika ini adalah kode baru, senjata lama tidak mengharapkannya menjadi cara mereka meninggalkannya, dan ketika mereka melihat keuntungannya, mereka mungkin belajar dan beradaptasi dengan cara baru.

Sistem lama dapat berubah, tetapi butuh waktu. Mengubah sesuatu menimbulkan risiko, dan risiko kebencian bisnis, dan Anda harus meluangkan waktu dan bekerja untuk membuat perusahaan nyaman dengan perubahan itu.

Scott S
sumber