Lavoro come sviluppatore di app da un anno e mezzo (non molto tempo che lo so) e mi è appena stato dato il mio primo grande progetto.

Inutile dire che non è andato molto bene, quindi ho chiesto consiglio a un programmatore senior coinvolto nel progetto su come affrontarlo.

Ha detto che ero stato drasticamente a pensare al compito da svolgere, e che non avevo mai affrontato un progetto di questa portata prima di passare troppo tempo a pensare ai modelli di progettazione. Nelle sue sagge parole, mi disse "F * ck il futuro, costruisci per ora".

È questo un programmatore di tendenza che in genere segue quando si occupa di un progetto come questo? Ad esempio, se ti è stato chiesto di fare un modello di prova del concetto, è una tendenza tipica solo fare un esempio realizzabile il prima possibile?

Modifica: Alla luce del dibattito che ha suscitato, vorrei ricordare che questa situazione è abbastanza estrema: abbiamo scadenze molto strette a causa di fattori al di fuori del nostro controllo (vale a dire che il mercato a cui miriamo perderà interesse se non lo facciamo mostrare loro qualcosa) e il suo consiglio si è rivelato molto efficace per questo compito specifico.

Capitano Ovvio al salvataggio!

Sarò il Capitano Ovvio qui e dirò che c'è una via di mezzo da trovare.

Vuoi costruire per il futuro ed evitare di bloccarti in una scelta tecnologica o in un cattivo design. Ma non vuoi passare 3 mesi a progettare qualcosa che dovrebbe essere semplice o aggiungere punti di estensione per un'app veloce e sporca che avrà una durata di 2 anni ed è improbabile che abbia progetti di follow-up.

È difficile trovare la distinzione, perché non puoi sempre prevedere il successo del tuo prodotto e se dovrai estenderlo in un secondo momento.

Costruisci per ora se ...

• il progetto verrà demolito
• il progetto ha una durata breve
• il progetto non dovrebbe avere estensioni
• il progetto non ha un valore di impatto del rischio (principalmente in termini di immagine)

In generale, per ora dovrebbero essere sviluppati progetti interni o qualcosa di costruito per un cliente. Assicurati di avere dei requisiti semplici e riferiti a loro secondo necessità per sapere cosa è necessario e cosa no. Non voglio passare troppo tempo su qualcosa di "bello da avere". Ma non programmare neanche come un maiale.

Lascia il problema generale per dopo, se mai è necessario e ne vale la pena:

Costruisci per il futuro se ...

• il progetto sarà pubblico
• il progetto è un componente da riutilizzare
• il progetto è un trampolino di lancio per altri progetti
• il progetto avrà progetti di follow-up o rilasci di servizi con miglioramenti

Se stai costruendo per qualcosa di pubblico, o che verrà riutilizzato in altri progetti, allora hai una probabilità molto più alta che un cattivo design tornerà a perseguitarti, quindi dovresti prestare maggiore attenzione a quello. Ma non è sempre garantito.

Linee guida

Direi di aderire ai seguenti principi nel miglior modo possibile e dovresti metterti nella posizione di progettare prodotti efficienti e adattabili:

• sappi che YAGNI ,
• BACIO ,
• ogni volta che hai voglia di grattarti un prurito e pensare a un'aggiunta, scrivila. Guarda indietro ai requisiti del tuo progetto e chiediti se le aggiunte sono prioritarie o meno. Chiedere se aggiungono valore commerciale primario o meno.

So che personalmente tendo a pensare troppo e ingegnere in modo eccessivo. Aiuta davvero a scrivere idee e molto spesso ripensare se ho bisogno di funzionalità aggiuntive. Spesso, la risposta è no, oppure "sarebbe bello dopo". Queste ultime idee sono pericolose, perché rimangono nella parte posteriore della mia testa, e ho bisogno di forzarmi a non pianificare per loro.

Il modo migliore per codificare senza ingegnerizzare eccessivamente e senza bloccarsi per dopo è concentrarsi su un buon design minimale. Suddividi le cose come componenti che puoi estendere in seguito, ma senza pensare già a come possono essere estese in seguito. Non puoi predire il futuro.

Costruisci cose semplici.

Dilemmata

Overengineering

È questo un programmatore di tendenza che in genere segue quando si occupa di un progetto come questo?

Inferno sì. È un dilemma noto e dimostra solo che ti interessa il prodotto. In caso contrario, è più preoccupante. C'è disaccordo sul fatto che meno sia sempre veramente di più e se il peggio sia sempre veramente meglio . Potresti essere un tipo del MIT o del New Jersey . Non c'è una risposta facile qui.

La prototipazione / Quick-n-Dirty / Less is More

È una tendenza tipica solo fare un esempio realizzabile il prima possibile?

È una pratica diffusa, ma non è l'approccio alla stragrande maggioranza dei progetti. Tuttavia, la prototipazione è una buona tendenza secondo me, ma con un lato negativo medio. Può essere allettante promuovere prototipi veloci e sporchi su prodotti reali o usarli come base per prodotti reali sotto pressione gestionale o vincoli di tempo. Questo è quando la prototipazione può tornare a perseguitarti.

Ci sono ovvi vantaggi nella prototipazione , ma anche un sacco di potenziale per uso improprio e abuso (molti come esatto inverso esatto dei vantaggi precedentemente elencati).

Quando utilizzare il prototipo?

Ci sono suggerimenti sui migliori tipi di progetti per usare la prototipazione :

[...] la prototipazione è più vantaggiosa nei sistemi che avranno molte interazioni con gli utenti.

[...] la prototipazione è molto efficace nell'analisi e nella progettazione di sistemi online, in particolare per l'elaborazione delle transazioni, in cui l'uso di finestre di dialogo sullo schermo è molto più evidente. Maggiore è l'interazione tra il computer e l'utente, maggiore è il vantaggio [...]

"Finora uno degli usi più produttivi della prototipazione rapida è stato uno strumento per la progettazione iterativa dei requisiti degli utenti e la progettazione dell'interfaccia uomo-computer."

D'altro canto:

I sistemi con scarsa interazione dell'utente, come l'elaborazione batch o i sistemi che eseguono principalmente calcoli, traggono poco vantaggio dalla prototipazione. A volte, la codifica necessaria per eseguire le funzioni di sistema potrebbe essere troppo intensiva e i potenziali guadagni che la prototipazione potrebbe fornire sono troppo piccoli.

E se hai un mostro verde in giro, assicurati di mantenere un prototipo nel budget ...

Quando inizi a programmare, tutto è una prova del concetto, anche se è solo per te stesso. Ci sono casi in cui un'idea richiede qualcosa di rapido e sporco o un prototipo perché il tempo è un fattore chiave. La grande paura tra gli sviluppatori è che le parti interessate pensino che la piccola app sia pronta per la produzione o che tu possa essere in grado di aggiungere funzionalità allo stesso ritmo per sempre. Lavori su un grande progetto e scopri che non è così.

I grandi progetti di solito hanno requisiti più complessi, quindi c'è la tentazione di provare a implementare progetti complessi. Trascorrerai molto tempo a leggere, ricercare e cercare di implementarli. Questo può diventare un grande spreco di tempo, ma fa tutto parte dell'apprendimento e dell'esperienza acquisita. Sapere quando utilizzare un particolare design è difficile e di solito viene fornito con esperienza. Ho provato "quello" su "questo" progetto e non ha funzionato, ma ora vedo che dovrebbe funzionare "qui".

Devi pianificare e pianificare molto, ma non farlo tutto in una volta. Sicuramente non deve essere fatto tutto all'inizio. Preferirei vedere qualcuno creare il suo primo grande progetto in questo modo:

1. Progetta e discuti un po '.
2. Scrivi un mucchio di codice che fa qualcosa.
3. Riconosci i problemi e STOP alla codifica.
4. Prendi sul serio il design e smetti di preoccuparti di perdere slancio o code mojo e ignora il project manager (gli stai facendo un favore).
5. Prendi il progetto sotto controllo. Risolvi i tuoi pasticci. Assicurati che tutti comprendano il piano. Mantieni il progetto sotto controllo.

A volte colpisci una di quelle funzionalità che ti preoccupano davvero di come implementarlo nella base di codice esistente. Questo non è il momento di "farlo funzionare". Avevo un capo che diceva "A volte devi prendere uno sgabello invece di un martello". Me lo disse dopo avermi sorpreso a "pensare" alla mia scrivania. A differenza di molti capi, non pensava che stavo scherzando e si assicurò che capissi che voleva che lo facessi di più. Genio.

In definitiva, il tuo codice è il design. È supportato da documenti, diagrammi, riunioni, e-mail, discussioni sulla lavagna, domande SO, argomenti, imprecazioni, attacchi di rabbia e silenziose chat sul caffè. C'è un punto in cui non puoi più progettare e rischiare di dover perdere più tempo a progettare a causa dei difetti che scoprirai solo provando a scrivere il codice. Inoltre, più codice scrivi, più possibilità avrai di introdurre un difetto di progettazione dal quale non puoi uscire. È di nuovo tempo per lo sgabello.

I programmatori in genere costruiscono qualcosa che funziona ora senza pensare al futuro?

Sì.

Dovrebbero farlo?

No.

A prima vista sembrerebbe che "pensare al futuro" violi principi di design consolidati come KISS e YAGNI , che sostengono che non dovrebbe essere implementato nulla che non sia richiesto in questo momento.

Ma in realtà non lo fa. Pensare al futuro significa progettare un software semplice, estensibile e gestibile. Ciò è particolarmente importante per i progetti a lungo termine. Con il tempo saranno necessarie nuove funzionalità e un design solido renderà più semplice l'aggiunta di nuovi pezzi.

Anche se non hai intenzione di lavorare su un progetto dopo averlo completato, dovresti comunque svilupparlo in modo intelligente. È il tuo lavoro e dovresti farlo bene, almeno per non dimenticare quanto è buono il lavoro svolto.

Gli sviluppatori Agile hanno un detto, "You Are't Gonna Need it (YAGNI)" che incoraggia a progettare per ciò di cui hai bisogno ora piuttosto che per quello che pensi di poter avere bisogno in futuro. Per estendere un progetto per funzionare in futuro, il percorso consigliato è il refactoring.

L'aspetto importante di ciò è tenere a mente i requisiti del prodotto durante la progettazione e assicurarsi che non si stiano progettando per una serie di requisiti che potrebbero verificarsi in futuro.

C'è qualcosa da dire per gli sviluppatori che possono pensare a due o tre iterazioni in anticipo: conoscono i loro clienti o il dominio così bene che possono anticipare le esigenze future con alti livelli di precisione e costruire per loro, ma se non sei sicuro, è meglio non dedicare troppo tempo a cose di cui tu o i clienti non avete bisogno.

È questo un programmatore di tendenza che in genere segue quando si occupa di un progetto come questo?

Ho il sospetto che il tuo mentore intendesse dire che non dovresti creare alcuna complessità aggiuntiva che potrebbe non essere richiesta dalla soluzione finale.

È fin troppo facile pensare che un'app dovrebbe fare questo e quello e farsi massacrare.

Per quanto riguarda i modelli di design, vale la pena ricordare che sono un mezzo per raggiungere un fine. Se scopri con esperienza che un certo modello di design non si adatta nonostante il tuo sospetto iniziale, questo potrebbe indicare un odore di codice.

Ad esempio, se ti è stato chiesto di fare un modello di prova del concetto, è una tendenza tipica solo fare un esempio realizzabile il prima possibile?

Vale la pena prendere una guida prima dell'inizio del progetto su quali pietre miliari ci siano e se vorranno vedere un po 'di tutto (fetta verticale) o solo ogni parte in dettaglio mentre la sviluppi (fetta orizzontale). Come parte del progetto iniziale, trovo che valga la pena salire a bordo della storia dell'intera app, quindi anche se il codice non è scritto puoi fare una vista in elicottero dell'intera cosa o un'immersione profonda di una determinata area.

Ha detto che ero stato drasticamente a pensare al compito da svolgere e che, poiché non avevo mai affrontato un grande progetto come questo, avevo passato troppo tempo a pensare ai modelli di progettazione. Nelle sue sagge parole, mi disse "F * ck il futuro, costruisci per ora".

Penso che sia un po 'una mentalità da cowboy dall'altro sviluppatore. La versione moderna di un duro secchione che "lo fa ora". È diventato un tema popolare tra le startup e no grazie alle persone su Facebook per aver iniziato la frase "farlo è meglio che farlo nel modo giusto".

È attraente. È incoraggiante e offre visioni di sviluppatori in piedi intorno a una console battendo le mani mentre lanciano il loro grande progetto nel mondo in tempo, budget e tutto perché non hanno ingegnerizzato nulla.

È una fantasia idealistica e la vita non funziona in questo modo.

Un pazzo si precipiterà in un progetto pensando di poter semplicemente "farlo" e farlo. Il successo favorirà lo sviluppatore che si prepara alle sfide invisibili e tratta la sua professione come una raffinata maestria.

Qualsiasi sviluppatore senior può criticare, condannare e lamentarsi - e molti lo fanno!

Mentre lui / lei ti dice che stai "pensando troppo" al progetto. Mi congratulo con te per aver "pensato" per primo. Hai mosso i tuoi primi passi per diventare uno sviluppatore migliore dell'altro.

È questo un programmatore di tendenza che in genere segue quando si occupa di un progetto come questo? Ad esempio, se ti è stato chiesto di fare un modello di prova del concetto, è una tendenza tipica solo fare un esempio realizzabile il prima possibile?

Questo è esattamente ciò che è una prova del concetto. È un tentativo di schiacciare qualcosa il più rapidamente possibile in modo che le persone possano fare un passo indietro e guardarlo. È fatto per prevenire errori, cattiva direzione e spreco di tempo / denaro.

Esistono molti tipi diversi di prove di concetti. Al termine, puoi creare qualcosa che viene gettato nella spazzatura oppure creare qualcosa che rappresenti un punto di partenza per il progetto. Tutto dipende da ciò di cui hai bisogno e da quanto è vicino il concetto al prodotto finale.

È anche un'opportunità per dimostrare le tue idee. Ci sono state volte in cui ho presentato un prototipo che ha portato le cose a un livello che non si aspettavano.

Il design è di solito a tempo indeterminato, quindi è troppo facile applicarne troppo o troppo poco. E conoscerai l'importo corretto solo dopo che il progetto sarà terminato o scartato. O nemmeno allora.

Non esiste una ricetta generale per il successo, ma puoi imparare a riconoscere gli estremi. Il design completo di tutto ciò che accade davanti non funziona quasi mai al di là di cose banali. Va bene lasciare i componenti per la raffinazione e avere la sensazione che possa essere fatto o c'è un modo per scoprire i problemi in anticipo.

Potresti cercare come funziona lo sviluppo incrementale se non hai familiarità. I metodi di successo di solito sono iterativi su uno o più livelli, cercano feedback ravvicinati e crescono su alcuni scheletri.

Ci sono alcuni buoni motivi per ascoltare i consigli per interrompere la pianificazione e iniziare a scrivere codice;

1. Dopo solo 18 mesi come sviluppatore, è improbabile che tu possa anticipare il futuro abbastanza bene da programmarlo, indipendentemente dal GPA del college. Questo è qualcosa che è estremamente difficile da comprendere per gli sviluppatori brillanti ma inesperti, poiché si tratta di non sapere ciò che non si conosce. Le mani esperte potrebbero aver riconosciuto questa debolezza nella tua visione e saggiamente ti hanno incoraggiato ad entrare e fare del tuo meglio.

2. I giovani sviluppatori potrebbero diventare ossessionati dal perfezionamento del design prima di iniziare a scrivere codice. Potrebbero coprire la paura di scrivere il codice (ansia da prestazione) o potrebbero avere un blocco del programmatore (come il blocco degli scrittori). Si perdono nella progettazione perché non è necessario alcun output di lavoro. Il giovane sviluppatore probabilmente risponderà con rabbia al suggerimento di "aver paura" di qualcosa. Forse alla fine del progetto si renderanno conto che lo erano. Il consiglio di non preoccuparti e ottenere la codifica costituisce l'unica cura nota per il blocco del programmatore. Una vecchia mano può saggiamente offrire questo consiglio.

3. In presenza di rigidi vincoli di programma, le possibilità di portare a termine il progetto sono limitate. Pianificare troppo a lungo, e non importa quanto sia buono il piano, non è possibile eseguirlo in tempo e non si arriva mai al mercato. Inizia a smanettare fin dall'inizio, e forse sarai fortunato e avrai ragione la prima volta. Consegni il prodotto miracolosamente. Oppure, forse non sei così fortunato, e distribuisci un pezzo di scorie cotto a metà ma arriva sul mercato in tempo e impari qualcosa. O forse fallisci. Ma "forse hai fallito" è ancora una probabilità migliore di "non arrivare mai sul mercato" perché hai pianificato troppo a lungo. La comprensione chiave è che le tue possibilità sono limitate dall'inizio, quindi non perdi nulla con l'hacking. Il tuo manager potrebbe sapere che ci sono poche possibilità di successo e ha assegnato una risorsa junior proprio come un esercizio di apprendimento. Impariamo meglio dal fallimento che dal successo. Hai forse chiesto "Quando posso avere un intero progetto?"

Ci vuole uno sviluppatore piuttosto introspettivo e privo di ego per vedere le proprie imperfezioni, quindi medita un po 'prima di leggere il resto, affinché non ti dia scuse per trascurare le tue debolezze ...

Non tutti gli sviluppatori sono particolarmente bravi nell'analisi, nella pianificazione e in altre attività che richiedono riflessione. Il pensiero è duro e icky. Richiede una sorta di sudore mentale che ti mette a disagio e strizzato dopo una giornata di lavoro. Non è così divertente come entrare nello stato di flusso con le tue due lattine di Monster e il tuo rock si è alzato rumorosamente e codificando, codificando, codificando. Gli sviluppatori a cui non piace pensare resisteranno all'idea che la pianificazione sia una buona idea. Raccomandano metodologie di sviluppo che non richiedono una pianificazione anticipata. A loro piacciono le aziende e i manager che non enfatizzano la pianificazione. Gravitano verso lavori in cui il costo della non pianificazione non è troppo elevato. Stimano per tutta la notte le sessioni di codifica e distribuiscono questo aggiornamento rapido ai clienti la cui intera attività è fallita a causa di un bug.

Alcuni sviluppatori si sono persino resi conto che far funzionare qualcosa abbastanza bene da dimostrarlo significa che farlo funzionare completamente e in ogni circostanza può essere rinviato, e forse persino spinto su un altro sviluppatore, mentre ricevono complimenti per "portare a termine il lavoro" inizialmente.

Ci sono manager che non possono da soli individuare una tendenza fino a quando non si sta già rompendo su Facebook. Invece di trovare un lavoro nella gestione di un negozio di pneumatici scontati, questi gestori hanno il problema di aver bisogno del codice in esecuzione entro venerdì. Non vogliono sentire che è necessario progettare l'API o verificare se l'algoritmo è scalabile. Questo è solo un mumbo-jumbo tecnologico per loro. Ti incoraggeranno a programmare perché è tutto ciò che hanno capito sul software quando scrivevano script perl per aiutare i clienti a trasferire i propri file. (Avevano il titolo di "ingegnere del software" nel loro primo lavoro di vendita. Chi sapeva che il software sarebbe stato così noioso e difficile?)

Mostrami il tuo codice e ti dirò chi sei

Il tuo codice è il tuo biglietto da visita. Se scrivi un codice disordinato, cosa ti dice di te agli altri? Basti pensare a quello. Ogni volta che troviamo in ufficio un frammento di codice davvero brutto, ci chiediamo, chi lo ha scritto e come diavolo è passato attraverso l'università?

Stai diventando ciò che codice

Il tuo codice è il tuo programma per la vita.

Un programmatore che scrive codici errati è come un ballerino che danza nel club di spogliarello

Ad alcune persone non interessa ballare nel club di spogliarello. Ma se sono ballerini di alto livello, stanno sprecando le loro abilità. Se sei un povero ballerino ma hai delle belle gambe, puoi spogliarti per molti.

Infine, dovresti leggere il romanzo di Gogol "Il ritratto" e dovresti essere avvertito dalla storia del personaggio principale. Il tuo amico è simile all'uomo del ritratto. Ti sta attirando con i soldi, ma pagherai il prezzo elevato.