Condivisione della tecnologia

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

Sto lavorando a un progetto da un po' e vorrei condividere alcuni pensieri e sentimenti personali utilizzando il mio tempo dopo essere uscito dal lavoro o nel tempo libero. Ti incoraggiamo insieme.

Diverse funzionalità che il front-end dovrebbe avere:

(1) La capacità di preparare dati falsi (dati simulati), perché a volte l'interfaccia back-end non è pronta e il front-end non ha dati, ma il programma è serrato e non può attendere il back-end. l'estremità deve avere la capacità di creare dati simulati.

(2) La possibilità di ignorare una determinata logica aziendale. Se un'attività a circuito chiuso richiede 5 passaggi per essere completata, se 2 sono bloccati, 345 non può continuare ad avanzare. Naturalmente, è davvero un buon modo per disturbare il backend cambiare il database. È semplice. Se è l'ultima risorsa ed è in un ambiente di sviluppo, penso che vada bene.

(3) Capacità di elaborazione dei dati. A volte i dati vengono elaborati bene dal backend ed è più semplice per il frontend renderli direttamente. Tuttavia, se i dati restituiti dall'interfaccia non possono essere utilizzati direttamente, il frontend deve prima eseguire alcune elaborazioni dei dati il rendering della pagina A volte l'elaborazione dei dati è Il carico di lavoro è ancora relativamente elevato. Questa è una domanda relativamente vaga. Devi considerare chi è meglio svolgere questo lavoro di elaborazione dei dati?

(4) Problemi di verifica. La verifica front-end può sostituire quella back-end e risparmiare molto lavoro di verifica, ma ci saranno problemi se utilizzi direttamente lo strumento di interfaccia Postman per eseguire il test. In alcuni scenari, il problema della verifica viene gestito meglio dal front-end, come la verifica dei moduli, in altri scenari, come i problemi di recupero ripetitivo con grandi quantità di dati, si tratta sicuramente della verifica del back-end. Deve ancora essere analizzato sulla base di scenari specifici.

(5) Quando vengono sviluppati più progetti contemporaneamente, il funzionamento dell'ambiente di sviluppo back-end influisce sullo sviluppo iterativo di diverse versioni del front-end. Cosa dovremmo fare?

(6) Gestione dei rami del codice La gestione del codice è particolarmente importante quando ci sono molti progetti o quando lo stesso progetto deve iterare più versioni contemporaneamente. I progetti su cui ho lavorato prima non erano standardizzati a questo riguardo. Man mano che sono diventati più formali e sono stati scritti più rami, ho gradualmente acquisito una nuova comprensione che quest'area deve davvero essere mantenuta bene. Se il codice viene perso o non viene unito nella versione del progetto, si verificherà un grave incidente di rilascio.

(7) La capacità di incapsulare i componenti. Qui vorrei condividere alcuni dei miei pensieri Sulla base dell'esperienza personale, penso che i componenti front-end possano essere semplicemente suddivisi in componenti funzionali generali pubblici e componenti aziendali che implementano funzionalità generali aziendali i componenti sono onnipresenti nell'implementazione dei sistemi. Le funzioni generali possono facilitare il successivo sviluppo di attività funzionali simili. I componenti aziendali sono strettamente correlati alla nostra attività richiesta. I dati e la logica in essi contenuti sono fortemente associati alla nostra attività e generalmente non possono essere utilizzati in altre pagine. Una cosa di cui il nostro front-end ha davvero bisogno e che deve considerare quando incapsula i componenti è cercare di non inserire dati e logica aziendale in componenti funzionali generali. Ciò causerà un accoppiamento del codice. Quando il nostro progetto diventerà gradualmente più forte, diventerà difficile da utilizzare nuovamente. Pertanto, quando si utilizzano i componenti, dovremmo preparare il più possibile i dati e la logica nei componenti aziendali. Se dobbiamo farlo, è meglio scrivere note e cercare di non influenzare la logica del codice precedente. Ho riscontrato questo problema quando ho iniziato a lavorare al progetto. Di conseguenza, un componente della tabella originariamente incapsulato aveva troppi se e altri aggiunti, penso che fosse perché l'accoppiamento con l'azienda era troppo forte questo da un lato e dall'altro: da un lato, il numero di iterazioni è frequente e il ciclo è relativamente lungo e ci sono molte persone che lo gestiscono, quindi diventa più difficile apportare modifiche. Pertanto, per quanto riguarda il confezionamento dei componenti, ho gradualmente scoperto alcuni punti che possono essere ottimizzati nello sviluppo del progetto attuale. Quindi, se i componenti devono essere confezionati nelle iterazioni successive del progetto, alcuni problemi dovrebbero essere evitati il ​​più possibile anche qualcosa che deve essere ulteriormente ottimizzato se c'è abbastanza tempo nel programma. Dopotutto, questo ci consente di utilizzare i componenti in modo più fluido.

continua...