Saya sarankan agar Anda membiasakan diri dengan transkrip laporan oleh Denis Isaev jirfag "Linter in Go. Cara memasaknya."
In go 50+ linter: apa keuntungan mereka dan bagaimana mengintegrasikan mereka secara efektif ke dalam proses pengembangan? Laporan ini akan berguna baik bagi mereka yang belum menggunakan linter, dan bagi mereka yang sudah menggunakannya: Saya akan mengungkapkan trik dan praktik yang tidak banyak diketahui untuk bekerja dengan linter.
Siapa yang peduli, tolong, di bawah kucing.
Hai Nama saya Dennis Isaev. Kami akan berbicara tentang cara memasak linter di Go. Laporan ini akan menarik baik untuk pemula yang belum menggunakan linter, dan untuk para profesional. Saya akan bercerita tentang beberapa trik kecil yang diketahui.
Sedikit tentang saya. Saya adalah penulis proyek opensource Golangci-lint. Bekerja di mail.ru. Sekarang saya bekerja sebagai TeamLead di backend di Yandex.Taxi. Laporan saya didasarkan pada pengalaman dengan ratusan pengguna Golangci-lint. Tentang bagaimana mereka menggunakan linter, kesulitan apa yang mereka miliki dan pengalaman menerapkan Go linter di mail.ru dan Yandex.
Kami akan membahas 5 masalah utama dalam laporan.
Saya cukup sering melihat bahwa linter tidak digunakan sama sekali. Angkat tangan Anda kepada mereka yang menggunakan benang di semua proyek tanpa kecuali. Tidak semua.
Mari kita bicarakan mengapa mereka tidak digunakan. Paling sering ketika saya bertanya mengapa kalian tidak menggunakan, mereka mengatakan bahwa linter mengganggu kami. Mereka hanya memperlambat perkembangan. Tidak ada yang baik di dalamnya. Ini sebagian benar. Jika Anda tidak tahu seluk-beluk tuning, maka mereka benar-benar dapat mengganggu. Kami akan membicarakannya nanti.
Selain itu, mereka sering berpikir bahwa linter hanya menemukan sesuatu yang kecil, sesuatu yang bergaya, beberapa bug yang tidak penting dan pada kenyataannya itu tidak layak. Apakah lebih mudah membuang waktu.
Segera kontra contoh. Bug di Docker ditemukan menggunakan go vet. Panggilan lupa untuk membatalkan fungsi. Karena itu, latar belakang goroutine mungkin tidak berakhir.
Bug dalam proyek Etcd. Linter go-kritik keren menemukan bahwa argumen string.HasPrefix bingung. Berarti memeriksa protokol HTTP yang tidak aman tidak akan berfungsi.
Dalam Go sendiri, bugnya adalah bahwa elemen i dibandingkan dengan elemen ke-i, meskipun harus dibandingkan dengan elemen ke-j. Juga ditemukan oleh linter.
Tiga contoh dalam proyek open source besar yang ditemukan oleh linter. Beberapa orang akan bertanya: Oke, lalu bagaimana? Dia menemukan beberapa bug kritis. Untuk satu bug kritis, ia menemukan 100 positif tidak kritis atau salah. Saya dapat memberikan statistik empiris saya: Saya biasanya memiliki sekitar 80 persen dari semua masalah yang dilaporkan oleh para linter: beberapa masalah gaya, misalnya, variabel tidak digunakan, dan seterusnya, 15 persen adalah bug nyata dan sekitar 5 persen adalah positif palsu.
Sekarang mari kita bicara tentang mengapa linter diperlukan. Bonus paling penting adalah bahwa linter menghemat waktu. Dan waktu adalah uang. Semakin cepat Anda menemukan bug, semakin murah biayanya untuk perusahaan Anda. Pada slide adalah grafik perkiraan biaya perbaikan bug tergantung pada tahap di mana bug ditemukan. Dengan demikian, dari setiap tahap dari pengembangan ke produksi, biaya meningkat tiga kali lipat. Temukan bug lebih awal, idealnya di IDE dan hemat uang perusahaan.
Sering terjadi bahwa pada CodeReview, pengembang akan melaporkan beberapa masalah yang mungkin ditemukan oleh linter. Mengapa mereka melakukan ini tidak dapat dipahami. Pertama, pembuat kode harus menunggu sampai melewati CodeReview. Kedua, pemeriksa sendiri perlu menghabiskan waktu untuk menemukan masalah mekanis. Dia bisa mempercayai ini kepada Linter. Ketika saya perhatikan ini, saya selalu memaksanya dan kami sepakat dalam tim bahwa kami tidak dapat melihat ulasan untuk semua yang kami temukan. Apakah kita percaya semua ini kepada linter. Selain itu, jika kami menemukan beberapa masalah yang sering terjadi dalam ulasan dan tidak ada linter pada mereka, kami mencoba untuk menemukan linter yang dapat menangkap mereka secara teori. Jadi kami tidak membuang waktu untuk ulasan.
Linter memungkinkan kita untuk entah bagaimana menjamin dan memiliki kualitas kode yang dapat diprediksi dalam proyek. Misalnya, dalam hal ini, ini adalah argumen fungsi yang tidak digunakan.
Linters memungkinkan Anda menemukan bug kritis sedini mungkin, menghemat waktu CodeReview. Pada saat yang sama, menjamin beberapa kualitas kode untuk proyek tersebut.
Go memiliki lebih dari 50 linter, tetapi yang paling populer adalah 4. Ini adalah yang ada di slide. Mereka digunakan hanya karena mereka keren. Sisanya biasanya tidak mau berurusan dengan. Sekarang saya ingin menunjukkan dengan contoh jenis apa linter yang ada. Saya ingin menunjukkan 25 contoh linter. Sekarang mungkin akan menjadi hal terpenting dalam laporan.
Mari kita mulai dengan formatters yang memeriksa formatters. Gofmt pada dasarnya bukan linter. Tapi kita bisa menganggapnya sebagai linter. Dia tahu cara memberi tahu kami bahwa tidak ada cukup umpan baris, di suatu tempat spasi tambahan. Secara umum, ini adalah standar untuk memeriksa dan mempertahankan pemformatan kode.
Gofmt juga memiliki opsi -s yang sedikit diketahui, yang memungkinkan Anda untuk menyederhanakan ekspresi.
Goimport berisi semua yang mengandung gofmt, tetapi selain itu masih tahu cara mengatur ulang impor, menghapus dan menambahkan impor yang diperlukan.
Unindent adalah linter yang luar biasa yang dapat menurunkan level kode bersarang. Dalam hal ini, dia memberi tahu kita bahwa jika kita menggabungkan dua seandainya menjadi satu, maka kita akan turun satu tingkat di tingkat persarangan.
Mari kita pertimbangkan linter memeriksa kompleksitas kode. Yang paling keren dari mereka adalah gocyclo. Dia yang paling membosankan. Banyak yang membencinya. Dia memeriksa kompleksitas cyclomatic dari kode dan bersumpah ketika kompleksitas fungsi ini melebihi batas tertentu. Ambang dapat dikonfigurasi. Jika disederhanakan, kompleksitas siklomatik adalah jumlah if dalam kode. Di sini dia terlalu besar dan orang yang bersumpah.
Nakedret adalah linter yang bisa mengatakan bahwa Anda menggunakan return tanpa nilai dan pada saat yang sama Anda menggunakannya dalam fungsi yang terlalu panjang. Menurut panduan resmi, pengembalian seperti itu tidak disarankan.
Ada sekelompok gaya pengujian linter. Misalnya, gochecknoglobals memeriksa bahwa Anda tidak menggunakan variabel global. Tentu saja mereka tidak perlu digunakan.
Golint bersumpah pada variabel apiUrl yang sama. Kata url harus digunakan dalam huruf kapital. Karena singkatan ini.
Gochecknoinits memastikan bahwa Anda tidak menggunakan fungsi init. Fungsi init tidak boleh digunakan untuk alasan tertentu.
Gosip keren keren. Bagian dari staticheck atau megacheck. Di dalamnya sendiri terdapat sejumlah besar pola untuk menyederhanakan kode. Dalam hal ini, Anda mungkin memperhatikan bahwa strings.HasPrefix tidak diperlukan, karena strings.TrimPrefix sudah berisi pemeriksaan yang diperlukan, dan Anda dapat menghapus jika.
Goconst memeriksa bahwa Anda tidak memiliki string string duplikat dalam kode Anda yang dapat ditarik ke dalam konstanta. Jumlah pengulangan ini dapat dikonfigurasi. Dalam hal ini, dua.
Linter salah eja, yang memeriksa bahwa Anda tidak memiliki kesalahan ketik dalam kode di komentar. Dalam hal ini, slide berisi kesalahan ketik kata lain dalam teks komentar. Anda dapat menyesuaikan dialek bahasa Inggris: Amerika, Inggris.
Unconvert linter, yang memeriksa bahwa Anda tidak melakukan konversi yang tidak perlu. Dalam hal ini, variabel sudah tipe string. Tidak ada gunanya mengubahnya.
Sekarang mari kita lihat benang yang memeriksa kode yang tidak digunakan. Yang pertama adalah varcheck. Ia memeriksa variabel yang tidak digunakan.
Tidak terpakai dapat bersumpah di bidang struktur yang tidak digunakan.
Deadcode memberi tahu kami jika suatu tipe tidak digunakan.
Atau fungsinya tidak digunakan.
Unparam dapat melaporkan ketika argumen fungsi tidak digunakan di badan fungsi itu sendiri.
Ineffassign melaporkan ketika perubahan oleh variabel tidak digunakan lebih lanjut dalam kode. Ini adalah hasil dari semacam refactoring. Di suatu tempat mereka lupa membersihkan sesuatu, atau bug. Dalam contoh ini, jumlah bertambah. Selain itu, tidak digunakan lebih lanjut. Ini sangat mirip dengan bug.
Ada sekelompok kinerja pengujian linter. Sebagai contoh, difitnah memberitahu kita bahwa struktur testStruck yang diberikan dapat dikompres dalam ukuran dengan menata ulang bidang. Selain itu, jika Anda menjalankannya sebagai bagian dari golangci-lint, ia memiliki opsi yang memungkinkan Anda untuk segera mencetak urutan bidang yang diinginkan, agar tidak mengambilnya sendiri.
Ada gocritic linter yang keren. Dia memiliki banyak cek di dalamnya. Salah satunya adalahParam besar. Dia tahu cara melaporkan kepada kami tentang menyalin struktur data berat. Dalam hal ini, heavyStruct disalin oleh nilai dan kita hanya perlu meneruskannya sebagai pointer.
Prealloc dapat menemukan tempat di kode tempat kami dapat melakukan pra-penempatan slice. Dia menemukannya sehingga dia mencari di mana kita melakukan iterasi setiap jam pada slice. Dan di dalamnya urusan menambahkan. Dalam hal ini, Anda dapat pra-mengalokasikan variabel ret untuk panjang slice dan menghemat memori dan CPU.
Dan akhirnya, linter yang menemukan bug. Scopelint mungkin menemukan kesalahan paling sering untuk pemula adalah dengan menangkap variabel rentang loop dengan referensi. Dalam hal ini, variabel loop arg ditangkap oleh referensi. Pada iterasi berikutnya, sudah ada makna yang berbeda.
Periksa statis Dulu disebut megacheck. Sekarang telah diganti namanya. Karena itu, ada sedikit kebingungan di masyarakat. Staticcheck dapat menemukan banyak bug yang berbeda. Ini adalah hal yang sangat keren. Seperti dokter hewan. Salah satunya pada slide adalah perlombaan. Tentu saja, kita perlu menambahkan sinkronisasi. Tunggu Grup sebelum memasukkan goroutine.
Go vet menemukan sebagian besar bug. Dalam hal ini, variabel i dibandingkan sehingga hasilnya akan selalu benar. Karena itu, jelas ada bug. Secara umum, Anda harus selalu menggunakan dokter hewan.
Gosec adalah singkatan dari go security. Menemukan masalah keamanan potensial di Go. Dalam hal ini, data pengguna dapat tiba di arg. Oleh karena itu, ia dapat menyusup ke perintah shell rm. Dan di sini mungkin shell beraksi misalnya. Saya perhatikan bahwa go security sering kali menghasilkan false positive. Karena itu, saya terkadang mematikannya.
Errchek menemukan tempat di mana kami lupa memeriksa kesalahan. Gaya pemrograman yang baik dan aman selalu ada di mana-mana untuk memeriksa semua kesalahan.
Dua linter harus dicatat secara terpisah: staticcheck dan go-critic. Karena di dalam masing-masing berisi lusinan, jika bukan ratusan, cek. Karena itu, pastikan untuk mencobanya.
Sekarang kita telah memeriksa 25 contoh linter. Dan saya juga mengatakan bahwa kita memiliki lebih dari 50 linter di Go. Yang mana untuk digunakan? Saya menyarankan Anda untuk menggunakan semuanya dengan maksimal. Cukup masukkan semua linter yang Anda bisa. Kemudian habiskan satu jam dan mulai mematikannya satu per satu. Matikan yang tampaknya tidak penting bagi Anda. Misalnya, ia menemukan beberapa optimasi kinerja yang Anda tidak tertarik sama sekali. Anda akan menghabiskan satu jam dan membuat daftar linter untuk Anda sendiri dan Anda dapat hidup dengannya lebih jauh.
Katalog lengkap semua linter tersedia di tautan pada slide.
Mari kita bicara tentang cara menjalankan linter. Terkadang linter diluncurkan menggunakan makefile semacam itu. Masalahnya adalah lambat. Semuanya dijalankan secara berurutan.
Kita dapat melakukan eksekusi secara paralel melalui xargs -P. Ada juga masalah. Pertama, ini hanya 4 linter. Dan sudah 10 baris kode. Apa yang terjadi jika kita menghidupkan 20 linter. Kedua, paralelisasi ini adalah, secara halus, bukan yang paling optimal.
Gometalinter datang untuk menyelamatkan. Gometalinter adalah agregator linter sehingga dapat berjalan secara harfiah dalam beberapa perintah. Pada slide, perintah untuk meluncurkan linter yang sama mirip dengan slide sebelumnya. Tetapi mereka tidak perlu dipasang secara independen dan tidak perlu di-perdukakan dengan peluncuran paralel. Gometalinter sudah memparalelkan semua yang ada di bawah tenda. Tapi dia punya satu masalah mendasar. Dimulai setiap linter sebagai proses terpisah. Garpu dia. Jika kita menambah pengetahuan ini bahwa setiap linter di dalam dirinya menghabiskan 80 persen waktu untuk mengurai kode dan hanya 20 persen pada analisis itu sendiri, ternyata kita membuang 80 persen pekerjaan. Dan jangan menggunakan kembali data. Kita dapat menguraikan program 1 kali dan kemudian memberi makan 50 liter.
Untungnya, ada golangci-lint yang melakukan hal itu. Dia mem-parsing sekali. Jenis sekali. Analisis lebih lanjut dijalankan pada mereka. Karena ini, ia bekerja lebih cepat. Perintah peluncuran serupa pada slide.
Anda dapat melihat grafik di salah satu proyek saya 30 ribu baris kode. Proyek kecil dan hanya 4 liter. Anda dapat melihat ada perbedaan besar dalam kecepatan pekerjaan pada waktu, baik antara peluncuran berurutan, dan antara gometalinter dan golangci-lint. Jika serat ini bukan 4, tetapi 20, maka perbedaannya akan jauh lebih besar.
Klarifikasi penting tentang gometalinter. Sejak 7 April, penulis proyek gometalinter menyatakan itu sudah tidak berlaku lagi. Repositori telah diarsipkan dan semua orang disarankan untuk beralih ke golangci-lint, karena lebih cepat, ia memiliki lebih banyak barang di sana. Misalnya, dukungan untuk modul go dan sebagainya.
Dan di samping modul kinerja dan Go, golangci-lint memiliki roti seperti konfigurasi YAML, kemampuan untuk melewatkan peringatan, mengecualikannya, dan sebagainya.
Golangci-lint dikonfigurasikan menggunakan file golangci-lint.yaml. Contoh file ini dengan deskripsi semua opsi ada di tautan pada slide. Pertimbangkan, misalnya, bagian pengaturan linters. Di bagian ini kita akan mengonfigurasi konfigurasi. Ini memiliki opsi awalan lokal yang langka. Di dalamnya, Anda dapat menentukan jalur ke proyek saat ini. Dalam hal ini, misalnya, github.com/local/repo.
Ketika goimport melihat impor lokal di github.com/local/repo, itu akan memastikan bahwa mereka berada di bagian terpisah.
Sehingga mereka pada akhirnya. Sehingga mereka terpisah dari semua impor eksternal. Ini membuatnya lebih mudah untuk membedakan secara visual antara impor eksternal dan internal. Jika dia memperhatikan bahwa ini tidak benar, maka dia akan bersumpah.
Dan jika Anda juga menggunakan opsi runang-lint golangci-lint, maka golangci-lint akan memperbaikinya untuk Anda secara otomatis dan mengurutkan kembali impor.
Mari kita bicara tentang apa yang ada dalam daftar istilah golangci-lint. Linter dibagi menjadi cepat dan lambat. Yang cepat disebut cepat, ditandai dengan bendera cepat untuk membantu. Mereka berbeda dalam hal bahwa linter cepat memerlukan representasi program yang agak terbatas, misalnya, pohon AST dan beberapa jenis informasi. Sementara tembaga linters masih membutuhkan pengiriman SSA oleh program dan menggunakan kembali cache lebih sedikit. Hanya ada enam linter lambat. Mereka ditandai pada slide. Ada kasus-kasus tertentu ketika menjalankan hanya linter cepat.
Anda mungkin melihat perbedaan dalam kecepatan. Ini luar biasa tiga kali antara mulai cepat dan lambat. Sebenarnya lari golangci-lint - cepat hanya linters cepat yang diluncurkan.
Tentang membangun cache. Ada yang namanya membangun cache. Ini adalah cache yang dibangun oleh biner Go ketika mengkompilasi program ketika tipe dimuat, sehingga waktu berikutnya kompilasi ini lebih cepat. Cache yang sama digunakan kembali oleh linter untuk mengurai program untuk membangun informasi jenis. Anda mungkin memperhatikan bahwa jika Anda menghapus cache, awal baru pertama akan cukup lama. Dan yang berikutnya akan 3 kali lebih cepat. Perhatikan peluncuran linter pertama Anda pada proyek Anda. Itu akan selalu jauh lebih lambat.
Di sini Anda dapat menyimpulkan bahwa masuk akal dalam CI antara peluncuran CI untuk menggunakan kembali cache Anda. Anda tidak hanya akan mempercepat linters, Anda juga akan mempercepat tes yang berjalan, hanya mengkompilasi dan mungkin sesuatu yang lain. Saya menyarankan semua orang.
Saya tidak bisa bicara tentang analisis go. Ini adalah kerangka kerja baru yang telah muncul sejak Go 1.12. Ini menyatukan antarmuka sedemikian rupa sehingga linter menjadi mudah untuk ditulis, linter mudah digunakan, dijalankan. Go dokter hewan mulai 1,12 semuanya beralih sepenuhnya untuk analisis. Jelas, ini adalah masa depan. Itu akan sangat mengubah seluruh ekosistem Go. Tetapi untuk saat ini, umumnya cukup awal untuk membicarakannya. Jadi apa yang akan terjadi selanjutnya? Karena saya hanya melihat beberapa linter yang sedang dianalisis dan hampir tidak ada yang sudah beralih ke sana.
Jika Anda membuat kesimpulan singkat pada bagian bagaimana menjalankan linter, maka saya menyarankan semua orang untuk menggunakan golangci-lint. Anda akan dengan cepat menjalankan linter dengan nyaman. Anda tidak perlu dukun dengan instruksi, perintah lainnya.
Mari kita bicara tentang bagaimana menerapkan linter dalam proyek. Saya pikir ada orang yang mencoba memperkenalkan linter menghadapi masalah seperti itu. Di sini Anda memiliki proyek untuk sejuta baris kode dengan sejarah. Anda meyakinkan TeamLead untuk menerapkan linter. Luncurkan dan lihat satu juta pesan. Pahamilah bahwa Anda tidak punya waktu untuk duduk berminggu-minggu untuk memperbaikinya. Apa yang harus dilakukan Anda bisa menyerah dan menyerah. Atau Anda dapat menemukan sesuatu.
Pertama, opsi termudah, Anda dapat mencoba untuk mengecualikan beberapa komentar dari linter pada teks secara teratur menggunakan konfigurasi golangci-lint.yaml. Jika Anda melihat ada linter bersumpah pada komentar, tetapi Anda biasanya tidak peduli dengan komentar ini, Anda dapat menambahkan pengecualian.
Bisa dikecualikan. Misalnya, Anda memiliki direktori pihak ketiga dan kode Anda tidak ada di sana. Anda tidak perlu memeriksanya. Dapat dikecualikan dengan nama file.
Jika Anda tidak ingin mengecualikan seluruh file, Anda dapat mengecualikan fungsi dengan nolint sebelum fungsi. Untuk nolint, Anda dapat menentukan melalui titik dua daftar linters yang bertindak sebagai pengecualian. Atau tidak menentukan, maka semua linter akan diabaikan.
Kapan harus menggunakan nolint? Misalnya, saya menggunakan nolint: deepguard, yang dapat menangkap impor, yaitu Impor tidak dapat digunakan. Saya mengejutkan impor perpustakaan logrus agar tidak sengaja menggunakannya bukan logger yang saya inginkan. Tetapi dalam logger saya sendiri saya menggunakan logrus. Oleh karena itu, saya hanya perlu di satu tempat di proyek untuk membuat hanya satu file dari impor. Saya menandainya dengan nolint.
Misalkan Anda melakukan semua ini, tambahkan mengecualikan, nolkan imbuhan. . . . . main.go, 5 , 6 . ?
revgrep. Revgrep git , . . 6 origin master, . , 5 . . . . golangci-lint . . , . git hash commit. . . hash commit tag revgrep CI. . . . mail.ru, .
revgrep golangci-lint. --new-from-rev --new. .
. --new. 20 , . . . . . ? --new-from , . .
. golangci-lint . . . , .
Kami berbicara tentang pengenalan linter dalam proyek apa pun. Sekarang mari kita bicara tentang kenyamanan bekerja. Pertama, Anda perlu mencapai reproduktifitas dalam CI. Segera setelah Anda menambahkan linter ke CI, Anda harus stabil. Jangan pernah pergi. Karena tidak berversi. Linter berubah kapan saja, diperbarui, dan semua build CI Anda mulai gagal. Saya telah melihat ini puluhan kali. Selalu gunakan versi tertentu. Lebih baik dengan wget taruh. Dia akan lebih cepat. Selain itu, saya tidak merekomendasikan menggunakan opsi --- enable-all untuk linter, karena dalam satu hari Anda memperbarui golangci-lint, misalnya, Anda menambahkan 5 linter baru dan semua build Anda mulai gagal. Karena Anda secara tidak sengaja menyalakan linter ini. Lebih baik secara eksplisit meresepkan linter mana yang Anda masukkan.
Yang keren adalah pre-commit hook. Siapa yang menggunakan kait pra-komit mengangkat tangan Anda? Cukup kecil. Pre-commit hook adalah file git yang memungkinkan Anda untuk mengeksekusi kode arbitrer setelah Anda ingin melakukan. Tetapi sebelum komitmen ini berhasil. Jika kait pra-komit mengembalikan kesalahan, komit akan gagal. Biasanya nyaman untuk menanamkan tes cepat, analisis statis dan sebagainya. Saya menyarankan semua orang untuk menanamkan golangci-lint. Anda dapat melakukan ini secara manual melalui skrip shell. Itu dimungkinkan melalui utilitas pra-komit. Contoh cara mengatur slide. Menginstal pra-komit dengan pip, utilitas untuk menginstal paket Python. pip install pra-komit menginstal konfigurasi. Golangci-lint sudah mendukung integrasi dengan pre-commit.
Opsi - cepat. Kami kembali padanya. Saya menyarankan semua orang untuk menggunakannya dalam IDE. Secara umum, IDE, tentu saja, harus menggunakan integrasi dengan linter. Agar IDE Anda tidak membeku, pastikan untuk menggunakan opsi - fast.
Saya pikir ini cukup jelas. Dalam CI, linter perlu ditanamkan. Jika Anda tidak menanamkannya, maka akan ada gambar klasik: "mari kita palu sekarang, sekarang kita memiliki rilis, bukan sebelum itu." Secara bertahap Anda akan memiliki lebih banyak komentar. Anda hanya berhenti memandangi linter sebagai sebuah kelas. Oleh karena itu, ketat dalam CI. Selain itu, Anda dapat menginstal linters di CI, dengan build gagal, kami naik ke log build, mencari alasan jatuh di sana. Di mana komentar, di baris mana? Ini sangat tidak nyaman.
Ada cara yang lebih keren. Anda dapat membuat linter bertindak sebagai pribadi, sebagai peninjau. Mereka dapat mengomentari Anda di github.com, gitlab.com untuk serangkaian kode kesalahan pada permintaan Tarik Anda. Linter dapat menulis bahwa ia menemukan masalah. Ini sangat keren. Ini menghemat kode waktu penulis. Karena Anda tidak harus masuk ke build log. Ditambah lagi, seseorang dapat berkomentar jika dia tidak setuju dengan komentar si orang buta ini. Pada contoh di slide, ini dilakukan dengan menggunakan utilitas reviewdog. Opensource utilitas. Dia bebas. Anda dapat menginstal sendiri.
Selain reviewdog, ada juga proyek seperti GolangCI, Code Climate, Hound. Mereka memungkinkan Anda untuk menghubungkan linter ini hanya dengan satu klik ke opensouce Anda atau repositori pribadi dan mengomentari inline di Pull Request. Masih ada hal keren SonarQube.
Saya belum bisa menyebutkan kartu goreport. Proyek ini memungkinkan Anda untuk membuat laporan di repositori Anda. Mereka memberi nilai di sana, memberikan lencana, menulis seberapa bagus kode Anda untuk selusin bersih. Saya juga menyarankan.
Saya ingin Anda datang bekerja tepat pada hari Senin dan dapat menerapkan sesuatu dari apa yang saya katakan. Berikut ini ringkasan dari apa yang dapat Anda terapkan. Pertama instal golangci-lint. Nyalakan semua linter di sana. Lalu habiskan 1 jam. Selama jam ini, matikan semua linters yang tampak seperti delusi bagi Anda. Setelah itu, embed golangci-lint di CI, di IDE dan konfigurasikan kait pre-commit. Tepat setelah itu, Anda dapat mengonfigurasi --new-from-rev dan menunjukkan bahwa dari commit saat ini kami mencari bug. Dan semua bug sebelumnya akan diperbaiki nanti secara terpisah. Setelah itu, konfigurasikan dog reviewd secara opsional sehingga komentar Anda di github atau di gitlab masih tersedia. Anda akan meningkatkan kualitas proyek dengan ini dengan luar biasa. Menyenangkan seluruh tim.
Terima kasih atas perhatiannya. Kontak saya di slide.
Pertanyaan: Katakan padaku, apakah Anda memiliki file konfigurasi siap pakai yang Anda masukkan akses terbuka dan yang bisa Anda unduh dan gunakan agar tidak memahami banyak pengaturan golangci-lint? Apa yang Anda rekomendasikan.
Jawab: Ide bagus. Golangci-lint sendiri sudah memiliki golangci-lint.yaml sendiri, yang digunakannya. Anda dapat menggunakannya sebagai titik awal.
Pertanyaan: Pada slide tentang build cache, lihat cache untuk modul. Dalam cache Anda menentukan seluruh cache modul. Anda dapat menentukan .cache / unduhan maka akan ada perbedaan yang cukup besar: 400 megabyte dibandingkan 10. Ini cukup dengan mengekstrak modul-modulnya. Tetapi ini hanya jika modul digunakan.
Pertanyaan: Apakah Anda juga mendukung modul go atau dep atau masuk ke sesuatu dalam satu?
Jawab: Tidak perlu ada yang mendukung. Sekarang ada perpustakaan paket pergi. Dia terlibat dalam memuat kode sumber. Ini mendukung modul dan non-modul. Dia belum akan tetapi menghapus dukungan untuk non-modul.
Pertanyaan: Apakah Anda berencana membuat berbagai plugin untuk integrasi dengan tidak hanya Travis, tetapi juga dengan server otomatisasi lainnya?
Jawaban: golangci-lint tidak melakukan integrasi. Untuk menjalankan dalam CI, panggil saja golangci-lint --run.
Pertanyaan: Untuk menguraikan beberapa laporan, misalnya, di Jenkins, kami menyimpan file html.
Jawab: Ada format keluaran junit, csv, json xml. Semua ini sudah bisa diuraikan.
Pertanyaan: kami menggunakan gometalinter sebelumnya dan lambat. Kemudian kami beralih ke linter bernama menghidupkan kembali. Anda sama sekali tidak menyebutkannya. Dan untuk bagian saya, saya bukan ahli dalam topik sama sekali. Saya tidak tahu tentang keturunan Anda, yang Anda ceritakan. Bisakah Anda menulis di akhir katakanlah pro dari linter Anda atau pro of revive.
Jawaban: Revive adalah golint yang ditulis ulang. Ini hanyalah salah satu dari ini. Ada pengaturannya. Dia juga menambahkan beberapa linter, beberapa cek. Golangci-lint dengan sendirinya 30-50 linter. Ini menghidupkan kembali satu setengah linter. Revive keren karena dibutuhkan golint dan membuatnya sejajar. Bangkit kembali bekerja lebih cepat daripada golint. Tapi ini hanya satu linter. Revive dapat dijadikan bagian dari golangci-lint.
Pertanyaan: Anda memiliki slide dalam ulasan linters tentang gocritic: hugeParam, yang direkomendasikan untuk mentransfer struktur tebal dengan pointer. Tetapi ini akan mengarah pada fakta bahwa semua struktur ini akan dialokasikan secara eksklusif dalam HEAP. Dan apakah ini tidak akan menyebabkan masalah yang lebih besar daripada keuntungan? Jika struktur seperti itu, misalnya, ditransmisikan banyak.
Jawab: Saya sepenuhnya setuju. Anda seharusnya tidak menggunakan peringatan ini dan jangan hanya mengikuti mereka. Ini bisa seperti optimasi prematur, dapat membahayakan proyek. Saya biasanya mematikan kelas linters ini secara umum jika saya tidak memiliki kinerja tugas yang kritis. di mana saya menemukan kelemahan dengan profiler.
Pertanyaan: Saya dari Yandex. Kami menggunakan linter Anda di repositori besar. Kami perhatikan bahwa dia sudah mulai bekerja dengan sangat cepat untuk repositori besar. Hanya dalam beberapa hari, mereka menulis sebuah utilitas sederhana yang melalui paket go menemukan paket yang telah berubah sejak diperkenalkannya cabang dari wizard dan paket yang bergantung pada mereka. Dan jalankan linter hanya pada mereka. Dan pemeriksaan linter dipercepat beberapa kali.
Jawaban: Mungkin Anda akan membuat idssue, melampirkan naskah, dan sangat mungkin saya akan menanamkan semua ini di golangci-lint.
Pertanyaan: Apakah tingkat keseriusan yang direncanakan untuk komentar ditemukan sehingga beberapa dapat dimasukkan dalam laporan, tetapi tidak memalsukan proses CI? Misalnya melalui kode kelengkapan.
Jawaban: Banyak orang bertanya dan saya akan segera mengatakan kesulitannya adalah tingkat keseriusan ini mendukung mereka semua, ada 3 atau 4 dari 30 liter di sana. Apa yang harus dilakukan dengan baja? Tidak jelas. Penting untuk menguraikan komentar mereka secara manual, entah bagaimana menandainya. Tangani positif palsu. Ini biasanya merupakan pekerjaan besar. Saya tidak yakin apa yang akan dilakukan kapan. Ada cara lain untuk mencapai tujuan yang sama.
Pertanyaan: Ada artikel di hub Lebih tepatnya, serangkaian artikel tentang C ++ linter. Perusahaan mengembangkan bisnis ini. Mereka menghasilkan uang dari itu. Bahkan, karya mereka, atau lebih tepatnya seri publikasi ini, tidak lagi ditujukan untuk pengembang, tetapi lebih pada mereka yang mengelola pengembang. Ini pada dasarnya adalah kode murni, stylization. Ini adalah tugas kita, tetapi juga tugas pemimpin, pemimpin tim. Apakah Anda berencana untuk mempopulerkan garis media ini di sini, dalam sumber daya yang besar sehingga orang membacanya dan kemudian memperkenalkannya ke tim mereka? Dan bukankah kita mengetuk dari bawah.
Jawab: Saya punya rencana. Terima kasih untuk sarannya. Saya punya rencana untuk menulis artikel yang komprehensif seperti pidato ini, tetapi ada lebih detail dan luas sepanjang tahun. Mungkin saya akan menulis dalam bahasa Rusia dan Inggris.