pengantar
Saya sering diminta untuk berbicara tentang bekerja dengan monolit warisan. Ada banyak pembicaraan tentang arsitektur layanan mikro, tetapi jarang disebutkan bahwa proyek datang setelah bertahun-tahun berkembang dengan aplikasi monolitik. Untuk mengubah arsitektur solusi langsung, Anda perlu melalui beberapa tahap. Penulis telah bekerja dengan berbagai proyek - baik dengan arsitektur REST berorientasi layanan multitenancy penuh, dan dengan monolit besar, di repositori yang sudah ada komit selama sepuluh tahun. Artikel ini membahas tentang sisi gelap, kode lama, dan solusi praktis untuk masalah dengan aplikasi PHP monolitik.
Alasan munculnya warisan
Ada dua alasan utama untuk kode warisan.
Alasan pertama adalah versi baru dari sistem operasi, bahasa, browser, perpustakaan dirilis. Masalahnya sangat relevan untuk aplikasi seluler dan bahasa skrip - dengan setiap rilis versi baru platform, masalah kompatibilitas harus diperbaiki dari kode lama. Proses ini stabil dan dapat diprediksi untuk tahun-tahun mendatang.
Kedua adalah utang teknis yang dibuat dengan sengaja. Manajemen mempersingkat waktu pengembangan perangkat lunak dengan menghilangkan desain, pengujian otomatis, atau tinjauan kode, menyetujui pustaka pihak ketiga yang tidak didukung, dan pengembang tidak mendokumentasikan logika yang rumit. Ini biasa terjadi dan tidak tergantung pada jumlah uang di rekening perusahaan. Jangan memarahi bos yang buruk. Mereka punya alasan bagus untuk melakukannya.
Produk memiliki siklus hidup , dengan periode permintaan tinggi untuk produk populer yang berlangsung selama tiga hingga empat bulan. Pesaing akan menyalin semua yang terbaik dan menjadikannya lebih baik, sehingga perusahaan terpaksa merilis item baru secara teratur. Untuk mempertahankan pendapatan, produk baru dan revisi dirilis setiap beberapa bulan, sehingga siklus penjualan baru mengimbangi penurunan penjualan produk di akhir siklus. Baik Apple dan Marvel membuat tiga atau empat rilis besar setahun, dan Oracle juga memiliki siklus rilis kuartalan di pasar SAAS perusahaan. Namun, tidak ada resep sukses. 97% startup membuang produk mereka dan mencoba sesuatu yang baru sebelum menemukan produk yang mereka beli. Oleh karena itu, biaya pengembangan MVP saat startup diminimalkan semaksimal mungkin.
Anda bermasalah dengan Legacy, jadi Anda beruntung!
, , . . , , , . , , , , . , , , , legacy-. - legacy , , .
?
. , Wordpress , 38% -. -, . Wordpress , , .
, - , .
, ?
. .
. API . , .
, .
, . . . , , .
PHP .
Rector , .
Exakat PHP, , , .
Phan , PHP.
, , .
. PHP 5- 7- , .
. , . , , . , , . git- . , , .
- . , - , golang. - , , , . .
, - , , API, . , .
:
,
API , ,
composer ,
, ,
, API.
- . . . API .
, PHP, API. , . “release, control, validation” “DevOps”. . , .
, , , .
- :
- , ;
API - , ;
- , ;
, ;
; : IoC- .
, .
, , , Packeton, git-. , Private Packagist.
composer- IoC-, : , , diff.
composer Symfony Dependency Injection IoC- . . IoC-, . IoC- .
:
) ,
) , .
, .
1. , , , “ ” .
: . : , diff .
:
- , . , , , , . : , , diff.
2. .
PHP (). , , / API (, diff).
: , , diff .
, , , - .
5. .
: , Single Responsibility Principle, . - , , . .
- -, . , , , , . - IoC-.
: , , diff, .
6. .
: $model = new ($modelName . ’Class’);
switch- . , .
IoC- . , . . , .
:
, , lazy.
API Service Subscriber.
API .
- Service Subscriber. , . : , , c , . Diff.
Service-Oriented Architecture
, , , , . - ? .
API. API restful-. - , , , . http- curl.
- :
. ID , API, . .
, . : . , , .
, . - . , . , . - . , , . , .