Una guida di base per la scelta del giusto stack tecnico per il lavoro dei clienti

Foto di Robert Anasch su Unsplash

Comprendere l'impatto della scelta del giusto stack tecnologico è un importante fattore di successo per gli sviluppatori freelance. Questa guida esplora le domande chiave a cui dovresti rispondere quando scegli le migliori tecnologie per l'applicazione o il sito web del tuo cliente. Ti consigliamo di leggerlo prima di saltare con noncuranza sul più recente framework JavaScript.

Come molti sviluppatori che hanno un po 'di esperienza sanno, costruire software professionalmente non significa solo spedire prontamente. Si tratta anche di ottimizzare per manutenibilità, scalabilità e sicurezza e il livello di ciascuno dipende dall'attività del cliente.

Una corretta analisi del progetto determinerà quali tecnologie dovresti usare, non viceversa. Questo semplice principio promuoverà relazioni commerciali a lungo termine.

L'impatto delle tue scelte tecnologiche si farà sentire in quasi tutti gli strati del business, dalle risorse umane ai finanziamenti, dalla gestione al marketing. Una mancanza di visione potrebbe rovinare la tua reputazione - un vantaggio che nessun libero professionista dovrebbe compromettere.

Per creare il seguente elenco, abbiamo intervistato gli sviluppatori freelance senior sulle importanti domande che si pongono prima di scrivere una singola riga di codice. Abbiamo diviso i risultati in 3 blocchi: comprensione del progetto (prospettiva aziendale), raccolta dello stack (prospettiva tecnica) e passaggio della torcia (prospettiva delle risorse umane).

Iniziamo.

Comprensione del progetto

È obbligatorio comprendere la visione del prodotto, l'attività del cliente e i tempi del progetto.

Qual è l'ambito, il budget e il calendario del progetto?

Il tuo cliente ha bisogno di tutto ciò che è stato consegnato in 2 settimane per sopravvivere o è un progetto a lungo termine che richiede robustezza e massima manutenibilità?

Dovresti sapere:

  • Quando deve essere consegnato?
  • Per quante ore possono pagare?
  • Qual è il risultato atteso?

Le risposte definiranno il quadro approssimativo per le seguenti domande. È anche un ottimo modo per sapere se il tuo cliente ha aspettative realistiche prima di iniziare (per ulteriori informazioni sui segnali per identificare i clienti terribili, leggi questo post).

È un progetto unico o di lunga durata?

Un progetto di breve durata che verrà immediatamente cestinato dopo un evento o una determinata pietra miliare non dovrebbe essere affrontato come un progetto decennale.

Non ha senso sovraprogettare l'architettura di un prototipo: è solo un ottimo modo per sprecare prezioso budget. D'altra parte, se il cliente prevede di assumere 20 sviluppatori nei prossimi 5 anni per iterare sulla base di codice, sarà necessario costruire pilastri robusti su tecnologie ampiamente testate.

Possono gestire il debito tecnico?

Un cliente che è costretto a generare entrate tollererà un po 'di debito tecnico per arrivare sul mercato al più presto. Se la raccolta di dati di marketing è l'obiettivo principale, non si preoccuperanno della continua integrazione e della percentuale di copertura del test. Obiettivi aziendali prima, obiettivi tecnici seconda.

Un po 'di educazione potrebbe essere necessaria qui. È tua responsabilità farli comprendere le conseguenze dell'accumulo di debito tecnico a lungo termine. Dimostrare tale lungimiranza è un buon modo per costruire credibilità.

Quanto deve essere sicuro?

Ora pensa al campo di attività del tuo cliente per un secondo. È probabile che la sensibilità dei loro dati varierà, giusto? Bene, le tecnologie che sceglierai devono riflettere questa realtà unica. Non avrai bisogno di una protezione RSA e DDoS a 4096 bit per il sito web del festival locale.

Ma integrare un plug-in sperimentale con exploit noti per un'app che ospita informazioni finanziarie? Un po 'rischioso, amico.

Tuttavia, filtra leggermente quando si tratta di clienti ossessionati dalla sicurezza. Alcuni di loro ascoltano storie horror fuori contesto che li tengono svegli di notte:

"Ma sono convinto che questi hacker russi che ho visto in TV ruberanno la mailing list del nostro ristorante".

No, caro cliente. Probabilmente non lo faranno.

Posso gestire il progetto?

Scegliere un progetto molto al di sopra del tuo livello di abilità finirà quasi sicuramente nel caos.

Le tue scelte non istruite graveranno sul flusso di lavoro e mancheranno le pietre miliari. Non essere sconsiderato con i soldi del tuo cliente - le conseguenze legali non sono mai troppo lontane.

Se hai dei dubbi sulla tua capacità di consegnare un progetto, assicurati di fare le tue ricerche prima di salire a bordo.

Scegliere lo stack giusto

Ora passiamo alle preoccupazioni relative alla gestione del progetto. Parliamo di ciò che conta davvero: lo stack. Scegliere le tecnologie giuste dovrebbe essere naturale se hai un po 'di esperienza e una chiara visione di ciò che devi costruire.

Come posso non codificare?

Centinaia di framework e migliaia di plugin sono gestiti da comunità attive di sviluppatori. Non perdere il tuo prezioso tempo ri-sviluppando qualcosa che è già stato raffinato nel corso degli anni.

Forse non hai nemmeno bisogno di un server! Persone generose e appassionate stanno cercando di semplificare il tuo lavoro, non trascurare i loro sforzi. Reinventare la ruota è stupido.

I tempi di sviluppo dovrebbero sempre concentrarsi su ciò che rende unico il progetto: la logica aziendale personalizzata. Prima di scrivere una singola riga di codice, assicurati che aggiunga valore al progetto.

È eccessivo o insufficiente?

Il tuo cliente prevede di vendere magliette personalizzate ai clienti locali attraverso un piccolo e-commerce? Non è necessario un meccanismo di cache front-end senza SQL ad elevata disponibilità, bilanciamento del carico, cluster, pronto a supportare un milione di clienti simultanei. Sarebbe come uscire dal tuo appartamento con una nave mercantile.

D'altra parte, cercare di abbattere un toro con una fionda non è molto efficace. Un cliente che prevede di vendere migliaia di articoli su base giornaliera ti risentirà per aver scelto una soluzione CMS gratuita distribuita su un'istanza economica.

Scegli lo strumento giusto per il lavoro.

Queste tecnologie sono ben documentate e supportate?

Scavare in una base di codice giapponese senza commenti perché un plug-in arcano improvvisamente ha smesso di funzionare non è il modo migliore per passare una notte. Assicurati che ci sia una comunità attiva attorno a ogni tecnologia che scegli. Se l'ultimo aggiornamento del repository è stato 4 anni fa, preoccupati.

Quella sensazione di impotenza quando ottieni 3 risultati Google inutili per la tua domanda tecnica è ancora peggio quando il cliente ti sta urlando al telefono.

Comprendo i rischi associati alla nuova tecnologia?

Quel quadro di tendenza su HackerNews probabilmente non è stato testato correttamente su strada. Potresti sentirti nervoso per usarlo come pilastro centrale di un progetto di produzione, ma sappi solo che aggiunge una grande quantità di rischi esterni non necessari.

Se ti senti ancora incurante, almeno sperimentale abbastanza per sapere se supporta i casi d'uso del tuo cliente. A loro non importa che il tuo framework ottenga 300 voti positivi se devi cambiarlo il giorno prima di un importante traguardo.

Passare la torcia: non si tratta solo di te

fonte

Odio scomporlo in questo modo, ma il tuo cliente non vuole fare affidamento su di te per sempre. Certo, il tuo stack potrebbe essere robusto, ben documentato, sicuro e velocissimo.

Ma se solo una piccola comunità di sviluppatori in tutto il mondo sa come farlo funzionare, stai creando un punto morto. I clienti odiano i deadlock.

Saranno in grado di trovare sviluppatori che lavorino con il tuo Stack?

Potrebbe essere perché non puoi più lavorare con loro, o perché vogliono ridimensionare il team, o forse vogliono rimpatriare gli sforzi di sviluppo internamente. Ma alla fine, il tuo client avrà bisogno di un altro sviluppatore per inviare il codice alla base di codice.

Se devono passare attraverso ogni singola bacheca di lavoro nel mondo per trovare un singolo sviluppatore con una competenza specifica, indovina chi sarà la colpa?

Avranno i soldi per pagare per tali sviluppatori?

Se le uniche persone che possono assumere per lavorare sul tuo stack tecnologico eccessivamente complicato sono guru costosi con 20 anni di esperienza, potrebbe essere più conveniente avere qualcun altro a rifare tutto con le tecnologie tradizionali.

Non tunnel la visione degli sforzi di sviluppo, non riguarda solo te.

Conclusione

Speriamo che questo breve articolo ti aiuti a evitare storie horror, notti stressanti e discussioni imbarazzanti. Precipitare le decisioni tecniche prima di rispondere alle domande chiave non ti farà risparmiare tempo nel lungo periodo. Questa è esperienza nel parlare.

Prenditi il ​​tuo tempo per valutare correttamente la situazione anche se hai già voglia di aprire il tuo IDE o l'editor di codice.

Clienti soddisfatti = Affari di ripetizione / referral = Meno sforzi di Bizdev = Sviluppo di più tempo trascorso.

Nota: questo post è stato realizzato in stretta collaborazione con Philip Barclay, un mio buon amico. Phil ha realizzato prodotti digitali per anni e ora sta realizzando cose fantastiche presso Mirego e Picks.

Facci sapere se nei commenti abbiamo perso domande chiave!

Originariamente pubblicato sul blog Snipcart e condiviso nella nostra newsletter.