🎢 🎀 🤼 Pengembangan frontend di perusahaan: apa itu dan bagaimana membuatnya efektif 🙆🏼 🤘 🙋🏾

Kami di KORUS Consulting CIS telah mengatur pengembangan layanan web untuk pelanggan kami selama lebih dari sepuluh tahun. Kami sudah memiliki beberapa lusin proyek serius di sektor perbankan, beberapa di antaranya telah menerima pengakuan internasional.

Selama dua tahun terakhir, jumlah tim dan proyek di perusahaan kami telah meningkat beberapa kali, sementara efektivitas pengembangan frontend juga telah meningkat berkali-kali. Kami belajar cara membuat aplikasi dalam beberapa minggu, bukan beberapa bulan.

Kami terus-menerus bekerja pada pengembangan infrastruktur pengembangan front-end kami, dan hari ini saya akan membagikan beberapa perkembangan pada organisasi departemen front-end, yang mungkin berguna bagi mereka yang mengatur front-end di perusahaan mereka.

Dalam artikel ini, Anda akan belajar tentang jalan kami untuk menjawab pertanyaan-pertanyaan berikut:

, ;
, ;
;
;
;
.

Bagian depan dari suatu situs atau aplikasi adalah apa yang Anda lihat di browser Anda, bagian ini secara aktif berinteraksi dengan bagian server (backend), yang terletak di server mana saja, terus-menerus bertukar data dengannya.

Dari sudut pandang teknis, ujung depan aplikasi adalah sekumpulan file, di antaranya ada file HTML, CSS dan JavaScript, gambar, dll. Bekerja dengan CSS dan HTML terkait dengan pengaturan huruf, JavaScript - hingga pemrograman. Kedua area ini menawarkan sejumlah besar alat dan teknologi untuk bekerja, secara aktif berkembang dan membutuhkan banyak pengetahuan. Ini terutama berlaku untuk JavaScript, yang telah menulis sejumlah besar kerangka kerja dan pustaka untuk pembuatan aplikasi web yang "lebih dan lebih efisien".

Entah bagaimana saya ditanya tentang apa yang sekarang saya perlukan untuk membuat aplikasi agar tidak menjadi usang selama beberapa tahun lagi?

Sebagai seorang programmer, saya dapat memberikan jawaban yang benar-benar akurat dan sama sekali tidak berguna: HTML, CSS dan JavaScript. Apa sebenarnya yang harus dipilih, jQuery, Angular, atau Bereaksi - ini adalah detailnya.

Jika Anda mempelajari rincian ini, Anda dapat memberikan jawaban yang sama benar dan tidak berguna: pada apa pun. Ya ini benar. Aplikasi dapat ditulis pada apa saja, itu akan berfungsi, dapat diubah dan dikembangkan.

Apa bedanya?

Untuk menemukan jawabannya, mari kita lihat apa yang diinginkan bisnis dari ujung depan. Saya pikir saya tidak akan mengejutkan siapa pun jika saya mengatakan bahwa bisnis ingin mendapatkan hasil berkualitas tinggi dengan cepat dan murah.

Jadi, apa yang perlu Anda lakukan aplikasi sekarang, sehingga pengembangan berjalan cepat, efisien dan tidak merusak pelanggan?

Kecepatan pengembangan

Seorang programmer dengan pengalaman luas dengan React akan dapat dengan cepat menulis aplikasi di React, memiliki pengalaman dengan Angular memberikan kecepatan bekerja dengan Angular, dan sebagainya. Semuanya cukup jelas. Kerangka kerja itu sendiri menghemat waktu pengembangan dengan memberikan solusi untuk masalah dan tugas umum. Intinya, solusi ini bisa sangat dekat satu sama lain, dan perbedaan di antara mereka bisa dalam sintaksis atau paradigma pemrograman.

Kecepatan pengembangan menggunakan kerangka kerja tertentu tergantung pada pengalaman dan kualifikasi programmer yang menulisnya, kerangka kerja itu sendiri adalah kepentingan sekunder.

Kualitas produk

Itu sama di sini: itu baik dan buruk Anda dapat menulis pada kerangka apa pun Anda dapat meletakkan arsitektur yang benar dan salah di mana saja.

Itu semua tergantung pada pengalaman dan pengetahuan pengembang.

Biaya

Semua kerangka kerja modern modern bersifat gratis, jadi jika Anda mengabaikan detailnya, biaya pengembangan adalah biaya waktu yang dihabiskan pengembang untuk mempelajari persyaratan, teknologi, menguraikan arsitektur dan menulis kode. Ditambah biaya untuk menemukan / melatih pengembang ini.

Oleh karena itu kesimpulannya: Anda tidak perlu terlalu bergantung pada teknologi seperti pada pengembang dan organisasi pekerjaan mereka.

Hampir semua kerangka kerja populer modern cukup baik untuk dibuat di dalamnya hampir semua aplikasi yang mungkin dibutuhkan oleh bisnis modern.

Oleh karena itu, akan lebih jauh tentang efektivitas ujung depan dalam hal organisasi pembangunan.

Bagaimana dengan kita

Pada 2017, kami memiliki aplikasi pada hampir semua hal yang patut mendapat perhatian di dunia JavaScript: dari jQuery ke berbagai versi Angular dan Bereaksi pada Typescript dan Flow. Pengembang layout dan backend / fullstack bekerja pada sisi klien dari aplikasi kami. Setiap pengembang memilih alat untuk tugas mereka, tergantung pada pengetahuan mereka tentang teknologi front-end.

Sekarang saya hanya bisa berspekulasi, tetapi bagi saya tampaknya pilihan kerangka kerja dan perpustakaan oleh pengembang fullstack / backend adalah sesuatu seperti ini:

"Mari kita lihat apa yang mereka tulis di Internet ..."

Ya, Anda mengerti.

Ketika memilih kerangka kerja / pustaka, pengembang terbatas dalam waktu, paling sering ia tidak punya waktu untuk secara mandiri menggunakan kerangka kerja baru untuknya dan membuat aplikasi pengujian. Karena itu, ia entah bagaimana membuat pilihan yang kurang lebih beralasan dan kemudian mengikuti ke arah yang dipilih.

Pada titik waktu yang berbeda, pilihan ini mungkin berbeda bahkan untuk pengembang yang sama (lihat ilustrasi di atas). Pada saat yang sama, ia menjadi tidak kurang beralasan. Lalu apa yang diharapkan dari pengembang yang berbeda dengan pengalaman yang berbeda?

Tanpa diketahui hingga 2017, kami berubah menjadi kebun binatang teknologi front-end yang nyata.

Frontend sebagai unit terpisah

Sejumlah besar teknologi berbeda di perusahaan adalah sumber risiko. Seorang pengembang dengan pengetahuan yang diperlukan dapat sibuk di proyek lain, ia dapat sepenuhnya meninggalkan perusahaan. Mempekerjakan spesialis dengan pengalaman luas di berbagai bidang juga bukan tugas yang mudah.

Dokumentasi berkualitas tinggi dapat mengurangi dampak negatif dari keanekaragaman tersebut, tetapi biasanya perlu waktu lama untuk mempelajari dan membenamkan diri dalam teknologi yang tidak dikenal.

Pada tahun 2017, divisi front-end muncul di perusahaan kami, yang merupakan respons terhadap meningkatnya permintaan pada kualitas bagian front-end dari proyek kami dan kuantitasnya, serta upaya untuk menstabilkan keragaman teknologi dan meningkatkan efisiensi pengembangan.

Ini adalah tahap penting untuk pengembangan perusahaan kami: apa yang kami lakukan sekarang, tidak mungkin dilakukan dengan bantuan pengembang tanpa mengkhususkan diri pada front-end.

Bagaimana cara menyembuhkan kebun binatang?

Variasi teknologi yang tidak terkontrol membuat sulit untuk memprediksi kecepatan dan kualitas pengembangan secara umum, sedangkan pengembangan komersial hanya membutuhkan itu.

Karena itu, langkah kami selanjutnya adalah menyatukan tumpukan perusahaan dengan bantuan para ahli dari divisi baru.

Tumpukan terpadu adalah kumpulan perpustakaan dan alat yang sangat terbatas yang dapat digunakan pengembang untuk memecahkan masalah bisnis. Ini juga mencakup kebijakan mengenai berbagai pendekatan untuk pemrograman, misalnya, penggunaan pendekatan fungsional yang dominan, atau sebaliknya, penolakan itu.

Tumpukan tunggal memberi pengembang kemampuan untuk dengan cepat beralih dari satu proyek ke proyek lain, melakukan tinjauan lintas tim, dan secara efektif berbagi pengalaman dan praktik terbaik dengan kolega.

Tugas utama di sini bukan untuk memutuskan apa yang kami tulis tentang Bereaksi atau Bersudut, tetapi untuk memastikan bahwa pengembang menggunakan alat yang sama untuk membuat aplikasi dan pendekatan yang sama untuk memecahkan masalah umum.

Untuk referensi: alat utama kami adalah React, tetapi kami juga mengembangkan keahlian dalam Angular.

Di sinilah kesenangan dimulai. Memaksa dalam dunia pemrograman bekerja sangat buruk.

Oleh karena itu, alih-alih paksaan, Anda harus memastikan bahwa pengembang sendiri ingin mengikuti aturan pengembangan tertentu.

Untuk melakukan ini, Anda perlu:

entah bagaimana memperbaiki, memformalkan persyaratan pengembangan;
Dorong pengembang untuk mengikuti pedoman ini.

Memformalkan tumpukan adalah kegiatan yang membutuhkan kemampuan untuk menjaga keseimbangan. Tidak perlu membuat peraturan rinci untuk semuanya untuk menyampaikan ide-ide dasar kepada pengembang. Selain itu, membuat dan memelihara spesifikasi terinci memakan banyak sumber daya.

Kami memecahkan masalah motivasi sebagai berikut: lebih baik daripada dokumentasi apa pun untuk memberi pengembang aplikasi setengah jadi (templat).

Hal ini memungkinkan pengembang untuk menyelesaikan tugas lebih cepat dan mengesankan rekan kerja dengan produktivitas mereka dan pada saat yang sama mendorong mereka untuk mematuhi aturan dasar yang sudah dilindungi dalam kode.

Di satu sisi, aplikasi serupa pada akhirnya memberikan peningkatan signifikan dalam kecepatan pengembangan karena akumulasi pengalaman, solusi siap pakai, tinjauan yang lebih dalam dan kemampuan untuk beralih dari proyek ke proyek. Di sisi lain, setiap proyek memiliki kekhasan masing-masing, oleh karena itu penting juga di sini untuk tidak berlebihan dengan standardisasi.

Apa yang Anda butuhkan untuk diletakkan di templat aplikasi

Saat memulai proyek baru, pengembang biasanya menyelesaikan tugas-tugas khas berikut:

definisi arsitektur, pemilihan teknologi / alat;
pembuatan kerangka kerja aplikasi, perakitan;
pembuatan dan konfigurasi mekanisme umum: penanganan kesalahan, modal windows, pemberitahuan, routing, permintaan server;
definisi seperangkat elemen antarmuka;
pencarian / kreasi, penyesuaian, stylization komponen antarmuka dengan fungsi yang diperlukan;
pemrosesan formulir, validasi;
tata letak;
implementasi fungsionalitas atas perintah klien (logika bisnis);
ulasan kode;
manajemen arsip.

Manakah dari tugas ini yang dapat diselesaikan oleh pengembang Anda dalam beberapa menit?

Templat aplikasi yang kami kembangkan menutup tiga item pertama dari daftar ini. Dalam templat ini, kami menyatakan tidak hanya keinginan kami untuk tumpukan tunggal untuk pengembangan, tetapi juga aturan dasar arsitektur aplikasi.
Dibandingkan dengan solusi populer yang ada di domain publik (misalnya, buat-reaksi-aplikasi), templat kami sudah mengandung:

struktur folder siap pakai;
router yang dikonfigurasi (rute);
Penyimpanan redux yang dikonfigurasi
modul permintaan server;
mekanisme siap pakai untuk menampilkan berbagai jenis loader, notifikasi dan modal windows melalui redux;
modul pemrosesan kesalahan (server dan pengguna) dengan output pesan ke pengguna;
halaman templat;

modul templat logika bisnis yang terhubung dengan penangan kesalahan, pemuat, dan pemberitahuan

Intinya, ini adalah aplikasi siap produksi dengan satu halaman yang menyapa dunia. Dimulai dengan kopi pagi, saat makan siang, pengembang dapat menunjukkan halaman pertama dari sebuah proyek yang berjalan.

Tetapi kemudian sejumlah besar tugas menarik lainnya (dan tidak demikian) menunggu pengembang.

Pemilihan Perpustakaan Komponen

Segala sesuatu yang menyangkut tata letak, komponen antarmuka (daftar drop-down, kalender, dll.), Formulir dan validasi, kami memutuskan menggunakan perpustakaan kami sendiri. Itu bagian tersulit.

Pada 2017, perpustakaan utama perusahaan adalah perpustakaan komponen Kendo berbayar, yang menyediakan solusi UI untuk berbagai teknologi, dimulai dengan jQuery. Karena berbagai alasan, itu tidak cocok untuk kami, dan kami memutuskan untuk mempertimbangkan perpustakaan alternatif, termasuk pilihan untuk membuat perpustakaan sendiri.

Ini adalah poin yang sangat penting di mana Anda perlu membuat pilihan yang tepat: temukan perpustakaan lain yang lebih baik bagi kami, atau buat perpustakaan Anda sendiri. Distribusi sumber daya pengembangan lebih lanjut dan waktu yang dihabiskan tim untuk membuat dan menyelesaikan elemen antarmuka tergantung pada pilihan ini. Dalam pilihan kami, kami melanjutkan dari pertimbangan berikut.

;
;
.

( , , );
;
, . ;
, . .

;
;
.

;
, / ( ..);
( , , , ).

Faktanya, solusi siap pakai tidak begitu siap pakai. Hampir setiap perpustakaan perlu dipersiapkan sampai tingkat tertentu. Jika Anda perlu membuat satu proyek kecil, maka Anda mungkin tidak menemukan kebutuhan seperti itu, tetapi jika Anda melakukan semacam proyek besar, atau banyak proyek kecil dan berbeda, maka biaya perbaikan mungkin berubah menjadi lebih tinggi daripada biaya membuat perpustakaan Anda sendiri, yang sepenuhnya memenuhi kebutuhan Anda.

Ternyata Anda harus memilih antara menginstal segera fungsi siap pakai dengan banyak keterbatasan dan mengembangkan solusi Anda sendiri dengan kebutuhan untuk menunggu dan menghabiskan sumber daya tambahan untuk pengembangan.

Tidak ada opsi yang cocok untuk kami, dan kami menemukan solusi lain.

Kami memutuskan untuk membuat add-on untuk perpustakaan yang sudah jadi.

Biarkan saya mengingatkan Anda bahwa pada waktu itu kami sudah menggunakan perpustakaan Kendo dalam bentuknya yang murni, alternatif yang ingin kami temukan. Itulah yang kami putuskan untuk dijadikan sebagai pustaka utama komponen kami untuk aplikasi pada React. Dan perpustakaan baru kami sendiri adalah fasad atas Kendo. Saya akan menghilangkan detail teknis, saya hanya akan mengatakan bahwa solusi seperti itu memungkinkan kami untuk segera mendapatkan semua fungsi Kendo, dan kami melakukan apa yang tidak kami miliki, termasuk perbaikan cepat bug, di lapisan antara API klien perpustakaan dan Kendo.

Arsitektur ini memungkinkan kami untuk dengan cepat memperluas jumlah komponen karena pustaka dan modul lain, hanya dengan menyematkannya di lapisan kami. Untuk klien perpustakaan (untuk pengembang aplikasi), ini tampak seperti peningkatan cepat dalam fungsi satu perpustakaan (saya akan membahas ini secara rinci dalam artikel terpisah).

Seiring waktu, kami mengganti semua komponen dengan implementasi kami sendiri dan merilis versi kedua perpustakaan, di mana kami memperhitungkan semua pengalaman sebelumnya, merevisi API dan membuat dokumentasi kami sendiri.

Kami memutuskan untuk meletakkan prestasi kami di domain publik, segera mereka dapat diunduh dan digunakan dalam proyek kami, ikuti pengumuman.

Apa yang kita dapatkan pada akhirnya?

Sekarang kami memiliki lebih dari 10 pengembang front-end di beberapa tim yang bekerja pada tumpukan yang sama dan dengan satu set teknologi. Pada satu tumpukan, kami telah membuat sekitar dua puluh proyek.

Statistik menunjukkan bahwa efisiensi kerja meningkat lebih dari tiga kali lipat selama dua tahun. Proyek yang kami gunakan untuk menghabiskan 4-6 bulan, sekarang kami lakukan dalam 1-2 bulan (kita berbicara tentang bagian front-end).

Kami mulai mengurangi waktu pengembangan dengan mengubah struktur tugas pemrogram. Mari kita lihat bagaimana mereka berubah.

Saya sudah memberikan daftar tugas yang diselesaikan pengembang dua tahun lalu:

definisi arsitektur, pemilihan teknologi / alat;
pembuatan kerangka kerja aplikasi, perakitan;
pembuatan dan konfigurasi mekanisme umum: penanganan kesalahan, modal windows, pemberitahuan, routing, permintaan server;
definisi seperangkat elemen antarmuka;
pencarian / kreasi, penyesuaian, stylization komponen antarmuka dengan fungsi yang diperlukan;
pemrosesan formulir, validasi;
tata letak;
implementasi fungsionalitas atas perintah klien (logika bisnis);
ulasan kode;
manajemen arsip.

Dari jumlah tersebut, di perusahaan kami hari ini, pengembang hanya terlibat dalam tiga terakhir:

implementasi fungsionalitas atas perintah klien (logika bisnis);
ulasan kode;
memelihara dokumentasi proyek.

Sisanya sudah diputuskan di templat aplikasi dan pustaka komponen.

Ini tidak hanya mempengaruhi kecepatan kerja, tetapi juga secara umum suasana hati para pengembang. Bagaimanapun, implementasi logika bisnis jauh lebih menarik daripada mengatur daftar drop-down. Manajer proyek juga jauh lebih mudah menjelaskan kepada pelanggan bahwa satu minggu waktu kerja dihabiskan untuk mengembangkan fitur-fitur bisnis yang penting, dan bukan pada fakta bahwa diperlukan penyelesaian elemen antarmuka yang kecil, meskipun mereka dapat cukup setara dalam hal biaya tenaga kerja.

Kami terus bekerja ke arah yang dipilih dan salah satu tugas utama untuk waktu dekat adalah meningkatkan motivasi pengembang untuk memperdalam kompetensi mereka di tumpukan yang dipilih dan untuk mencari solusi baru yang efektif. Menskalakan solusi semacam itu di seluruh perusahaan sekarang mudah berkat perpustakaan umum dan templat aplikasi.

Dengan harapan efisiensi dan sampai jumpa lagi!

Pengembangan frontend di perusahaan: apa itu dan bagaimana membuatnya efektif