Source asli: http://www.softwarequalityconnection.com/2012/04/how-to-inherit-somebody-elses-code/
Anda dihadapkan dengan tugas untuk meng-upgrade aplikasi yang dibuat orang lain. Bagaimana Anda memulai dengan cepat dan dengan rasa sakit yang minimal? Berikut adalah lima pedoman nya.
oleh John Mueller | April 17, 2012
Setiap pengembang/programmer menghadapi situasi dimana aplikasi membutuhkan suatu update (namun bukan dibuat sendiri dari awal). Banyak yang bilang lebih baik cabut gigi tanpa bius dibanding mengembangkan program orang lain dengan struktur kode yang tidak pasti.
Ini bukan berarti bahwa pengembang lainnya sengaja menciptakan aplikasi yang sulit di oprek. Namun ini menyangkut masalah cara berpikir pengembang lain tersebut dalam membuat aplikasi sehingga Anda akan kesulitan ketika mencari lokasi kode-kode yang diinginkan. Artikel ini memberikan beberapa tips untuk meringankan rasa sakit dan Anda bisa mulai lebih cepat.
Hindari Merasa Harus Tau Semua
Sangat penting untuk tidak menjadi terbebani oleh ruang lingkup suatu proyek tertentu. Buat gambaran dari aplikasi dalam pikiran Anda sebelum Anda menelusuri untuk menemukan detail kode. Jangan langsung berusaha menemukan tempat dalam code aplikasi dan mencoba untuk menemukan setiap detailnya-atau Anda akan terjebak dalam detailnya. Cameron Laird, seorang kontributor dari SQC, melihat seperti ini: "Saya menyerah untuk memahami semuanya. Dalam banyak kasus, Saya me-maintenance aplikasi tanpa memahami apalikasi tersebut. Kadang-kadang hal tersebut berhasil. "
Dalam beberapa kasus, Anda mungkin tidak tahu bahasa pemrogramman yang digunakan (atau setidaknya tidak terlalu mahir). Jim Mischel menjelaskan:
"Tugas pemrogramman pertama saya adalah pada sebuah perusahaan yang memberikan dukungan perangkat lunak untuk bank kecil (vendor software). Basis kodenya terdiri dari beberapa ratus ribu baris COBOL, yang sebagian besar ditulis oleh kontraktor dari sebuah ad hoc design document . Pada saat saya mulai bekerja, tidak ada satupun pekerja disana yang telah terlibat dalam pengembangan awal. Lebih buruk lagi, saya tidak tahu COBOL."Saya menyadari dengan cepat bahwa akan dibutuhkan waktu dan riset yang lama untuk memahami kode orang lain. Di satu sisi, beruntung bahwa saya tidak tahu COBOL, karena bila tidak akan memunculkan rekasi bodoh yaitu: "Saya bisa menulis ulang ini lebih cepat dari saya bisa memperbaikinya." Reaksi itu hampir selalu merupakan ide yang buruk. Saya tahu bahwa saya tidak bisa menulis ulang program COBOL ribuan baris yang telah ditugaskan untuk memperbaiki. Aku hampir tidak bisa memahami apa maksud dari kode-kode itu"
Ambil sedikit waktu untuk membaca kode yang akan Anda warisi dan menilai kualitasnya. Dalam beberapa kasus, Anda dengan senang hati akan menemukan bahwa pekerjaan itu hampir tidak sesulit yang Anda pikir. Bill Schindler, software arsitek di Holmes Corporation di Eagan, MN, menggambarkannya sebagai berikut, "Hanya ada tiga jenis kode yang akan Anda warisi. Yang terbaik adalah ketika programmer lain berpikir dengan cara yang sama Anda lakukan dan tahu dengan jumlah yang sama. Jika tidak, Anda mewarisi kode dari seseorang junior (dalam kemampuan, bukan hanya masa kerja), atau dari seseorang yang senior untuk Anda. "
Organisirkan
Baca dokumentasinya dan coba untuk mencocokkannya dengan modul aplikasi-nya. Terlalu terburu-buru adalah buang-buang waktu. Habiskan waktu di depan untuk menemukan fungsionalitas aplikasi tersebut, karena Anda tidak pernah akan mengerti sampai Anda melakukannya.
Rod Stephens, dari VB Helper , melakukan dengan cara ini. "Ada tiga alasan utama yang mungkin membuat Anda harus mengambil alih kode orang lain: untuk memperbaiki bug, untuk mengembangkan, atau untuk me-maintenance di masa depan. Pada ketiga alsan tersebut, tujuan Anda adalah untuk memahami kode secepat mungkin sebelum Anda dapat membuat perubahan." Laird menerangkan lebih jauh, "Habiskan waktu di depan. Saya ingin berlatih membuat aplikasi. Di tempat pertama, saya perlu meyakinkan bahwa semua telah benar-benar ada, dan mulai dari awal membantu saya dengan itu. Juga, melihat arsitektur dari pabrik membantu saya masuk ke dalam mentalitas para pekerja di dalamnya. "
Lihatlah aplikasi dari perspektif pengguna akhir . Jika memungkinkan, duduk dengan user dan melihat pekerjaan rutin harian yang dilakukan user. Luangkan waktu untuk bermain dengan aplikasi dan membangun pemahaman tentang bagaimana sebenarnya aplikasi itu berjalan untuk menghindari prasangka-prasangka yang mungkin Anda pikir.
Buat daftar lengkap komponen untuk aplikasi, termasuk perangkat keras tempat aplikasi akan bergantung, dengan menggunakan perangkat Application Performance Monitoring (APM). Anda mungkin akan terkejut untuk menemukan bahwa tidak ada yang benar-benar tahu komponen apa saja yang dibutuhkan aplikasi untuk melakukan tugasnya. Tentu saja, Anda tidak harus menggunakan seperti yang disebutkan diatas untuk melakukannya. Laird menambahkan, "Saya juga ingin semua tersusun rapi dalam Sistem Kontrol Source Code."
Luangkan Waktu Secukupnya pada hal Detail
Cari area yang membutuhkan perubahan dan baca komentar/keterangan programmer yang ada dibelakang code tersebut. Dengan pemahaman Anda diperoleh dari dokumentasi aplikasi dan gambaran telah Anda bangun dalam pikiran, Anda mungkin menemukan bahwa komentar akan sangat membantu.
Namun, jangan terlalu berharap. Mischel berpendapat seperti ini:
"Komentar akan sering bohong seperti seringnya benar. Tapi jangan mengabaikannya sama sekali. Bahkan sekalipun jika komentar tidak cocok dengan kode yang dikomentari. Mereka tetap memberikan informasi yang berharga. Jika komentar dan kode tidak cocok, maka salah satu berikut ini adalah benar:1) Anda tidak memahami sesuatu.2) Komentar sebenarnya benar, tetapi ada perubahan kode.3) Komentar ini menceritakan bagaimana harapan kode tersebut harusnya berjalan.Setiap komentar tunggal dengan sendirinya tidak terlalu berguna, tetapi ketika Anda memperhatikan/merangkup semua komentar dalam modul tertentu atau seluruh sistem, Anda akan mulai memahami cara berpikir programmer sebelumnya, dan hal tersebut akan dapat membantu Anda untuk lebih memahami kode nya . "
Gunakan debugger untuk melacak melalui kode aplikasi yang Anda tidak mengerti. Jalan step-by-step melalui code. Namun ingat bahwa Anda tidak sedang mencari kesalahan, Anda hanya ingin melacak melalui kode untuk melihat bagaimana hal itu berfungsi. Perbedaan perspektif adalah penting.
Stephens mengatakan, "Gunakan debugger untuk mempelajari apa yang kode lakukan dan untuk mengisolasi bug. Set suatu breakpoint dalam kode yang mengandung masalah dan jalan pelan-pelan untuk mencari tau apa yang salah. Jangan mulai memodifikasi kode sampai Anda benar-benar mengerti apa yang tujuannya dan apa yang sebenarnya dilakukan. Sungguh menakjubkan betapa banyak orang hanya mengatakan, 'Aku bertaruh aku tahu apa yang terjadi', dan mulai memodifikasi kode tanpa memverifikasi bahwa teori mereka benar. "
Jangan Menemukan kembali Roda
Ada godaan untuk membuang apapun yang tidak anda mengerti dan menulis ulang dari awal. Pendekatan ini biasanya terbukti sia-sia dan akhirnya Anda melewatkan tenggat waktu jika Anda mencobanya. Seperti yang Mischel jelaskan, "Butuh waktu jauh lebih sedikit untuk mempelajari, memahami, dan memperbaiki kode daripada menulis ulang semua dari awal. Perbedaan waktu akan makin jauh ketika berhadapan dengan sistem lebih besar dan lebih kompleks. Dalam lima tahun saya bergulat pada kode program perbankan. Saya tidak ingat situasi di mana saya menemukan bahwa menulis ulang bagian dari kode lebih cepat dibandingkan dengan memahami kode yang sudah ada dan kemudian memperbaikinya."
Selain itu, Mischel mengatakan, bahkan kode yang ditulis dengan buruk pun. "Membuang kode itu dan menulis ulang karena itu 'mudah' adalah keputusan yang sangat buruk," Lanjutnya, "Dengan gagalnya untuk memahami kode, berarti Anda telah kehilangan keuntungan dari proses pengumpulan informasi sebelumnya. Sebagai hasilnya, 'implementasi baru Anda yang lebih baik' dipastikan hampir akan gagal dan akan memerlukan debugging jauh lebih banyak dari yang Anda pikir. "
Lakukan Update Ketika Diperlukan
Jika sebelumnya dikatakan praktik "Menemukan kembali Roda" adalah hal yang buruk, kadang-kadang aplikasi harus dikorbankan ketika dihadapkan pada suatu masalah. Russ Mullen, Jasa Mullen Bisnis, jika ditemukan proyek semacam itu dan perlu membuat beberapa perubahan signifikan.
"Saya mengerjakan pada sebuah aplikasi dengan front end berbasis web dan back end SQL. Setelah saya sudah membuat beberapa perubahan sehingga aplikasi tersebut bekerja dengan benar, manajemen memutuskan untuk mengubahnya ke aplikasi desktop karena peralatan yang tesedia tidak bisa menangani volume pekerjaan yang akan diperlukan.Setelah mendesain ulang saya berhadapan dengan masalah yang mengharuskan saya untuk mengkonversi hub lama mereka menjadi switch yang lebih cepat, selain itu di-update pula RAM dari workstation, dan sebagainya. Konversi aplikasi terjadi dalam tiga tahap, dengan upgrade OS baru pada tahap pertama, bersama dengan membuat beberapa koneksi baru antara kantor pusat dan perusahaan satelitnya. Tahap kedua adalah menciptakan entri data baru yang lebih lengkap. Akhirnya, fase ketiga adalah berhubungan dengan form-form laporan"
Membuat sebuah Proses Berharga untuk Anda
Penting diingat bahwa anda mendapatkan pengalaman pribadi dari pekerjaan yang Anda lakukan. Hal ini merupakan investasi buat Anda. Schindler melihat kode-kode yang sulit adalah suatu pengalaman belajar yang potensial. "Orang-orang cenderung merespon secara berbeda terhadap kode yang ditulis oleh seseorang yang lebih sempurna daripada mereka buat. Ini bisa membuat frustasi juga, karena Anda melihat apa yang mereka lakukan dan Anda benar-benar bingung. Melihat kode yang ditulis oleh orang cerdas adalah sebuah tantangan, Anda bisa belajar sesuatu darinya ".
Anda tidak selalu cukup beruntung untuk dapat bekerja dengan kode dari seseorang lebih sempurna daripada Anda. Stephens menambahkan, "Jika Anda tidak mendapatkan pelajaran dari bekerja dengan kode orang lain, maka Anda akan mendapatkan pelajaran buruknya. Saya pernah melihat proyek tanpa dokumentasi dengan kurang dari 500 komentar dari 60.000 baris kode yang ada. Bahkan untuk mengubah sesuatu yang kecil pun harus dilakukan selama ber-minggu-minggu karena hampir mustahil untuk mencari tahu apa program itu lakukan" Dari situ Anda akan mendapatkan pelajaran bahwa Anda harus meng-imporove code yang ada buat agar mudah di-maintenance di masa mendatang.
Penutup
Mewarisi kode orang lain bisa sulit, membuat frustasi, dan membingungkan. Namun, jika Anda mengerjakannya dengan benar, maka tugas update aplikasi tidak akan sulit. Bahkan, Anda mungkin menemukan bahwa pengalaman belajar untuk kesempatan di masa depan.
Tentu saja, bekerja dengan kode orang lain juga merupakan proses pembelajaran. Anda menemukan bahwa Anda akan memiliki tanggung jawab untuk orang lain yang mungkin meneruskan pekerjaan Anda. Seperti yang Stephens katakan, "Kasihanilah mereka yang mengikuti Anda. Catatlah, tulislah dokumentasi, dan berikan banyak komentar/keterangan. Saya sudah benar-benar menemui sebuah proyek gagal karena kurangnya komentar. Ini tidak hanya akan membantu siapa saja yang kemudian perlu memodifikasi kode Anda, tetapi akan membantu Anda jika Anda perlu melihat kode lagi beberapa bulan atau tahun dari sekarang dan Anda tidak ingat cara kerjanya. "
Tidak ada komentar:
Posting Komentar