Papan Pemuka Unity - pelajaran yang dipelajari untuk meningkatkan tahap kemajuan, budaya dan proses pembangunan kita

Di Unity, kami baru-baru ini berusaha untuk meningkatkan Papan Pemuka kami - suatu usaha yang secara dramatik mengubah bukan sahaja timbunan teknologi frontend kami, tetapi juga cara kami bekerja dan bekerjasama.

Kami telah mengembangkan amalan dan perkakas terbaik untuk membantu kami memperkembangkan seni bina frontend kami, membina produk dengan UX dan prestasi yang hebat, dan untuk menghantar ciri baru secepat mungkin.

Artikel ini mengumpulkan amalan ini dan bertujuan untuk memberikan seberapa banyak alasan di sebalik setiap keputusan yang mungkin. Tetapi pertama, beberapa konteks.

Warisan

Melihat jumlah jurutera, Unity lebih daripada empat kali ganda jumlahnya dalam 4 tahun kebelakangan. Oleh kerana syarikat itu berkembang secara organik dan melalui pemerolehan, penawaran produknya juga meningkat. Walaupun produk yang dikembangkan pada awalnya di Unity sebahagian besarnya seragam dari segi bahasa teknologi dan reka bentuk, produk yang baru diperoleh secara semula jadi tidak.

Hasilnya, kami mempunyai beberapa papan pemuka yang berbeza secara visual yang berfungsi dan berkelakuan berbeza dan yang tidak mempunyai unsur navigasi yang sama. Ini mengakibatkan pengalaman pengguna yang buruk dan pengguna yang kecewa. Dalam pengertian yang sangat harfiah, keadaan frontend produk kami menelan belanja kami.

Setelah menganalisis portfolio produk kami, kami telah memperoleh tiga bahagian yang berbeza yang akan dibahagikan kepada Unity Dashboard: Membangun, Mengendalikan dan Memperolehi, masing-masing memenuhi keperluan perniagaan yang berbeza dan dimaksudkan untuk kumpulan pelanggan yang berbeza, sehingga mengandungi set fitur yang sangat bebas antara satu sama lain. .

Struktur baru ini, dan pengenalan elemen navigasi umum yang bertujuan untuk menyelesaikan masalah utama pertama yang dihadapi oleh pengguna kami - di mana untuk mencari maklumat dan pilihan konfigurasi yang mereka cari, dan walaupun semuanya kelihatan baik di atas kertas, perjalanan bagaimana sampai di sana jauh dari jelas.

Pertimbangan

Banyak pembangun kami sangat gembira dengan kemungkinan berpindah ke React dan timbunan teknologi yang lebih moden. Oleh kerana penyelesaian ini telah diuji pertempuran dalam aplikasi besar, dan praktik dan konvensyen terbaik mereka kebanyakan diselesaikan, semuanya kelihatan sangat menjanjikan.

Walaupun begitu, apa yang paling diketahui oleh pembangun kami dan apa yang ditulis oleh kebanyakan aplikasi yang dikembangkan secara aktif adalah AngularJS. Memutuskan untuk memulakan penghijrahan semuanya dalam satu perjalanan adalah bencana yang menanti berlaku. Sebaliknya, kami mula menguji andaian kami pada skala yang jauh lebih kecil terlebih dahulu.

Mungkin kumpulan produk yang paling tidak baik yang kami ada ialah papan pemuka Pengewangan . Projek-projek ini, yang akhirnya akan berakhir di bawah payung dashboard Operate, sangat berbeza dengan hampir semua cara yang mungkin: teknologi yang digunakan, pendekatan ke UI / UX, amalan pembangunan, konvensyen pengkodan - anda namakan.

Inilah keadaannya secara kasar:

Setelah melakukan percambahan fikiran, kami mengenal pasti bidang utama yang perlu kami bekerjasama untuk menyatukan semua produk:

1. Satu produk

Kami memerlukan papan pemuka ini (terbahagi kepada beberapa aplikasi, domain dan tumpukan teknologi) untuk:

  • Rasa seperti satu produk (tiada pengalihan halaman penuh semasa pengguna menavigasi halaman dari semua aplikasi yang berbeza)
  • Mempunyai penampilan dan rasa yang konsisten
  • Sertakan elemen navigasi biasa yang selalu kelihatan dan kelihatan sama, tidak kira bahagian papan pemuka yang dikunjungi pengguna

2. Sokongan warisan

Walaupun kami benar-benar memiliki pilihan yang baik ketika datang ke pilihan teknologi solusi frontend baru kami, kami harus menampung projek-projek lama yang perlu disatukan ke dalam sistem baru. Penyelesaian, yang tidak melibatkan usaha pemurnian semula yang besar, dan yang tidak akan menghentikan pengembangan fitur, atau berlarutan selama berbulan-bulan tanpa akhir.

3. Amalan dan perkakas

Walaupun hampir semua pasukan menggunakan AngularJS, alat yang berbeza digunakan untuk mengatasi tantangan yang sama. Pelari ujian dan pernyataan penegasan yang berbeza, penyelesaian pengurusan negeri atau kekurangannya, jQuery vs pemilih penyemak imbas asli, SASS vs KURANG, pustaka peta dll.

4. Produktiviti pembangun

Oleh kerana setiap pasukan mempunyai jalan keluar sendiri untuk mengembangkan, menguji dan membangun aplikasi mereka, lingkungan pengembangan seringkali penuh dengan bug, langkah manual, dan ketidakefisienan.

Selain itu, banyak pasukan kami bekerja di lokasi yang dipisahkan oleh perbezaan 10 jam (Helsinki, Finland dan San Francisco), yang menjadikan keputusan yang cekap pada bahagian yang dikongsi menjadi cabaran.

Baru

Bidang fokus utama kami adalah:

  1. Galakkan dan pelihara cara-cara tangkas dalam bekerja dalam pasukan kami, dan biarkan pasukan bebas daripada satu sama lain
  2. Manfaatkan dan kembangkan perkakas dan konvensi umum sebanyak mungkin, untuk mendokumentasikannya, dan membuatnya mudah diakses dan digunakan

Kami percaya bahawa mencapai matlamat ini akan meningkatkan masa kami untuk memasarkan dan meningkatkan produktiviti. Untuk itu, kami memerlukan penyelesaian yang akan:

  • Bina ciri produk dengan pengalaman pengguna yang lebih baik
  • Tingkatkan kualiti kod
  • Benarkan kolaborasi yang lebih baik tanpa menyekat kemajuan kerja seseorang dalam prosesnya.

Kami juga ingin mendorong dan mempermudah perpindahan ke timbunan teknologi moden untuk membuat pemaju kami lebih berpuas hati dengan pekerjaan mereka, dan dari masa ke masa menjauh dari kerangka kerja dan perkakas kuno kami.

Hasil kerja kami yang sentiasa berkembang adalah SPA berasaskan React yang dibina di dalam monorepository di mana semua halaman dan ciri yang lebih besar dimasukkan ke dalam kumpulan kod bebas yang dimuat berdasarkan permintaan, dan yang dapat dikembangkan dan digunakan oleh banyak pasukan pada masa yang sama .

Sebagai alat kotak pasir semua aplikasi lama tetapi masih memaparkannya dalam konteks aplikasi baru yang sama, kami memuatkannya di dalam iframe dari mana mereka dapat berkomunikasi dengan SPA utama menggunakan bas mesej yang dilaksanakan menggunakan postMessage()API.

Monorepositori

Inilah struktur direktori yang kami mulakan dengan:

/src /components /scenes /foo /components package.json foo.js /bar /components package.json bar.js package.json index.js

Yang package.jsondi dalam direktori akar tersebut mengandungi satu set devDependencies bertanggungjawab untuk pembangunan, ujian dan alam bina keseluruhan permohonan itu, tetapi juga mengandungi dependenciesteras permohonan (lebih kepada yang sedikit kemudian).

Semua potongan UI yang lebih besar disebut sebagai pemandangan . Setiap kejadian mengandungi package.jsonmana dependenciesyang digunakan oleh komponen yang kejadian yang ditakrifkan. Ini memungkinkan dua perkara:

  1. Penyebaran hanya mengemas kini fail yang telah diubah

    Langkah build menyusun bundel vendor dan aplikasi yang berasingan untuk setiap adegan, menamakan masing-masing menggunakan hash yang akan berubah hanya apabila kandungan fail telah berubah. Ini bermaksud pengguna kami hanya memuat turun fail yang telah berubah sejak lawatan terakhir mereka, dan tidak lebih dari itu.

  2. Pemandangan dimuat hanya apabila diperlukan

    Kami memuatkan semua pemandangan secara asinkron dan mengikut permintaan yang secara drastik meningkatkan masa muat keseluruhan aplikasi. "On demand" di sini biasanya bermaksud mengunjungi laluan tertentu, atau melakukan tindakan UI yang melakukan import modul dinamik.

Inilah cara penyediaan seperti itu dalam praktik (dipermudah untuk dibaca):

// In src/routes.jsconst FooLoader = AsyncLoadComponent( () => import(‘src/scenes/foo/foo’), GenericPagePreloader,);
// In src/scenes/foo/foo.js 

Ini AsyncLoadComponentadalah pembungkus tipis di sekitar React.lazy(), selain menerima komponen preloader, yang sama melewati fallback ke React.Suspense(), dan kelewatan selepas itu preloader harus diberikan jika pemandangan belum selesai dimuat.

Ini berguna semasa memastikan pengguna kami melihat pramuat yang sama tanpa gangguan atau kilatan kandungan dari saat adegan diminta hingga saat semua failnya telah dimuat turun, semua permintaan API kritikal telah selesai, dan komponennya telah selesai membuat.

Tahap komponen

Apabila setiap aplikasi berkembang, struktur direktori dan abstraksi berkembang seiring dengannya Setelah kira-kira setengah tahun membina dan memindahkan ciri ke pangkalan kode baru, direktori satu komponen terbukti tidak mencukupi.

Kami memerlukan struktur direktori kami untuk memberitahu kami mengenai:

  • Telah komponen dikembangkan untuk menjadi generik, atau hanya dimaksudkan untuk kasus penggunaan tertentu?
  • Apakah mereka cukup generik untuk digunakan di semua aplikasi, atau harus digunakan hanya dalam konteks tertentu?
  • Siapa yang bertanggungjawab dan paling berpengetahuan mengenai kod tersebut?

Berdasarkan itu, kami telah menentukan Tahap Komponen berikut :

1. Khusus aplikasi (src / app)

Komponen penggunaan tunggal yang memenuhi kes penggunaan tertentu dalam aplikasi ini, dan yang tidak dimaksudkan untuk digunakan kembali atau diekstrak ke perpustakaan komponen (rute, footer, header halaman dll.).

2. Generik (src / komponen)

Komponen pelbagai guna generik untuk digunakan di seluruh aplikasi dan pemandangannya. Setelah kami sampai di API yang stabil untuk komponen ini, komponen tersebut dapat dipindahkan ke perpustakaan komponen biasa (lebih banyak lagi di bawah)

3. Komponen pemandangan tunggal (src / adegan / adegan / komponen)

Komponen dikembangkan dengan mempertimbangkan kes penggunaan tertentu; tidak dimaksudkan untuk digunakan dalam pemandangan lain. Untuk kes apabila komponen dari satu adegan perlu digunakan di tempat lain, kami akan menggunakan:

4. Komponen pelbagai pemandangan (src / adegan / komponen / ciri saya)

Komponen yang digunakan di pelbagai babak, tetapi tidak dimaksudkan untuk cukup generik untuk digunakan di tempat lain. Untuk menggambarkan mengapa memindahkannya src/componentstidak cukup baik:

Bayangkan sejauh ini anda mempunyai satu pemandangan yang mengandungi komponen yang digunakan untuk membina beberapa carta data yang agak spesifik. Pasukan anda kini membina pemandangan kedua yang akan menggunakan data yang berbeza untuk carta, tetapi secara visual kedua-duanya akan kelihatan sama.

Mengimport komponen dari satu adegan ke adegan yang lain akan memecahkan enkapsulasi pemandangan dan ini bermaksud bahawa kita tidak lagi dapat memastikan sama ada perubahan yang dibuat pada komponen satu pemandangan hanya mempengaruhi satu pemandangan itu.

Untuk tujuan ini, setiap komponen atau sekumpulan komponen, yang secara kasar disebut sebagai fitur, akan ditempatkan src/scenes/componentsdari mana ia dapat diimport dan digunakan oleh pasukan lain, namun:

Setiap kali pasukan ingin mula menggunakan komponen pemandangan yang dikembangkan oleh pasukan lain, amalan terbaik adalah menghubungi pasukan itu terlebih dahulu untuk mengetahui sama ada kes penggunaan yang anda mahukan komponen ini dapat disokong dengan selamat di masa depan. Memberi kepemimpinan kepada pasukan yang pada awalnya mengembangkan kod itu akan mencegah penghantaran yang rosak pada masa akan datang apabila kod yang telah anda gunakan pasti akan berubah dengan cara yang tidak anda harapkan (kerana tentu saja, bagaimana mungkin anda!) yang mungkin tidak selalu terperangkap dengan ujian unit.

5. Perpustakaan umum

Komponen yang telah kami uji-pertempuran dalam pengeluaran dan ingin mengekstrak ke perpustakaan komponen bersama kami, yang digunakan oleh pasukan papan pemuka lain di Unity.

Ode kepada kebergantungan bersama

Walaupun sangat senang untuk dapat membangun dan menyebarkan setiap bahagian aplikasi kita dalam lingkungan yang sepenuhnya terpencil, kebergantungan tertentu - perpustakaan luaran dan kod aplikasi dalaman - hanya akan digunakan di seluruh pangkalan kode. Perkara seperti React itu sendiri, Redux dan semua logik berkaitan redux, komponen navigasi biasa dll.

Melancarkan perubahan

Pada masa ini, merangkumi pemandangan tidak praktikal dan dalam banyak kes mustahil. Ia memerlukan penghantaran banyak pergantungan berkali-kali dan dalam proses memperlahankan pemuatan halaman, atau membina abstraksi yang bertujuan untuk menjadikan perpustakaan tertentu berfungsi dalam masa yang belum mereka rancangkan.

Walaupun perkembangan web dan ekosistemnya berkembang, perpustakaan nampaknya semakin mandiri dan terbungkus, yang kami harapkan di masa depan tidak akan memberi sedikit kebergantungan bersama, dan pengasingan yang benar antara semua modul.

Mungkin kelemahan terbesar untuk mengarang aplikasi berskala besar adalah melakukan perubahan kod dan kemas kini kebergantungan tanpa memecahkan sesuatu dalam prosesnya

Menggunakan monorepository memungkinkan (walaupun tidak wajib) melancarkan perubahan dan kemas kini kod secara lebih beransur-ansur dan selamat - jika perubahan menyebabkan masalah, masalah ini hanya akan mempengaruhi sebahagian kecil aplikasi, bukan keseluruhan sistem.

Dan sementara bagi beberapa kemampuan untuk melakukan kemas kini pada beberapa kawasan yang tidak berkaitan pada pangkalan kode pada masa yang sama akan memberi manfaat, kenyataannya mempunyai banyak pasukan yang bekerja pada pangkalan kode yang sama dan tidak mengetahui semua ciri pasukan lain secara menyeluruh bermaksud bahawa sangat berhati-hati ketika membina perancah aplikasi dan mengambil langkah-langkah untuk mengurangkan risiko kerosakan.

Cara mengelakkan perkara pecah

Mungkin strategi paling mendasar yang membantu kita melakukannya, selain pengasingan pemandangan, mempunyai liputan ujian unit yang tinggi .

  1. Ujian

Ujian unit tentu saja bukan segalanya - banyak produk matang bahkan pada skala sederhana dilakukan setelah semua melabur dalam suite integrasi dan ujian e2e yang melakukan pekerjaan yang lebih baik untuk mengesahkan sama ada aplikasi berfungsi seperti yang diharapkan secara keseluruhan. Namun, apabila bilangan ciri bertambah, kos penyelenggaraan dan masa yang diperlukan untuk menjalankannya - kos yang tidak selalu dapat dibenarkan untuk ciri yang kurang penting tetapi tetap penting.

Beberapa pelajaran yang kami pelajari dari pelbagai strategi ujian:

  • Cuba uji unit sebanyak mungkin kod, terutamanya: logik bersyarat, transformasi data dan panggilan fungsi
  • Melabur dan memanfaatkan ujian integrasi sepenuhnya sebelum membuat keputusan untuk menulis sebarang ujian e2e. Kos awal ujian integrasi jauh lebih tinggi, tetapi sedikit dibandingkan dengan harga pemeliharaan suite e2e
  • Cuba jangan bertindak balas berlebihan dengan mula menulis ujian e2e untuk perkara yang tidak ditangkap oleh ujian unit atau integrasi. Kadang kala, proses atau perkakas salah
  • Biarkan kes ujian menjelaskan tingkah laku UI dan bukannya perincian pelaksanaan
  • Ujian automatik tidak dapat menggantikan ujian manual sepenuhnya

2. Minimumkan permukaan kod bersama

Selain daripada pengujian, kod yang digunakan kembali di seluruh aplikasi tetap minimum. Salah satu strategi yang paling berguna sejauh ini adalah memindahkan komponen dan kod yang paling sering digunakan ke perpustakaan komponen bersama, dari mana ia digunakan sebagai pergantungan dalam pemandangan yang memerlukannya. Ini membolehkan kami melancarkan sebahagian besar perubahan secara bertahap, berdasarkan setiap pasukan atau halaman.

3. Akauntabiliti

Akhir sekali, faktor besar dalam beberapa pasukan dapat berkolaborasi dalam pangkalan data yang sama berasal dari mendorong dan meminta pembangun mengambil tanggungjawab peribadi dan akauntabiliti terhadap produk , dan bukannya memikul tanggungjawab untuk menguji dengan betul bahawa semuanya berfungsi kepada QA, penguji atau automasi.

Ini juga memerlukan tinjauan kod. Memastikan setiap perubahan dikaji dengan teliti lebih sukar daripada yang terlihat di permukaan. Apabila pasukan bekerjasama rapat, tahap kepercayaan yang sihat dikembangkan antara anggotanya. Kepercayaan ini bagaimanapun, kadang-kadang boleh diterjemahkan kepada orang yang kurang rajin terhadap perubahan yang dibuat oleh pemaju yang lebih berpengalaman atau yang boleh dipercayai.

Untuk mendorong ketekunan, kami menekankan bahawa pengarang PR dan pengulas sama-sama bertanggungjawab untuk memastikan semuanya berfungsi .

Perpustakaan komponen

Untuk mencapai rupa dan nuansa yang sama di semua halaman papan pemuka kami, kami telah mengembangkan perpustakaan komponen. Apa yang terdapat dalam pendekatan kami, adalah bahawa komponen baru hampir tidak pernah dikembangkan dalam perpustakaan itu.

Setiap komponen, setelah dikembangkan dalam pangkalan kode papan pemuka, digunakan dalam sekumpulan fitur dalam pangkalan kode itu terlebih dahulu. Biasanya setelah beberapa minggu kita mula merasa lebih yakin bahawa komponen itu dapat dipindahkan, memandangkan:

  • API cukup fleksibel untuk menyokong kes penggunaan yang dapat diramalkan
  • Komponen tersebut telah diuji dalam pelbagai konteks
  • Prestasi, responsif, dan UX semuanya dipertanggungjawabkan

Proses ini mengikuti Peraturan Tiga dan bertujuan untuk membantu kami melepaskan hanya komponen yang benar-benar dapat digunakan kembali dan telah digunakan dalam pelbagai konteks sebelum dipindahkan ke perpustakaan umum kami.

Beberapa contoh komponen yang akan kami pindahkan termasuk: footer, header halaman, elemen navigasi sisi dan atas, blok bangunan susun atur, sepanduk, butang versi berkuasa, elemen tipografi dll.

Pada masa awal, perpustakaan komponen biasanya terletak di pangkalan kode yang sama dengan aplikasi itu sendiri. Kami sejak itu mengekstraknya ke repositori yang berasingan untuk menjadikan proses pembangunan lebih demokratik untuk pasukan lain di Unity - penting ketika berusaha untuk diadopsi.

Reka bentuk komponen modular

Untuk masa yang paling lama, membina komponen yang dapat digunakan semula bermaksud menangani pelbagai cabaran, yang kebanyakannya tidak mempunyai penyelesaian yang baik:

  • Bagaimana dengan mudah mengimport komponen bersama dengan gaya, dan hanya itu
  • Cara mengatasi gaya lalai tanpa perang kekhususan pemilih
  • Dalam komponen yang lebih besar yang terdiri daripada beberapa komponen yang lebih kecil, bagaimana cara mengatasi gaya komponen yang lebih kecil

Papan pemuka kami, serta perpustakaan komponen kami sangat bergantung dan menggunakan UI Bahan. Apa yang menarik dalam penyelesaian gaya Bahan UI adalah potensi yang dibawa oleh JSS dan Bahasa Gaya Bersatu mereka (layak dibaca), yang memungkinkan untuk mengembangkan UI yang dikemas dengan reka bentuk seperti dalam modul CSS, dan menyelesaikan perkara yang disebutkan di atas masalah secara bertahap.

Ini berbeza dengan pendekatan seperti BEM yang menyediakan enkapsulasi secara konvensional yang cenderung tidak dapat diperluas dan kurang dikemas.

Panduan gaya hidup

Perpustakaan komponen tidak akan lengkap tanpa cara untuk mempamerkan komponen yang terdapat di dalamnya dan dapat melihat komponen ketika mereka berubah sepanjang rilis.

Kami mempunyai pengalaman yang cukup baik dengan Storybook yang sangat mudah untuk disiapkan dan dimulakan, tetapi setelah beberapa lama kami menyedari bahawa penyelesaian yang lebih mantap dan ujung ke hujung diperlukan. Cukup dekat dengan apa yang ditawarkan oleh Styleguidist, tetapi lebih disesuaikan dengan keperluan kami.

Dokumen reka bentuk yang ada

Dokumentasi yang berfungsi sebagai sumber maklumat utama mengenai spesifikasi reka bentuk terbaru terletak di Confluence, di mana para pereka menyimpan spesifikasi terkini untuk setiap komponen menggunakan tangkapan layar yang menggambarkan kes penggunaan, keadaan dan variasi komponen yang dibenarkan, disenaraikan amalan terbaik, serta perincian seperti dimensi, warna terpakai dan lain-lain. Mengikut pendekatan itu, kami telah menghadapi beberapa cabaran:

  • Spesifikasi reka bentuk bahan terus berkembang dan oleh kerana itu kita sering kali menghabiskan masa untuk mengemas kini semua tangkapan skrin dan garis panduan, atau membiarkan garis panduan reka bentuk kita menjadi ketinggalan zaman
  • Mengetahui mana yang lebih betul: pelaksanaan atau spesifikasi tidak selalu menjadi tugas yang mudah. Kerana kami telah menerbitkan demo Buku Cerita dari setiap komponen dan untuk setiap versi perpustakaan, kami dapat melihat apa dan bagaimana perubahannya. Kami tidak dapat melakukan perkara yang sama untuk spesifikasi reka bentuk.
  • Tangkapan skrin dan video hanya dapat berkomunikasi seberapa banyak . Untuk menyediakan komponen berkualiti tinggi dan yang dapat digunakan oleh beberapa pasukan, anda perlu menyemak sama ada setiap komponen berfungsi dalam semua resolusi, bebas pepijat dan mempunyai UX yang baik - ini sukar tanpa membuat pereka duduk secara literal di sebelah anda untuk melihat demo pelaksanaan ditunjukkan di skrin

Aplikasi dokumentasi komponen

Aplikasi dokumentasi kami bertujuan untuk menyediakan cara kerjasama yang cekap antara pereka dan jurutera untuk menjadikannya lebih mudah dan tidak memakan masa untuk kedua-dua pihak mendokumentasikan, mengkaji dan mengembangkan komponen. Untuk lebih spesifik, kami perlu:

  • Mempunyai satu titik rujukan yang mempamerkan komponen , bagaimanasekiranya mereka kelihatan, berkelakuan, dan digunakan - disediakan untuk setiap pelepasan - menggantikan penerangan terperinci dengan demo langsung
  • Permudahkan pereka dan pembangun untuk berkolaborasi pada komponen dan dokumen mereka dan melakukannya sebelum komponen dilancarkan - tanpa perlu berkongsi video, tangkapan skrin, atau berada di lokasi yang sama secara fizikal
  • Pisahkan reka bentuk menjadi apa yang kita rancangkan berbanding yang telah dilakukan

Sama seperti sebelumnya, setiap rilis perpustakaan komponen menyebabkan versi baru panduan gaya hidup diterbitkan. Walau bagaimanapun, terdapat beberapa perbezaan:

  1. Pereka menyumbang kepada dokumentasi komponen secara langsung dengan mengedit fail dokumentasi melalui Github UI, melakukan perubahan pada siaran terbaru.
  2. Demo komponen sebagai WYSIWYG - kod yang sama seperti yang anda lihat sebagai contoh bagaimana melaksanakan komponen yang digunakan untuk membuat demo, termasuk sebarang import fail perantaraan, deklarasi berubah-ubah, dll. Sebagai bonus tambahan, komponen yang dibungkus withStyles()akan dipaparkan dengan betul (ada masalah dalam Buku Cerita pada masa ini).
  3. Perubahan pada dokumen dan kodnya hampir seketika dapat dilihat tanpa memeriksa cawangan secara tempatan dan memulakan aplikasi dokumentasi - aplikasi ini dibina semula dan diterbitkan pada dan untuk setiap komitmen.

Pengalaman pembangunan

Salah satu tujuan utama tinjauan kod adalah memastikan bahawa setiap perubahan diteliti, dipertimbangkan dan diuji dengan teliti sebelum digabungkan dan digunakan.

Untuk menjadikan tugas ini bebas dari halangan yang mungkin, kami telah membangunkan Pratonton Server yang mampu membuat binaan baru aplikasi kami setiap kali PR dibuat atau dikemas kini.

Pereka, pengurus produk dan jurutera kami dapat menguji setiap perubahan sebelum menggabungkannya, baik dalam lingkungan pementasan maupun produksi dan dalam beberapa minit setelah melakukan perubahan.

Kata penutup

Sudah hampir setahun sejak kita bertekad untuk menggabungkan papan pemuka kita. Kami telah meluangkan masa untuk belajar mengembangkan projek perisian yang besar tetapi sihat, bagaimana menjadi lebih baik dalam kolaborasi dan komunikasi, dan bagaimana meningkatkan bar kualiti untuk diri kita sendiri.

Kami memperbesar projek frontend tidak hanya dari segi garis kod, tetapi juga dari segi jumlah jurutera yang bekerja di pangkalan kodnya - sejumlah yang empat kali lipat sejak awal.

Kami melakukan perubahan 180 darjah dalam menangani perbezaan masa antara pasukan kami, menjauh dari model di mana pasukan kami bekerja secara terpencil menjadi satu di mana kerjasama dan komunikasi yang erat adalah kejadian sehari-hari.

Walaupun kami masih memiliki jalan panjang untuk memastikan kami dapat meningkatkan pendekatan kami ke lebih banyak pasukan dan menghadapi cabaran yang lebih besar, kami telah melihat sejumlah peningkatan:

  • Peta jalan dan keterlihatan kerja

    Oleh kerana mempunyai satu tempat di mana semua pekerjaan sedang berlangsung, kemajuannya akan dilacak, dan semua masalah dikumpulkan

  • Halaju pengembangan dan masa ke pasaran

    Ciri-ciri baru dapat dibuat sebahagian besarnya dari komponen yang sudah ada dan diuji dengan baik - mudah didapati melalui aplikasi dokumentasi kami

  • Kualiti kod & liputan ujian

    Semasa membina perkara baru, penyelesaian untuk masalah serupa biasanya sudah ada dan dapat dicapai, bersama dengan contoh cara mengujinya

  • Kualiti keseluruhan & UX

    Menguji ciri dan memastikan kualitinya kini lebih mudah daripada sebelumnya, kerana pereka, pengurus produk dan pihak berkepentingan lain dapat menguji setiap perubahan pada mesin mereka sendiri, dengan akaun dan set data mereka sendiri

Secara semula jadi, sepanjang jalan kita menghadapi sejumlah cabaran yang harus kita selesaikan, atau yang perlu diselesaikan di masa depan:

  • Pembinaan & prestasi CI

    Seiring dengan bertambahnya jumlah kebergantungan, bundel binaan, dan ujian, begitu juga masa yang diperlukan untuk melakukan penyebaran. Pada masa akan datang, kita perlu mengembangkan perkakas untuk membantu kita hanya membangun, menguji dan menyebarkan kepingan yang berubah.

  • Budaya pembangunan

    Untuk membina perisian yang sihat, kita perlu terus menerus mengusahakan cara berkomunikasi dan pertukaran idea yang sihat, dan komunikasi berasaskan teks menjadikan tugas ini lebih sukar. Kami berusaha untuk mengatasi masalah ini melalui sesi latihan kepemimpinan secara berkala dan menerapkan cara kerja yang lebih terbuka, serta mengatur beberapa sesi berkumpul setiap tahun agar pasukan saling bertemu satu sama lain.

  • Pengasingan & kemas kini kerosakan

    Seiring bertambahnya bilangan ciri dan halaman, kita memerlukan kaedah yang lebih mantap untuk mengasingkan modul aplikasi kita untuk mengelakkan kerosakan merebak ketika ada yang tidak kena. Ini dapat dicapai dengan memformat semua kod yang dikongsi (redux logic, src / components), atau dalam kes-kes yang ekstrem menghasilkan pembuatan ciri-ciri tertentu.

Nyatakan kemudian, sekarang dan masa depan

Penghijrahan tersebut melibatkan perpindahan dari AngularJS ke React. Inilah bagaimana keadaan berubah sepanjang tahun lalu:

Ini bungkus! Terima kasih kerana membaca! Anda boleh menemui saya di LinkedIn di sini.

Sekiranya mengusahakan cabaran serupa kelihatan menarik bagi anda, kami sentiasa mencari jurutera berbakat untuk menyertai pasukan kami di seluruh dunia.