Gaya kode sebagai standar pengembangan

Ayo segera, ini bukan tentang kurung. Di sini kita akan berbicara tentang bagaimana otak kita bekerja dan mengapa gaya kode membantu memastikan pengembangan linier proyek, secara signifikan mempercepat adaptasi karyawan baru dan, secara umum, membentuk dan mendidik budaya pengembangan. Saya mencoba mengumpulkan dalam satu artikel beberapa studi dan prinsip kerja otak pengembang, dan bagaimana programmer membaca kode, dan juga berbagi hasil percobaan pribadi.

Menarik? Selamat datang di kucing.



Hai Nama saya Anton, saya menulis backend di ManyChat. Baru-baru ini kami memiliki mitap yang didedikasikan untuk pengembangan PHP, di mana saya memberikan ceramah tentang gaya kode sebagai salah satu standar pengembangan. Pada umpan balik, ia pergi dengan baik ke para tamu acara, dan kami memutuskan untuk mendekripsi laporan tentang Habr. Bagi mereka yang terutama menghargai efek kehadiran pribadi dan lebih suka menonton video daripada membaca teks, kami menyiarkan, yang tersedia sekarang. Anda dapat menemukannya di sini. Bagi mereka yang suka longrid, selamat datang lebih lanjut.

Otak kita adalah jaringan saraf

Layak dimulai dengan uraian tentang cara kerjanya secara umum dan mengapa Anda membutuhkan semua yang akan saya bicarakan nanti. Banyak dari Anda yang akrab dengan konsep jaringan saraf, atau paling tidak pernah mendengar ungkapan ini, yang selama beberapa tahun hampir menjadi simbol hype dalam ruang dan pemasaran TI. Bahkan sekarang, banyak perusahaan menambahkan "berbasis AI" ke produk mereka, seperti stiker "Non-GMO" pada pangsit. Jaringan saraf beroperasi pada prinsip pengenalan pola dan sangat efektif ketika bekerja dengan data homogen. Ini adalah gambar, video, suara, dll. Sorotan yang berkaitan dengan penataan kode adalah prinsip dasar pembuatan kode. Perceptrons, sel-sel jaringan, digambarkan sebagai proses otak dan diletakkan jauh sebelum mereka dapat diimplementasikan ke dalam jaringan yang fungsional, dapat bekerja dan efisien karena daya komputasi yang buruk. Otak kita, meskipun jauh lebih kuat, bekerja dengan cara yang sama. Akibatnya, seseorang menggunakan kekuatan jaringan saraf terlatih dari lahir sampai mati, dan pelatihan hampir mulus.

Jadi, kami hanya melihat gambar. Bagi otak, tidak ada teks, suara, dan hal-hal lain - kami memahami semua ini hanya setelah pembusukan. Secara kasar, kami memisahkan gambar "pixel demi pixel", menambahkannya ke memori, dan kemudian dengan bantuan pemikiran asosiatif kami mengenali berbagai objek. Berkat ini, kita dapat memahami apakah kita harus lari dari ular atau naik sepeda dan menekan pedal. Berikut adalah diagram perceptron standar, yang menggambarkan bagaimana klasifikasi objek terjadi. Bagi mereka yang tidak terbiasa dengan prinsip perceptron , mungkin terlihat sedikit kacau. Tetapi berkat skema keseimbangan dan penimbangan, jaringan saraf mengenali gambar dengan cepat dan efisien.



Dari pemrograman, Anda dapat mengingat prinsip DuckType, ketika diyakini bahwa jika sebuah objek berenang seperti bebek, terbang seperti bebek dan dukun seperti bebek, itu bebek. Perkiraan aneh dari deteksi objek. Dan bagi otak kita, pengenalan objek terjadi secara instan. Pelatihan adalah proses yang jauh lebih lama. Karena itu, Anda dapat membayangkan proses ini serta pelatihan seorang anak kecil yang hanya belajar kata-kata. Anda mengambil sebuah apel, tunjukkan dan katakan: "Ini adalah sebuah apel." Ambil yang lain dan ulangi lagi: "Ini apel."



Demikian seterusnya hingga hasilnya diperbaiki. Hijau, kuning, merah, bulat, memanjang, dengan dan tanpa stek, hitam dan putih. Tahun demi tahun, anak membangun basisnya berdasarkan pengetahuan empiris. Saya pikir prinsipnya jelas. Kami melakukan hal yang sama ketika melatih jaringan saraf. Dari objek ke objek atau, lebih tepatnya, dari gambar ke gambar.

Bagaimana seorang programmer membaca kode

Hal yang sama terjadi ketika kita bekerja dengan kode. Kami membuka halaman, mempelajarinya, menguraikannya menjadi blok, mengidentifikasi bagian yang berbeda - kami dengan mudah memisahkan properti dari fungsi, tingkat isolasi metode dan properti, menemukan konstanta dan sebagainya. Kami mengidentifikasi semua ini dengan blok, dan oleh karena itu, aspek penting dari penataan kode adalah untuk membawa seluruh kode ke bentuk yang sama. Ini adalah faktor kunci yang menjadi ciri pembacaan kode.

Mengapa ini penting? Karena sebagian besar waktunya, seorang programmer membaca kode. Beberapa korelasi langsung tidak ditemukan, sebagian besar tergantung pada kualifikasi, bahasa (misalnya, Python indentasi, dan kode terstruktur yang salah tidak akan berfungsi), kualitas kode, dll. Tetapi dari 50% waktu yang dibutuhkan untuk membaca kode Anda sendiri dan orang lain. Jika kodenya rumit, maka indikatornya bisa mencapai 75%, dan jika kodenya benar-benar buruk, maka 95% waktunya dapat dihabiskan untuk membaca dan mencoba mencari tahu di mana menambahkan satu baris untuk memperbaiki beberapa jenis cacat. Dan sekarang pertanyaannya. Apa yang akan Anda lakukan jika Anda melihat bahwa kode Anda menghabiskan 75% waktunya membaca disk atau mengalokasikan memori ke daftar yang ditautkan ganda? Programmer akan mencoba mengoptimalkan proses ini, mencoba mengubah algoritme, menerapkan struktur penyimpanan yang lebih efisien, dll. Karena itu, ketika waktu yang dihabiskan menjadi kritis, saya mulai memeriksa proses ini. Dan bisa dikatakan, itu otak, jauh lebih kuat daripada komputer mana pun dan dapat menyimpan sekitar satu petabyte data. Tapi, dalam proses mengembangkan kerangka mental saya untuk bekerja dengan kode (proses tersembunyi membentuk kebiasaan membaca kode), saya menemukan studi di mana sensor memonitor pergerakan mata dari programmer pemula dan berpengalaman. Ini terlihat seperti ini:
Pemula



Berpengalaman



Perhatikan apa yang dilakukan oleh programmer yang berpengalaman. Itu memilih blok kode, membusuk mereka, dan membacanya dalam blok, menyoroti bagian-bagian kunci dan menganalisis pekerjaan mereka. Pemula bergegas tentang baris demi baris, hanya mencoba memahami apa yang sedang terjadi di sini. Bagian terbesar dari waktu dihabiskan untuk menyusun gambaran besar dan membaca kode berlangsung dengan inspeksi silang yang konstan.

Video ini cukup lama, mulai 2012, dan rekaman itu ditujukan untuk mempelajari proses otak seorang programmer. Anda dapat membaca sedikit lebih banyak di sini dan di sini .

Sekarang adalah waktunya untuk kembali ke deskripsi operasi perceptrons. Ini adalah demonstrasi yang jelas dari pekerjaan jaringan saraf yang terlatih dan tidak terlatih. Berdasarkan basis pengetahuannya, seorang programmer berpengalaman mengikuti kode seperti juru bahasa, seringkali tanpa menyadarinya. Seseorang dapat mendekati solusi dari masalah ini dengan cara yang sama seperti kita mendekati masalah pelatihan jaringan saraf.

Ada 2 cara untuk mempercepat pembacaan kode:

1. Secara terus menerus membangun basis pengetahuan pengembang tentang bagaimana kode itu terlihat. Ini berarti pembelajaran terus menerus, yang secara konstan memperluas kekuatan jaringan.
2. Bawa semua kode ke satu standar, atur gaya kode yang sama

Tentu saja, sangat jelas bahwa metode pertama sangat padat karya. Dalam hal ini, programmer harus terus membaca repositori. Dan mengingat pergantian staf, munculnya teknologi dan praktik baru, ini menjadi hampir mustahil. Metode pengecualian tetap merupakan stylization dari kode, yang akan mengurangi pengaruh dekomposisi dan hanya meninggalkan pengaruh pada logika bisnis.

Jumlah Tuner Piano

Bayangkan bahwa tim yang terdiri dari 5 orang menulis, seperti yang mereka inginkan, untuk semua modul dan komponen sistem, terus-menerus menerima tugas yang tumpang tindih, menyesuaikan kode masing-masing. Berapa jumlah yang mungkin dari semua opsi untuk menulis suatu kondisi jika, mengingat bahwa setiap orang menulis dengan caranya sendiri? 5. Dan berapa banyak blok valid yang kita miliki? Semua konstruksi, panggilan fungsi argumen tunggal dan banyak argumen, ruang nama, kelas, sifat, antarmuka, penentuan posisi blok, statika, zona visibilitas, dll. Ini disediakan bahwa setiap orang hanya menggunakan 1 gaya penulisan, yang berbeda dari gaya orang lain. Dan jika seseorang berumur 10? Bagaimana dengan 50? Jelas bahwa dengan peningkatan jumlah orang, varians akan berkurang karena sejumlah cara untuk menulis blok yang sama. Dan ini adalah level pertama di mana kita tidak menginvestasikan salah satu masalah pemrograman utama - penamaan variabel. Efek pengganda dan semua kemungkinan kombinasi bahkan tidak diperhitungkan. Lemparkan di atas gaya pemisahan, lekukan pada spasi dan tab, suka jika mie, dll. dll. Dan spesialis baru terus berdatangan dan yang lama akan pergi. Sebagai hasilnya, Anda mendapatkan kode besar yang tidak dapat dibaca yang tidak mungkin digunakan dan tidak mungkin untuk mengembangkan jaringan saraf yang terlatih baik dari programmer di perusahaan.

Otak kita malas

Efek menarik lainnya dari prosesor sentral kami di tengkorak adalah persepsi yang sangat negatif dari informasi baru. Otak kita sangat malas. Dengan massa sekitar 1,5-2% dari total berat tubuh, otak mengonsumsi 25% dari seluruh energi tubuh. Salah satu operasi yang paling intensif sumber daya untuk otak adalah, adalah dan tetap menjadi konsentrasi perhatian. Anda dapat menjaga konsentrasi maksimum selama 20-25 menit (hai teknik Pomodoro), dan selama waktu ini otak akan melahap glukosa sebanyak yang akan melahap seluruh hari istirahat subyektif. Memproses data baru adalah proses yang sangat intensif sumber daya. Dan salah satu tujuan utama otak adalah menyelamatkan sumber daya yang sama ini. Ini karena karya model mental kita. Semacam pemblokir psikologis. Itu terlihat seperti ini. Anda mulai belajar sesuatu yang baru. Sesuatu yang baru sulit untuk diberikan dan karena kurangnya dinamika kemajuan yang nyata, harga diri Anda mulai menurun karena pemikiran "Aku bodoh!" Mengambang di latar belakang. Jiwa kita diatur sedemikian rupa sehingga seluruh sikap tergantung pada harga diri, dan pada sikap kita, pada gilirannya, tergantung pada keberhasilan kita di masyarakat. Dan agar tidak mematahkan lift sosial dasar pada dependensi adaptif, otak kita mulai menolak aktivitas yang mengurangi harga diri. Akibatnya, Anda ingin menonton serial TV, membaca habr, pergi minum kopi, duduk di sosial. jaringan, dll. Apa pun, hanya saja tidak mempelajari teori medan Landau. Atau perbaiki bug yang sulit direproduksi. Atau ... baca kode berkualitas rendah yang sulit diketahui. Sebuah contoh yang bagus tentang bagaimana otak berperilaku sesuai dengan batasan di area ini adalah orang-orang berusia sekitar 70-80 tahun yang point blank tidak ingin mempelajari smartphone atau 2 tombol pada robot vacuum cleaner. Sumber daya hampir habis. Otak mati-matian menghalangi proses belajar dan bertindak berdasarkan ibu jari. Ada banyak sumber daya ini saat Anda masih muda. Dengan berlalunya waktu dan tumbuh, mereka menjadi semakin dan semakin sedikit. Ini bekerja cukup linear. Untungnya, ini diimbangi dengan meningkatnya kekuatan jaringan saraf kita. Kecuali kita berbicara tentang degradasi yang ditargetkan langsung, tentu saja.

Beberapa stereotip

Kesalahpahaman umum yang mungkin pernah Anda dengar: “Yah, saya pro, saya bisa membaca kode apa pun. Saya menulis dengan cepat dan keren, memecahkan masalah perusahaan. Dan tidak masalah seperti apa kode saya jika itu memecahkan masalah. Sisanya tidak bisa mengetahuinya dengan cepat, saya tidak punya masalah dengan ini. " Jika Anda memiliki pembuat enkode di lingkungan Anda, Anda dapat memberitahunya: “Bung, saya punya berita buruk untuk Anda. Anda memengaruhi seluruh tim, dan pendekatan ini adalah alasan mengapa orang lain menulis lebih lambat ketika seorang programmer super efisien dengan cepat memaksa kode. "

Seorang programmer super efisien yang menulis tanpa memformat dan standardisasi sebenarnya sangat efisien dalam 2 hal:

• Super efisien menutup tugas tanpa masuk ke desain dan gaya.
• Sangat efisien untuk memperlambat semua orang, karena setelah penambahannya, orang sudah lama mencoba untuk memahami apa yang terjadi di sini.

Mengapa gaya kode diperlukan

Meskipun ini seharusnya sudah jelas, perlu untuk menekankan poin utama.
Gaya kode:

1. Menyediakan pengembangan linier proyek dan tidak mempengaruhi jumlah basis kode. Jika Anda telah memberikan penulisan historis kode yang dapat dimengerti, maka tidak peduli berapa banyak pengembang yang datang dan pergi, Anda selalu memiliki kualitas kode yang sama, yang memungkinkan proyek untuk tumbuh secara dinamis terlepas dari ukurannya.

2. Secara signifikan mempercepat proses adaptasi programmer baru. Jika kode Anda ditulis dengan jelas, seorang spesialis baru akan dengan cepat melatih jaringan sarafnya untuk mengidentifikasi blok dan mulai berguna. Ada titik swasembada karyawan. Ini adalah titik di mana karyawan mulai hanya membawa keuntungan. Dan jika kode ditulis dengan jelas, karyawan baru tidak perlu memahami logika bisnis, itu hanya akan belajar membaca kode Anda. Dan semakin cepat dia melakukannya, semakin cepat dia akan berhenti bertanya banyak pertanyaan kepada spesialis lain, mengambil waktu mereka. Dan waktu spesialis yang telah melewati titik impas jauh lebih mahal bagi tim dan perusahaan dalam hal nilai potensi produk yang dibawa.

3. Menghapus ketergantungan pada keterangan. Anda tidak perlu terus-menerus menemukan orisinalitas dan desain spesifik orang lain.

4. Minimalkan efek mental blocker ketika mempelajari kode baru. Otak Anda kurang tahan karena tidak perlu mempelajari gaya orang lain. Sumber daya mental untuk membaca kode yang jelas membutuhkan lebih sedikit.

5. Meminimalkan kerugian reputasi. Segera, setelah tiba di sebuah perusahaan baru, programmer akan mulai membagikan kesan-kesannya dengan mantan kolega dan teman. Dan dia akan mengatakan bahwa semuanya keren di sini, atau dia akan menyoroti aspek negatif dalam bekerja dengan kode. Dalam arti tertentu, ini memberi Anda bonus SDM: jika Anda ingin programmer keren bekerja bersama Anda, buatlah proyek yang bagus. Meskipun ini tidak selalu penting, dan di beberapa perusahaan mereka tidak melihat kualitas kode pada prinsipnya, tetapi hanya melihat pengiriman fitur ke penjualan, ini adalah bonus yang bagus. Bukan rahasia lagi bahwa alasan sering pergi adalah kelelahan karena pemotongan konstan dari basis kode berkualitas rendah.

6. Membentuk dan menumbuhkan budaya pembangunan. Tugas programmer berada pada level yang lebih rendah dari masa depan seluruh perusahaan, tetapi penting untuk menyampaikan pemahaman bahwa kelengkapan dan keterbacaan kode sekarang memengaruhi dinamika pengembangan lebih lanjut. Jika kode itu sulit dibaca dan tidak terstandarisasi, dapat di-refactored dan diskalakan dengan rasa sakit dan penderitaan, maka dengan pertumbuhan basis kode proyek, kecepatan pengembangan akan turun. Semakin rendah kualitas kode, semakin sulit untuk menulis yang baru, semakin lambat suatu produk berkembang, semakin sulit bagi perusahaan untuk tumbuh dan semakin sulit bagi Anda untuk membayar lebih banyak uang, karena banyak uang dihabiskan untuk menyediakan siklus hidup proyek dengan karyawan baru dan baru, yang merupakan faktor utama mereka menggunakan waktu bukan untuk memberi manfaat bagi perusahaan, tetapi pada klasifikasi obat-obatan yang menjadi dasar penulisan kode ini.

Kode sempurna

Kita semua mengerti bahwa itu tidak ada. Dari sudut pandang gaya kode kanonik adalah konsep desain kode. Dan semua akan baik-baik saja jika itu benar. Dalam pengembangan gaya kode jarak jauh konsep lebih luas, yang mencakup prinsip-prinsip pengembangan. Pemecahan kode menjadi blok yang terisolasi secara logis di kelas atau file juga mengacu pada desain. Penamaan, tingkat isolasi, warisan. Semua alat ini tidak hanya interaksi, tetapi juga desain mekanisme kompleks Anda, di mana setiap bata berperan.

Konsep berubah dari bahasa ke bahasa. Tulisan-tulisan khusus mengemuka. Namun fondasinya tetap tidak berubah. Kode kualitas ditentukan oleh hanya dua kriteria:

• Kode bersifat anonim
• Kode dibaca seperti buku

Kode anonim

Keadaan ideal yang Anda perlukan dalam proses ini disebut kode anonim. Saya yakin banyak dari Anda, setelah membuka draft kerja dan komponen acak, dapat mengatakan tanpa hambatan yang mana dari rekan-rekan yang menulis ini. Setiap orang sering memiliki gaya. Seseorang suka mie dari jika, seseorang dengan dan tanpa muncul lambda, seseorang suka mengurangi variabel untuk menghemat satu karakter. Dalam kode anonim, Anda tidak dapat melakukan ini. Dalam kode depersonalisasi yang ideal, tidak mungkin mengidentifikasi penulis. Dan ini adalah kasus ketika Anda sampai pada titik akhir dari gaya kode Anda.

Keterbacaan Tingkat Buku

Ingat 2 masalah pemrograman utama? Validasi cache dan penamaan variabel. Kami akan melewati masa lalu yang gelap dari proses cache dan langsung menuju kesakitan kami. Penamaan variabel, kelas, objek, file, metode, konstanta, dan sebagainya. Masalah ini memiliki 2 ekstrem. Nama terlalu pendek dan terlalu panjang. Akal sehat memberi tahu kita bahwa logika ada di suatu tempat dekat, dekat tengah. Di sini programmer super efisien mengetuk pintu kami dan memberi tahu kami bahwa mereka tidak peduli. Tetapi mengapa kita berteori tentang ini? Katakan padaku apa yang dilakukan kode ini?



Dan yang ini?



Kode kedua dibaca secara langsung dan mudah. Tidak perlu benar-benar memahami logika bisnis untuk memahami beban fungsional dengan penamaan tersebut. Dalam contoh ini, kami hanya mengambil seluruh repositori, lalu menggunakan pembuat untuk membuat koleksi, lalu menerapkan filter. Anda bahkan tidak perlu mempelajari kode untuk memahami apa yang terjadi. Seperti membaca buku tentang berita utama. Namun penamaan bukanlah segalanya.

Pola desain

Anda ditanya tentang pola desain di hampir setiap wawancara. Tujuan publik mereka adalah solusi arsitektur yang berulang. Efek sampingnya adalah prediktabilitas dan konsistensi. Saat Anda beralih ke arsitektur berdasarkan pola desain, Anda membentuk sistem yang cukup dapat diprediksi. Yaitu berdasarkan nama, Anda dengan mudah memahami tujuan kelas atau objek. Apa yang dilakukan pola Repositori? Ini adalah tampilan repositori dengan metode akuisisi data. Apa yang dilakukan pola pembangun? Merakit objek atau struktur yang kompleks. Dan di semua lini.

Ada pola seperti Command. Apa yang bisa dilakukan dengan itu? Tentu saja, jalankan saja! Anda tidak perlu mempelajari apa yang ada di dalamnya. Jelas itu bisa dilakukan. Pola desain membantu Anda memahami cara kerja proyek Anda. Jika Anda menulis semuanya dengan baik, Anda tidak akan bertanya-tanya: "Apa yang ada di direktori saya?" Dengan namanya Anda dapat dengan mudah menentukan apa dan di mana lokasinya.

Anggap saja begitu. Semua keputusan pada pola desain dibentuk, dengan menanggung rasa sakit pengembang pada masalah tertentu. Rasa sakit ini sudah dialami oleh seseorang, dibingkai dan mendapat solusinya dalam bentuk salah satu model arsitektur yang ada. Selain itu, semua ini dibentuk di atas SOLID terkenal.

PADAT

SOLID adalah akronim dari lima prinsip pemrograman berorientasi objek. Catatan: 5 prinsip. Berorientasi objek. Pemrograman Ini bukan praktik. Ini bukan rekomendasi. Ini bukan keinginan beberapa programmer lama untuk mengajar anak muda. , SOLID — . SOLID, 6 , , SOLID — . , , . — . , , : , , . . , .

? ? . , . code style, , SOLID. . . . — -. Yaitu , , , , , , . , .

, code style community . , , , , . , . , . , . , .

code style? ! . , . , . . - open-source based . , PSR , - . symfony2 code style, PSR . , , PHP. , , .

?

, , ? — , , CodeStyle , . , PHPStorm , phpcs codestyle — . , . , , , .

, (), . , ? . . , . 2 Google Sheets . 23% . , 7 , , 20 . . , 20 . 21% . , , .

, , , , 90% , . ? Middle PHP Developer . onboarding , 3-. … - . . onboarding -, , . , 1- Junior PHP Developer. « » . success story.

, , , 25%, onboarding' ⅔. « » , . , . , , , phpstorm Sonar Light.

— , Senior , , . , , . Senior QA Engineer .

, 21-27%. , , - . , 5%, 5 ( , ), 5 69 . , 14 840 – 40 /. phpcs phpstorm? , 50 .

PS: , , ManyChat, .