Bagaimana Jika Kode Legacy Sebenarnya Menarik – M.Scott Ford tidak menikmati pekerjaannya sebagai pengembang perangkat lunak tetapi bukan karena alasan biasa. Dia suka bekerja dengan komputer, dan pernah menjadi pengembang di sejumlah perusahaan setelah lulus dari Virginia Tech dengan gelar di bidang ilmu komputer.

Bagaimana Jika Kode Legacy Sebenarnya Menarik

binaryjs – Tetapi di setiap pekerjaan, ketika dia merasa telah membuat segalanya lebih baik dengan membersihkan basis kode, dia akan diberitahu untuk berhenti membuang-buang waktu dan kembali bekerja. Jadi dia akan pindah ke pekerjaan berikutnya, berharap lingkungan yang lebih kondusif untuk jenis pekerjaan refactoring yang dia nikmati, hanya untuk digagalkan lagi.

“Peningkatan itu tidak dipandang sebagai sesuatu yang berharga,” kata Ford dalam episode perdana podcast yang ia selenggarakan, yang disebutnya, Legacy Code Rocks!

Baca Juga : Pelajari Cara Membuat Coding, Panduan Untuk Belajar Otodidak

Seperti yang dipelajari Ford melalui pengalaman, perusahaan tidak tertarik untuk membuat kode terlihat cantik. Praktik terbaik untuk pengembangan perangkat lunak mendikte kode yang bersih dan mudah dibaca, tetapi dalam bisnis, menghasilkan pendapatan adalah yang terpenting.

Bagi para pemimpin bisnis, itu biasanya berarti lebih banyak kode, belum tentu kode yang baik. Tetapi perusahaan mungkin membayar harganya nanti jika perangkat lunaknya perlu diubah, pemrogram asli sudah lama pergi, dan kodenya tidak dapat diuraikan.

Suatu hari, ketika Ford sedang menonton episode acara perbaikan rumah Rumah Tua Ini , dia mendapat pencerahan.

“Saya seperti, ‘Itulah yang ingin saya lakukan!’” katanya dalam sebuah wawancara dengan Built In. “Mitra bisnis saya mengira saya ingin berhenti dari pekerjaan saya dan merombak rumah. Tidak — saya ingin melakukan apa yang mereka lakukan untuk rumah, tetapi saya ingin melakukannya untuk sistem perangkat lunak.” Ford menyadari bahwa dia ingin bekerja secara eksklusif dengan kode warisan.

Siapa yang ingin bekerja di Kode Legacy

Keputusan Ford tidak biasa, untuk sedikitnya kode warisan tidak memiliki reputasi terbaik. Menurut definisi, ini mengacu pada perangkat lunak yang dibuat bertahun-tahun yang lalu, seringkali dalam bahasa yang lebih tua yang hanya sedikit dikenal oleh pengembang.

Ketika perusahaan mendapati diri mereka tiba-tiba perlu melakukan perubahan setelah beberapa tahun, tugas itu ada di meja beberapa pengembang miskin yang belum pernah melihatnya sebelumnya, tanpa ada orang di sekitar untuk membimbing mereka atau membantu mereka memahami cara kerjanya.

Beberapa pengembang mendengar “kode lama” dan mulai mencari pekerjaan baru.

Ford melihatnya secara berbeda. Dia menikmati bagian dari pengembangan perangkat lunak yang, baginya, terasa seperti pekerjaan detektif — menguraikan kode spageti, penggalian perpustakaan yang terkubur, dan penyelaman mendalam ke panggilan metode bersarang.

Andrea Goulet, mitra bisnis Ford dan co-host podcast, menceritakan tentang Legacy Code Rocks! waktu ketika mereka mengerjakan proyek warisan pelanggan yang tidak memiliki dokumentasi, sejauh yang dapat diketahui siapa pun, dan ditulis dalam bahasa pemrograman internal. Mimpi buruk pemrograman dasar Anda.

“Saya belum pernah melihat Anda begitu bahagia,” kata Goulet kepada Ford. “Kamu seperti anak kecil saat Natal, menyelami file biner.”

Mengurai sejarah dibalik kode warisan

Sementara menonton acara TV realitas tentang renovasi rumah mungkin merupakan cara yang aneh bagi pengembang perangkat lunak untuk menemukan panggilan hidup mereka, Ford melihat kepuasan yang dia rasakan bekerja pada kode warisan yang dicerminkan dalam proyek-proyek yang ditangani oleh pemeran Rumah Tua Ini setiap musim.

“Saya mengamati cara mereka bekerja di rumah-rumah tua, dan jumlah perhatian, kerajinan, dan cinta yang mereka berikan ke dalam infrastruktur yang sedang mereka kerjakan,” katanya. “Cara mereka berbicara tentang orang-orang yang bekerja di rumah sebelumnya – bagaimana, bahkan jika sesuatu tidak dilakukan untuk menyajikan standar, cara itu dilakukan adalah cara yang benar untuk melakukannya.”

Ketika orang lain melihat kekacauan kode yang mengintimidasi, Ford melihat tantangan yang menarik, dan peluang untuk melakukan peningkatan yang akan menguntungkan banyak orang, termasuk pelanggan, pengguna, dan bahkan pengembang.

“Untuk sistem warisan yang baru saja mengumpulkan satu ton utang teknis, atau mereka hanya menanggung beban untuk dikerjakan, ada banyak orang yang hidupnya dipengaruhi oleh keadaan sistem itu,” katanya. “Ini seperti kamu membuat hidup seseorang lebih baik.”

“Ini memiliki nilai, melakukan sesuatu yang berarti, memecahkan masalah yang sebenarnya.”

Ford juga merasa puas karena mengetahui bahwa setiap proyek warisan yang dia kerjakan benar-benar berharga bagi penggunanya — lagi pula, jika tidak, maka tidak ada yang mau repot-repot mengerjakannya.

“Umumnya, jika Anda mengerjakan sesuatu yang sudah ada selama beberapa tahun, dan perusahaan yang membangunnya ingin berinvestasi untuk membuatnya lebih baik, maka itu memberikan nilai bagi seseorang,” katanya. “Ini memiliki nilai, melakukan sesuatu yang berarti, memecahkan masalah yang sebenarnya.”

Antusiasme Ford terhadap infrastruktur yang menua mirip dengan apa yang mungkin dirasakan seseorang yang menemukan lantai kayu keras tersembunyi di bawah karpet di rumah abad ke-19. Baginya, “warisan” mengambil makna aslinya dari mewarisi sesuatu yang berharga.

“Apa pun yang ditinggalkan seseorang adalah warisan mereka,” kata Ford di podcast. “Ini mengambil sesuatu yang orang lain telah tinggalkan dan mungkin menyerah, dan menghembuskan kehidupan tambahan ke dalamnya, dan benar-benar menarik keluar keindahan batin dan potensinya.”

TENTU SAJA, TERKADANG ‘KODE LAMA’ HANYA BERARTI KODE BURUK
Ford dan Goulet mulai bekerja secara eksklusif pada proyek warisan beberapa tahun setelah memulai perusahaan konsultan perangkat lunak mereka, Corgibytes , pada tahun 2009. (Tagline: “Kode lama, trik baru.”)

Meskipun istilah “kode lama” membangkitkan perangkat lunak berusia puluhan tahun, perusahaan melihat banyak permintaan dari proyek yang dibangun dengan bahasa pemrograman modern juga.

“Ada dua kubu besar,” kata Ford. “Salah satunya adalah mereka memikirkan COBOL dan Fortran, dan mereka memikirkan mainframe — seperti barang kuno yang sangat tua. Dan ada orang lain yang memikirkan hal-hal yang mereka tulis dua minggu lalu, itu tidak mungkin untuk dikerjakan.”

Ford mengatakan 98 persen proyek yang dikerjakan Corgibytes dibangun dengan bahasa pemrograman yang relatif modern seperti Python, JavaScript, atau Ruby.

Proyek node yang ditulis dalam JavaScript, misalnya, mungkin tampak terlalu baru untuk memiliki kode lama, katanya. “Tapi saya pikir ini lebih tentang gejala bagaimana rasanya bekerja dengan sistem, dan bagaimana rasanya menjadi pihak yang menerima konsumsinya.”

Dalam banyak proyek yang dilakukan Ford, pengguna akhir mungkin frustrasi dengan bug, jumlah waktu yang dihabiskan untuk menunggu perbaikan perangkat lunak, dan versi yang baru dirilis yang tidak berfungsi dengan benar. Pada saat yang sama, pengembang frustrasi bekerja dengan kode dan dengan area basis kode yang takut mereka sentuh.

“Jika segala sesuatunya tidak diciptakan dengan cara yang ideal, saya pikir itu tergantung pada kendala yang dihadapi orang-orang.”

“Fitur yang digunakan untuk dibuat dan dikirimkan dengan cepat, dan sekarang sepertinya setiap fitur yang berurutan membutuhkan waktu lebih lama dan lebih lama — itu masalah yang sering kami dengar,” kata Ford.

“Lainnya adalah retensi sulit, moral pada proyek rendah, orang tidak menikmati pekerjaan mereka lagi. Mereka tidak bisa mengikuti bug, atau setiap kali mereka melepaskan lebih banyak bug daripada yang mereka lakukan terakhir kali. .”

Jenis kondisi ini dapat menyebabkan kondisi kerja yang tegang, yang menurut Ford dapat memperburuk situasi.

“Kami memperjelas bahwa tugas kami bukanlah untuk masuk dan menunjuk, dan mengatakan bahwa orang-orang yang bekerja pada sistem tidak tahu apa yang mereka lakukan atau mereka orang jahat,” kata Ford.

“Jika segala sesuatunya tidak diciptakan dengan cara yang ideal, saya pikir itu bermuara pada kendala yang dihadapi orang. Salah satu kendalanya adalah pengetahuan — Anda adalah pengembang junior yang hanya memiliki pengalaman beberapa tahun, dan masih banyak yang belum Anda ketahui.

Atau Anda seorang eksekutif yang benar-benar membutuhkan kemampuan dari sebuah sistem, dan Anda tidak mengerti mengapa butuh waktu lama untuk membuatnya. Kendala dan motivasi ini dapat menciptakan lingkungan yang kurang ideal kode akan dibuat. Dan itu bisa dimengerti.”

Frustrasi dengan proyek yang ada dapat menyebabkan pengembang membuat keputusan pengkodean yang picik, tetapi perbaikan nyata memerlukan pemahaman tentang basis kode, yang dapat memakan waktu dan usaha.

“Anda tidak akan melibas rumah Anda hanya untuk memberi diri Anda dapur baru,” kata Ford. “Tapi saya merasa ada banyak tim teknik yang akan melakukan itu, karena mereka frustrasi dengan sistem pembangunan mereka.”

Kiat renovasi kode diy

Seperti acara perbaikan rumah lainnya, Corgibytes memulai setiap proyek baru dengan pemeriksaan menyeluruh.

“Kami melakukan penyelaman yang sangat dalam ke basis kode, di mana kami melihat metrik analisis statis berbeda yang dapat kami ukur,” kata Ford. “Dan itu seperti dokumen setebal 30 halaman, kami membutuhkan empat hingga enam minggu untuk menyusunnya.”

Tim menggunakan metrik analisis kode statis termasuk kompleksitas kode, duplikasi, cakupan, dan churn — untuk menentukan bagian mana dari basis kode yang perlu diperhatikan dan untuk memprioritaskan upayanya. Metrik dianggap secara holistik, sehingga kode yang memiliki kompleksitas tinggi mungkin masih mendapat prioritas rendah jika tidak sering diubah.

Inspeksi juga mencakup proses dan dinamika tim.

“Kami juga melihat praktik tim yang berbeda apakah ada ulasan kode? Apakah penerapan dapat diulang? Bagaimana kontrol kode sumber digunakan?” kata Ford. “Praktek teknik Anda yang berbeda, praktik DevOps yang berbeda, gaya komunikasi Anda. Lihat orang-orang bagian dari tim dan juga produk yang sedang dibuat, dan bagaimana mereka bersatu untuk menceritakan sebuah kisah.”

Salah satu strategi yang direkomendasikan Ford kepada perusahaan adalah menghapus kode dari basis kode yang tidak lagi digunakan, yang disebutnya sebagai “kode mati”. Sama seperti kayu yang membusuk dapat merusak struktur di sekitarnya, kode mati dapat berdampak negatif pada infrastruktur perangkat lunak dan menggunakan sumber daya yang lebih baik digunakan di tempat lain.

“Kami telah melihat beberapa sistem di mana ada bagian besar dari basis kode yang tim teknik pastikan untuk terus bekerja tim teknik tidak menyadari bahwa mereka tidak digunakan lagi,” kata Ford.

“Biayanya benar-benar hanya upaya yang terlibat dalam memastikan bahwa semuanya tetap berfungsi terlepas dari bagaimana Anda mengujinya, apakah Anda melakukannya secara otomatis atau manual. Untuk tim yang melakukannya secara otomatis, saya merasa ini lebih sering terjadi ‘Oh ya, tesnya rusak, jadi kami harus memperbaikinya.’”

“Setiap kali Anda membuat perubahan, perubahan itu akan menimbulkan beberapa kerumitan, kecuali jika Anda melawannya.”

Ford juga merekomendasikan untuk menjaga hal-hal minimal “netral berantakan” setiap kali pengembang masuk ke basis kode untuk membuat perubahan. Meskipun proyek-proyek warisan sering dilihat sebagai sesuatu yang terkutuk secara inheren kekacauan yang entah bagaimana masih berjalan dan mudah-mudahan akan bertahan beberapa tahun lagi — Ford mengatakan perangkat lunak yang digunakan akan selalu menumpuk utang teknis, bahkan jika pengembang tidak secara aktif mengerjakannya.

“Selama itu digunakan, akan ada tekanan untuk berubah,” katanya. “Tekanan itu akan datang dari lingkungan yang berinteraksi dengannya — perpustakaan pihak ketiga, atau antarmuka pengguna, atau sistem operasi yang dijalankannya atau bisa juga dari harapan pengguna: tata letak, seberapa cepat, apakah menyediakan fungsi yang tepat.”

Tekanan ini hanya akan hilang ketika perangkat lunak dihentikan. Sampai saat itu, pertanyaannya adalah bagaimana tim pengembangan akan menangani perubahan yang akhirnya dibutuhkan oleh tekanan ini. Ford merekomendasikan pengembang untuk melakukan pembersihan dan pemeliharaan sebagai ganti setiap perubahan yang mereka lakukan pada sistem lama.

“Setiap kali Anda membuat perubahan, perubahan itu akan menimbulkan beberapa kompleksitas, kecuali jika Anda melawannya,” kata Ford. “Jadi saya pikir saat Anda membuat perubahan adalah saat masuk akal untuk melakukan sedikit pembersihan, dan setidaknya pastikan perubahan Anda netral. Jangan hanya melakukan perbaikan cepat, jangan hanya menempelkan Band-Aid lain pada sistem.”

Baca Juga : Eksploitasi Spectre Windows dan Linux yang Bekerja Ditemukan di VirusTotal

Misalnya, pengembang yang menanggapi permintaan fitur pelanggan mungkin tergoda untuk menambahkan fitur tanpa memahami kode di sekitarnya, tetapi perubahan semacam itu menambah kompleksitas pada basis kode. Sebaliknya, pengembang harus mencari cara untuk meningkatkan sistem dan membuatnya lebih mudah untuk digunakan di lain waktu, kata Ford.

“Jadikan lebih performans, atau permudah penambahan fitur,” ujarnya. “Atau jika tidak ada tes otomatis, tambahkan beberapa tes otomatis. Jika tidak ada di kontrol sumber, letakkan di kontrol sumber. ”