Capstone Week 5: il know-how è inutile senza "know-why" e come imparare i frame come un ingegnere

Imparare come usare un framework non è esso stesso ingegneria del software. L'apprendimento dei problemi risolti dal framework nei suoi domini problematici è più vicino all'ingegneria del software. Se il progetto a cui stai lavorando pone sfide che vanno ben oltre ciò che può essere risolto da un semplice framework, si tratta di ingegneria del software. Facebook usa React e anche l'app pratica del carrello della spesa che ho costruito in un giorno o due. Facebook è un'incredibile impresa di ingegneria; la mia app del carrello non lo è.

Ci sono alcuni aspetti dell'apprendimento di un nuovo strumento o quadro che mi piace e altri che non mi piacciono. Mi piace conoscere i problemi che i framework risolvono o i compromessi posti dai diversi metodi di strutturazione del codice. Ad esempio, trovo il modello di design Flux semplicemente geniale. La creazione di un'app senza Flux diventa incredibilmente disordinata poiché devi passare lo stato dell'applicazione attraverso una moltitudine di componenti, solo per quei componenti figlio che possono chiamare una lunga catena di funzioni antenate fino a quando il componente proprietario dello stato viene avvisato dell'evento in uno dei suoi figli, nipoti, pronipoti, ecc. Flux rende astronomicamente più semplice pensare a cosa sta facendo un'app, a come viene gestito lo stato e di quali componenti sono responsabili anche quando cresce la base di codice.

Questo è ciò su cui concentrarsi nell'apprendimento di un nuovo framework: quali problemi risolve e come? Qual è la filosofia da cui è nata la soluzione? Qual è l'architettura generale e quali punti deboli introduce questa architettura? Quali credenze prescrittive su come risolvere un problema hanno informato la creazione di questa particolare soluzione e condividete queste credenze? Se non li condividi, dovresti? Un framework è molto più di uno strumento: è una dichiarazione sul modo in cui un problema fondamentale, o molti problemi fondamentali, dovrebbero essere risolti. Quando ho il compito di apprendere un nuovo strumento o quadro, queste sono le domande che faccio. Non mi interessa memorizzare le sfumature esatte della configurazione del webpack: arriverà col tempo e, in caso contrario, è qualcosa che posso facilmente ricercare in pochi minuti. Posso chiedere a Google cosa significa un messaggio di errore. Non posso chiedere a Google se le decisioni di progettazione di un framework e i compromessi che introducono sono quelle con cui concordo.

Imparare bene un quadro e impararlo rapidamente non si escludono a vicenda se si è armati della conoscenza dei fondamenti del dominio in cui si sta lavorando. È inoltre necessario assegnare le priorità alle proprie conoscenze in base a un'agenda pre-concepita. La mia agenda è quasi sempre: "Comprendi il" perché "tanto quanto il" come ". Il motivo è questo: sarai sempre più competente con uno strumento se conosci il motivo della sua esistenza e il motivo (i) delle decisioni alla base del suo design. “Come?” E “Perché?” Non sono domande non correlate, e in effetti, avere una forte comprensione del “Perché” rafforzerà la tua capacità di usare il “Come”. Questo perché se capisci perché lo strumento ha le caratteristiche specifiche che ha, allora non hai solo una comprensione dello strumento stesso: hai una comprensione dei processi di ragionamento, di cui lo strumento è una manifestazione. Ciò significa che quando inevitabilmente si incontra una sfida tecnica che non è suscettibile di una serie memorizzata di comandi e procedure, è possibile applicare il ragionamento dietro lo strumento stesso e orientarsi verso una soluzione. Questa è la differenza tra un utente del framework e un ingegnere.

Quindi abbiamo imparato a reagire come team questa settimana. Dacci un'altra settimana e probabilmente potremmo spedire il codice di qualità della produzione (e in effetti ci verrà data un'altra settimana). Questo perché comprendiamo il dominio del problema abbastanza da sapere quali errori cercare (e sappiamo come testare per prevenire questi errori). In altre parole, non faremo qualcosa come costruire uno scambio crittografico che si basa interamente sulla convalida lato client.