Memfaktorkan semula perisian warisan: daripada cabaran kepada peluang

Artikel ini menceritakan cara kami mengendalikan pengantarabangsaan sistem pengurusan logistik (OMS) dan cabaran penyepaduan dengan platform e-dagang baharu. Sistem ini dibangunkan pada 2018 untuk mengoptimumkan proses penyediaan pesanan syarikat e-dagang yang berkembang pesat dan berintegrasi secara cekap dengan pengendali logistik yang berbeza. Dibina menggunakan PHP (Symfony), MySQL, Socket.io dan jQuery, ia merangkumi keseluruhan proses daripada pembungkusan hingga penghantaran, termasuk ciri seperti penjejakan pesanan, sambungan kurier, penjanaan label dan metrik prestasi penyediaan pesanan.

Pengumpulan hutang teknikal

Sistem ini berfungsi dengan baik selama bertahun-tahun, tetapi apabila perniagaan berkembang, batasannya semakin ketara. Hutang teknikal amat membimbangkan, menjejaskan pelbagai peringkat projek. Dari segi infrastruktur teknikal, aplikasi berjalan pada rangka kerja lapuk dan versi bahasa asas:

• Versi Symfony (4.0) bukan versi sokongan jangka panjang (LTS) dan akan berhenti menerima kemas kini keselamatan sejak Januari 2019.
• PHP 7.1 juga telah menamatkan kitaran hayatnya dan sistem tidak mempunyai kemas kini keselamatan yang kritikal.

Selain versi lapuk, projek ini juga mempunyai kelemahan serius dalam asas pembangunan perisian:

• Kurang atau Tidak Mencukupi Ujian: Kekurangan ujian automatik (unit, penyepaduan dan ujian hujung ke hujung) bukan sahaja menghalang pengesanan awal pepijat, tetapi juga membuat sebarang pengubahsuaian yang berpotensi menjejaskan kestabilan daripada sistem.
• Kekurangan piawaian pengekodan: Pangkalan kod tidak mengikut sebarang corak atau piawaian yang didokumenkan, dan walaupun ada, ia tidak konsisten dengan amalan terbaik industri. Ini menyukarkan penyelenggaraan dan penyelarasan pembangun baharu ke projek.
• Dokumentasi yang tidak mencukupi: Dokumentasi sedia ada jarang dan selalunya tidak lengkap. Ini menjejaskan bukan sahaja pembangunan teknikal tetapi juga pemahaman proses perniagaan yang dilaksanakan dalam kod.
• Kawalan versi tidak lengkap: Sejarah Git tidak mempunyai penjelasan, perincian komitmen adalah kasar, mesej tidak mengikut mana-mana konvensyen dan kekurangan maklumat latar belakang tentang perubahan yang dibuat. Ini menyukarkan untuk memahami evolusi kod dan keputusan yang dibuat dari semasa ke semasa.

Pengumpulan hutang teknikal bukan sahaja menimbulkan ancaman kepada kestabilan dan keselamatan sistem, tetapi juga:

• Mengurangkan kelajuan pembangunan ciri baharu
• Peningkatan risiko memperkenalkan pepijat
• Meningkatkan kesukaran untuk ahli baharu untuk menyertai pasukan
• Peningkatan kos penyelenggaraan
• Menyukarkan diagnosis dan penyelesaian masalah

Batasan struktur

Seni bina asal mempunyai isu gandingan yang menjejaskan fleksibiliti dan skalabilitinya dengan serius:

• Bergantung sepenuhnya pada platform e-dagang utama: Aplikasi tidak boleh berjalan secara bebas, dan semua operasi logistik bergantung secara langsung pada data dan proses platform e-dagang. Ini bermakna bahawa sebarang perubahan pada platform utama boleh merosakkan fungsi sistem.
• Pangkalan data dikongsi menyebabkan isu prestasi: Aplikasi logistik dan platform e-dagang menggunakan pangkalan data yang sama, yang membawa kepada isu prestasi, terutamanya semasa tempoh pemuatan puncak untuk mana-mana aplikasi. Selain itu, konfigurasi ini merumitkan pengurusan kebenaran kerana sebarang akses kepada pangkalan data boleh menjejaskan data penting daripada sistem lain.
• Tidak boleh berjalan sendiri: Apl ini direka bentuk untuk dijalankan hanya dengan platform e-dagang. Ini bukan sahaja mengehadkan kemudahalihannya, ia juga menghalang ujian dalam persekitaran terpencil atau berhijrah ke platform lain. Kebergantungannya tidak dikapsulkan dengan betul, sebarang percubaan pengasingan memerlukan perubahan besar dan mahal pada keseluruhan sistem, dan Prinsip Tanggungjawab Tunggal (SRP) tidak dipatuhi dalam kelas utama.
• Kesukaran dalam melaksanakan ciri baharu: Kekurangan pematuhan terhadap Prinsip Terbuka/Tertutup (OCP) dan Prinsip Penggantian Liskov (LSP) sangat menghalang evolusi sistem. Ciri baharu memerlukan pengubahsuaian pada kod sedia ada, meningkatkan risiko memperkenalkan regresi. Selain itu, kebergantungan langsung antara modul menjadikan mengikut Prinsip Inversi Ketergantungan (DIP) hampir mustahil.

Keterbatasan struktur ini bukan sahaja mengurangkan kebolehselenggaraan dan kebolehskalaan sistem, tetapi juga meningkatkan risiko yang berkaitan dengan sebarang pengubahsuaian atau evolusi, menjadikan aplikasi dalam keadaan rapuh dari segi teknikal dan terdedah secara strategik.

Pengurusan pembangunan dan penjajaran strategik

Salah satu cabaran yang paling ketara bukan sahaja teknikal, tetapi juga strategik. Walaupun pembangunan luaran adalah betul dari segi fungsi, terdapat had organisasi yang ketara:

• Terputus hubungan daripada strategi global: Pembangunan dilakukan secara silo tanpa pemahaman lengkap tentang matlamat dan proses dalaman syarikat. Ini menghasilkan ciri yang, walaupun secara teknikalnya betul, tidak selalu memenuhi keperluan sebenar perniagaan.
• Kekurangan keutamaan strategik: Pelaksanaan ciri baharu tidak mempunyai proses penilaian dan keutamaan yang jelas. Tidak dipersoalkan sama ada ciri itu benar-benar diperlukan, sama ada ia adalah cara terbaik untuk melaksanakannya atau sama ada alternatif yang lebih cekap wujud.
• Pembangunan Reaktif lwn. Pembangunan Proaktif: Pembangunan terutamanya mengikut model reaktif, menangani keperluan segera tanpa mengambil kira kesan jangka panjang atau potensi sinergi dengan proses lain dalam syarikat.
• Kekurangan Proses Pengesahan: Kekurangan semakan berstruktur dan proses pengesahan menyebabkan ciri yang, semasa berfungsi, tidak selalu memberikan penyelesaian terbaik untuk pengguna akhir atau matlamat keseluruhan syarikat.

Keadaan ini tidak dapat dikekalkan dalam jangka masa panjang kerana ia:

• Mengakibatkan produk semakin terpesong daripada keperluan sebenar
• Menghalang integrasi dengan sistem dan proses syarikat lain
• Menyukarkan keputusan strategik tentang produk
• Menghadkan keupayaan pasukan untuk berinovasi dan menambah baik secara berterusan

Kesan kos asas

Aspek yang sering diabaikan tetapi amat penting dalam projek ini ialah kos asas, yang saya percaya merupakan konsep utama dalam pembangunan perisian dan merujuk kepada kos untuk memastikan sistem berjalan walaupun tanpa menambah ciri baharu atau membuat peningkatan kos minimum yang diperlukan.

Dalam kes kami, kos asas termasuk semua kos yang berkaitan dengan mengekalkan rangka kerja dan versi bahasa yang usang, menyelesaikan kecemasan akibat pengumpulan hutang teknikal, mengurus pergantungan dengan sistem lain, menyesuaikan diri dengan seni bina yang digabungkan dan kos pengetahuan domain yang ditanggung kerana pemahaman yang tidak mencukupi . Semua ini menggunakan sejumlah besar sumber yang ada dan secara langsung memberi kesan kepada keupayaan untuk melabur dalam inovasi dan penambahbaikan berterusan.

Walaupun faktor ini bukanlah faktor penentu dalam keputusan kami untuk menginternalisasi pembangunan, ia agak berpengaruh dalam diagnosis awal projek. Kos asas sering diabaikan apabila menilai kemampanan sistem, tetapi dalam kes ini ia jelas menunjukkan bahawa strategi semasa tidak mampan dalam jangka panjang. Tambahan pula, seperti yang akan kita lihat dalam artikel seterusnya, sebarang percubaan untuk mengekalkan struktur sedia ada akan meningkatkan kos asas secara eksponen dari semasa ke semasa.

Untuk penjelasan yang lebih terperinci tentang konsep kos asas dan kepentingannya, adalah disyorkan untuk merujuk artikel asal Eduardo Ferro.

Titik Perubahan: Cabaran Baharu dan Keputusan Strategik

Dalam mana-mana projek pemfaktoran semula, terdapat pelbagai strategi yang boleh digunakan dan dilema sering dihadapi: strangler fig atau big bang rewrite.

Keputusan teknikal awal adalah untuk bekerja dalam projek warisan yang sama menggunakan Strangler Pattern, pendekatan yang melibatkan pembangunan modul atau sistem baharu yang menggantikan bahagian sistem lama secara beransur-ansur. Strategi ini membolehkan kami membuat perubahan selari, mengurangkan risiko dan mengekalkan kefungsian semasa sambil membina asas yang lebih kukuh untuk menyokong kefungsian masa hadapan.

Walau bagaimanapun, dari perspektif perniagaan, pilihan ini menimbulkan risiko yang tidak wajar kepada sistem sedia ada (yang sudah beroperasi dan melaksanakan fungsinya). Kami memutuskan untuk mengelak daripada menyentuh projek sedia ada dan sebaliknya membangunkan aplikasi kendiri untuk memenuhi keperluan baharu.

Peralihan ini menyebabkan kami meninggalkan pangkalan kod sedia ada, keputusan yang boleh dilaksanakan secara teknikal tetapi mempunyai kelemahan tertentu:

• Penduaan pangkalan kod: Dua pangkalan kod berasingan kini perlu dikekalkan.
• Pemisahan Pangkalan Data: Struktur data mesti disalin dan disesuaikan untuk setiap sistem.
• Replikasi infrastruktur: Memerlukan penggunaan pelayan bebas dan memastikan kebolehmerhatian yang sesuai untuk setiap sistem.
• Peningkatan beban kognitif pada pasukan: Semua pertindihan ini memerlukan usaha tambahan untuk mengekalkan konsistensi antara kedua-dua sistem, dengan itu meningkatkan kerumitan pasukan dan risiko kesilapan.

Pendekatan ini membolehkan kami bergerak ke arah penyelesaian bebas, memastikan kestabilan sistem sedia ada sambil membangunkan projek yang sejajar dengan matlamat strategik baharu. Walau bagaimanapun, analisis terperinci tentang kebaikan dan keburukan adalah perlu untuk merancang dan menangani cabaran ini dengan yakin. Di samping itu, kami mencapai kata sepakat dengan peringkat perniagaan untuk tidak mengembangkan fungsi dan mengawal ketat tunggakan projek sehingga pemindahan ke platform e-dagang baharu selesai.

Kesimpulan dan langkah seterusnya

Keputusan untuk menghayati dan menulis semula perisian warisan tidak pernah mudah, terutamanya apabila perisian itu mampu menjalankan tugasnya. Pepatah "Jika berjaya, jangan sentuh" ??akan sentiasa ada. Walau bagaimanapun, kadang-kadang ia mengambil satu langkah ke belakang untuk mengambil dua langkah ke hadapan.

Dalam artikel seterusnya dalam siri ini, kami akan meneroka cara kami bertindak balas terhadap cabaran ini, keputusan teknikal dan strategik yang kami buat, dan cara kami menukar cabaran ini kepada peluang untuk penambahbaikan dan pembangunan pasukan.

Atas ialah kandungan terperinci Daripada warisan perisian kepada peluang strategik: Titik permulaan (I). Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!