Inzicht op software ontwikkelen

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Java Developer / Overheid / Complexiteit

Functieomschrijving Wil jij als Java Developer een bijdrage leveren aan een veiliger Nederland en je als Java Developer bezig houden met zeer complexe bedrijfskritische applicaties? Lees dan snel verder! Doorontwikkelen bedrijfskritische applicaties; Aanpassingen maken in de bestaande applicatie; Vertalen van jouw visie op continuous integration en continuous delivery; Debuggen van de applicatie; In gesprek gaan met eindgebruikers om verbetervoorstellen op te halen. Functie-eisen Minimaal HBO-werk en denkniveau; Minimaal 5 jaar werkervaring als Java Developer; Je bent minimaal OCP-Java SE 6 gercertificeerd; Je hebt kennis van Webservices en Continuous Integration; Je bent analytisch sterk en zowel klant- als resultaatgericht. Bedrijfsomschrijving Binnen

Bekijk vacature »

Senior DevOps-ontwikkelaar eIDAS

Functie­omschrijving Burgers en bedrijven veilig en betrouwbaar digitaal toegang geven tot diensten en producten van het ministerie van Economische Zaken en Klimaat. Als senior DevOps-ontwikkelaar bouw je daar letterlijk aan mee. En dat doe je bij DICTU: een van de grootste en meest vooruitstrevende ICT-dienstverleners van de Rijksoverheid. Jij werkt mee aan de doorontwikkeling van eIDAS, dat staat voor Electronic IDentification Authentication and trust Services. Deze koppeling maakt de grensoverschrijdende authenticatie op overheidswebsites binnen de Europese Unie mogelijk. Het ministerie van Economische Zaken en Klimaat heeft één moderne toegangspoort voor zijn diensten en inspecties. Enkele daarvan zijn dankzij eIDAS inmiddels

Bekijk vacature »

Front-end Developer Vue.js Meewerkend voorman

Functieomschrijving Ben jij een ervaren Front-end Developer, bedreven in Vue.js en lijkt het jou gaaf om als meewerkend voorman verantwoordelijk te zijn voor de ontwikkeling van drie junior ontwikkelaars? Werk jij graag aan diverse projecten t.b.v. het vergroten van klant- en medewerkerbeleving? Lee dan snel verder! Het onderhouden, ontwikkelen en testen van front-end software van diverse klant- en medewerkersapplicaties; Het ontwikkelen van maatwerk front-end oplossingen in Vue.js en participeren in een scrumteam; Verantwoordelijk voor het begeleiden en coachen van drie junior front-end developers; Verantwoordelijk voor code-reviews en het opstellen van de juiste documentatie zoals userstories en api ontwerp; Participeren in

Bekijk vacature »

Izildo Pimentel

Izildo Pimentel

24/10/2018 13:53:58
Quote Anchor link
Je hoort het vaak je leert coderen door te werken aan projecten.
Ik wil graag vragen om meer inzicht bij het beginnen van het bouwen van software.
Bijvoorbeeld iets kleins net als tic tac toe spel. Hoe zou je dit benaderen?

- Open vs
- Maak nieuw project
- Maak classes? drawUI bijvoorbeeld, gameflow
- Bedenken wat voor method's je gaat aanmaken.

Als je tic tac toe in stukjes zou hakken wat voor problemen zou je dan zien om op te lossen? En hoe ga je te werk.
 
PHP hulp

PHP hulp

04/08/2020 21:44:36
 
Thomas van den Heuvel

Thomas van den Heuvel

24/10/2018 15:37:41
Quote Anchor link
Vergelijk het met het bouwen van een huis: ook hiervoor heb je een duidelijk vantevoren opgezet plan nodig (een blauwdruk). Ook zodat je al weet hoe alles er uiteindelijk uit komt te zien.

Daarnaast zijn er ook enkele noodzakelijke randvoorwaarden zoals:
- een set minimale theoretische kennis
- enig abstract denkvermogen
- kennis over keuzes in gereedschappen, materiaal en (bouw)technieken

Het meeste -of in ieder geval voldoende- (denk)werk is vantevoren al gedaan, daarna volgt pas het uitrollen / daadwerkelijk bouwen. Je begint ook niet zomaar ergens met het bouwen van een huis.

Toegepast op het "tic tac toe" voorbeeld: stel eerst een functionele spec op. Los van techniek beschrijf je wat je gaat bouwen en wat het zou moeten doen. Je beschrijft bijvoorbeeld de verschillende schermen, interactievormen, en de mogelijke zetten die je in het spel kan doen. Ook beschrijf je condities waaronder het spel voorbij is. Eigenlijk dus de set van spelregels en alles wat tijdens een speelronde kan gebeuren.

Maar als je dit concreet wilt maken dan is dit voorbeeld te abstract, je vertelt namelijk niet:
- in wat voor programmeertaal/welke techniek dit gemaakt zou moeten worden
- in wat voor soort applicatie dit zou moeten komen (web? standalone? single player? multiplayer? vs AI?)
 
Jacco Engel

Jacco Engel

24/10/2018 15:39:18
Quote Anchor link
Hoe ik het (de ene keer wat uitgebreider dan de andere) doe :
-- Voorbereiding --
Functioneel ontwerp

Wat wil je maken en waarom (in dit geval niet zo heel relevant)
Welke requirements zijn er (in dit geval, wat zijn de spelregels)
Wat gebeurt er als er een ongeldige invoer is (bijv: gebruiker klikt op een veld dat al gevuld is)

Hier denk ik vaak ook al na over mijn eerste testcases, omdat nadenken over testcases je een beter inzicht kan geven in waar je technisch op moet letten. Bijvoordbeeld:
Case : Een gebruiker klikt op een veld dat al in gebruik is
Expected : Gebruiker krijgt een melding dat hij/zij een ander veld moet kiezen
Het is belangrijk dat je hierbij objectief blijft. Dus probeer weg te blijven van de "Dit ga ik toch niet fout doen" en de "dit is toch logisch" gedachte gang

-- Hiertussen indien van toepassing laat ik vaak reviewen door de opdrachtgever. Dit is omdat je dan duidelijk op papier hebt/zou meoten hebben wat een opdrachtgever verwacht.
In deze fase kan een opdrachtgever nog aangeven dat hij dingen anders wil of bedoeld

Technisch ontwerp
Ben ik geen held in, maar bij mij is dit vaak de structuur van het systeem dat ik ga opzetten. Classes, database, welke libraries ga ik gebruiken, dingen van die strekking.

-- Ontwikkelen --
Code kloppen

-- Testen --
Test de cases die je in je Funtioneel Ontwerp hebt gedefineerd, alsmede dingen waar je tijdens het ontwikkelen aan denkt (alles van tevoren bedenken is een uitdaging).

(als je een opdrachtgever hebt)
-- Acceptatie --
Je maakt je functionaliteit beschikbaar op een test omgeving waar de opdrachtgever ook bij kan, zodat hij/zij kan testen en eventueel dingen terug kan melden.
Hou hierbij in het achterhoofd dat er een groot verschil is tussen een bug, en toch niet helemaal wat hij/zij had verwacht.
In de perfecte wereld zou je dan kunnen aangeven dat het werkt zoals in de FO gespecced staat, waar hij/zij akkoord ,en dat er na de release een RFC gedaan kan worden.
Speccen is erg belangrijk in dit geval omdat er zo min mogelijk ruimte voor interpretatie in moet zitten.

-- Oplevering --
Livegang van het project

Ben ongetwijfeld dingen vergeten of doe dingen verkeerd, maar dat hoor ik vanzelf :P
 
Izildo Pimentel

Izildo Pimentel

27/10/2018 23:13:31
Quote Anchor link
Wat denken jullie van dit technisch design.
https://imgur.com/7pXyqUP
Gewijzigd op 27/10/2018 23:13:54 door Izildo Pimentel
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.