...
Op het moment dat wij het SRS (tussentijds) gingen opleveren wisten we eigenlijk al dat de kwaliteit hiervan zwaar onder de maat was. Er was veel feedback van docenten die we hier in hebben kunnen verwerken. Eén van de belangrijkste dingen in een SRS is misschien wel dat alles coherent en consequent is. In het SRS moet je namelijk dezelfde termen gebruiken als in het PvA. Dit was bij ons niet het geval. Ook is het zo dat we in het SRS verschillende termen hebben gebruikt voor dezelfde gebruiker zonder deze verder toe te lichten. Dit zorgt ervoor dat iemand niet goed zou kunnen begrijpen wat het uiteindelijke product nou wordt. Dit is echter wel de hoofdbedoeling van een SRS. De opdrachtgever heeft een opdracht, deze werk je voor een opdrachtgever (en mogelijk andere programmeurs) uit in een SRS. We moeten als groep alles op alles zetten om dit document duidelijk en goed te krijgen omdat ook andere groepen dit document zullen moeten gaan gebruiken. De documentatie is voor deze opdracht dan ook belangrijker dan de code zelf.
Code
De code die voor mij een groot deel van de tijd in beslag heeft genomen en ook nog niet volledig af is is de login. Als we het hebben over de backend van deze code dan gaat het vooral over de code die Thomas geschreven heeft, en later aangepast is door Wijnand. Zelf heb ik hier niet aan gewerkt, maar wel gereviewd. Zelf ben ik bezig geweest met de front-end van de login, de koppeling van de front-end en backend en moet ik nog werken aan de foutafhandeling en het doorgeven van een token. De token is nodig om op elke pagina te kijken of de gebruiker hier mag zijn, en als dit het geval is, wat deze gebruiker mag en kan. Als ik kijk naar de backend is hier veel tijd aan besteed. Er zijn tijdens het maken van de login aanpassingen geweest, grotendeels door meerdere invalshoeken. Iedereen kijkt er toch net wat anders naar. De één vindt het beter om de gebruiker te laten weten of zijn wachtwoord of gebruikersnaam misschien niet klopt, terwijl de ander juist denkt dat er maar één bericht moet komen dat er iets fout is. Dit zijn constant kleine aanpassingen, maar kunnen later op andere stukken weer een grotere impact hebben. Ik durf niet met zekerheid te zeggen of het allemaal veel sneller had gekund omdat mijn focus niet lag op waar Thomas precies mee bezig was. Ik denk echter wel dat het sneller had gekund als we gelijk de uiteindelijke richting hadden gekozen zoals: het wachtwoord moet gehasht in de database staan en er komt 1 foutmelding.
De Backend van de login werkt nu en is klaar, de front-end heb ik met behulp van Angular ook snel in elkaar weten te zetten. Ook door het feit dat er veel over te vinden is het een redelijk snel en makkelijk proces. toch ben ik meerdere obstakels tegen gekomen. Allereerst wou ik een Toastr toevoegen voor foutmeldingen. Toastr's zijn gekleurde berichten die vaak rechts bovenin een scherm te zien zijn (bijvoorbeeld https://codepen.io/RaiseTheBahr/pen/JOybye). Dit leek ook in Angular makkelijk te kunnen al kreeg ik foutmeldingen waar ik geen raad mee wist en ook na veel onderzoek nog niet uit ben gekomen. Ik heb mij voor nu neergelegd bij het niet kunnen gebruiken van Toastr's en ben verder gegaan met de koppeling. De koppeling tussen de twee was er snel en werkte goed. Op het moment dat de login backend af was kon je ook gelijk met de front-end inloggen, al deed deze verder nog niks. De vervolgstap is het doorgeven van een token aan de user. Ook hier heeft al wat tijd ingezeten, al denk ik nu te weten hoe ik dit kan oplossen. Ik denk niet dat hier veel tijd bespaard had kunnen worden. Het gebruik van Toastr's heb ik misschien te graag gewild terwijl een rode tekst voor nu ook genoeg zou zijn geweest. Dit is ook de oplossing die we hier gaan gebruiken. De oplossing voor het meegeven van een token komt uiteindelijk af van Meron Brouwer. Als ik hier eerder de vraag aan had gesteld in plaats van het onderzoek zelf vanaf 0 te doen was misschien de hele login ook al klaar.
...