-
Notifications
You must be signed in to change notification settings - Fork 0
Peer2Peer studievereniging software standaarden
Hallo Peer2Peer softwarepersoon! Welkom in de hele interessante Wiki van Peer2Peer voor de ontwikkeling van software. Dit is het punt waaruit alle softwarestandaarden binnen de Peer2Peer software commissie geregeld zijn.
Het gebruik van GitHub repositories wordt binnen de Software Commissie altijd gedaan. Er zijn hier ook een aantal regels aan verbonden. Namelijk,
- Er moet een code review plaatsvinden voordat iets naar de hoofdbranche gestuurd mag worden. Als het een project is met sensitieve kenmerken, dan moeten hier specifieke personen voor aangewezen worden die een verantwoordingsplicht zullen dragen.
- Er moeten kwaliteitsmaatregelen getroffen worden als het gaat om software. (Denk CI/CD)
- De hoofdbranche is altijd protected, er mogen geen directe commits naar gedaan worden.
- Per feature wordt er gewerkt in een aparte branch.
- Complexere features dienen gedocumenteerd te worden in de wiki van de betreffende repository. Hier kan om gevraagd worden door andere ontwikkelaars.
- Er wordt gewerkt via project boards, dit is op een per-project basis. (Zie het
Projectstabje.). Hieruit worden issues gemaakt, en deze issues worden opgelost.
Het automatiseren van het kwaliteitsproces is van belang. Processen zoals automatische testen, code style conformiteit en dergelijke opschoningen dienen geautomatiseerd te worden. Dit wordt gedaan via GitHub Actions.
Voor deployment moet er contact opgenomen worden met de voorzitter of iemand die daar op dat moment specifiek voor aangesteld is, meestal is dit gewoon de voorzitter. Het is verplicht om het mogelijk te maken om het softwaresysteem direct te kunnen draaien via een Dockerfile, aangezien er (behalve bij bijzonderheden) gebruik gemaakt wordt van Google Cloudrun. Is er zo'n dergelijke bijzonderheid? Dan dient het bespreekbaar gemaakt te worden bij de vergadering.
Er is hier een volledig vrije keuze in, zolang het uitvoerbaar is binnen Google Cloudrun zonder dat er grote complexiteit en/of kosten aan verbonden zitten, behalve als dit vooraf besproken en goedgekeurd is.
Er zijn een aantal tools- en technieken waar standaard gebruik van gemaakt dient te worden.
- Het gebruik en conformering aan SonarLint is verplicht.
- Het toepassen van design patterns die bruikbaar zijn voor het betreffende probleem is van belang, behalve als het écht onnodig is kijkende naar de doorontwikkeling van het systeem (Moet het later uitgebreid worden?). Het boek 'Design Patterns' van The Big Four is een goed referentiekader.
- Het toepassen van best-practices binnen de software engineering, bijvoorbeeld YAGNI, KISS, SOLID, etc.
- Het toepassen van automatiseringstooling waarmee developers snel en vertrouwd van start kunnen gaan is verplicht. (Docker-compose voor containers die nodig zijn, automatisch database klaarzetten bij integratietesten, etc.)
Binnen Peer2Peer wordt er zoveel mogelijk gebruik gemaakt van codestijl standaarden om de stijl van software gelijk te houden rondom de verschillende projecten. Het is in ieder geval verplicht om te programmeren in de voertaal Engels. Geen Nederlandificering van methoden, variabelen, etc.
Hier wordt gebruik gemaakt van PEP-8. Het is een pro-tip om Poetry op te zetten met pre-commit, black, mypy, test automatisering, etc.
Hier wordt gebruik gemaakt van de Google Style Guide voor C#, deze kan hier gevonden worden.
Prefereer TypeScript over JavaScript ten alle tijden. Er wordt gebruik gemaakt van ESLint in combinatie met Prettier bij het gebruik van TypeScript. De regels hiervan mogen wel vrij geconfigureerd worden, mits het naar redelijkheid gedaan wordt.
Refereer naar de Google Style Guide voor verdere code style guides, deze kunnen hier gevonden worden.
Om te conformeren aan de stijl van Peer2Peer wordt er gerefereerd naar diens style guide. Deze is hier te vinden: Huisstijl Peer2Peer guide