Teknologian jakaminen

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

Olen työskennellyt jonkin projektin parissa jonkin aikaa ja haluaisin jakaa henkilökohtaisia ​​ajatuksia ja tunteita käyttämällä aikaa töistä poistumisen tai parittoman ajan jälkeen. Kannustetaan teitä yhdessä.

Useita ominaisuuksia, jotka etupäässä pitäisi olla:

(1) Mahdollisuus valmistaa väärennettyjä tietoja (simuloitua dataa), koska joskus taustaliittymä ei ole valmis ja käyttöliittymässä ei ole tietoja, mutta aikataulu on tiukka eikä voi odottaa taustaa. lopussa on oltava kyky luoda simuloitua dataa.

(2) Mahdollisuus ohittaa tietty liikelogiikka Jos suljetun kierron liiketoiminta vaatii 5 vaihetta, jos 2 on jumissa, 345 ei voi jatkaa eteenpäin muuttaa tietokantaa. Jos se on viimeinen keino ja se on kehitysympäristössä, mielestäni se on ok.

(3) Tiedonkäsittelyominaisuudet Joskus taustaosa käsittelee tiedot hyvin ja käyttöliittymän on helpompi renderöidä suoraan, jos käyttöliittymän palauttamia tietoja ei voida käyttää suoraan, käyttöliittymän on suoritettava jonkin verran tietojen käsittelyä Sivun renderöiminen Joskus tietojen käsittely on edelleen suhteellisen suuri. Tämä on suhteellisen epämääräinen kysymys. Sinun on pohdittava, kuka tekee tämän tiedonkäsittelyn paremmin?

(4) Vahvistusongelmat. Etupään vahvistus voi korvata taustan ja säästää paljon varmennustyötä, mutta ongelmia ilmenee, jos käytät testaamiseen suoraan postman käyttöliittymätyökalua. Joissakin skenaarioissa varmistusongelma on helpompi käsitellä käyttöliittymällä, kuten lomakkeen varmistus, muissa skenaarioissa, kuten suuria tietomääriä koskevissa toistuvissa nouto-ongelmissa, se on ehdottomasti taustavarmennus. Se on vielä analysoitava erityisten skenaarioiden perusteella.

(5) Kun useita projekteja kehitetään samaan aikaan, taustakehitysympäristön toiminta vaikuttaa käyttöliittymän eri versioiden iteratiiviseen kehittämiseen. Mitä meidän pitäisi tehdä?

(6) Koodihaarojen hallinta on erityisen tärkeää, kun projekteja on useita tai kun sama projekti tarvitsee iteroida useita versioita samanaikaisesti. Aiemmin työskennellyt projektit eivät olleet standardoituja tältä osin. Kun ne muodollistuivat ja haaroja kirjoitettiin enemmän, sain vähitellen ymmärryksen siitä, että tätä aluetta on todellakin pidettävä hyvin yllä. Jos koodi katoaa tai koodia ei yhdistetä projektijulkaisussa, kyseessä on vakava julkaisuonnettomuus.

(7) Kyky kapseloida komponentteja Tässä haluan jakaa omia ajatuksiani henkilökohtaisen kokemuksen perusteella, että front-end-komponentit voidaan jakaa yksinkertaisesti yleisiin toiminnallisiin komponentteihin komponentit ovat läsnä kaikkialla järjestelmien toteuttamisessa. Liiketoimintakomponentit liittyvät läheisesti vaadittuun liiketoimintaamme. Niissä olevat tiedot ja logiikka liittyvät vahvasti liiketoimintaamme, eikä niitä yleensä voida käyttää muilla sivuilla. Yksi asia, joka meidän käyttöliittymämme todella tarvitsee ja joka on otettava huomioon komponenttien kapseloinnissa, on yrittää olla laittamatta liiketoimintadataa ja logiikkaa sellaisiin yleisiin toiminnallisiin komponentteihin. Tämä aiheuttaa jonkinlaista koodikytkentää se taas. Siksi komponentteja käytettäessä meidän tulee valmistella dataa ja logiikkaa mahdollisimman paljon liiketoimintakomponenteissa. Jos näin on tehtävä, on parasta kirjoittaa muistiinpanoja ja yrittää olla vaikuttamatta aiempaan koodilogiikkaan. Törmäsin tähän ongelmaan, kun aloin työskennellä projektin parissa. Tämän seurauksena alunperin kapseloituun taulukkokomponenttiin oli lisätty liian monta if-toimintoa ja muuta tämä on toisaalta, ja toisaalta, iteraatioiden määrä on tiheä, ja sykli on suhteellisen pitkä, ja sitä käsittelee monia, joten muutosten tekeminen on vaikeampaa. Komponenttien pakkaamisen suhteen olen siis vähitellen keksinyt joitain kohtia, jotka voidaan optimoida nykyisessä projektikehityksessä. Jos komponentteja halutaan pakata myöhemmissä projektien iteraatioissa, joitain ongelmia tulisi välttää niin paljon kuin mahdollista myös jotain, jota pitää edelleen optimoida, jos aikataulussa on tarpeeksi aikaa. Loppujen lopuksi tämä antaa meille mahdollisuuden käyttää komponentteja sujuvammin.

jatkuu...