Capstone Week 5: Viden er ubrugelig uden 'know-how' og hvordan man lærer rammer som en ingeniør

At lære at bruge en ramme er i sig selv ikke software engineering. At lære de problemer, rammerne løser i sit (n) problemdomæne, er tættere på software engineering. Hvis det projekt, du arbejder på, udgør udfordringer, der er langt ud over, hvad en ren ramme kan løse, er det software engineering. Facebook bruger React, og det samme gør den praktiske indkøbsvogn-app, jeg har bygget på en dag eller to. Facebook er et utroligt resultat af teknik; min indkøbsvogn app er ikke.

Der er nogle aspekter ved at lære et nyt værktøj eller ramme, som jeg har glæde af, og nogle andre kan jeg ikke. Jeg kan godt lide at lære om de problemer, der er løst, eller om de kompromisser, som forskellige metoder til strukturering af kode udgør. For eksempel finder jeg Flux designmønster simpelthen genialt. Opbygning af en app uden Flux bliver utroligt rodet, da du er nødt til at passere applikationens tilstand ned gennem en mangfoldighed af komponenter, kun for de underordnede komponenter til at ringe til en lang kæde af forfaderfunktioner, indtil den komponent, der ejer staten, får besked om begivenheden i en af dets børn, børnebørn, oldebarn osv. Flux gør det astronomisk lettere at tænke over, hvad en app laver, hvordan dets tilstand styres, og hvilke komponenter der er ansvarlige for, selv når kodebasen vokser.

Dette er hvad man skal fokusere på, når man lærer en ny ramme: hvilke problemer løser det, og hvordan? Hvilken filosofi er løsningen født ud fra? Hvad er den generelle arkitektur, og hvilke smertepunkter introducerer denne arkitektur? Hvilke receptbelagte overbevisninger om, hvordan et problem skal løses informerede om oprettelsen af ​​denne særlige løsning, og deler du denne tro? Hvis du ikke deler dem, skal du da? En ramme er langt mere end et værktøj: det er en erklæring om, hvordan et grundlæggende problem, eller mange grundlæggende problemer, skal løses. Når jeg har til opgave at lære et nyt værktøj eller ramme, er dette de spørgsmål, jeg stiller. Jeg er ligeglad med at huske de nøjagtige nuancer ved konfiguration af webpack: det kommer med tiden, og hvis det ikke gør det, er det noget, jeg let kan undersøge på få minutter. Jeg kan spørge google, hvad en fejlmeddelelse betyder. Jeg kan ikke spørge google, om designbeslutningerne for en ramme og de kompromiser, de indfører, er dem, som jeg er enig med.

At lære en ramme godt og lære det hurtigt er ikke gensidigt eksklusivt, hvis du er bevæbnet med viden om de grundlæggende elementer i det domæne, du arbejder i. Du er også nødt til at prioritere din viden i henhold til en på forhånd udtænkt dagsorden. Min agenda er næsten altid: ”Forstå” hvorfor ”lige så meget som” hvordan ”. Årsagen er denne: Du vil altid være dygtigere med et værktøj, hvis du kender dets grund til eksisterende og årsagen til beslutningerne bag dens design. “Hvordan?” Og “Hvorfor?” Er ikke relaterede spørgsmål, og at have et stærkt greb om “Hvorfor” vil faktisk styrke din evne til at bruge "Hvordan". Dette skyldes, at hvis du forstår, hvorfor værktøjet har de specifikke funktioner, det har, så har du ikke bare et greb om selve værktøjet: du har et greb om de ræsonnementsprocesser, som værktøjet er en manifestation. Det betyder, at når du uundgåeligt støder på en teknisk udfordring, der ikke er tilgængelig for et memoriseret sæt kommandoer og vejledninger, kan du anvende resonnementet bag selve værktøjet og navigere dig vej til en løsning. Det er forskellen mellem en rammebruger og en ingeniør.

Så vi lærte reactJS som et team denne uge. Giv os endnu en uge, og vi kunne sandsynligvis sende produktionskvalitetskode (og faktisk får vi en anden uge). Dette skyldes, at vi forstår problemdomænet nok til at vide, hvilke fejl vi skal kigge efter (og vi ved, hvordan vi tester for at forhindre disse fejl). Vi vil med andre ord ikke gøre noget som at opbygge en kryptobørs, der helt afhænger af validering på klientsiden.