Pada akhir 2018,
Frontend Panda-Meetup # 9 terjadi di Samara. Di acara ini, saya mencoba sendiri dalam peran baru dan membuat presentasi. Nama saya Evgeny Kholmov. Saya datang ke pemrograman lebih dari 10 tahun yang lalu, sebagai mahasiswa. Selama 5 tahun terakhir, saya telah mengembangkan sistem layanan jarak jauh di bank-bank besar Rusia, yang dua tahun sebagai manajer. Selama waktu ini, saya berpartisipasi dalam penciptaan beberapa aplikasi perusahaan Rusia terkemuka, melewati duri solusi arsitektur, integrasi dan proses yang berat. Berdasarkan pengalaman saya dalam mengembangkan beberapa bank Internet besar, saya memberi tahu para tamu mitap manfaat apa yang akan didapat dengan mengikuti aturan gaya yang baik dalam pengembangan. Tokoh-tokoh yang disuarakan mengesankan penonton. Peserta rapat benar-benar membuat saya kewalahan dengan pertanyaan. Ada kemungkinan bahwa di antara para pembaca Habré topik ini akan menemukan respons yang hidup.
Anda dapat menonton video presentasi saya di Youtube.
Dan untuk warga Khabrovsk, saya menyiapkan versi teks dari laporan saya.
Mempelajari masalah keterbacaan kode, saya menemukan StackOverflow pada topik yang aneh. Itu membahas betapa pentingnya kode yang bisa dibaca bisnis, dan apakah itu lebih penting daripada kinerja dan kebenaran. Akibatnya, menurut anggota masyarakat, kriteria yang paling penting adalah keterbacaan kode.
Pada saat itu, saya tidak tertarik dengan masalah keterbacaan kode - saya sedang mengembangkan bank Internet berikutnya. Frontend menggunakan HTML5, AngularJS, KURANG. Proyek ini dikembangkan untuk salah satu bank terbesar di Rusia. Saya beralih ke proyek ini dari Promsvyazbank, tempat saya mengembangkan bank Internet yang sangat mirip: segmen pelanggan yang sama, jumlah pengguna yang sama, tumpukan teknologi yang hampir sama (HTML5, AngularJS, SCSS). Tetapi, terlepas dari kesamaan proyek yang kuat, transisi bagi saya sangat sulit. Ini semua tentang gaya. Kode untuk proyek-proyek ini sangat berbeda dalam desain dan keterbacaan umum. Jika di Promsvyazbank pengembang secara ketat mengikuti pedoman, maka dalam proyek baru tidak ada aturan gaya yang jelas.
Saat itulah saya bisa memahami (dan bahkan menghitung) apa manfaat proyek besar membawa ke panduan gaya yang ketat. Setelah menganalisis biaya pengembangan proyek baru saya, saya sampai pada kesimpulan yang sama dengan pembaca StackOverflow: keterbacaan adalah kriteria yang paling penting.
Aturan gaya yang bagus
Untuk AngularJS dan Angular 2+, seorang ahli terkenal di dunia pengembangan frontend, John Papa, menciptakan panduan gaya yang menggambarkan aturan gaya yang baik ketika mengembangkan aplikasi Angular. Bekerja di Promsvyazbank, saya belajar tentang panduan gaya ini. Tim jelas mengikuti mereka di semua proyek. Tetapi pada proyek baru, kode berasal dari kontraktor yang tidak berpikir serius tentang gaya pemrograman. Dengan tim baru saya, saya menemukan tugas-tugas harian yang sebelumnya telah saya selesaikan. Namun, ini tidak memberi saya keuntungan apa pun, tetapi hanya rasa sakit dan penderitaan.
Kisah kehilangan waktu atau mengapa kita membutuhkan semua aturan ini
Panduan gaya John Papa mencantumkan banyak aturan. Berulang kali mendaftar mereka tidak masuk akal, mereka dengan sempurna ditetapkan dalam
sumber aslinya . Saya akan membatasi diri hanya pada beberapa contoh yang menunjukkan manfaat rekomendasi ahli dengan penuh warna.
Mari kita mulai dengan yang sederhana
Studi kasus. Pengguna bank Internet menampilkan nilai tukar yang tidak relevan. Saya diberi tugas memuat kursus saat ini pada saat operasi. Saya berharap melihat kode yang bertanggung jawab untuk memuat nilai tukar dalam layanan dan komponen. Tapi, tentu saja, dia tidak ada di sana (kalau tidak saya tidak akan menulis apa-apa). Ternyata nilai tukar diekstraksi dan difilter pada tingkat awal aplikasi, dalam file app.run, setelah itu mereka ditempatkan di Session Storage. Ini jelas bukan pendekatan terbaik. Selain itu, untuk menyelesaikan masalah, kode harus dikeluarkan dari sana. Butuh satu hari penuh untuk menyelesaikan tugas sederhana.
Sekarang, lihat aturan Bootstrapping (Gaya 02-05) dari panduan gaya.
Tempatkan kode yang melayani peluncuran aplikasi dalam file terpisah, dan jangan letakkan logika aplikasi dalam file ini. Logika harus ditempatkan dalam layanan dan komponen.
Juta contoh
Seperti yang Anda lihat di atas, mengabaikan satu aturan saja dapat menyebabkan masalah. Tetapi kita akan mendapatkan konsekuensi serius jika kita tidak mendengarkan beberapa rekomendasi sekaligus.
Studi kasus. Tim kami menerima tugas: untuk pembayaran perumahan dan layanan komunal, tambahkan kemungkinan termasuk jumlah asuransi sukarela dalam pembayaran. Pada bagian frontend, ini dirubah menjadi tugas sederhana: untuk menempatkan kotak centang pada formulir, yang dimasukkan yang akan menambah biaya asuransi ke jumlah pembayaran. Di Promsvyazbank, kami menangani tugas serupa dengan sangat cepat. Tetapi pada proyek baru, semuanya berjalan salah.
Karena fakta bahwa kode modul pembayaran sangat tidak berhasil diorganisasikan, keputusan itu berlangsung berbulan-bulan. Dalam mencari opsi yang paling cocok, kami menunda tugas ini beberapa kali dan mengambilnya lagi. Dan bank, sementara itu, mengalami kesulitan dengan pembayaran untuk perumahan dan layanan komunal. Pada akhirnya, kami, tentu saja, menangani masalah tersebut. Tapi saya bertanya-tanya berapa banyak kode yang buruk dapat merugikan sebuah organisasi dengan contoh tugas yang begitu sederhana. Saya menghitung berapa lama semua spesialis yang terlibat dalam menyelesaikan masalah yang dihabiskan untuk itu. Berbekal statistik rata-rata gaji. Saya menemukan dan mengumpulkan kerugian yang terkait. Sebagai hasilnya, saya sampai pada kesimpulan bahwa jika kami memiliki kode yang awalnya bagus dalam modul pembayaran, kami akan menghemat setidaknya 5 juta rubel.
Saat memeriksa panduan gaya John Papa, saya melihat bahwa modul kami melanggar beberapa aturan kode yang baik sekaligus. Setelah memperkirakan tingkat pengaruh masing-masing aturan ini, saya mengidentifikasi tiga, pelanggaran yang sebagian besar memperlambat pekerjaan kami:
- Rule of One - Saya menghapus 25% dari waktu yang hilang karena melanggar aturan ini;
- Tanggung jawab tunggal - penyimpangan dari prinsip ini berkontribusi terhadap kerugian keseluruhan 35%;
- LIFT - pelanggaran kelompok pendekatan ini, saya pikir 40% dari kita adalah orang yang paling melambat.
Aturan satu
Bank online kami mendukung banyak pembayaran, beberapa di antaranya dalam model mereka sangat berbeda satu sama lain. Namun demikian, para programmer mencoba membuat bentuk pembayaran "universal" yang dapat bekerja dengan semua opsi pembayaran.
Pada formulir itu sendiri, banyak blok berbeda dibuat, yang ditunjukkan dalam beberapa kondisi dan tidak pernah ditunjukkan di bawah yang lain. Pada saat yang sama, mereka dilayani oleh logika umum, yang sangat menggembungkan ViewModel'i.
Akibatnya, semua ini mengarah pada fakta bahwa jika sesuatu ditambahkan di satu tempat, pasti jatuh di tempat lain. Pada awalnya, ternyata pilihan kotak centang tidak mengubah jumlahnya. Kami mencoba memperbaiki bidang jumlah. Tetapi itu menjadi tidak dapat diedit pada semua jenis pembayaran lainnya. Kami mencoba mengganti bidang jumlah dengan yang baru. Tetapi logika validasi umum gagal: kotak centang berfungsi, tetapi tombol pembayaran tidak tersedia. Masuk ke situasi yang sama?
Sekarang mari kita lihat apa yang dikatakan aturan Aturan Satu.
Setiap elemen individu, seperti komponen atau layanan, harus ditempatkan dalam file terpisah. Anda perlu memastikan bahwa file tidak tumbuh. Jika jumlah baris kode melebihi angka ajaib 400, ini merupakan pertanda pasti bahwa komponen tersebut pantas dipatahkan.
Tanggung jawab tunggal
Ketika kami selesai dengan formulir itu sendiri, ternyata fungsi yang terletak di luar formulir berhenti bekerja. Misalnya, bekerja dengan pembayaran konsep telah rusak. Kesalahan muncul dalam sejarah operasi. Dan ini terjadi karena komponen lain di samping formulir pembayaran itu sendiri terikat pada model dan pengontrol pembayaran formulir. Lebih buruk lagi adalah kenyataan bahwa upaya untuk memperbaiki fungsi ini mengembalikan kami ke formulir pembayaran yang rusak.
Kami berurusan dengan kasus klasik pelanggaran Tanggung Jawab Tunggal. Prinsip ini telah lama dimasukkan dalam serangkaian programer pria yang berpengalaman. Dan panduan gayanya secara eksplisit merekomendasikan menggunakannya ketika mengembangkan aplikasi Angular.
Menerapkan prinsip tanggung jawab tunggal (SRP).
LIFT
Hal yang paling tidak nyaman yang harus saya tangani adalah menavigasi proyek itu sendiri. Logikanya tersebar di beberapa file, digabung menjadi hierarki pewarisan dan pendelegasian yang tidak bisa dipahami. Dari nama-nama file-file ini tujuan mereka sama sekali tidak mengikuti. File diletakkan di folder yang berbeda. Dalam beberapa folder, misalnya, Controllers, di antara puluhan file lain, sepanjang waktu saya harus mencari yang diperlukan saat ini. Jumlah tab terbuka di lingkungan pengembangan tidak muat di layar komputer dan di kepala saya. Selama debugging, mencapai komponen N ke akun, saya sudah lupa jalur apa dan mengapa saya datang ke sini. Dari waktu ke waktu, perlu untuk melakukan rekayasa balik penuh dengan debugger dihidupkan untuk menemukan di mana folder proyek file dengan fungsi spesifik apa pun berada. Akumulasi kebencian terhadap kode itu membuat matanya kabur dan mengalihkan perhatiannya dari pekerjaan.
Panduan gaya yang bijak juga mengetahui masalah ini. Untuk mengatasinya, grup aturan LIFT telah dibuat. LIFT adalah singkatan dari Locate, Identify, Flat, dan Try to be DRY. Menurut prinsip-prinsip LIFT, perlu untuk mengatur struktur proyek sedemikian rupa sehingga:
- jelas di mana harus menempatkan komponen baru dan di mana mencari yang sudah ada (Lokasi);
- jelas tujuan komponen dengan nama file (Identifikasi);
- itu mudah dinavigasi folder, gunakan struktur yang paling rata untuk mereka (Flat);
- Cobalah untuk tidak mengulangi kode Anda, tetapi tidak dengan mengorbankan aturan lain (Cobalah menjadi KERING).
Pendekatan LIFT dilengkapi dengan dua aturan lagi.
Pedoman struktural keseluruhan menawarkan untuk membuat folder untuk setiap komponen individu dan mengelompokkan semua file yang terkait dengan komponen ini di dalamnya. Misalnya, akan lebih mudah bila file payment-form.controller.js tidak ada di folder Controllers, tetapi di folder form pembayaran bersama dengan payment-form.html dan payment-form.css.
Struktur folder demi fitur merekomendasikan untuk membuat folder terpisah dengan nama yang sesuai untuk fitur dan bidang subjek proyek. Menurut aturan ini, folder bentuk pembayaran yang disebutkan di atas harus berada di folder pembayaran bersama dengan komponen lain yang diperlukan untuk bekerja dengan pembayaran.
Akibatnya, jika pembuat kode mengikuti aturan LIFT, struktur proyek akan terlihat seperti ini:
Setuju, opsi ini untuk mengatur kode jauh lebih nyaman bagi pembaca. Dan dia akan menghemat seluruh tim kami banyak waktu.
Pemrogram yang baik pergi ke bar
Saya berharap contoh-contoh di atas terdengar cukup meyakinkan sehingga pembaca, yang sebelumnya tidak memikirkan gaya pemrograman, akan memiliki keinginan untuk melihat ke dalam pedoman. Secara umum, kode yang dibaca dan dikelola dengan baik tidak hanya bermanfaat bagi anggaran proyek, tetapi juga programmer itu sendiri. Kode yang mudah dibaca lebih mudah ditinjau. Jika Anda membutuhkan bantuan rekan kerja, mereka akan dengan cepat memahami kode yang dapat dibaca. Jika Anda hanya seorang spesialis pemula, maka keterbacaan kode adalah hal pertama yang harus Anda kerjakan. Bahkan jika Anda menulis kode yang sangat benar dan dioptimalkan dengan sempurna, tetapi benar-benar tidak dapat dibaca dan tidak didukung, Anda tentu akan dihormati di tim, tetapi Anda tidak akan diundang ke bar setelah bekerja.
Jika teks ini membuat Anda memikirkan sesuatu atau mengingatkan sesuatu yang akrab, saya akan senang melihatnya di komentar di pos.