Tentang linter, kualitas kode, kualitas dalam manajemen umum dan kualitas

Takut dengan keinginan Anda, mereka mungkin menjadi kenyataan.
Kebijaksanaan rakyat.

Satu pasangan ingin menikah dan menemukan kebahagiaan abadi. Saya meledakkan mobil mereka di gereja segera setelah pernikahan.
One Wish Grant, film Rute 60.



Catatan filosofis lain tentang manajemen, dan dalam hal ini kualitas, terdiri dari tiga bagian: sangat abstrak, cukup abstrak, konkret dan kesimpulan terpisah. Ini mengkritik praktik saat menggunakan linter.

Bagian yang sangat abstrak tentang kualitas

Pertama, saya ingin berbicara tentang kualitas, atau lebih tepatnya tentang manajemen kualitas apa pun, tentang produk dalam arti luas, produk sebagai hasil dari aktivitas manusia, apakah itu menciptakan yang baru (menulis kode atau gambar, merancang pesawat ruang angkasa), memotong kelebihan (patung) , penggilingan, pemilihan buah yang baik), atau transformasi (transportasi, pembekuan, pengemasan, produksi bensin dan plastik dari gas).

Produk yang baik memiliki beberapa tanda bahwa itu berkualitas tinggi. Produk yang berbeda memiliki tanda yang berbeda pula. Misalnya, buah-buahan yang baik wangi, enak, enak.

Sekarang saya akan memberikan contoh hiperbolik, dan nanti saya akan langsung ke kode.

Bayangkan kita memiliki toko buah dan ada masalah, buah kita mulai laku lebih buruk, dan pesaing memiliki saluran langsung. Kami melakukan penelitian dan mengetahui bahwa bau di dekat konter kami tidak menyenangkan bagi pengunjung. Dan bau di toko-toko pesaing seperti. Oh, kami menemukan masalah, indeks kepuasan pengunjung berdasarkan aroma! Mari kita selesaikan, ada pemasaran aromaterapi, kami hanya akan menempatkan instalasi otomatis di dekat rak dan mendapatkan aroma yang indah dari kebun apel. Mereka berhasil. Dan indeks kepuasan pelanggan berdasarkan bau secara alami meningkat. Hanya sekarang ada lebih sedikit pembeli.

Jika Anda terlihat serius, masalah aslinya bisa sangat berbeda:

1. Pesaing kami menjual buah-buahan berkualitas tinggi yang sama, tetapi mereka melakukan pemasaran aromatik di hadapan kami dan menarik pengunjung dengan aroma tersebut.
2. Buah-buahan kita baik, tetapi buah-buah pesaing benar-benar lebih baik daripada buah kita (varietas, penyimpanan, apa pun)
3. Buah kita busuk. Mereka membusuk dan bau.
4. Buah-buahan dari tahun lalu, yang berada di belakang etalase, busuk, dan kami berharap kami masih bisa menjualnya. Dan mereka bau dari sana.
5. Pesaing memiliki lebih banyak koleksi
6. Pesaing lebih cantik meletakkan buah-buahan mereka, secara umum, sama seperti kita.
7. Jauh lebih murah di sana
8. Di sana, penjual itu indah, dan di tempat kami Baba Manya datang untuk menggantikan ...

Jelas, hanya dalam kasus pertama pemasaran aromatik akan membantu kami. Dalam beberapa hal itu bisa membantu, tetapi bisa menutupi masalah yang sebenarnya, tetapi yang ketiga itu tidak akan mengambil tindakan atau menyebabkan lebih jijik. Dan oh, seberapa sering masalahnya adalah buahnya busuk.

Bahkan, ketika masalah seperti itu muncul, perlu untuk menganalisis penyebab secara komprehensif dan dalam setiap kasus membuat keputusan khusus kasus.

Bahkan lebih hiperbolik

Anda memiliki tomat hijau, dan Anda tahu hanya tomat merah yang dijual. Tidak perlu melukis tomat. Adalah baik bahwa Anda dapat mempercepat pemasakan dengan etilena . Dan itu akan menjadi matang penuh, bukan melukis. Jika tidak mungkin untuk mempercepat, maka akan perlu untuk membuang tomat ini dan mendapatkan yang baru, sudah bagus.

Dengan kata lain, jika Anda tidak puas dengan kualitas produk yang dihasilkan, maka ada masalah dalam rantai produksinya dan Anda perlu menganalisis dan mengubah proses, dan tidak mengecatnya pada output.

Nah, Anda mengerti intinya. Jika sesuatu berbau tidak sedap, parfum tidak akan membantu.

Bagian abstrak tentang kualitas kode

Di antara sifat-sifat kode yang baik, kita akan menemukan (tanpa memilah berdasarkan kepentingan):

• konsistensi gaya
• keterbacaan
• kinerja
• diperpanjang
• transparansi arsitektur dan pola.

Ini dicapai terutama melalui disiplin diri dan tingkat keterampilan pengembang, serta ketika ada banyak pengembang, melalui perjanjian gaya kode dan perjanjian arsitektur (MVC, MVVM, ECS, ribuan dari mereka). Kode berkualitas tinggi muncul jauh lebih awal daripada linter, setiap konvensi dan pola arsitektur.
Sebagian besar aturan linter adalah murni kosmetik dan menyelesaikan masalah peningkatan keterbacaan kode karena penerapan yang seragam dari praktik kecil dan lokal. Panjang garis di sana, nama-nama variabel, konst di mana pun tidak ada modifikasi, kadang-kadang bahkan pembatasan diperkenalkan pada kompleksitas fungsi siklomatik. Ini bukan tentang aturan khusus, tetapi tentang fakta bahwa aturan ini umumnya kosmetik, mereka membantu kode terlihat lebih baik. Kata kuncinya di sini adalah melihat .

Ketika indikator apa pun mulai digunakan sebagai tujuan, itu kehilangan nilainya sebagai alat.
Interpretasi bebas dari hukum Goodhart .

Sekarang mari kita menggambar analogi dengan tomat. Kami belum cukup dewasa. Linter otomatis akan memberi tahu kita: "Lihat di sini dan tidak ada warna yang tepat." Apa yang akan dilakukan programmer? Sangat sering dilukis. Dan ini adalah ide utama kritik saya terhadap linter. Sekarang saya akan memberikan contoh nyata, dan kemudian menarik kesimpulan.

Spesifik

PixiJS 2 Februari 2018 (setahun yang lalu).

Kumpulan permintaan tiba . Intinya adalah bahwa sebelumnya jumlah titik yang konstan digunakan untuk menggambar kurva, yang jelas tidak optimal. Diusulkan untuk menggunakan algoritma licik untuk memperkirakan panjang kurva. Algoritma ini bukan ilmu roket, tapi jelas tidak jelas, diterbitkan pada 2013 dan dikutip dengan artikel oleh penulisnya (ada masalah dengan https). Kebahagiaan yang umumnya dia pertahankan di halaman pribadinya.

Ada kode C (16 baris):

float blen(v* p0, v* p1, v* p2) { va,b; ax = p0->x - 2*p1->x + p2->x; ay = p0->y - 2*p1->y + p2->y; bx = 2*p1->x - 2*p0->x; by = 2*p1->y - 2*p0->y; float A = 4*(ax*ax + ay*ay); float B = 4*(ax*bx + ay*by); float C = bx*bx + by*by; float Sabc = 2*sqrt(A+B+C); float A_2 = sqrt(A); float A_32 = 2*A*A_2; float C_2 = 2*sqrt(C); float BA = B/A_2; return ( A_32*Sabc + A_2*B*(Sabc-C_2) + (4*C*AB*B)*log( (2*A_2+BA+Sabc)/(BA+C_2) ) )/(4*A_32); }; 

Dan kode berikut (JS) dikirim ke kumpulan permintaan:

 /** * Calculate length of quadratic curve * @see {@link http://www.malczak.linuxpl.com/blog/quadratic-bezier-curve-length/} * for the detailed explanation of math behind this. * * @private * @param {number} fromX - x-coordinate of curve start point * @param {number} fromY - y-coordinate of curve start point * @param {number} cpX - x-coordinate of curve control point * @param {number} cpY - y-coordinate of curve control point * @param {number} toX - x-coordinate of curve end point * @param {number} toY - y-coordinate of curve end point * @return {number} Length of quadratic curve */ _quadraticCurveLength(fromX, fromY, cpX, cpY, toX, toY) { const ax = fromX - ((2.0 * cpX) + toX); const ay = fromY - ((2.0 * cpY) + toY); const bx = 2.0 * ((cpX - 2.0) * fromX); const by = 2.0 * ((cpY - 2.0) * fromY); const a = 4.0 * ((ax * ax) + (ay * ay)); const b = 4.0 * ((ax * bx) + (ay * by)); const c = (bx * bx) + (by * by); const s = 2.0 * Math.sqrt(a + b + c); const a2 = Math.sqrt(a); const a32 = 2.0 * a * a2; const c2 = 2.0 * Math.sqrt(c); const ba = b / a2; return ( (a32 * s) + (a2 * b * (s - c2)) + ( ((4.0 * c * a) - (b * b)) * Math.log(((2.0 * a2) + ba + s) / (ba + c2)) ) ) / (4.0 * a32); } 

Kode dirancang sesuai sepenuhnya dengan pengaturan linter. Deskripsi semua parameter ditunjukkan, tautan ke algoritme asli, sekelompok konstanta, sesuai dengan persyaratan linter tanpa operator campuran: 1 tanda kurung disusun. Bahkan untuk kinerja, api dilakukan tidak secara objektif, tetapi dengan parameter terpisah, jadi biasanya biasanya lebih baik di JS.
Ada satu masalah. Kode ini membuat sampah lengkap. (Upaya untuk menandai ekspresi kacau di Rusia, yang cukup digunakan dalam publikasi Barat untuk mengekspresikan tingkat masalah dan tampaknya sesuai).


Panjang yang sangat besar kembali, dan banyak titik menonjol di atasnya, ada baiknya ada batasan dari atas, di sana itu berhasil. Sebelumnya, mode ini dinonaktifkan secara default, tetapi kemudian dihidupkan untuk semua orang (karena bug lain). Perbaikan sudah diinjak-injak . Saya tidak menghubungi penulis komit dan tidak bertanya kepadanya mengapa ia memutuskan untuk memasang kurung, tetapi saya merasa bahwa ia meluncurkan linter, file konfigurasi yang sudah ada di PixiJS. Linter ini memberitahunya, kode Anda buruk, karena tidak memiliki tanda kurung, tambahkan tanda kurung. Opsi "no-campur-operator" mengatakan bahwa Anda tidak memiliki hak untuk menulis

 2*2+2*2 

karena dapat menyebabkan keterbacaan yang buruk. Seseorang membuat opsi ini, kemudian seseorang memasukkannya ke dalam proyek, yang berarti bahwa banyak orang menganggapnya berguna.

Kesimpulan

Saya tidak ingin mengatakan bahwa orang jahat itu jahat, tetapi saya menganggap ini sebagai kejahatan. Kami (dalam arti kemanusiaan) mampu mengotomatisasi deteksi hanya sebagian kecil dari tanda-tanda kode yang baik, terutama kosmetik seperti tanda kurung. Linter sangat baik sebagai alat untuk menganalisis kualitas kode, tetapi segera setelah kami meningkatkan kepatuhan dengan persyaratan linter ke kerangka persyaratan wajib, kami mendapatkan kepatuhan ini. Kami hanya mendapatkan kepatuhan. Ini adalah cara meletakkan kamera di konveyor dengan tomat dan mengirim untuk mengecat semua yang tidak cukup merah. Sampai kami memberi pengembang alat untuk menilai kualitas tampilan kode, dia bisa mengirim kode yang buruk, dan kami bisa melihatnya. Sekarang kode yang buruk akan lebih baik disamarkan. Ini akan meniru yang bagus, karena ada semua tanda-tanda eksternal dari kode yang baik di atasnya. Dan kita akan kehilangan linter sebagai alat evaluasi, karena semua kode konsisten. Kami memiliki alat penilaian, tetapi sekarang tidak ada di sana, tetapi kode dengan tanda kurung, meskipun kadang-kadang tidak ada, tetapi ini adalah rinciannya. Secara total, saya menganggap linter sebagai alat yang keren, tetapi hanya jika kepatuhan dengan persyaratan tidak menjadi tujuan .

Dan ya, di sini kita dapat mengatakan bahwa tidak ada tes, bahwa Anda tidak perlu menyalin-menempelkan kode, bahwa ini adalah pengembangan stackOverflow, bahwa Anda tidak memasukkan kode dalam proyek yang tidak Anda mengerti. Itu saja ya. Dan ini pertanda kode buruk. Tetapi linter membantu membuatnya secara visual mirip dengan segala hal lain dalam proyek. Tetapi linter tidak akan pernah memeriksa apakah Anda memahami apa yang Anda tulis dengan baik.

Dengan kata lain, saya percaya bahwa penggunaan linter yang benar adalah dengan meluncurkannya secara rutin sebagai petunjuk dan mengevaluasi bagaimana dan apa yang terjadi. Nah, aturan seperti lebih banyak kurung untuk dewa kurung, pada prinsipnya, saya anggap berbahaya. Ketika kita melihat bahwa seseorang melakukan kode dengan kualitas buruk, ada baiknya memahami mengapa dia melakukan ini dan menyelesaikan masalah ini di tingkat yang lebih dalam. Secara alami, Anda tidak perlu memformat kode dengan tangan Anda; Saya menyambut autoformers dengan segala cara yang mungkin, tetapi sampai mereka menyentuh bagian semantik dari kode dengan cara apa pun. Jika kita memaksa orang tersebut untuk membawa kode ke standar dengan linter, maka pada dasarnya kita akan mengecat tomat hijau dengan warna merah. Dan akan lebih sulit untuk memahami bahwa itu sebenarnya hijau. Apa yang harus dilakukan dalam proyek sumber terbuka dengan sekelompok orang yang berbeda, pertanyaannya lebih rumit, tetapi bahkan di sini Anda mungkin berpikir apa yang harus dilakukan.

Perlu dikatakan bahwa sikap saya terhadap linter dibentuk sejak lama, lebih dari tiga tahun yang lalu, tetapi saya tidak dapat menemukan contoh yang cocok dalam praktik ketika linter memainkan lelucon yang kejam. Jadi saya menemukannya. Fakta bahwa saya telah mencarinya begitu lama mengatakan bahwa masalahnya bukan skala besar, atau betapa sulitnya untuk melihat efek negatifnya, tetapi saya pikir artikel ini akan bermanfaat. Ingat, linter adalah alat, dan seperti alat apa pun itu dapat digunakan untuk merugikan dan untuk kebaikan, dan bagaimana Anda kadang-kadang dapat memotong diri sendiri dengan alat apa pun.