🛀 🔳 🤘🏼 Sialan CRM lama 👾 🧙🏼 👨🏻‍💼

Sepanjang tahun lalu, orang-orang kami menyelesaikan CRM 2.0 dengan BPMS Camunda dan hanya sepuluh proses, bukannya ratusan status, dan kemudian mencoba meluncurkannya kepada pengguna dan layanan tanpa menjatuhkan apa pun. Saya berharap bahwa setelah akhirnya memotong tcm-ku pertama (bagian tertua dari semua Skyeng) dari ekosistem kita, mereka akan berbagi penggaruk dan menemukannya di sini.

Sementara itu, setelah menjadi tertarik pada topik ini, saya menemukan kasus serupa - dan memutuskan untuk bertanya kepada Dmitry Kosov dari Finam tentang pengalaman mereka meninggalkan warisan awal 2010-an.

Hai , saya "Seryozha dari Bryansk" yang sama yang memutuskan untuk memompa pengetahuan pengembangan dengan blog dan screencast pada topik PHP. Tahun ini saya ingin menambahkan podcast ke aktivitas saya: mengundang rekan industri untuk melakukannya. Di episode pertama, kisah perpindahan dari Zend pertama ke Symfony. Jika Anda ingin detail teknis lebih lanjut, periksa juga pembicaraan Dima di Youtube . Nah, dalam diskusi kami setelah laporan Anda akan tahu:

bagaimana tidak kehilangan dan menemukan motivasi, jika Anda mengerti bahwa itu setahun penuh sebelum meluncurkan kode Anda pada produksi,

mengapa ada dokumentasi jika itu tidak bohong, itu bohong,

dan bagaimana proses refactoring dua tahun diatur tanpa menghentikan produksi fitur menggunakan contoh proyek dan tim nyata.

Nikmati membaca atau mendengarkan .

Kerangka apa yang dipilih antara 2011? Dan bagaimana memilih yang baru di tahun 2016

Dima, Finam: Saya secara khusus mencari, bersiap untuk rilis: kami memiliki persis 4.600 file di papa, di mana tepatnya kode kami bukan vendor, bukan js. Ayah ini memiliki berat 16 meter. Dan komitmen pertama yang akan kita buat pada Desember 2011, - penulisnya masih bekerja, ini adalah pemimpin tim kami.

Awalnya, tumpukan dipilih dengan benar. Dan bahkan pada 2012, itu cukup modern - Zend pertama cukup relevan. Saya kemudian bekerja di pekerjaan lain, tetapi saya ingat bahwa pada tanggal 12 di suatu tempat di akhir musim semi, kami memilih tumpukan untuk proyek baru. Kami melihat:

Zend - yang kedua baru saja keluar, tetapi terlalu muda, tidak ada komunitas untuknya,

Yii pertama - tetapi kami tidak menyukai konsep ActiveRecord,

Phalcon,

dan sesuatu yang lain dari yang eksotis.

Dan mereka juga memilih Zend pertama. Pada saat itu, itu adalah pilihan yang baik dan relevan. Tapi lidahnya bergerak maju. Tetapi Anda ingin menggunakan ruang nama normal, bukan penamaan kelas melalui garis bawah. Saya ingin menghubungkan beberapa perpustakaan yang sudah jadi dari open source, yang, tentu saja, tidak ada yang menulis di bawah Zend pertama. Saya ingin menarik karyawan ke tim - beberapa kali ketika kami mencari orang baru, untuk beberapa itu tertulis langsung di wajah: "Saya tidak akan menerimanya".

Pada akhirnya, Zend pertama hanya berhenti mendukungnya. Misalnya, pada 7.0 mereka masih merilis tambalan pembaruan keamanan, dan kami menambal 7.2 dan 7.3 sendiri.

Kami menarik sedikit dengan awal proses relokasi.

Tidak ada risiko global - kami hanya melihat apa yang modern, relevan. Dibandingkan dengan itu di proyek-proyek lain: kami bukan satu-satunya tim PHP di perusahaan. Kami menyadari bahwa Symfony senang dengan semua orang - itu tampak seperti proyek yang akan hidup selama beberapa tahun, memiliki komunitas yang luas, banyak perpustakaan yang siap pakai, utilitas baru dan sebagainya.

Saya memulai bisnis ini - saya menggali pada saat-saat pertama hanya untuk bergerak, pada gerakan menuju Symfony. Ketika saya tiba, saya tenggelam di berbagai bagian proyek sehingga saya dapat mengenalnya seluas mungkin - dan pada saat refactoring skala besar dimulai, saya cukup mengenalnya. Dan kawan lainnya datang setelah kami mulai. Kami membenamkannya dalam proses - tetapi berusaha untuk tidak membuatnya takut banyak. Setidaknya di awal)

BAIK. Kami telah memilih kerangka kerja. Apa berikutnya?

Seryozha, Skyeng: Ada dua cara - Anda dapat menulis ulang semuanya sekaligus. Anda dapat mencoba menyeret dan melepas secara perlahan. Di mana Anda mulai?

Dima, Finam: Kami mulai dengan holivar, jalan ke mana. Tidak ada yang pernah memiliki pengalaman menulis ulang volume seperti itu. Sebagai contoh, dari pekerjaan saya sebelumnya, saya memiliki pengalaman menulis ulang layanan otonom kecil - di sana kami hanya membekukan pembangunan selama sebulan, menulis ulang semuanya dan melanjutkan. Di sini kita tidak akan cukup selama setahun. Mungkin kita akan berhasil menghasilkan 80 persen dalam setahun, tetapi, Anda tahu ...

Ada sebuah prinsip: 80% pertama dari pekerjaan membutuhkan 80% dari waktu. 20% sisanya dari pekerjaan akan membutuhkan 80% lagi dari waktu.

Tidak mungkin untuk menghentikan aplikasi dan tugasnya saat ini. Dan ada dua konsep untuk kasus ini: apakah Anda melakukan sesuatu dengan aplikasi saat ini, atau Anda menggunakan yang baru. Kami menolak opsi penempatan yang baru - karena ada banyak kode. Akibatnya, kami tidak menggunakan aplikasi Symfony di sebelah yang lama, tetapi di atasnya.

Tapi kenapa begitu. Kami memiliki lebih dari 250 tabel dalam database, dan jika Anda menghapus beberapa pelat layanan, ini adalah sekitar 200 entitas. Mereka cukup terhubung satu sama lain dan karena jumlah koneksi ini sangat sulit untuk mengalahkan kode menjadi beberapa bagian logis otonom. Bagaimanapun juga, jangan putus, koneksi akan keluar dari bagian ini: misalnya, panggilan dan telepon terhubung dengan manajer dan klien. Karenanya, kami menyadari: jika Anda menggunakan aplikasi baru, mulai menulis fitur baru untuknya, dan perlahan-lahan mentransfer yang lama, ini akan menghasilkan kerja ganda. Lagi pula, kode yang akan kami transfer ke aplikasi baru tidak dapat sepenuhnya dihapus dari yang lama. Dan kita harus mendukungnya di dua tempat.

Kemudian kami ingat pengalaman lain yang sudah dimiliki tim kami.

Ini adalah pengalaman menulis ulang layer untuk mengakses data. Karena pada suatu waktu, bersama dengan Zend pertama, Mongo dipilih sebagai basis data utama. Tetapi latihan telah menunjukkan bahwa pilihannya tidak terlalu benar.

Seryozha, Skyeng: Ya, Anda memiliki semua koneksi relasional, tetapi Anda telah memilih basis data berorientasi dokumen.

Dima, Finam: Ya, dan ketika saya tiba, mereka baru saja dalam proses menulis ulang dari Mongo ke PostgreSQL ... Dan kami mendapat ide bahwa kami memiliki lapisan akses data. Dan karena kita sudah tahu cara menulis ulang layer untuk akses data, mungkin kita akan mengambilnya sedikit lebih lebar darinya dan segera mengambil layer ORM.

Jika Anda membayangkan aplikasi seperti kue seperti itu, akan ada 5 lapisan: ORM, akses data, logika bisnis, pengontrol, tampilan. Dan kita dapat menyentuh 2,5 lapisan - benar-benar mengubah ORM dan akses ke data, ditambah sebagian - logika bisnis. Bukan algoritme itu sendiri, tetapi kelas dan objek yang digunakan algoritme ini. Saya jelas tahu bahwa adalah mungkin untuk mencerna doktrin secara terpisah, yah, saya melakukannya.

Jadi saya masuk ke bootstrap kami, menginisialisasi doktrin di sana, meresepkan semua pengaturan yang diperlukan - dan memberi orang-orang review kode dengan kata-kata: "Yah, seseorang harus memulai ini."

Awal jalan mungkin terlihat seperti ini. Dan kemudian kami menerapkan prinsip bahwa mamut harus dimakan dalam beberapa bagian. Kadang-kadang potongan-potongan itu ternyata lebih dari yang kami duga, tetapi tugas dasar untuk sprint dua minggu adalah mengambil satu langkah - dan kami memastikan bahwa tidak ada tugas fitur di area yang sama.

Saya menangkap serangga, terguling ke belakang, terguling

Seryozha, Skyeng: Tetap saja, refactoring adalah hal yang penting, bagaimana Anda mengasuransikan diri sendiri?

Dima, Finam: Kami memiliki sejumlah unit test - yang mencakup poin-poin utama. Ada sejumlah tes fungsional yang diotomatisasi oleh tester kami. Pekerjaan utama CRM adalah bekerja dengan data. Dan untuk menguji tanpa data, dengan unit test tidak selalu mungkin: lebih mudah untuk mengirim paket, memeriksa apakah itu diproses secara normal, bahwa entitas dengan parameter yang diperlukan telah dibuat di dalamnya.

Secara alami, kami banyak memeriksa dengan tangan kami: terutama beberapa hal penting dan penting, seperti klien dan panggilan yang sama.

Saya ingat betul bagaimana saya melakukan tugas ini. Saya menelepon kepala pusat panggilan kami, dan kami sepakat bahwa ketika mereka kehabisan hari kerja dan hanya petugas yang tersisa, saya akan menyerahkan semuanya, dan petugas akan memeriksa semuanya dengan panggilan yang sebenarnya. Saya memberikan yang terbaik, mengawasi kayu-kayu gelondongan, menangkap banyak serangga, berguling, memerintah mereka, memperingatkan petugas, menggelinding, kembali menangkap bungkusan berikutnya, memutar kembali ... Dan beberapa iterasi.

Seryozha, Skyeng: Setelah berjalan jauh, tapi sekarang mungkin lebih dari setengahnya, apa yang akan Anda sarankan?

Dima, Finam:Saya mungkin akan menyarankan penerapan aplikasi Symfony yang sama di atas kita sedikit lebih awal. Untuk memastikan apa yang kita tulis, apa yang kita lakukan, itu benar-benar berfungsi. Saya ingat bagaimana kami menyebarkannya, meluncurkannya pertama dari konsol, kemudian dari controller, mengetuk lapisan logika bisnis kami - dan memastikan bahwa aplikasi melihatnya, dapat mengakses semua layanan, menarik semua metode, membongkar hasilnya.

Saya baru menyadari betapa kuatnya seorang motivator adalah kesadaran bahwa kami benar-benar menulis semuanya dengan benar. Untuk memastikan bahwa Anda berada di arah yang benar, untuk memastikan bahwa Anda melakukan semuanya dengan benar, harus dilakukan lebih awal.

Bukan pada langkah pertama, tetapi ketika Anda sudah memiliki sesuatu yang ditulis, ambillah seperti ini, tembak untuk tahun depan, atur mesin waktu lokal seperti itu, pastikan Anda melakukan semuanya dengan benar - ini akan memberi Anda kekuatan. Dan Anda akan melangkah lebih jauh.

ps

Terima kasih sudah membaca dan mendengarkan. Lebih banyak podcast PHP dapat ditemukan di sini .

Dan jika Anda ingin laporan yang lebih menarik dan percakapan di sekitar mereka, "datang" ke pertemuan PHP virtual ketiga pada 30 Mei.

Sialan CRM lama