Headhunter adalah perusahaan produk, kualitas kode sangat penting bagi kami. Semakin baik, semakin cepat kita dapat merilis fitur bisnis baru dan lebih sering menyenangkan pengguna.
Untuk setiap permintaan tarik, Anda harus lulus ulasan, meskipun hanya satu baris yang diubah. Setidaknya satu orang membutuhkan penilaian, ulasan terbuka, siapa saja dapat berpartisipasi, dan ini disambut baik. Diperlukan tinjauan untuk meningkatkan kualitas kode dan menyebarluaskan pengetahuan di antara berbagai tim.
Sebelumnya, ulasan ini memiliki perdebatan konstan tentang bagaimana dan apa yang harus ditulis dengan benar. Butuh banyak waktu dan usaha. Untuk mengatasi masalah ini, Panduan Gaya ditulis. Dia banyak membantu, ketika sumber kebenaran muncul, yang selalu bisa dirujuk. Panduan Gaya juga membantu pemula memasuki proyek, segera menjelaskan apa dan bagaimana menulis, dan apa yang diharapkan dalam ulasan.
Namun demikian, ada masalah besar dengan Panduan Gaya - orang sering lupa tentang dia, dia harus terus membaca ulang dan menautkan permintaan tarik untuk membuktikan bahwa dia benar. Akibatnya, ulasan tersebut terkadang berubah menjadi sengketa yang bias, sesuatu seperti ini ternyata:
Anda sendiri memahami betapa ini mendemotivasi pengembang, dan berapa banyak waktu yang dihabiskan untuk sengketa yang tidak berguna dalam ulasan. Akibatnya, orang tidak ingin meninjau dan meninjau pengembang lain.
Untuk membuat kepala pembuat kode dan peninjau tidak terlalu sibuk dengan pertanyaan tentang bagaimana menempatkan koma dan bagaimana cara menulis aturan untuk border kami memutuskan untuk menerapkan otomatisasi, pada saat itu jshint , itu menjadi jauh lebih baik. Setelah beralih ke eslint karena sejumlah keunggulan:
- Ia lebih fleksibel
- Ada semua jenis plugin untuk itu.
- Perusahaan yang berbeda memiliki konfigurasi siap pakai yang bagus
Untuk waktu yang lama, kami mewarisi dari airbnb , tetapi tidak semuanya cocok dengan kami, kami harus mendefinisikan ulang beberapa aturan. Itu tidak terlalu nyaman, akibatnya kami menulis konfigurasi kami berdasarkan airbnb. Kami juga menambahkan kait precommit, pada waktu itu kami menggunakan husky . Jika pengembang menulis sesuatu yang salah, ia segera mengetahui ketika ia mencoba untuk melakukan perubahan pada github.
Namun sayangnya, eslint tidak mencakup semua aspek pemformatan kode, lebih cantik ditambahkan untuk menyelesaikan masalah ini.
Untungnya, eslint dan lebih cantik bekerja dengan baik, Anda hanya perlu menempatkan eslint-plugin-prettier dan eslint-config-lebih cantik dan kemudian perbaiki .eslintrc seperti ini:
... "plugins": ["prettier"], "extends": ["@hh.ru/eslint-config", "prettier"], "rules": { "prettier/prettier": ["error"], ...
Sebelum merilis semua ini ke prod, perlu untuk pergi melalui seluruh basis kode dan memperbaikinya untuk mematuhi aturan baru, ternyata tidak sulit sama sekali: yarn eslint --fix <path_to_js>
Setelah itu, sebagian besar perdebatan tentang cara menulis dan memformat kode menghilang, karena semuanya ditutupi oleh otomatisasi. Total sekarang kita miliki:
- Semua js dan jsx diperiksa dan diperbaiki secara otomatis menggunakan eslint dan lebih cantik.
- Untuk lebih sedikit, stylelint digunakan.
- Untuk python flake8.
File yang dimodifikasi diperiksa pada mesin pengembang ketika melakukan, menggunakan lint-staged , di sini adalah .lintstagedrc kami:
{ "*.{js,jsx}": ["eslint --fix", "git add"], "*.less": "stylelint", "*.py": "flake8", "package.json": "bash -c 'yarn check-versions && yarn install --frozen-lockfile'", }
Kode yang sudah lulus linting dan tes masuk ke github, reviewer tidak perlu memikirkan hal ini lagi dan memperhatikan hal-hal kecil. Anda dapat sepenuhnya berkonsentrasi pada seberapa baik kode ini ditulis, jika akan ada masalah kinerja, dan berpikir tentang arsitekturnya.
Setelah ditinjau, wadah buruh pelabuhan dirakit, selama perakitan semua autotest dan linter dijalankan. Sekarang seluruh proses perakitan memakan waktu sekitar 7,5 menit, sementara sekarang kami memiliki sekitar 1000 js dan 650 file lebih sedikit. Semua ini diperlukan, karena secara lokal pada mesin Anda dapat melewati menggunakan --no-verify , dan komentar di github tidak memblokir tugas. Menipu majelis tidak bekerja.
Setelah melewati autotest, pengujian manual dimulai. Jika penguji tidak menemukan satu bug pun, tugas beralih ke prod.
Jika kesalahan terjadi pada tahap apa pun, tugas kembali untuk revisi.
Hasilnya adalah:
- Lebih mudah dan lebih cepat untuk menulis kode.
- Lebih mudah melakukan review
- Wizard selalu memiliki kode kualitas
- Kontroversi lebih sedikit, lebih banyak kebahagiaan
Kami memantau kualitas kode selama pelaksanaan tugas bisnis, tetapi produk terus berkembang, kondisi tambahan muncul dalam kode, kompleksitas meningkat. Teknologi baru juga muncul, yang lama mati karena semua ini, pajak teknis muncul. Sebagai bagian dari pajak, kami terlibat dalam:
- Optimalisasi halaman khusus
- Perubahan infrastruktur
- Perbaikan basis kode
Semua tim produk harus menghabiskan 70% waktunya untuk mengembangkan tugas bisnis, dan 30% untuk pajak - ini memberi setiap pengembang kesempatan untuk terlibat dalam tugas infrastruktur, mempertahankan basis kode dalam kondisi sangat baik, dan menyebarluaskan pengetahuan tentang infrastruktur proyek di semua tim. Sebagai pajak, tidak perlu melakukan tugas-tugas tim Anda, Anda dapat menulis kode di bagian mana pun dari proyek. Siapa pun dapat menyarankan pajak, jika tampaknya bermanfaat, maka akan ditambahkan ke dalam jaminan simpanan. Selain itu, ada tim arsitektur yang berurusan dengan fitur teknologi sepanjang waktu. Semua ini memungkinkan Anda untuk terus memperbarui basis kode.