Saya akan memberi Anda pengalaman kami refactoring LedgerSMB. Kami membuat keputusan untuk melakukan hal-hal yang berbeda sejak awal dan masih melakukan apa yang Anda jelaskan tetapi tanpa banyak metode lem (kami memiliki beberapa metode lem btw, hanya saja tidak banyak).
Hidup dengan Dua Basis Kode
LedgerSMB telah bertahan dengan dua basis kode selama sekitar 5 tahun dan akan ada beberapa lagi sebelum basis kode lama dihilangkan. Basis kode lama adalah horor sejati untuk dilihat. Desain db buruk, Perl membangun seperti IS->some_func(\%$some_object);
bersama dengan kode yang menunjukkan dengan tepat mengapa metafora spaghetti kadang-kadang digunakan (jalur eksekusi berkelok-kelok antara modul dan kembali, dan antara bahasa, tanpa sajak atau alasan). Basis kode baru menghindari ini dengan memindahkan kueri db ke dalam prosedur tersimpan, memiliki kerangka kerja yang lebih bersih untuk penanganan permintaan, dan banyak lagi.
Hal pertama yang kami putuskan untuk lakukan adalah mencoba untuk memperbaiki modul demi modul. Ini berarti memindahkan semua fungsi di area tertentu ke modul baru dan kemudian mengaitkan kode lama ke modul baru. Jika API baru bersih, ini bukan masalah besar. Jika API baru bukan sesuatu menjadi berbulu dan itu undangan untuk bekerja sedikit lebih keras di API baru ....
Yang kedua adalah ada banyak waktu ketika kode baru harus mengakses logika dalam kode lama. Hal ini harus dihindari sejauh mungkin karena mengarah pada metode lem yang jelek tapi tidak selalu bisa dihindari. Dalam hal ini metode lem harus diminimalkan dan dihindari sejauh mungkin tetapi digunakan jika perlu.
Untuk membuat ini berfungsi, Anda harus berkomitmen untuk menulis ulang semua fungsi di area tertentu. Jika Anda dapat, misalnya, menulis ulang semua kode pelacakan informasi pelanggan sekaligus, itu berarti bahwa kode yang memanggil ini dari kode lama tidak sulit untuk dikerjakan, dan pengiriman ke kode lama dari kode baru diminimalkan.
Yang kedua adalah bahwa jika Anda memiliki abstraksi yang masuk akal di tempat Anda, Anda harus dapat memilih level API mana yang harus dihubungi dan bagaimana menjaga kebersihannya. Namun, Anda harus memikirkan untuk menulis ulang bagian-bagian yang memanggil API Anda sehingga mereka juga sedikit lebih bersih.
Ada banyak bidang alat bisnis yang tidak dapat direduksi menjadi rumit. Anda tidak dapat menghilangkan semua kerumitan. Tetapi Anda dapat mengelolanya dengan berfokus pada API bersih yang secara spesifik melakukan apa yang perlu Anda lakukan, dan modul yang memanfaatkan API itu secara konstruktif. Lem harus menjadi pilihan terakhir hanya setelah mempertimbangkan bahwa menulis ulang sisa kode panggilan mungkin lebih cepat.