Una delle idee che mi intriga \u00e8 la mentalit\u00e0 "ship it or muori". Riguardo a come si chiama, ci sono variazioni, ma l’idea alla base della frase \u00e8 semplice:<\/p>\n
Se hai un’idea, portala dall’ideazione al prodotto il pi\u00f9 rapidamente possibile.<\/p>\n
Certo, l’idea di arrivare al concept di un prodotto pu\u00f2 anche essere chiamata "concept to cash", ma non c’\u00e8 mai la garanzia che genererai denaro, giusto? C’\u00e8 una garanzia che puoi trasformarlo in un prodotto tangibile, per\u00f2.<\/p>\n
E nei circoli di sviluppo software, c’\u00e8 sempre molto per cui una persona pu\u00f2 discutere a favore o contro l’idea. In cima alla mia testa, i due pro e contro che mi vengono subito in mente sono:<\/p>\n
In breve, potrebbe esserci un compromesso tra la velocit\u00e0 con cui puoi spedire qualcosa per un mercato e l’architettura dietro il progetto. A volte c’\u00e8, a volte non c’\u00e8. In generale, per\u00f2, penso che sia lecito presumere il primo.<\/p>\n
Inoltre, alcuni potrebbero vedere la prima come una facile via d’uscita, alcuni potrebbero vedere la seconda come un esercizio in YAGNI o, ancora pi\u00f9 semplicemente, che il problema pu\u00f2 essere affrontato ogni volta che si presenta.<\/p>\n
Ma cosa c’entra questo con qualcosa in questo momento?<\/p>\n
L’intera ragione per cui sto dedicando tempo a scrivere di questo \u00e8 che \u00e8 qualcosa a cui io, e sospetto che altri nel nostro campo, riflettiamo almeno un po’. Tutto questo va bene quando se ne parla in senso astratto, ma vorrei provare a legarlo a qualcosa di un po’ pi\u00f9 realistico.<\/p>\n
Alcuni anni fa, lo sviluppo del front-end consisteva nel racchiudere il contenuto in elementi inline oa livello di blocco e modellarli con CSS di base?<\/p>\n
Avevamo strumenti avanzati per lavorare con il nostro codice back-end, ma il front-end era relativamente semplice a parte forse gli standard di codifica imposti dall’azienda o dal team con cui lavoravamo.<\/p>\n
I nostri dispositivi avanzati (che, per la cronaca, considero una cosa buona e persino naturale nella tecnologia). Insieme a tale avanzamento, ora disponiamo di strumenti di creazione specifici per lo sviluppo front-end che sono altrettanto avanzati per alcuni aspetti rispetto a quelli che utilizziamo per il software di back-end.<\/p>\n
Certo, abbiamo alcuni che sono "sviluppatori full stack", ma sono felice di ammettere che sono molto pi\u00f9 a mio agio a lavorare sul lato server che sul front-end. Se lavoro sul front-end, tendo ad attenermi agli strumenti che conosco e cerco di rimanere all’interno dei guardrail definiti dalla corsia in cui opero.<\/p>\n
Aiuta a mantenere lo sviluppo concentrato, veloce e coerente tra i progetti.<\/p>\n
Di per s\u00e9, questa sezione potrebbe essere un post lungo, ma non mi interessa andare cos\u00ec lontano. Invece, prender\u00f2 una singola fetta di come funziona lo sviluppo front-end in questo momento e vedr\u00f2 se non riesco a usarlo per chiarire il mio punto.<\/p>\n
Prendi ad esempio ci\u00f2 che \u00e8 diventato CSS. Abbiamo le lingue sopra le lingue (come Sass<\/a><\/strong> che si trova sopra o aggiunge ai CSS di base).<\/p>\n E abbiamo processori che compilano, minimizzano, sfilacciano e ci impediscono di vedere il nostro lavoro prima che determinati errori e avvisi vengano corretti per motivi di qualit\u00e0. (Non lo considero una cosa negativa, ma mostra il livello crescente di complessit\u00e0 – o forse maturit\u00e0 – dei nostri strumenti di front-end).<\/p>\n Lo sviluppo del front-end \u00e8 fin troppo facile, rendiamolo pi\u00f9 complesso in modo da poterci sentire pi\u00f9 intelligenti tra quei nostri colleghi che apparentemente hanno a che fare con aspetti pi\u00f9 "critici" del business. Ricorda che questa \u00e8 una competizione.<\/p>\n<\/blockquote>\n\n