Hvordan strukturere prosjekter for utvikling av nettløsning - Frontend vs. Backend

[Anonym5656]

Hei!

 

Lurte på hvordan folk i bransjen strukturerer måten man jobber på med tanke på backend og frontend når det gjelder avanserte nettløsninger? Har jobbet med et prosjekt nå en stund hvor jeg har hatt mye av ansvaret for frontend/design, og ser at ting ikke fungerer helt optimalt.

 

Er det noen som har erfaringer for hva som fungerer best for å oppnå best mulig resultat?

F.eks. Lager designer skjermbilder først, for å gi disse til utviklere som gjør at dere fungerer i praksis, eller lager utviklerne en funksjon som fungerer, og designeren gjør slik at dette "ser pent ut".

 

I mitt tilfellet er det en nettløsning hvor det innholder flere funksjoner og flere brukere som har forskjellige visninger(tabeller, oversikter, brukerprofiler osv), og jeg laget først digitale skisser på hvordan dette skulle se ut. Men som tiden har gått har jo det kommet flere funksjoner som backend-utviklere har implementert og dermed bestemt hvordan skal fungere og se ut(noe som gjør at dette skiller seg helt ut i fra det jeg har laget).

 

Fyr løs for dere som har noe erfaringer med dette og kan dele noen tanker på hvordan slike prosjekter bør strukteres!

Endret 27. mai 2010 av Gakkakk

[Matsemann]

Backend skal jo ikke på noen måte bestemme hvordan ting skal se ut. Hvordan gjør de dette?

 

Backend skal jo heller ikke trenge å se designet. Bare lage funksjoner og hente frem data som blir etterspurt.

 

MVC?

[Anonym5656]

Veldig enig! Men når backend spytter ut dataen så lager de en tabell og setter på noen knapper, og om jeg velger å gjøre noe annet med denne dataen så får jeg høre "hvorfor fjernet du tabellen, skal vi ikke heller gjøre det slik, osv". Da mener jeg at jobben jeg gjør er ganske meningsløs.

 

Mener du at backend ikke engang skal lage outputen i enkel html også? For de som ikke har alt for mye programmeringserfaring kan dette være greit for å slippe å finne igjen funksjoner og variabler o.l. Og backend må kanskje uansett generere enkel html slik at de ser at ting fungerer..?

[Matsemann]

Man skal skille backend og frontend, altså skal ikke de ha noe med html å gjøre, annet enn å gi dataen. Du bør isåfall få bestemme hvordan tabellen bygges. Da er det greit med en form for template system, eller at du i så fall gir dem koden til tabellen slik du vil ha den.

[Bolson]

At man skal skille presentasjon og logikk i så stor grad som mulig er vel nesten selvklart i enhver utvikling av programvare, også nettløsninger.

 

Men for meg virker faktisk ikke det å være hovedproblemet her. Hovedproblemet virker vel så mye å være at prosjektet fungerer dårlig når det gjelder kommunikasjon, arbeidsfordeling, spilleregler, metode og oppdragsbeskrivelse. Jeg kan ta feil, men problemet virker velkjent ut fra egen erfaring.

 

Når det gjelder spørsmålet om "backend" skal spytte ut HTML-kode, så vil jeg si klart nei. Dvs., velger man å bruke MVC metodikk så kan gjerne backend programmere også kode views, men da primært etter designers eller kundes spesifikasjon. Og på en slik måte at views enkelt kan justeres (som er hensikten med å skille views fra model og kontroller). Om man ikke koder etter MVC, så er det som matsemann skriver, svært greitt å bruke et "templating system". Templating system gjør det også enkelt for utviklere å lage en enkel mal for å teste funksjonalitet, mens designer kan manipulere malene slik han ønsker. Det gjør også løsningen mer fleksibel.

 

Men som nevnt ovenfor, min erfaring er at arbeidsformen i prosjektet - dvs samhandlingen, som oftest er nøkkelen til at det skal fungere bra.

[Anonym5656]

Du treffer nok bra når det gjelder arbeidsformen, Bolson. Arbeidsfordeling og hvem som har ansvar for hva tror jeg ligger alt for løst. Dette kommer kanskje tydelig frem ved at måten ting skjer på er at utviklerne skriver html-en og at jeg/designeren etterpå blir bedt om å "pynte på det" – noe jeg mener blir litt feil.

 

Men det dere sier om at backend/utvikler ikke skal skrive noe html-kode, hvordan kan kan da denne utviklere vite om det han lager fungerer eller ikke? Må da backend/utvikleren først programmere logikken og kontrollerne og deretter vente på at jeg/designeren har laget views for disse for å se om det utvikleren har laget faktisk fungerer?

[Bolson]

Utvikleren kan fint lage enkle views for å teste funksjonaliteten - det vil ikke hindre deg i å designe med skikkelig kode etterpå. Poenget er at HTML koden ikke skal være blandet inn alle steder som gir funksjonalitet. Personlig bruker jeg en publiseringsløsning som lenge har skilt presentasjon og logikk - ikke primært gjennom MVC, men ved bruk av markers (templating system). Når jeg da skal testen om funksjonen virker, så lager jeg bare en helt enkelt HTML med markers. Denne kan jeg endre så mye jeg vil etterpå uten å endre noe i selve modulens kode. Så uten å endre noe i funksjonen kan jeg velge mellom tabell, visning i bokser, legge til/ta vekk informasjon etc.

 

Poenget er at selve funksjonen kommer med all relevant informasjon på en måte som jeg designmessig kan manipulere. La oss eksemplifisere det med et system for oversikt over personer og adresser. Jeg ønsker da å ha tilgang i malsystemet på alle relevante data på en måte at jeg kan enkelt kan lage ulike lister og visning av enkeltposter bare ved å velge hvilke markers jeg bruker i HTML-koden. Om jeg bare ønsker en liste med navn, så skal jeg kunne gjøre det uten å måtte få utvikler til å skrive ny kode.

 

Mulig det er litt krøkkete beskrevet - men håper det forstås.

Endret 27. mai 2010 av Bolson

[Thlom]

Tror kanskje dere burde funnet en systemutviklingsmetode å forholde dere til. Når det plutselig dukker opp ny funksjonalitet uten at du blir konsultert så er det noe galt et sted. Om programmererne bare sitter for seg selv og spyr ut funksjonalitet som du etter beste evne må prøve å gjøre fint så vil det fort kunne føre til at produktet blir fullt av unødvendig og vanskelig tilgjengelig funksjonalitet.

 

Når man begynner å programmere så bør all funksjonalitet være bestemt, hvis ikke blir det fort rotete og ustrukturert.

 

Minstekravet bør være at dere kommuniserer jevnlig.

[cruzader]

har vært med på et par prosjekt for utvikling av nettløsninger, da hovedsakelig til internbruk i bedrifter som intranet, lager/ticket/support systemer laget spesielt for den aktuelle bedriften.

 

har hovedsakelig jobbet sammen med samme folkene, fremgangsmåten har altid vært ganske lik men fellestrekket er en relativt lang oppstartsprosess.

- kartlegge kunden/bedriften sitt ønske av funksjonalitet

- felles møte hvor vi kikker på lignende systemet og vurderer deres løsninger og hva vi liker fra de forskjellige (trenger ikke altid finne opp hjulet pånytt).

- frontend har møte for seg hvor de lager et par utkast i statisk utgave som presenteres for kunden/bedriften som velger hvilken de vil ha.

- backend har møte for seg og blir enige om tabellstrukturer, navn på alle variabler, hvor detaljert kommentering skal være, hvilke funksjoner som trengs og navngir disse.

- møte med alle igjen hvor begge "leire" deler sine resultater og fremgang, frontend får navneliste på alle funksjonene samt hva alle variablene blir hetende.

- frontend lager hele systemet statisk for en siste godkjenning fra kunden før det går i utvikling.

- frontend og backend starter på sine respektive deler, kort fellesmøte ved start samt slutt på dagen med kort statusoppdatering samt info om noe som evnt har måttet endres på.

- beta testing, lar en blackhat prøve angripe/skade systemet først uten en bruker så med en lav rettighets bruker for og avsløre evnt sikkerhetshull.

- retter opp evnt hull og bugs funnet i beta, presentere ferdig produkt for kunden

- profit

 

gjennomgående "motto" under hele prosessen at funksjonalitet og brukervennlighet har hovedsete, alt kan kodes enkelte ting tar bare mer ting og snarveier som gir kompromis i funksjonalitet eller brukervenlighet er utelukket.