Berbagi teknologi

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Saya telah mengerjakan sebuah proyek selama beberapa waktu, dan saya ingin berbagi beberapa pemikiran dan perasaan pribadi menggunakan waktu saya setelah pulang kerja atau waktu senggang. Mari kita dorong Anda bersama.

Beberapa kemampuan yang harus dimiliki front end:

(1) Kemampuan menyiapkan data palsu (data simulasi), karena terkadang antarmuka back-end belum siap dan front-end tidak memiliki data, tetapi jadwalnya padat dan tidak bisa menunggu front-end. end harus memiliki kemampuan untuk membuat data simulasi.

(2) Kemampuan untuk melewati logika bisnis tertentu. Jika bisnis loop tertutup memerlukan 5 langkah untuk menyelesaikannya, jika 2 langkah macet, maka 345 tidak dapat melanjutkan kemajuan mengubah database. Itu sederhana. Kalau itu pilihan terakhir dan dalam lingkungan pengembangan, menurut saya tidak apa-apa.

(3) Kemampuan pemrosesan data. Terkadang data diproses dengan baik oleh backend dan frontend lebih mudah untuk dirender secara langsung. Namun, jika data yang dikembalikan oleh antarmuka tidak dapat digunakan secara langsung, frontend perlu melakukan beberapa pemrosesan data sebelumnya merender halaman. Terkadang beban kerja pemrosesan data masih relatif besar. Ini adalah pertanyaan yang relatif kabur. Anda perlu mempertimbangkan siapa yang lebih baik untuk melakukan pekerjaan pemrosesan data ini?

(4) Masalah verifikasi. Verifikasi front-end dapat menggantikan back-end dan menyimpan banyak pekerjaan verifikasi, namun akan ada masalah jika Anda langsung menggunakan alat antarmuka tukang pos untuk menguji. Dalam beberapa skenario, masalah verifikasi lebih baik ditangani oleh front-end, seperti verifikasi formulir; dalam skenario lain, seperti masalah pengambilan berulang dengan data dalam jumlah besar, sudah pasti verifikasi back-end. Masih perlu dianalisis berdasarkan skenario tertentu.

(5) Ketika beberapa proyek dikembangkan pada saat yang sama, operasi lingkungan pengembangan back-end mempengaruhi pengembangan berulang dari versi front-end yang berbeda. Apa yang harus kita lakukan?

(6) Manajemen cabang kode. Manajemen kode sangat penting ketika ada banyak proyek, atau ketika proyek yang sama perlu melakukan iterasi beberapa versi pada waktu yang sama. Proyek-proyek yang saya kerjakan sebelumnya tidak terstandarisasi dalam hal ini karena semakin formal dan semakin banyak cabang yang terbentuk, lambat laun saya mendapat pemahaman baru bahwa bidang ini memang perlu dipertahankan. Jika kode hilang atau kode tidak digabungkan dalam rilis proyek, ini akan menjadi kecelakaan rilis yang serius.

(7) Kemampuan merangkum komponen. Di sini saya ingin berbagi beberapa pemikiran saya sendiri. Berdasarkan pengalaman pribadi, menurut saya komponen front-end secara sederhana dapat dibagi menjadi komponen fungsional umum dan komponen bisnis yang mengimplementasikan Fungsi umum komponen ada di mana-mana dalam penerapan sistem. Fungsi umum dapat memfasilitasi pengembangan bisnis fungsional serupa selanjutnya. Komponen bisnis berkaitan erat dengan bisnis yang kita butuhkan. Data dan logika di dalamnya sangat terkait dengan bisnis kita dan umumnya tidak dapat digunakan di halaman lain. Satu hal yang benar-benar dibutuhkan dan harus dipertimbangkan oleh front-end kami ketika mengenkapsulasi komponen adalah mencoba untuk tidak memasukkan data dan logika bisnis ke dalam komponen fungsional umum tersebut. Hal ini akan menyebabkan beberapa penggabungan kode. Ketika proyek kami secara bertahap menjadi lebih kuat, itu menjadi sulit untuk dioperasikan itu lagi. Oleh karena itu, ketika mengoperasikan komponen, kita harus mempersiapkan data dan logika dalam komponen bisnis semaksimal mungkin. Jika kita harus melakukan ini, sebaiknya tulis catatan dan usahakan untuk tidak mempengaruhi logika kode sebelumnya. Saya memang mengalami masalah ini ketika saya pertama kali mulai mengerjakan proyek ini. Akibatnya, komponen tabel yang awalnya dienkapsulasi memiliki terlalu banyak if dan elses yang ditambahkan ke dalamnya. Saya pikir itu karena hubungannya dengan bisnis terlalu kuat hal ini di satu sisi, dan di sisi lain, jumlah iterasinya sering, siklusnya relatif panjang, dan banyak orang yang menanganinya, sehingga semakin sulit melakukan perubahan. Oleh karena itu, mengenai pengemasan komponen, saya secara bertahap menemukan beberapa poin yang dapat dioptimalkan dalam pengembangan proyek saat ini. Kemudian, jika komponen ingin dikemas dalam iterasi proyek berikutnya, beberapa masalah harus dihindari sebisa mungkin juga merupakan hal yang perlu lebih dioptimalkan jika jadwalnya memiliki cukup waktu. Bagaimanapun, ini memungkinkan kita menggunakan komponen dengan lebih lancar.

bersambung...