Această intrare este postată încrucișată de la dev.to

Am lansat recent „Important Men”, un proiect artistic pe care îl filmam de doi ani.

Am implementat în octombrie, dar întreținerea și depanarea au durat peste o lună. O parte din ea s-a datorat lipsei de experiență, iar cealaltă parte a fost supraextinsă la mai multe termene limită.

Site-ul web prezintă profiluri de fotografii stilizate ale bărbaților care joacă un rol important în viața mea. Partea frontală este statică cu tahioni; backend-ul a fost Node/Express, API Sendgrid pentru preluarea formularelor și trimiterea de e-mailuri cu un formular încorporat în el, toate înregistrările au fost colectate în MongoDB pe MLab, iar backend-ul a fost găzduit pe Heroku.

După câteva critici cu un designer, am făcut machete în InVision, dar am fost atât de presat de timp până la sfârșit încât am petrecut mai mult luptând cu gestionarea răspunsurilor API și adaptând proiectul la Heroku decât verificând erorile.

În retrospectivă, eram prea concentrat să potrivesc design-urile mele și să fac un site web cu aspect mai elegant decât oricare dintre lucrările mele anterioare. Dar am trecut complet cu vederea planificarea comportamentului API al formularului de întrebări și răspunsuri de pe pagina lui Matthew.
Sper că această postare ajută pe cineva să-mi evite greșelile.

Capătul din față este decuplat de capătul din spate.

Atâta timp cât datele revin în JSON, le pot manipula oricum vreau, la orice punct final URL în care fac referire la fișierul js cu cererea de preluare.
Acum peste un an, la un curs de imersiune Angular, am învățat că rutarea ar trebui serviți anumite parțiale sau fișiere la punctele finale (adică „/” ar trebui să răspundă cu index.html etc.). Rutarea este pentru trimiterea de date înainte și înapoi. Rutarea este pentru trimiterea de date înainte și înapoi. Tot trebuie să-mi amintesc asta.

Descărcați mai întâi funcționalitatea de bază. Depanați câte un lucru.

În loc să amestecăm blocurile de cod cu soluții de la StackOverflow (ceea ce fac când sunt stresat), realizarea de mici aplicații de testare și verificarea fiecărei linii de cod a avut sens pentru a construi o funcție, a ajutat mai mult decât scrierea a 10 linii de cod spaghetti care s-au spart în mai multe locuri . Am fost tentat să adaug din ce în ce mai multe funcționalități, cum ar fi timestamp și autentificare Oauth pentru comentarii (mai mult o piedică pentru un proiect atât de mic, în opinia mea), dar a trebuit să fiu realist în ceea ce privește capacitățile mele.

Nu-mi pot urma propriul plan de sprint.

…deci aș putea la fel de bine să optez pentru cea mai productivă și captivantă listă de sarcini pe care aș revedea cu siguranță. Pentru mine asta a fost trello. Deoarece aveam mai multe proiecte care se încheiau, a fost mult mai realist să aruncăm totul în mai multe coloane pe trello și să mutați orice a fost făcut într-o coloană „Terminat”.

Proiectați API-uri având în vedere rezultatele vizuale logice

Nu cred că pot explica acest lucru fără a intra în detaliu cum gândirea mea orientată vizual a reprezentat doar un set de rezultate, dar, în realitate, obținerea acestor rezultate a necesitat mai multe condiții și interogări care să fie incluse în codul backend.

În cazul afișării întrebărilor la care s-a răspuns, nu m-am gândit la:
1) notificarea utilizatorilor prin e-mail când a fost postat un răspuns la o întrebare
2) afișarea doar a înregistrărilor care au avut atât întrebări, cât și răspunsuri deci nu ar părea că întrebările au rămas fără răspuns sau că cererea de obținere nu a funcționat
3) a avea atât de multe etichete de comutare în jos pentru a dezvălui informații esențiale de pe pagină nu era necesar (obsesia minimalistă asupra funcției într-adevăr)
4) inclusiv un încărcător sau un fel de semnal vizual în timp ce răspunsul de preluare se încarca, dar acest lucru poate fi, de asemenea, excesiv

Decideți-vă instrumentele și citiți documentele înainte de a ajunge la acea parte a planului.

Nu m-am gândit la implementare și aveam doar cunoștințe de lucru despre compartimentele AWS. Ar fi prea mult un pariu să înveți cum să configurezi un server în ajunul unei lansări, așa că Heroku mi s-a părut un pariu bun, deoarece eram deja familiarizat cu git.

Nu pierde timpul încercând să înveți un nou cadru

(mai ales la un termen limită), dacă nu sunteți pregătit să îl utilizați în producție.

Pentru un site de ‹10 pagini, ar putea fi doar o balonare suplimentară și să introducă un gradient de învățare inutil care necesită timp.

Testați întotdeauna local

Reveniți la testarea pe localhost dacă ceva nu reușește după implementarea în Heroku și ați creat o pagină inactivă („Lucrăm la asta”). Testarea de frustrare impulsivă a însemnat că am ajuns să am atât de multe versiuni pe Heroku încât am uitat ce modificări am făcut codului backend. Console.logs pentru MongoDB va fi, de asemenea, mai lizibil în acest fel. (Corectați-mă dacă greșesc în acest sens)

A plăti pentru a juca este nasol, dar consecvența poate merita.

Nu știam că una dintre solicitările mele de preluare aveam un timp de vizualizare de până la 15 secunde!
Dacă trebuie să funcționeze cu viteza fulgerului, probabil că merită să plătiți pentru nivelul Heroku Hobby. Am auzit toate aceste lucruri grozave despre a avea un mic proiect găzduit gratuit pe Heroku, dar este inutil dacă comportamentul dorit este inactiv, deoarece serverul „inactivează” după o jumătate de oră de inactivitate și trebuie să fie „trezit” printr-o solicitare. Am auzit că oamenii au scris scripturi pentru a trezi serverul la fiecare jumătate de oră, astfel încât să nu intre în somn. Pare multă muncă suplimentară pentru cineva aflat sub presiune.

Acordați-vă suficient timp să faceți încurcătură.

… ca 1,5x din acel sprint final.

Nu am făcut-o, așa că am ajuns să lansez un proiect care a fost de aproximativ 80% funcțional, apoi am petrecut luna următoare ținând cont de promovare până când am funcționat întreaga funcție de întrebări și răspunsuri. În retrospectivă, ar fi trebuit să fac o listă de verificare înainte de desfășurare pentru a pune atingeri finale precum:

  • creați robots.txt pentru a permite accesarea cu crawlere și indexare pe web
  • testați metaetichetele Open Graph pentru Facebook și Twitter pentru a asigura previzualizările imaginilor și subtitrărilor pentru munca de partajare a linkurilor
  • determinând mai mulți utilizatori să testeze link-urile site-urilor web
  • Utilizați Chrome devTools pentru a verifica timpii de performanță
  • asigurați-vă că oamenii pot trece prin linkuri și câmpuri de introducere
  • a verificat cum arăta pagina pe diferite dispozitive
  • m-am asigurat că pot trece prin intrări sau butoane pentru focalizare (accesibilitate)

Această „listă ar putea continua”, dar acestea au fost câteva lucruri pe care chiar mi-aș fi dorit să le fac.

Protejați-vă proiectul și portofoliul înainte de a aplica pentru locuri de muncă.

Când este live, este public și orice nu funcționează probabil că nu s-a reflectat bine asupra mea ca dezvoltator și artist digital la mijlocul carierei. Chiar a trebuit să-mi înfrânez disperarea profesională.

Mulțumesc că mi-ai citit gândurile de nooby. Care sunt unele dintre listele de verificare și fluxurile de lucru înainte de implementare?