Masalah yg ditimbulkan refactoring

Jangan pernah berpikir suatu teknik tidak memunculkan masalah.. Emang kadang klo kita pelajarin suatu teknik yg kren dan menambah produktifitas , pengennya kita terapkan di semua tempat. Contohnya kita baru blajar design pattern … Semuanya mw di pattern kan .. wkwkwkw . bukan jadi bagus .. malah terjadi ledakan kelas .. padahal ga perlu make pattern. Nah refactoring ini juga memiliki keterbatasan juga. Jadi jangan sampai salah menggunakannya.

Database

Salah satu area yg sulit direfactor adalah berhubungan dengan database. Kebanyakan aplikasi banyak yg terikat dengan skema database. Yang lain adalah perpindahan data. Meskipun kita sudah hati2 sekali membagi aplikasi menjadi layer2 untuk meminimalkan ketergantungan terhadap database dari object model tetap aja klo skema database diubah data harus dimigrasikan. Ini yg butuh waktu lama

kalau kita menggunakan relational database kita bisa mengatasinya dengan membuat layer pemisah object model dengan database model. Jadi perubahan pada tiap model bisa diisolasi. Jadi jika kita mengubah satu model misalkan object model yang perlu diupdate hanyalah layer penengahnya. Emang jadi lebih kompleks tapi lebih flexible.

Perubahan Interface

Dengan object kita dapat mengubah implementasi dari suatu software terpisah dengan pengubahan interface. Ingat prinsip programming to Interface not to Implementation. Jadi kita bebas mengubah internal dari object tanpa ada yg perlu takut codenya break. Selama interface nya tetap. Interface ibarat spesifikasi. Masukin A keluarnya B. Jadi ga perduli gimana di dalamnya. Tapi kalau misalnya interfacenya yg berubah ?????????? Duer …….. Bagaimana dengan nasib halayak ramain yg bergantung pada Interface tersebut.

Padahal di refactoring banyak teknik yang mengubah interface. Contohnya mengubah nama method.
Ga bakalan jadi masalah sih kalo memang kita punya akses ke semua code yang mengakses method tersebut. Find and Replace aja atau gunakan fasilitas rename pada IDE. SElesai. Itu bisa klo kita punya source codenya. Tapi klo misalnya tidak ??

Ketika interface tersebut dipublish. Berarti digunakan oleh banyak orang. comunitas atau yg lain. Ga semudah itu mengubah interface. Bakalan banyak yg demo klo interface diubah seenaknya. Begitu kita keluarkan versi baru dari assembly kita. Dan komunitas mengupdate. Dan ternyata interfacenya sudah berubah. Duer… Maka terjadilah amuk massa dimana2. Pertumpahan darah dimana2. Hanya karena rename method. kwkwkwwk

Jadi gimana caranya kita melakukan refactoring tanpa mengubah published interface.

Kita tidak boleh langsung ganti begitu aja. Tapi tetap harus mempertahankan interface yang lama dan tambah dengan yg baru. Sampai user terhadap library kita tersebut tau klo misalnya ada interface yg baru dan yg lama udh usang. Jadi gimana cara mengakalinya ??

Kita buat agar interface yg lama memanggil interface yg baru. Nah meskipun user memakai interface yg lama pada dasarnya dia tetap dapat versi terbaru. Agree ?? Jadi tidak ada yg dirugikan dan tidak ada amukan massa karena code break. Jangan lakukan copy paste. Bikin duplikasi karena kedua method tersebut sama. Dan tandai method yg lama dengan deprecated. Jadi nanti yg make method usang tersebut tau klo method tersebut sudah ketinggalan jaman.

Jadi hati2lah dalam memilih interface yang akan dipublish. Karen begitu method itu memiliki public access maka orang ramai akan berlomba lomba memakainya. Apalagi dengan bantuan intellisense sekarang.

jangan mempublish interface terlalu dini. Jika kita anggap tidak penting jangan dipublish. Jangan pernah berharap kalau lingkungan sekitar kita akan selalu menggunakan code tersebut dengan benar. Jangan terlalu polos.

Perubahan design yg fundamental

Ada saatnya kita bakalan sulit melakukan refactoring. karena berhubungan dengan fundamental design. Sulit untuk merefactor dari satu design ke pilihan design lain.

Kapan kita tidak merefactor ?

Ada saatnya kita tidak melakukan refactor sama sekali. Contohnya.. pada waktu kita harus menulis ulang semuanya dari awal. Ada kalanya code yg udh ada itu lebih mudah di tulis ulang ketimbang diubah ato dimodifikasi. Ini keputusan yg sulit.

Salah satu alasan kita menulis ulang code yg ada adalah code tersebut ga jalan. Testnya gagal. Banyak bugs yg ga bisa diatasi. Kita hanya melakukan refactor pada code yg sudah berjalan.

Nah kalo misalnya lagi kita sudah dikejar2 deadline. Itu seru.. hehehe… Ga bakalan ada lagi yg mikir kalau refactoring itu penting. Sebodo amat yg penting kelar. Customer puas. Pulang cepat. Heheh
Code yg ga selesai direfactor adalah hutang. Emang supaya perusahaan bisa jalan harus berutang juga. Tapi jangan lupa bayar. Utang yg ditumpuk2 akan lebih berat bayarnya ketimbang yg dicicil. Code yang complex akan membutuhkan maintenance yg besar.

that is, the extra cost of maintenance and extension caused by overly complex code. You can bear some interest payments, but if the payments become too great, you will be overwhelmed. It is important to manage your debt, paying parts of it off by means of refactoring.

Ingat dengan refactoring produktifitas akan bertambah. Kalau misalnya kita berpikir .. ah waktu ga cukup lagi, banyak yg harus dikerjakan … sebenarnya itu menunjukkan bahwa kita perlu melakukan refactoring

Dengan melakukan refactoring penambahan fungsionalitas mudah dilakukan

Advertisement