Workflow

Workflow

Shoutout naar Kris voor het erin krijgen van een chille workflow; ik heb er inmiddels wel een beetje m'n eigen, lossere versie van gemaakt maar voor mijn doen is het nog steeds best georganiseerd. Hieronder omschrijf ik de onderdelen van m'n huidige workflow.

Project board

In week 2 besloot ik dat het toch wel handig is om m'n to-do's overzichtelijk en up-to-date online te hebben. Ik heb een project board aangemaakt binnen deze repo zodat ik een beetje in de gaten kon houden waar ik sta en dat ik geen dingen vergeet zonder 't te documenteren. Eerst deed ik het in Trello maar ik vind die van Github toch best prima werken.

Issues

Issues zijn basically m'n to-do's voor dit project. Als er iets gefixt moet worden (feature, bugfix, refactoring, docs etc) open ik een issue met in de titel de to-do. Ik heb ook een aantal templates gemaakt voor de issues die anderen bij mij inschieten tijdens de Peer Reviews. Die templates gebruik ik dan zelf ook wanneer ik een ander moet reviewen. Voor m'n to-do's gebruik ik eigenlijk geen template aangezien ik ze zo kort mogelijk wil houden; de titel zou voldoende moeten zijn.

Labels

Ik heb labels gebruikt om overzicht te creëren betreft wat voor soorten taken ik heb; zo kan ik ook m'n planning hierop aan laten sluiten.
Ik doe bijvoorbeeld het liefst documentatietaken achter elkaar, of codeertaken achter elkaar. Ik heb nogal wat moeite om van focus te switchen dus dit helpt wel met prioriteren.

Milestones

Deze assignment bestond uit een deel 'werken met enquêtedata', en een deel 'werken met conceptdata'.
Ik heb dan ook aparte milestones aangemaakt hiervoor zodat ik eerst het een zou afmaken voor ik aan het ander begin.

Branches

Voor het adden van features maak ik een aparte branch aan met feat/ , en als ik specifiek voor refactoren ga maak ik een branch aan met refactor/. Readme-updates of het uploaden van images voor de wiki/readme doe ik ook gewoon op de main branch.
Daarover gesproken; ik heb m'n main branch trunk genoemd nadat ik aangekaart zag worden dat master branch best wel een rukbenaming is gezien de history met die benaming; kleine moeite om 'm dan te hernoemen. En zeg nou zelf: als je met branches werkt, is het toch sowieso logischer dat ze van een trunk afkomen?

Ik werk overigens in branches omdat het je forceert te focussen op het ene ding waar je mee bezig bent (waar ik moeite mee heb lol, het scheelt je merge conflics en het is handig om vast aan gewend te raken voor teamprojecten of werk. Het is ook fijn als je een feature gewoon af kan sluiten zo.

Pull Requests

De branches merge ik met m'n main branch middels een pull request; normaal gesproken zou Netlify dan ook gelijk moeten checken of ik dan niet iets breek maar ik heb Netlify niet de goede build-commands doorgegeven dus vandaar dat je nu allemaal kruisjes ziet. Momenteel deploy ik toc via Github Pages dus maakt niet zo veel uit verder.

Commits

Commits probeer ik te doen volgens deze guidelines.
Mostly betekent dat dat ik alles in tegenwoordige tijd doe, en ervoor zet waar het over gaat (feat:, refactor:, fix: etc.).
'Commit early, commit often.' --> ik probeer zo veel mogelijk single-purpose commits te doen, en zo veel mogelijk. Is ook leuk voor je graph. Is minder leuk als je commits van je backupaccount niet meegeteld worden in je graph.

Code conventions

Hoort dit hier onder workflow? Ik vind van wel.

Filenames

De naming van de files heb ik als volgt onderverdeeld:

• Codefiles (js, html etc): kebab-case
• Bestanden met content/data, zoals een image of json-bestand: snake_case
• Functies en variabelen: camelCase
• 'Grote'/exportfuncties: PascalCase

SCSS

Heb ik verdeeld onder de modules:

• CSS Reset
• Variables
• Typography
• Layout
• Index (om ze te bundelen)

Daarbinnen houd ik de structuur/volgorde volgens SMACCS aan; eerst de 'Base' bestaande uit de elementselectoren, dan de 'Layout' bestaande uit de class-selectors, dan de specifiekere zaken zoals een backToTop-button, dan 'Animations' voor het geval ik wat bewegend moois weergeef op m'n webpagina.

👍🏽 Best practices

Dit is een klassiekertje qua zelf samengestelde guidelines en heb ik al eens eerder gedeeld in repo's maar het blijft worth sharing:

• Work in branches, even if it's a one-man project. It helps staying focused on one feature until it's finished, and keeps your from doing 10 different things at the same time. Saves you merge conflicts, too. In this project you can only collaborate via Pull Requests anyways, so branches are mandatory.
• ^ also helps with 'closing' a feature, so you are more likely to move on to the next. Too little time, too much ideas.
• Commit early, commit often.
• Make single-purpose commits, following our commit guidelines
• Always fix your .gitignore-contents asap; node_modules or the like won't ever be pushed that way.
• Styling comes last. It's gonna change anyways so most of the time, it's better to fix the technical stuff first.
• Don't use declarations in the global scope.
• Start your project with writing down the future function names (pre-actors, basically).
• Google, google, google. 99% of the time, it'll get you to the solution of your problem.
• Set timers for solving problems that aren't super relevant in the current sprint but you do would like to work on; 25 mins tops, otherwise you'll be stuck with this for too long.
• Make an actor diagram halfway through, it's a great reminder to refactor the code.
• Explicitly limit the scope of your functions
• Remember that most problems/features that have to do with the UI, can be fixed with mainly CSS.
• Do not use .innerHTML
• If there's an error, walk through your code from the top/beginning; explain it to your rubber ducky and state where certain data is passed.
• Implement useful error handling.