it-swarm-eu.dev

Přední konec první nebo zadní konec první. Z těch dvou, co je dobrá konstrukce systému?

Právě teď mám klienta, který vyžaduje, abych vyvinul systém zápisu do školy. Teď je to poprvé, kdy mám tento druh výzvy. Většina z minulého softwaru, který jsem vytvořil, není tak složitá.

Vím, že většina z vás vytvořila komplexní software, chci jen poradit. Měl bych nejprve navrhnout přední nebo zadní konec?

dík!

Zde je závěr článku, který jsem našel na internetu před chvílí. Jen se chci podělit

http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157

Vývojáři front-end vs. back-end (můj odběr)

Můj osobní pohled

Opět se jedná o školení, zobecnění širokého tahu:

Vývojáři front-end

  • Typicky nemají titul CS nebo titul CS ze 3. úrovně školy.
  • Práce v jazycích, které jsou podobné základní (viz PHP je základní)
  • Mít vizuální dovednost při převodu dokumentů Photoshopu na CSS/HTML/atd.
  • Mají vysokou toleranci pro iterační programování, kvůli psaní volných jazyků

Zadní vývojáři

  • Mít CS titul nebo spoustu zkušeností
  • Mají systematičtější přístup k řešení problémů
  • Nevadí vám strávit dny hledáním jednoho objektu, který uniká
  • Vyzkoušejte a vytvářejte nástroje k řešení problémů
30
drexsien

Pokud začnete vzadu a jdete kupředu, riskujete nedorozumění klientovi. Jak budete vytvářet věci, které nemohou snadno vidět a pochopit, nemohou se velmi snadno účastnit ověřování, zda splňujete požadavky. To znamená, že můžete ztratit spoustu práce.

Pokud začnete zepředu a jdete zpět, riskujete, že si klient bude myslet, že je to téměř hotové, když vše, co jste udělali, je nakreslit jednoduchý formulář na obrazovku. Potom se mohou ptát, proč to trvá tak dlouho, protože jste to většinou dokončili za pár dní. Také riskujete, že se budete malovat do rohu, když si uvědomíte, že musíte udělat nějakou komplikovanou práci, abyste se oženili s frontou dozadu, když by vhodnější front-end byl jednodušší.

IMO, měli byste na tom nejprve pracovat. Napište přední a zadní konec společně pro každou funkci v systému. To dává klientovi větší viditelnost pokroku a dává jim možnost říci „ne, to není to, co jsem myslel“, aniž by vám to způsobovalo přílišnou úzkost.

To znamená, že pokud se jedná o velmi velký projekt, ve kterém musíte zvážit serverový hardware nebo schopnosti jakéhokoli softwaru, na který se spoléháte (např. Na kterou databázi používáte), měli byste pravděpodobně nejprve nejprve o této části dobře promyslet.

42
Paul Butcher

Software má mnoho dimenzí, a proto je příliš zjednodušující front-back-back špatnou otázkou a je velmi, velmi obtížné poskytnout rozumnou a užitečnou odpověď.

Jedním pohledem je statická struktura dat. V tomto pohledu jsou alespoň tři dimenze: architektonické vrstvy („front-to-back“), případy použití a aktéři, jakož i náklady nebo rizika implementace.

Jedním pohledem je dynamická struktura zpracování. Tento pohled má také alespoň tři rozměry.

Třetím pohledem jsou architektonické komponenty, které přirozeně spadají do vrstev, podporují případy použití a mají náklady a rizika.

Mohl bych pokračovat, ale jde o to.

Vývojáři front-end vs. back-end (můj přístup)

Je přibližně nejméně užitečným způsobem, jak se na problém podívat. Skuteční vývojáři - a vaše názory na ně - na tom záleží velmi, velmi málo. Na čem záleží

  • Použijte případy a herce

  • Logický datový model pro podporu těchto případů použití

  • Proces, který se provádí jako součást případu použití

  • Komponenty, které použijete k vytvoření logických a procesních prvků případu použití.

To je důvod, proč většina lidí říká, že musíte svůj systém rozložit podle příběhu uživatele nebo případu použití.

Neprovádějte zevšeobecnění o lidech, kteří budou dělat vývoj.

9
S.Lott

Ani. Co musí vaše aplikace udělat? Ujistěte se, že horký ventil dodává horkou vodu, studený ventil dodává studenou vodu, že voda nejprve proudí, že můžete potrubí rozšiřovat, kdekoli je potřeba, a pak se starat o implementaci skutečného vodovodu do všech místností domu nebo toho, co bude v domě ve skutečnosti vypadají přesně.

Přední část je pouze maska ​​s několika spínači a pákami. Zadní část je jen věc, která přijímá žádosti o načtení a zpracování dat. Dostaňte se do bodu, kdy můžete rychle implementovat oba v libovolné požadované kombinaci jako první.

Ale ať děláte cokoli, nenechte design jednoho diktovat design druhého. Tímto způsobem leží šílenství.

Získejte nástroje na místě, aby mohli vaši vývojáři sestavit vše, co potřebují pro svého klienta, bez ohledu na to, kolikrát změní názor. Pak ji vytvořte podle specifikací a znovu ji spusťte, dokud nejsou malé cusse konečně šťastné.

Také srovnání front-devs-back-end-devs v roce 2008 je dávno před webovými roky. Kvůli legraci bych ráda opravila/přidala pár věcí ke starému kaštanu, protože jsme to spojili v otázce, ale (doufejme) také vložili několik tipů:

Přední vývojáři

Obvykle nemají titul CS nebo titul CS od 3. úrovně školy.

Ukázka rukou. Kolik lidí s titulem CS se naučilo osvědčené postupy na front-endu? Nebo jak neudělat nepořádek s JavaScriptem? Nebo jak řešit problémy CSS z IE6-IE9? Průmysl učebnic, který provozuje akademii, je příliš tlustý líný a nafouklý na to, aby zvládl neustále se měnící technologii, takže na vysokých školách získal jen velmi malou „vážnou“ pozornost. To bylo skvělé pro pozdní bloomery, jako jsem já.

Práce v jazycích, které jsou podobné základním (viz PHP je základní)

Protože PHP je technologie na straně klienta?) Nebo protože JavaScript, který byl inspirován primárně schématem, má více společného s Basic než Visual Basic, který již nyní nepředstavuje pokračování na frontendu a nikdy Opravdu byl, ale stále je k dispozici pro webové aplikace typu back-end .NET? Blog porovnává samoučené vývojáře s otevřeným zdrojovým kódem s vývojáři CS grad pomocí vývojových technologií pro firmy v tomto bodě. Myslím, že jsem narazil na nesnesitelné a kompetentní. podíly na obou stranách tohoto konkrétního boje, ale stále je tam OT).

Mít vizuální dovednost při převodu dokumentů Photoshopu na CSS/HTML/atd.

Více pozornosti k detailům než „vizuální dovednost“, která je trochu široká. Ne všichni z nás mají estetické designové dovednosti. Ale ano, většina z nás se musí učit tyto věci na úrovni Jr. a ve skutečnosti je naprosto rozhodující pro psaní dobrého uživatelského rozhraní, které nepoužívá kladiva JS, když budou provádět skalpely CSS.

Mají vysokou toleranci pro iterační programování, kvůli psaní volných jazyků

To je důvod, proč chcete kousky, které jsem zmínil dříve, na prvním místě. Předáme stisknutá tlačítka, vyprodukujete/načtete zboží. Zabalíme a doručíme je. Neexistuje žádný důvod, aby tyto věci byly jakýmkoli způsobem pevně svázány. Rovněž by přísné psaní nemělo zasahovat do iteračního procesu, pokud nemáte sát na OOP) které většina lidí, kteří se rádi nechají pustit do jazyka, který nemá technicky třídy, ve skutečnosti ano, obvykle "Ale i když to smrdí, frontend potřebuje pouze předvídatelný přístupový bod a vy můžete dělat cokoli sakra, které chcete na zadním konci, pokud nechcete dělat něco hloupého, jako dynamicky psát JavaScript, který není JSON nebo pevně vázat úspěšné chování koncových částí ke struktuře HTML, která je „jen tak.“ * kašel * Java devs */kašel *

6
Erik Reppen

Na to neexistuje jediná správná odpověď. Každý přístup může být v určitých situacích dobrý (a špatný).

Doporučuji zvážit přístup TDD, kde je jeden proveden (přejímacími a jednotkovými) testy.

Začněte sestavením kostry systému: základní infrastruktury s absolutní minimální funkčností. Toto je pouze ukázat, že váš koncept funguje a různé komponenty jsou schopny spolupracovat. To také zahrnuje UI holých kostí (pokud je to použitelné), stačí, aby skutečně dělal a/nebo ukázal něco minimálního.

Poté vymažete podrobnosti, funkce po prvku : napište akceptační test pro specifický prvek/scénář, nechte jej selhat, poté napište kód pro jeho uspokojení . Díky tomu budete pracovat zvnějšku : systém přijme nějakou vstupní zprávu, takže tuto zprávu musíte zpracovat/převést, udělat s ní něco, pak šířit výsledky zpět do uživatelského rozhraní. Cestou objevíte koncepty domén a budete je reprezentovat novými třídami, od uživatelského rozhraní směrem k vrstvě domény a zpět.

Pro tento přístup je doporučené čtení Rostoucí objektově orientovaný software, vedený testy .

5
Péter Török

Nejprve API

Inženýři z obou týmů by měli spolupracovat na API mezi front-endem a back-endem. Poté mohou oba týmy začít pracovat na základě navrženého rozhraní API. To má tu výhodu, že jiný front-end tým může také začít pracovat (možná mobilní, po webovém klientovi), kromě zřejmé výhody, že týmy mohou začít pracovat paralelně.

Kombinujte s iteračním přístupem a měl by vypadat takto:

  1. Navrhněte jednoduché API
  2. Oba týmy se vyvíjejí a testují na základě API
  3. Integrační test
  4. Ukažte klientovi a získejte zpětnou vazbu.
  5. Vylepšete API a opakujte.
1
m3th0dman

Začněte frontendem, ale nejprve, proč nemohou najít aplikaci, která již existuje? To by poskytlo lepší přehled o tomto projektu. Mají nějaké jedinečné požadavky nebo si myslí, že můžete stavět levněji?

Získejte plnou představu o jejich bezpečnostních očekáváních a zákonech. Nejste si jisti, jaký typ školy to je, ale informace o studentovi obvykle vyžadují určitou důvěrnost.

Pokud potenciální studenti zadávají data na webové stránce, bude grafický design více problémem.

Na základě jejich požadavků nakreslete makety přední části. Pokud si myslíte, že gui není přímo vpřed, možná budete muset udělat něco funkčního, aby ho mohli vidět v akci. Mohou vidět zápis jako nějaký typ 'průvodce', který se odbočuje v různých směrech na základě zadávání dat.

Pak můžete začít získávat informace přetrvávající do databáze.

0
JeffO

Rozšiřuji můj komentář:

Nejprve shromáždit požadavky, pak je proměnit v Pouzdra a design.

Nejprve přichází podrobná definice databáze. Je mi jedno, jestli to klient úplně nevzdal, nutím je, aby se posadili a podívali se na to - a odhlásili se (možná pak nutí pak si uvědomit, že jednou z jejich technologicky důvtipnějších chlapů by to mělo udělat) ), než budete pokračovat.

Jak můžete začít s FE bez BE? FE za co ?? Definujte svou databázi !! To FE manipuluje.

Dobře, budou problémy a později vyladění, a já do souhlasím s tím, že je dobré získat jednoduchý, vzorek, GUI před klientem ASAP, protože ten konkrétní tip ledovce je to, co nejvíce nejvíce rozumět.

I 1) stres že je to jen hrubý vzor, ​​pro diskusní porpoise, a 2) úmyslně je to ošklivé, ale funkční , aby ti, kteří nerozumí, mohli nitpick a řekni mi, aby ten vstupní rámeček měl šířku přesně 400px a pozadí světle modrou.

Padl jsem, že většina odpovědí zde (a následoval jsem je) se obvykle příliš soustředil na zákazníka, ale z čistě s/w hlediska tvrdím, že nemůžete navrhnout FE pro manipulaci s BE bez prvního navrhování, že BE.

Ano, uvědomil jsem si, že se OP zeptal chvíli zpátky. Začněte na zadním konci, ale MOCK UP frontend, aby uživatel mohl vidět, co si představujete. Přední část, za vše, co stojí za to, jsou jen zvonky a píšťalky. Zadní část je tam, kde jsou peníze, a jakmile máte rovnou, FE je jen omáčkou nad masem.

0
Fabasard