Sviluppatori front-end vs codificatori HTML / CSS più "lo sviluppatore JavaScript" [chiuso]

Naviga le tue risposte
3

Stavo solo cercando su google per trovare una buona definizione di sviluppatore front-end e le definizioni che ho trovato erano più o meno "un ragazzo che fa HTML / CSS / JavaScript (jQuery)".

Ma penso che non sia più così. Oggi abbiamo interfacce molto complesse, diciamo una singola app BackboneJS che richiede molto di più che "un ragazzo che fa HTML / CSS / JavaScript" e che non ha esperienza in Informatica.

Direi che il ragazzo che progetta l'app di front-end (Backbone, Angular, ecc.) dovrebbe essere (se non di più) un abile programmatore rispetto al ragazzo che progetta il back-end.

Quindi nel mio scenario ( app web singola pagina - dire con Backbone), ho 3 persone:

  1. Un programmatore di back-end - il responsabile di tutte le chiamate API che l'app Backbone avrebbe reso
  2. Un programmatore "front-end" - il tipo che è responsabile di ottenere il lavoro dal designer (wireframe se lo desideri) e trasformarlo in un codice HTML / CSS reattivo, cross-browser e multipiattaforma
  3. Lo sviluppatore "JavaScript" che illumina tutto, collega HTML / CSS all'API e dà vita all'app.

La mia domanda è: qual è la struttura del team di sviluppo moderno più abituale? Com'è solitamente suddiviso il lavoro tra gli sviluppatori front-end e back-end.

Ovviamente se hai solo sviluppatori full stack in grado di produrre JavaScript e dire PHP altrettanto bene, allora hai meno problemi. Ma comunque, chi è lo sviluppatore front-end e come si chiama "lo sviluppatore JavaScript"?

Scusa il mio linguaggio semplice, ho cercato di stare il più lontano possibile dalla terminologia.

    
posta Teodor Talov 13.05.2014 - 10:07
fonte

1 risposta

1

Sono d'accordo sul fatto che tu abbia una struttura di team di sviluppo "moderna". Proprio come gli ultimi di cui ho fatto parte.

Penso che le inefficienze possano derivare dalla definizione di responsabilità o "domini" come proprietà intrinseche del team, tuttavia, odora troppo come una raccolta di lavori piuttosto che un team di ingegneri che aggiunge il maggior valore possibile al raggiungimento di un obiettivo comune.

Penso che la familiarità completa sia essenziale, quindi tutti parlano correntemente la stessa lingua - descrivendo problemi e soluzioni con precisione (end-to-end, se appropriato) costruisce la fiducia nella direzione del progetto e accelera la discussione dei problemi difficili. Crea anche un 'noi', una 'nostra cosa' per ogni membro del team che deve restare indietro e possedere. Se solo un ragazzo è "l'interfaccia utente", hai una porta verso concetti come la colpa e il martirio che si insinuano nella dinamica.

Viceversa, la proprietà e le competenze condivise, combinate con la vera esperienza in aree specializzate crea un ecosistema fertile in cui ogni membro è ispirato dai suoi compagni di squadra, e ha l'esperienza empowering di creare un contributo appagante, in cui hanno "guidato" l'intero squadra, ispirando mi rivolgo.

Soprattutto, la mia opinione è che ci dovrebbe essere un focus ricorrente sull'utente e il design di una "esperienza" che "funziona" in modo trasparente

L'onestà e la fiducia nelle capacità del tuo team non possono essere prodotte, tuttavia una cultura con un apprezzamento pervasivo del servizio clienti reale è ciò che ho visto lavorare prima, con grande efficacia.

    
risposta data 13.05.2014 - 12:26
fonte

Leggi altre domande sui tag

Accede agli oggetti di un contenitore con un motivo Domanda di licenza di Dalvik + Java