🍂 📂 👨🏻 Metode untuk berurusan dengan kode lawas menggunakan GitLab sebagai contoh 🐻 🔝 💇🏽

Anda dapat tanpa henti menipu apakah GitLab adalah produk yang baik. Lebih baik untuk melihat angka-angkanya: menurut hasil putaran investasi, GitLab bernilai $ 2,7 miliar, sedangkan penilaian sebelumnya adalah $ 1,1 miliar. Ini berarti pertumbuhan yang cepat dan perusahaan akan mempekerjakan lebih banyak dan lebih banyak pengembang front-end.

Ini adalah kisah tentang penampilan frontend di GitLab.

Ini adalah grafik dari jumlah vendor front-end di GitLab, dimulai pada 2016, ketika tidak ada sama sekali, dan berakhir pada 2019, ketika sudah ada beberapa lusin dari mereka. Tapi GitLab sendiri sudah ada selama 7 tahun. Jadi, hingga 2017, kode utama di frontend ditulis oleh pengembang backend, lebih buruk, pengembang backend di Ruby on Rails (dalam hal apa pun kita tidak ingin menyinggung siapa pun dan menjelaskan di bawah apa yang kita bicarakan).

Selama 7 tahun, proyek apa pun, suka atau tidak, menjadi usang. Pada titik tertentu, refactoring menjadi tidak mungkin ditunda lagi. Dan perjalanan dimulai, penuh petualangan, titik akhir yang tidak pernah tercapai. Tentang bagaimana ini terjadi di GitLab, kata Ilya Klimov.

Tentang pembicara: Ilya Klimov (xanf) senior frontend engineer di GitLab. Sebelum itu, ia bekerja di startup dan outsourcing, memimpin perusahaan outsourcing kecil. Kemudian saya menyadari bahwa saya belum punya waktu untuk mengerjakan produk, dan datang ke GitLab.

Artikel ini didasarkan pada laporan oleh Ilya di FrontendConf , oleh karena itu tidak begitu banyak struktur informasi yang mencerminkan pengalaman pembicara. Ini mungkin tampak terlalu banyak bicara, tetapi tidak kalah menarik dari sudut pandang bekerja dengan warisan.

Di GitLab, seperti di banyak proyek lain, mereka secara bertahap bermigrasi dari teknologi lama ke sesuatu yang lebih relevan:

CoffeeScript dalam JavaScript. Pengembang di Ruby on Rails, ketika mereka memulai proyek, mau tidak mau memperhatikan CoffeeScript, yang terlihat sangat mirip dengan Ruby.
JQuery Vue. , JQuery. GitLab SPA. server-side rendering progressive enhancement, Vue-. , : Vue-, .
Karma Jest. Jest - . Karma , , .
REST GraphQL , , Vuex Apollo. Vuex, Redux Vue, Apollo local state , . GraphQL , .

Pada saat yang sama, penggantian berlangsung di beberapa arah sekaligus, dalam proyek ada secara bersamaan kode warisan pada tahap yang berbeda.

Sekarang bayangkan Anda datang ke proyek yang berada di tengah-tengah semua migrasi ini. Titik standar dan referensi bagi saya adalah situasi ketika Anda membuka mengedit proyek, tekan tombol simpan - dan menurut Anda apa yang akan terjadi? Jika Anda berpikir bahwa kami adalah fag-tua seperti HTML, maka tidak. JavaScript hadir karena Anda perlu "berevolusi" untuk menampilkan jendela sembul. Ini adalah titik bawah dalam gambar warisan saya.

Selanjutnya: kelas yang ditulis sendiri dalam jQuery, komponen Vue dan, sebagai titik tertinggi, fitur modern baru ditulis dengan Vuex, Apollo, Jest, dll.

Seperti inilah grafik kontribusi saya di GitLab.

Di dalamnya - dan ini sangat penting untuk memahami esensi cerita dan semua rasa sakit saya - beberapa segmen dapat dibedakan:

Onboarding di area April. "Honeymoon" ketika saya baru saja mulai bekerja di GitLab. Pada saat ini, pemula diberikan tugas yang lebih mudah.
Dari akhir April hingga pertengahan Mei hanya ada beberapa komitmen - periode penolakan : "Tidak, tidak mungkin semuanya dilakukan dengan cara itu!" Saya mencoba memahami di mana saya tidak memahami sesuatu, jadi ada beberapa komitmen.
Paruh kedua bulan Mei adalah kemarahan : "Saya tidak peduli tentang segalanya - saya perlu memindahkan produksi, berbagi fitur, mencoba melakukan sesuatu tentang hal itu."
Awal Juni (nol komitmen) adalah depresi . Ini bukan liburan, saya menyaksikan dan mengerti bahwa tangan saya jatuh, saya tidak tahu apa yang harus saya lakukan dengannya.
Setelah itu, saya setuju dengan diri saya sendiri , memutuskan bahwa saya dipekerjakan sebagai seorang profesional, dan saya bisa menjadikan GitLab lebih baik. Pada bulan Juni dan Juli, saya menawarkan sejumlah besar perbaikan. Tidak semua dari mereka beresonansi untuk alasan yang akan kita bicarakan.
Sekarang saya berada pada tahap adopsi dan mengerti dengan jelas: bagaimana, di mana, mengapa dan apa yang harus dilakukan dengan semua ini.

Saya akan memberi tahu Anda secara lebih rinci apa yang saya lakukan dari Agustus hingga Oktober. Jujur saja, di perusahaan outsourcing kecil atau startup, saya akan dipecat lima kali dengan produktivitas seperti itu dalam tiga bulan ini.

Jadi, dalam tiga bulan saya melakukannya:

Kontrol tersegmentasi - tiga tombol.
String pencarian yang menyimpan sejarah lokal adalah komponen yang sedikit lebih kompleks.
Pemintal. Dan komponen ini belum dibekukan.

Selanjutnya, langkah demi langkah, kita akan menganalisis mengapa ini terjadi dan bagaimana hidup dengannya. Jika menurut Anda saya melebih-lebihkan, ini adalah tangkapan layar dari beberapa tugas yang menggantung saya di GitLab (Anda dapat melihat langsung pada GitLab, terbuka).

Lihat: tidak terjawab 12.1, terjawab 12.2, terjawab 12.3. Sprint berlangsung sebulan, dan kontrol tersegmentasi - 3 sprint. Spinner masih pergi, dia akan menjadi karakter utama kita.

Masalah refactoring dan filosofi refactoring telah menghadapi kemanusiaan sejak lama - selama ribuan tahun. Sekarang saya akan membuktikan:

« ; , , ; ; , .

, , , : ».

Alkitab memberi tahu kita bagaimana menggabungkan fungsi lama dan baru. Bagian kedua dari kutipan ini bernilai dari sudut pandang manajemen: tidak peduli bagaimana Anda melakukan inisiatif, Anda akan menghadapi perlawanan besar.

Pada fase depresi, saya menonton banyak laporan tentang refactoring proyek-proyek besar, tetapi sekitar 70% dari mereka mengingatkan saya pada lelucon.

Pembicaraan Javist:
- Bagaimana kita mempercepat aplikasi Java kita?
- Oh, jadi saya punya laporan tentang itu! Apakah Anda ingin memberi tahu?
- Untuk mengatakan dan saya bisa, saya akan mempercepat!

Jika Anda masih memutuskan untuk memulai jalan refactoring yang berbahaya dan goyah, saya memiliki beberapa resep sederhana yang telah saya kembangkan untuk diri saya sendiri dan yang bekerja dalam kondisi yang mendekati kenyataan.

1. Isolasi

Untuk mempercepat, memperbaiki, refactor, Anda perlu memotong gajah menjadi steak, yaitu, membagi tugas menjadi beberapa bagian. GitLab sangat besar, kami memiliki saluran Slack "Apakah ini dikenal", di mana orang mengajukan pertanyaan seperti "Apakah ini bug atau fitur, siapa yang bisa menjelaskan?" - dan jawabannya tidak selalu ditemukan.

Contoh sederhana: tangkapan layar dari tempat yang sama di GitLab, diambil dengan perbedaan satu hari.

Saya sangat kesal, karena saya bekerja pada tombol ini, dan ini semua satu atau lain masalah dengan tombol.

Apa yang terjadi? Sederhana: kami mengembangkan sistem desain, dan sebagai bagian dari alat buku cerita terpisah untuk menguji sistem desain, kami menonaktifkan CSS global GitLab untuk memeriksa bagaimana komponen CSS diisolasi dari CSS global.

Meringkas: CSS tidak lagi menyimpansetidaknya di GitLab.

Saya telah bekerja dengan JavaScript selama 14 tahun dan belum pernah melihat proyek yang setidaknya satu atau dua tahun lamanya memelihara CSS yang dikelola sepenuhnya. Omong-omong, HTML juga tidak bisa disimpan (di GitLab pasti).

GitLab telah dikembangkan untuk waktu yang lama dan backendov. Mereka membuat keputusan kontroversial untuk menggunakan Bootstrap karena Bootstrap menawarkan sistem tata letak yang ramah-backend.

Tapi apa itu Bootstrap dalam hal filosofi isolasi komponen? Ini adalah sekitar 600-700 kelas global (pada kenyataannya, setiap kelas CSS adalah global) yang menyerap seluruh aplikasi. Dalam hal pengelolaan, tidak ada hal baik yang akan terjadi.

Tindakan selanjutnya (jangan menyebutnya kesalahan) - GitLab mengambil Vue.js. Pilihannya masuk akal, karena tiga kerangka kerja, Vue yang memungkinkan Anda untuk menulis ulang sesuatu dengan paling lancar. Anda tidak perlu segera membuang dan memotong Aplikasi Halaman Tunggal yang besar, tetapi Anda dapat menulis ulang setiap node kecil. Sekarang hal itu dapat dilakukan pada Angular, tetapi 3-4 tahun yang lalu, ketika Angular 2 muncul, itu tidak dapat hidup berdampingan di halaman dalam lebih dari satu contoh. Bereaksi juga dimungkinkan sekarang, tetapi semua keajaiban ini dengan kurangnya langkah membangun dan seterusnya mengarahkan timbangan ke arah Vue.

Akibatnya, satu kejahatan digabungkan dengan yang kedua. Ini buruk, karena gaya Bootstrap tidak tahu apa-apa tentang sistem komponen, dan komponen Vue ditulis pada awalnya. Oleh karena itu, keputusan yang kuat dibuat untuk membuat sistem desain mereka sendiri. Kami menyebutnyaPiyama , tapi tidak ada yang bisa menjelaskan mengapa.

Saya melihat bahwa sekarang ada semakin banyak sistem desain kita sendiri, dan ini bagus.

Sistem desain melibatkan isolasi, tetapi karena GitLab sudah ditulis dalam Bootstrap, sekitar 50-60% dari sistem desain kami adalah pembungkus komponen Bootstrap / Vue dengan penurunan fungsionalitasnya. Ini diperlukan agar sistem desain tidak memungkinkan Anda untuk menggunakan komponen secara salah. Jika kita berbicara tentang perpustakaan abstrak, maka fleksibilitas penting di sana, misalnya, kemampuan untuk membuat tombol apa pun yang Anda inginkan. Jika di GitLab spinners dapat empat ukuran yang disetujui oleh desainer, maka Anda perlu secara fisik tidak membiarkan orang lain melakukannya.

Suatu hari nanti, niat baik akan menang, dan kami akan memiliki alat penting yang dengannya, tentu saja, jika Anda mendapat skor dukungan untuk IE dan Edge, Anda dapat secara efektif memperbaiki proyek-proyek front-end - ini adalah Shadow DOM . Shadow DOM memecahkan masalah gaya global yang mengalir ke komponen. Tolong jangan mengambil Polymer, yang bahkan Google telah dimakamkan. Gunakan elemen-lit dan HTML-lit, dan Anda dapat membangun gaya terisolasi menggunakan kerangka favorit Anda.

Anda dapat mengatakan bahwa Bereaksi memiliki modul CSS, Vue memiliki cakupan gaya yang melakukan hal yang sama. Berhati-hatilah dengan mereka: modul CSS tidak menyediakan isolasi 100% karena hanya bekerja dengan kelas. Dan dengan gaya cakupan dalam Vue, skenario yang sangat menarik dapat direalisasikan ketika gaya komponen teratas jatuh ke elemen root dari induk, dan ada atribut data yang digunakan yang memperlambat.

Terlepas dari kenyataan bahwa saya memarahi Angular selama tiga tahun, sekarang saya harus mengakui bahwa saat ini penerapannya adalah yang terbaik. Dalam Angular, untuk memastikan isolasi gaya yang baik, cukup dengan hanya beralih mode isolasi dan, jika perlu, gunakan Shadow DOM, jika tidak emulasi normal.

Kembali ke pemintal. Dari tiga bulan saya berkelahi dengannya, untuk beberapa waktu saya terlibat dalam bisnis yang menarik: membersihkan.

Kelas loading-containeradalah detail implementasi dari pemintal, yaitu kelas di dalam implementasi pemintal. Kami memutuskan, karena CSS tidak dapat disimpan, di Pyjamas untuk membuat CSS terpisah berdasarkan Atomic CSS. Saya pribadi tidak terlalu menyukai konsep Atomic CSS, tetapi kami memiliki apa yang kami miliki.

Artinya, saya terlibat dalam membersihkan gaya dalam kode produk utama yang digantung pada elemen yang merupakan detail implementasi. Semuanya terlihat sangat sederhana - karena, tentu saja, ada tes di GitLab.

2. Tes

Tes di GitLab mencakup semua kode , memberikan keandalan. Dan jadi pipa selesai dalam 98 menit.

GitLab mengumpulkan 40% dari waktu pelari publik di GitLab.com karena GitLab mengumpulkan pipa untuk setiap permintaan penggabungan.

Saya sangat terinspirasi: Saya akhirnya mengerjakan proyek di mana semuanya tercakup dalam ujian! Cakupan kode backend mendekati 100%, dan kode front-end pada saat kedatangan saya dicakup oleh 89,3%.

Sayangnya, ternyata sebagian besar liputan ini adalah sampah karena:

rusak ketika perubahan dilakukan yang tidak terkait dengan komponen;
Tidak pecah saat perubahan dilakukan.

Saya akan jelaskan dengan contoh. Kami mengambil Jest karena kami berpikir bahwa dia akan mengizinkan kami dalam situasi tertentu untuk tidak menulis pernyataan, tetapi untuk menggunakan snapshot. Masalahnya adalah bahwa jika Anda tidak mengonfigurasi Jest dan menambahkan serializer yang benar, maka Vue Test Utils hanya menampilkan alat peraga dalam HTML. Kemudian, misalnya, ternyata alat peraga dengan nama pengguna, yang memiliki alat peraga di parameter dengan data nama, di mana objek objek dilewatkan. Setiap perubahan dalam format data yang dikirimkan tidak mengarah pada kegagalan snapshot.

Pengembang Ruby terbiasa melakukan tes, secara kasar, mencakup semua metode.

Saat kami melakukan pengujian untuk komponen Vue atau React, kita perlu menguji bagaimana perilaku API publik.

Jadi, kami memiliki tes besar untuk properti yang dihitung, yang tidak digunakan dalam beberapa skenario, tetapi yang lain secara fisik tidak mungkin untuk mencapai keadaan saat komputasi ini akan dipanggil. Terima kasih khusus kepada Vue, di mana templatnya adalah string, jadi Anda tidak dapat menghitung cakupan pengujian templat. Di Vue 3, Source Maps akan muncul dan kemampuan untuk memperbaikinya, tetapi tidak akan segera.

Untungnya, ada satu keterampilan sederhana yang akan memungkinkan Anda untuk secara efektif memperbaiki warisan. Ini adalah kemampuan untuk menulis apa yang disebut tes pinning di dunia pengujian besar.

Tes menjepit

Ini adalah tes yang mencoba menangkap perilaku yang Anda refactoring. Harap dicatat bahwa tes pinning kemungkinan besar tidak akan berakhir pada repositori. Yaitu, Anda, melalui segala macam penyempurnaan, misalnya, menggunakan lingkungan pementasan, tulis sendiri tes yang menjelaskan bagaimana komponen Anda dirender. Setelah refactoring, tes pinning harus menghasilkan HTML yang sama, dan ini kemungkinan besar pertanda baik, atau Anda harus memahami perubahan apa yang telah terjadi.

Saya akan memberi contoh dari kehidupan. Beberapa bulan yang lalu, saya melakukan tinjauan permintaan gabungan dengan refactoring daftar drop-down. Konteks lama adalah ini: sebelumnya, untuk memisahkan cabang seorang teman dari satu sama lain dengan tanda hubung dalam daftar drop-down, string teks "pembagi" hanya disahkan. Karena itu, jika cabang Anda disebut pembagi, maka Anda kurang beruntung. Dalam proses refactoring, seseorang bertukar dua kelas dalam node HTML, ini masuk ke produksi dan menghancurkannya. Dalam keadilan, tentu saja, tidak cukup produksi, tetapi dalam pementasan, tetapi tetap saja.

Akibatnya, ketika kami mulai menulis tes seperti itu, kami menemukan bahwa, meskipun indikator cakupan tes keren, tes tersebut ditulis secara tidak benar. Karena, pertama, kami memiliki tes untuk Karma, yaitu yang lama. Kedua, hampir semua tes membuat asumsi tentang internal komponen. Artinya, mereka berpura-pura menjadi unit test, dan bekerja pada dasarnya seperti ujung ke ujung, memeriksa bahwa tag tertentu dengan kelas tertentu sedang dibuat, alih-alih memeriksa bahwa komponen tertentu sedang dirender dengan alat peraga tertentu. Pahami perbedaannya: kelas adalah komponen?

Akibatnya, 18 permintaan saya bergabung dengan tes refactoring dengan total 8-9 ribu baris, total changelog ternyata sekitar 20 ribu, karena 11 ribu terpotong.

Pada saat yang sama, secara formal, saya mengerjakan ulang semua tes ini demi satu hal: untuk menghapus pernyataan tentang kelas-kelas pemintal, dan sebagai gantinya memeriksa bahwa pemintal dengan alat peraga yang benar ditampilkan di sana.

Sekilas, ini adalah pekerjaan tanpa pamrih. Tetapi penulisan ulang tes untuk arsitektur yang tepat cukup mudah dijual ke bisnis. GitLab adalah produk yang menguntungkan secara komersial. Tentu saja, jika Anda memberi tahu manajer produk bahwa Anda membutuhkan tiga iterasi untuk menulis ulang 20 tes, tebak ke mana Anda akan dikirim. Hal lain: “Saya perlu tiga iterasi untuk menulis ulang tes. Ini akan memungkinkan kami untuk memperkenalkan pemintal lebih efisien dan mempercepat implementasi elemen-elemen baru dari sistem desain di masa depan. " Dan di sini kita sampai pada yang penting.

3. Perlawanan

Ada fungsi lain yang menunggu lebih banyak pemintal saya dalam sistem desain GitLab - ini adalah ikon SVG biasa.

Kami memiliki ikon yang dibuat oleh perancang yang digunakan dalam proyek utama, tetapi mereka tidak ada dalam sistem desain, karena GitLab memiliki masa kecil yang sulit. Sebagai contoh, pada tahun 2019 CSS dikumpulkan bukan melalui Webpack, tetapi dengan sepotong yang disebut Sprockets - ini adalah pipeline Ruby, karena kita perlu menggunakan kembali CSS yang sama di backend dan frontend. Karena itu, ikon harus terhubung ke proyek yang berbeda dengan cara yang berbeda. Oleh karena itu, seseorang refactored basis kode utama selama tiga bulan sehingga Anda dapat menghubungkan ikon dari sistem desain ke proyek terkait.

Ada poin penting di sini yang pasti akan Anda temui. Refactoring adalah proses peningkatan berkelanjutan. Tetapi cepat atau lambat Anda harus berhenti.

Ini benar-benar normal untuk berhenti, tidak menyelesaikan refactoring, tetapi mendapatkan perbaikan nyata yang terukur.

Tetapi jika Anda sedang mengerjakan proyek warisan, Anda pasti akan menemukan orang-orang yang melakukan ini.

Ini berarti mereka menulis dengan cara lama, karena mereka sudah terbiasa. Sebagai contoh, backenders kami mengatakan: "Saya tidak ingin mengajarkan ini Jest Anda. Saya sudah melakukan tes tertulis untuk Karma selama tiga tahun, saya perlu menambahkan fungsionalitas baru, dan karena mereka tidak akan mengambil fungsionalitas tanpa tes, inilah tes untuk Karma. "

Tugas Anda adalah melawan ini sebanyak mungkin. Ini relatif mudah untuk dilawan, tetapi ada dosa yang bahkan lebih besar dari itu. Terkadang dalam proses refactoring Anda menemukan masalah, dan ada keinginan untuk mengesampingkannya.

Artinya, mengganti kruk baru hanya karena untuk alasan tertentu tidak mungkin membawa refactoring sampai akhir. Sebagai contoh, jika kita memiliki masalah mengintegrasikan ikon ke basis kode utama, kita dapat meninggalkan kelas utilitas yang akan ditarik dari CSS Aplikasi global. Secara formal, tugas bisnis akan diselesaikan, tetapi dalam praktiknya, seperti dalam sejarah hydra Lernean: ada 8 bug, 4 diperbaiki, 13 tetap.

Refactoring, seperti memperbaiki rumah - tidak mungkin selesai, Anda hanya bisa menghentikannya.

80% pertama dari refactoring membutuhkan 20% dari waktu, 80% sisanya dari refactoring (hanya seperti itu) membutuhkan 80% lagi dari waktu tersebut.

Penting untuk tidak memperkenalkan retasan baru selama proses refactoring. Percayalah, selama proses pengembangan, mereka sendiri akan muncul.

4. Alat

Untungnya, bahkan sebelum saya tiba, GitLab memulai jalur yang benar untuk memperkenalkan alat yang baik: Lebih cantik, Utilitas Uji Vue, Jest. Meskipun Prettier diimplementasikan dengan bengkok.

Saya akan menjelaskan apa yang dipertaruhkan. Sementara saya menemukan apa dan mengapa secara historis, 80% dari pencarian saya menemukan komit 37 ribu baris kode cantik. Hampir tidak mungkin untuk menggunakan histori, dan saya harus mengkonfigurasi plug-in untuk Kode VS sehingga akan mengecualikan komit ini ketika mencari histori perubahan.

Tentu, alat itu penting, tetapi Anda harus memilihnya dengan hati-hati. Sebagai contoh, kami memiliki Vue, dan Vue memiliki alat pengujian yang bagus - Vue Test Utils. Tetapi jika Vue 2 dirilis 2-3 tahun yang lalu, maka Vue Test Utils masih belum keluar dari beta. Selain itu, menurut informasi orang dalam, saat ini satu-satunya pengembang Vue Test Utils tidak menulis di Vue.

Dalam proses memilih alat, Anda bermain-main dengan takdir, dan benar-benar mencoba untuk menang.

GitLab mengalami cedera pada masa kanak-kanak dengan CoffeeScript. Itulah mengapa tidak mungkin untuk mendorong bahkan gagasan teoritis menulis dalam TypeScript di GitLab. Semuanya terurai menjadi satu argumen sederhana: apakah itu tidak akan sama dengan CoffeeScript ketika bahasa yang dikompilasi dalam JavaScript telah mati.

Saat memilih alat, cobalah agar alat tersebut dapat diganti, atau, dalam kasus yang ekstrim, dirawat secara mandiri.

Kami di GitLab menggunakan hal keren yang disebut Bahaya.

Ini adalah tangkapan layar nyata situs web mereka pada tahun 2019. Tapi, kolega mengatakan bahwa sebenarnya pada 2019 situs itu mungkin terlihat seperti apa pun.

Bahaya adalah bot yang menempati kondisi antara antara linter dalam CI Anda dan pedoman tertulis. Bot ini dapat diperluas dan akan datang untuk menarik permintaan atau, karena mereka dipanggil dengan benar, menggabungkan permintaan dan meninggalkan komentar seperti:

"Ada komentar nonaktifkan ESlint di file ini, perbaiki."
“File ini dulunya diperintah oleh orang ini. Mungkin Anda perlu memberi ulasan. ”

Menurut pendapat saya, ini adalah kerangka kerja yang sangat baik, penting dan dapat diperluas untuk memantau keadaan basis kode.

5. Abstraksi

Saya akan mulai dengan sebuah contoh. Beberapa bulan yang lalu, saya melihat berita: “GitHub menyingkirkan jQuery. Kami telah menempuh jalan yang sulit dan tidak lagi menggunakan jQuery. ” Secara alami, saya berpikir bahwa kita juga perlu menyingkirkan jQuery di GitLab.

Pencarian cepat menunjukkan bahwa jQuery digunakan dalam 300 file. Itu terlihat menakutkan, tetapi tidak ada - mata takut, tangan melakukan. Tapi tidak! jQuery adalah perekat integral dalam basis kode GitLab, karena kami memiliki Bootstrap.

Bootstrap awalnya ditulis dalam jQuery. Ini berarti bahwa jika Anda perlu, misalnya, untuk menangkap acara pembukaan tarik turun di Bootstrap, ini adalah acara jQuery. Anda tidak dapat mencegatnya secara asli.

Ini adalah hal pertama yang harus Anda abstraksi saat bekerja dengan kode lawas. Jika Anda memiliki jQuery yang tidak dapat Anda buang, tulis Event Emitter Anda sendiri, yang akan bersembunyi di dalam kantor dengan acara jQuery.

Ketika masa depan yang cerah datang, kita dapat menghapus jQuery, tetapi untuk sekarang, maaf, Anda harus memusatkan govnokod. Dalam proyek lawas biasa, itu tersebar merata di seluruh kode. Kumpulkan di bottleneck yang ditandai dengan bendera “Jangan masuk tanpa baju pelindung bahan kimia”.

6. Metrik

Anda tidak dapat melakukan sesuatu yang hasilnya tidak dapat diukur. Di GitLab, kami mengukur semua yang kami lakukan untuk mengetahui secara objektif bahwa kode tersebut berfungsi lebih baik.

Misalnya, kami memiliki jadwal migrasi dari tes Karma (biru) ke Jest (hijau):

Anda melihat bahwa ada kemajuan bertahap. Dan kami memiliki banyak jadwal seperti itu. Tetapi penting untuk dipahami bahwa tidak selalu semuanya berakhir dengan baik.

Saya akan memberikan satu contoh lagi (demo dalam laporan dimulai dari saat ini ).

Ini adalah antarmuka permintaan gabungan yang biasa dalam produksi GitLab. Jelas, kita dapat menutup file, klik pada header dan file akan mulai runtuh.

Bagaimana menurut Anda, berapa lama waktu yang dibutuhkan untuk menutup file 50 baris, sementara mesin dengan Core i7 generasi kedelapan dipelintir untuk kinerja maksimum? Berapa lama waktu penyebaran?

Waktu yang dibutuhkan file untuk runtuh berkisar antara 7 hingga 15 detik. Penempatan terjadi secara instan. Sebelum refactoring, keduanya bekerja sama cepatnya.

Itulah mengapa sangat penting untuk memiliki metrik.

Saya akan memberi tahu Anda apa yang terjadi di sini. Ini Vue, sistem reaktivitasnya melacak nilai: jika ia berubah, semua dependensi yang bergantung pada nilai ini dipanggil. Setiap baris adalah komponen Vue yang terdiri dari banyak hal, karena Anda dapat memberikan komentar pada sebuah baris, komentar dapat dimuat secara dinamis dari server, dll. Semua ini berlangganan Vue-store, yang juga merupakan komponen Vue.

Ketika Anda menutup permintaan penggabungan, semua, katakanlah, 20 ribu langganan toko perlu diperbarui ketika toko diperbarui. Jika baris dihapus, itu harus dihapus dari dependensi. Dan kemudian matematika sederhana: Anda perlu melihat array 20 ribu elemen untuk menemukan mereka yang perlu dihapus. Katakanlah ada 500 baris seperti itu, dan setiap baris adalah beberapa komponen. Hasilnya adalah operasi matematika O (N), yaitu, O (20.000) * 500. JavaScript telah berjalan selama ini.

Penempatan terjadi secara instan, karena menambahkan dependensi hanya merupakan dorongan ke array, mis. operasi matematika O (1).

Terkadang, peningkatan kualitas kode menurunkan kinerja dan metrik lainnya. Sangat penting untuk mengukurnya.

Singkatnya: pisahkan kode buruk dan catat metrik.

legacy — . , – TechLead Conf — , . – , legacy Python, PHP.

, ++, , FrontendConf. .

Metode untuk berurusan dengan kode lawas menggunakan GitLab sebagai contoh