Cara menaklukkan kode warisan

Pada titik tertentu dalam karier pengembang Anda, atasan Anda akan memberikan kode warisan - kode yang sudah lama ditulis orang lain. Atasan Anda akan memberi tahu Anda untuk mempelajari kode warisan ini, memperbaikinya, dan menambahkan fitur baru padanya.

Saya telah mengalami situasi ini berkali-kali selama dua dekade terakhir. Saya dapat membantu.

Bagaimana memahami kode warisan

Jika Anda beruntung, Anda akan memiliki dokumentasi, atau setidaknya komentar sebaris. Mungkin satu atau dua penulis asli masih ada untuk membantu. Tetapi sebagian besar waktu, Anda tidak akan seberuntung itu.

Mari kita bicara tentang apa yang akan Anda lakukan dalam kasus sial itu.

Pertama, Anda harus rendah hati. Hormati kodenya, dan pengembang yang menulisnya.

Sangat mudah untuk melihat pekerjaan yang datang sebelum Anda dan memutuskan bahwa itu tidak baik dan Anda dapat melakukannya dengan lebih baik. Ini adalah sikap yang salah. Ini akan membawa Anda ke jalan yang sangat berbahaya.

Jika Anda menempuh jalur berbahaya ini, Anda akan mulai membuat perubahan sebelum benar-benar memahami dampak dari perubahan tersebut. Anda akan "memperbaiki" hal-hal yang tidak rusak, karena ditulis dengan gaya yang tidak Anda sukai, atau didasarkan pada cara lama dalam melakukan sesuatu. Pada akhirnya, Anda akan membuang banyak waktu dengan sikap ini.

Jadi berhentilah. Ambil langkah mundur dan sadari bahwa segala sesuatu dalam basis kode itu dilakukan dengan cara tertentu karena suatu alasan.

Sampai Anda mengetahui kodenya maju dan mundur, Anda harus berasumsi bahwa ada alasan bagus untuk itu ditulis sebagaimana adanya, dan bahwa Anda belum menemukan jawabannya.

Ini adalah sikap yang jauh lebih produktif, dan ini akan menyelamatkan Anda dari merusak segalanya, lalu hanya ingin melompat keluar jendela ketika Anda tidak dapat menyatukannya kembali dengan cukup cepat.

Jangan Humpty Dumpty basis kode Anda.

Cara terbaik yang saya temukan untuk mempelajari basis kode adalah mulai dari tingkat antarmuka pengguna, lalu kembali ke kode.

Pilih aliran pengguna tunggal, seperti masuk, melakukan pemesanan, menulis ulasan, atau apa pun yang relevan dengan aplikasi khusus Anda. Ikuti arus sebagai pengguna akhir. Kemudian lihat kodenya, dimulai dengan kode antarmuka pengguna - yang paling mudah dikenali - dan ikuti setiap langkah di belakang, sampai ke database.

Saat Anda melanjutkan, gambarlah diagram urutan untuk membantu menggambarkan apa yang sedang terjadi. Jika Anda tidak yakin apa itu diagram urutan, atau cara menggambarnya, lihat tutorial gratis ini. Jika Anda tidak memiliki alat yang bagus untuk menggambar UML, ini yang gratis.

Setelah Anda menyelesaikan diagram urutan pertama Anda, menggunakan salinan lokal basis kode yang dapat Anda pulihkan dengan mudah, mulailah membuat perubahan halus pada beberapa komponen yang Anda temui. Lihat apakah Anda dapat memprediksi efek perubahan Anda pada aplikasi. Ini adalah cara yang baik untuk menguji pemahaman Anda.

Terus ulangi proses ini, tambahkan ke diagram Anda sampai Anda memiliki gambaran lengkap tentang keseluruhan aplikasi (atau setidaknya semua bagian yang menjadi tanggung jawab Anda).

Untuk poin bonus, pastikan Anda membagikan catatan dan diagram Anda. Tempatkan mereka di tempat yang sangat terlihat di mana pengembang berikutnya yang datang dapat dengan mudah menemukannya. Jangan khawatir tentang membuatnya sempurna, atau bahkan cantik. Lakukan saja apa yang Anda bisa. Sedikit membantu.

Secara keseluruhan, yang paling penting adalah bersabar, dan hindari menyalahkan diri sendiri. Kode adalah hal yang kompleks. Memahami kode lama membutuhkan waktu. Tetap tenang.

Cara memperbaiki kode lama

Tantangan terbesar yang akan Anda hadapi saat memperbaiki kode lama adalah memutuskan seberapa jauh perbaikan yang Anda lakukan. Saya sangat menyarankan Anda untuk membuat perubahan minimum yang layak terlebih dahulu. Ini berarti Anda harus membuat perubahan yang paling tidak mengganggu yang benar-benar memperbaiki masalah sebelum mencoba untuk membersihkan dan mengubah kode apa pun.

Ini memberi Anda jalan keluar. Skenario kasus yang lebih buruk, jika Anda ditarik untuk menangani beberapa prioritas lain - atau jika Anda berada pada tenggat waktu yang ketat - setidaknya Anda telah mengumpulkan beberapa kode kerja yang dapat Anda gunakan kembali.

Setelah kode Anda berfungsi, jika Anda masih memiliki waktu tersisa, Anda dapat mulai membuat perbaikan kecil dan bertahap.

Martin Fowler telah menyusun katalog refactorings yang akan memberi Anda ide bagus tentang jenis perubahan yang dapat Anda lakukan untuk meningkatkan basis kode secara bertahap. Lihat disini. Idenya adalah untuk selalu membiarkan kode dalam bentuk yang lebih baik daripada saat Anda menemukannya.

Terkadang, Anda akan menemukan bug yang sebenarnya merupakan hasil dari kerusakan struktural. Bug ini tidak dapat diperbaiki dengan perubahan sederhana pada beberapa logika kondisional. Mereka membutuhkan perubahan yang lebih invasif.

Di sinilah hal-hal menjadi berbulu. Anda harus benar-benar jujur ​​pada diri sendiri tentang apa perubahan minimum yang layak. Setiap serat dari keberadaan Anda akan ingin memisahkan kode dan menulis ulang semuanya. Jangan lakukan itu!

Tetap berpegang pada perbaikan cepat, diikuti dengan peningkatan bertahap yang merefaktor dan membersihkannya sebanyak waktu mengizinkan. Tujuan Anda hanyalah membuat kode sedikit lebih baik setiap saat. Semakin lama Anda mempertahankan basis kode, semakin baik hasilnya.

Untuk benar-benar membuat pendekatan ini berhasil, pastikan Anda selalu menyesuaikan perkiraan Anda untuk memberikan waktu untuk sedikit refactoring.

Terkadang, kerusakan struktural sangat buruk sehingga strategi penambalan selamanya tidak akan berhasil. Situasi ini sebenarnya jauh lebih jarang dari yang Anda kira.

Sekali lagi, Anda harus benar-benar jujur ​​pada diri sendiri tentang biaya / manfaat dari penulisan ulang atau desain ulang. Anda perlu menerima bahwa, pada akhirnya, ini akan menjadi keputusan bisnis dan bukan teknis.

Bersiaplah untuk menyatakan kasus Anda dalam istilah bisnis. Berapa biaya untuk melakukan restrukturisasi besar-besaran pada kode? Apa risiko bisnis nyata jika tidak melakukannya? Jika Anda memiliki kasus yang kuat, Anda akhirnya akan didengarkan. Namun, jangan kaget jika perlu beberapa siklus perbaikan terlebih dahulu.

Ingat: jika Anda melakukan perombakan besar-besaran, pertama-tama pastikan ada dukungan untuk perubahan dan anggaran yang masuk akal untuk menyertainya. Jangan mencoba terbang di bawah radar dengan ini. Kecuali, tentu saja, Anda menikmati percakapan canggung dengan manajemen ketika Anda mulai melanggar banyak hal dan melewatkan tenggat waktu.

Cara menambahkan fitur baru ke kode lama

Akhirnya, Anda akhirnya akan dipanggil untuk menambahkan fitur ke kode lama. Pada titik ini, Anda harus membuat keputusan penting. Apakah Anda "mengikuti arus" basis kode saat ini, atau mengambil sesuatu ke arah yang baru?

Sekali lagi, saya menyarankan Anda untuk jujur ​​dalam evaluasi Anda. Apakah terus mengikuti pola dan praktik yang terbukti dalam basis kode yang ada membuatnya lebih buruk, atau menumpuk ke masalah yang sudah ada?

Sering kali, Anda ingin menjaga agar semuanya tetap stabil. Buat saja penambahan bertahap menggunakan pola dan praktik kode yang ada. Gunakan kembali elemen yang ada. Buat perubahan yang paling tidak mengganggu, sambil membuat perbaikan kecil dan bertahap dengan pembersihan dan pemfaktoran ulang.

Jika Anda yakin bahwa arah baru mutlak diperlukan, Anda harus menemukan cara untuk mengisolasi perubahan Anda dan memasangkannya selonggar mungkin ke basis kode yang ada.

Coba buat fitur baru sebagai proyek terpisah. Anda kemudian dapat mengekspos API yang memungkinkan kode lama dicolokkan ke kode baru Anda. Ini membuatnya sehingga kode baru Anda dan kode lama yang lama tidak perlu tahu banyak tentang satu sama lain.

Ini mulai menjadi sedikit rumit saat Anda perlu menggunakan fungsionalitas dari kode lama untuk mengimplementasikan fitur baru. Cara terbaik untuk memisahkan kode lama dari kode baru adalah dengan menggunakan Pola Adaptor.

Pabrik DO memiliki penjelasan yang baik tentang Pola Adaptor:

“Pola Adaptor menerjemahkan satu antarmuka (properti dan metode objek) ke antarmuka lainnya. Adaptor memungkinkan komponen pemrograman untuk bekerja bersama yang sebaliknya tidak akan bisa karena antarmuka yang tidak cocok. Pola Adaptor juga disebut sebagai Pola Pembungkus. Salah satu skenario di mana Adaptor biasanya digunakan adalah ketika komponen baru perlu diintegrasikan dan bekerja sama dengan komponen yang ada dalam aplikasi. Skenario lain adalah pemfaktoran ulang di mana bagian-bagian program ditulis ulang dengan antarmuka yang ditingkatkan, tetapi kode lama masih mengharapkan antarmuka asli. ”

Berikut beberapa tautan ke penjelasan dan contoh dalam berbagai bahasa.

  • Contoh JavaScript dari Pola Adaptor
  • Contoh C # dari Pola Adaptor
  • Contoh Java dari Pola Adaptor

Poin-poin penting

Singkatnya, berikut adalah poin-poin utama yang akan membantu Anda mengatasi dan pada akhirnya menaklukkan basis kode apa pun:

  1. Jangan pernah menilai kode lama atau mengubahnya sampai Anda meluangkan waktu untuk memahaminya sepenuhnya.
  2. Diagram urutan adalah teman Anda.
  3. Lebih suka perbaikan kecil dan bertahap daripada penulisan ulang atau perubahan grosir.
  4. Setiap perubahan harus berusaha membuat kode menjadi sedikit lebih baik daripada saat Anda menemukannya.
  5. Jika Anda perlu membuat perubahan besar, buat kasus bisnis dan dapatkan persetujuan terlebih dahulu.
  6. Saat menambahkan fitur baru, cobalah untuk "mengikuti arus".
  7. Jika Anda perlu membawa kode ke arah yang baru, pisahkan perubahan Anda dan gunakan Pola Adaptor untuk mengintegrasikan.

Semoga artikel ini bermanfaat bagi Anda. Misi saya adalah membantu pengembang sebanyak yang saya bisa. Tolong ❤ rekomendasikan ❤ cerita ini menggunakan hati hijau di bawah ini untuk membantu menyebarkan berita.

Ingin membuat kode yang lebih baik? Bergabunglah dengan ribuan pengembang yang menerima artikel dan informasi berharga seperti ini dari saya setiap minggu secara gratis . Klik di sini.