Doorleren en bijspijkeren: je bent nooit klaar met Java

Een leven lang leren en Java; er zijn weinig onderwerpen die beter op elkaar van toepassing zijn. Er zijn zoveel methodes, omgevingen en functionaliteiten dat je ze nooit allemaal tegen kunt komen tijdens je eerste opleiding. Het echte werk begint tijdens je eerste baan, maar je moet doorleren om bij te blijven als ontwikkelaar. Ga je aan de slag met Java of wil je je kennis bijspijkeren? Wij geven je alvast zes manieren om je Java-kennis zo goed mogelijk in te zetten en je klanten blij te maken met je codes en applicaties.
 
Een noot vooraf: dit artikel is het eerste in een serie blogs over Java. We duiken daarom niet direct de diepte in, maar houden het hier bij de basiswerkzaamheden. In latere blogs zoomen we verder in op de onderwerpen die hier aan bod komen. Ben je al meer ervaren en direct toe aan verdieping? Dan besparen we je graag de leestijd en nodigen we je uit direct een kijkje te nemen in ons Java-portfolio.
 

Terug naar school

Of het nu lang of kort geleden is, je herinnert je vast nog wel de eerste problemen die je tegenkwam als Java-ontwikkelaar. Tijdens je opleiding zijn die nog relatief eenvoudig. De werking van algoritmes, de juiste datastructuren kiezen en leren hoe je de code repareert die je zelf hebt geschreven. Tijdens je eerste baan kreeg je te maken met veel vraagstukken die je op school nooit had gezien. Je code aanpassen zodat hij past in de standaarden van je team. De code begrijpen die iemand anders heeft geschreven. Weten waar je het beste eten kunt halen als je een avondje door moet werken. Je kan er vast nog een paar bedenken.
 
Die vraagstukken zijn en blijven onderdeel van je werk en fouten zijn onvermijdelijk. Maar er zijn zes manieren om het aantal fouten te minimaliseren in de code, database of applicatie waar je aan werkt. Een deel daarvan heeft te maken met ervaring en voor sommigen klinkt deze werkwijze dus bekend. Maar dat neemt niet weg dat je minder fouten maakt als consistent deze methode hanteert:
 
1. Je code testen en je test schrijven
Elke ontwikkelaar weet dat coderen een groot onderdeel van het werk is. Maar het schrijven zelf is misschien wel het makkelijkste deel. De aanpassingen en de variabele elementen in de IT-omgeving maken het een uitdaging. Daarnaast wordt tegenwoordig van ontwikkelaars verwacht dat ze ook de unit tests voor hun code schrijven en ook dat is een kunst op zich. Deze unit tests kun je zelfs al schrijven voordat je de betreffende methodes gaat compileren. Op die manier kun je ook delen testen en weet je dat de methods naar behoren werken als alle tests zijn geslaagd.
 
2. Bestanden mergen
Een merge is op zichzelf niet bijzonder. Maar bij het samenvoegen van twee of meerdere ontwikkelgeschiedenissen, tekstbestanden, arrays of andere objecten kan van alles fout gaan. Bijvoorbeeld als je maar een deel van de bestanden wilt committen. Daarom is het belangrijk de code en het proces volledig te begrijpen voor je op commit klikt. Dat wil natuurlijk niet zeggen dat je hier ellenlang over moet doen. In ontwikkelomgevingen wordt veelal gewerkt op basis van continuous integration (CI). Dat houdt onder meer in dat je niet te lang moet wachten met een commit. Zo ontdek je fouten in een vroeger stadium en kun je hier sneller op inspelen.
 
Je kunt dit handmatig doen door zelf de bestanden te controleren, de veranderingen te identificeren en de gevolgen voor de bestaande code te bekijken. Maar je kunt ook een van de vele beschikbare tools kiezen die dit werk voor je kunnen doen, bijvoorbeeld een versiebeheersysteem als Git.
 
3. Debuggen doorgronden
Als je code actief is, of in ieder geval draait in je ontwikkelomgeving, is het tijd om te controleren of het naar behoren werkt. Het debuggen zelf is vrij eenvoudig binnen de diverse beschikbare IDE’s. Maar om het meeste nut uit dit proces te halen moet je genoeg aandacht aan je logs besteden. Je kunt kiezen uit diverse niveau’s:
 
Trace – de meest gedetailleerde informatie
Debug – Gedetailleerde berichten die in het log zijn genoteerd
Info – runtime events, zichtbaar in je console
Warning – berichten over mogelijke problemen
Error – onverwachte omstandigheden
Fatal – ernstige fouten
 
Er zijn frameworks die deze berichten voor je schrijven. Maar het is belangrijk om zoveel mogelijk informatie te geven. Alleen dan zijn de diverse vraagstukken op te lossen.
Eerst moet je het correcte niveau bepalen van elk bericht. Gebruik Debug bijvoorbeeld om alles vast te leggen dat in het programma gebeurt. Zo is je code beter te debuggen en begrijp je precies wat er is gebeurt voor je de code naar productie stuurt. Met Info zie je welke acties zijn ontstaan door gebruikers. Warn kun je inzetten om events te identificeren die een fout op kunnen leveren.
 
Voorzie je logs altijd van voldoende informatie. Je collega’s moeten je code ook kunnen begrijpen en je moet ook voorkomen dat je zelf niet meer weet wat je bedoelde als je een paar later met je logs te maken krijgt. Schrijf je code zoals je hem zelf wilt ontvangen.
 
4. Profiteren van Exceptions
Java heeft veel exceptions, dat is een feit. Maar hoe kun je ze in je voordeel gebruiken tijdens het ontwikkelen? Door breakpoints te gebruiken. Je kan breakpoints handmatig instellen voor opgeworpen exceptions. Daarmee kun je aangeven waar de uitvoering moet pauzeren als de applicatie draait in je ontwikkelomgeving. Elke keer als een breakpoint wordt uitgevoerd, verschijnt een bericht in de Debugger Console met de relevante informatie. Het werkt dus als een soort pauze-knop voor je applicatie, waardoor je precies kunt controleren wat er gebeurde tot dat punt. Er zijn verschillende types van breakpoints waarmee de uitvoering van de applicatie stopt bij het bereiken van een specifieke methode, class, variabele of regel.
 
5. De productieomgeving doorstaan
Het belangrijkste verschil bij het in productie nemen van je code is de omgeving. De overgang van je ontwikkelomgeving naar productie kan voor problemen zorgen. Je logs met gedetailleerde informatie helpen bij de oplossing, maar soms is het alsnog moeilijk te begrijpen wat er precies is gebeurd. Gelukkig zijn er diverse tools voor debugging en configuratie voor meerdere omgevingen.
 
Als je organisatie al op basis van Continuous Integration werkt, is de kans groot dat jullie ook Continuous Deployment inzetten. Dat houdt in dat het in productie nemen van de code onderdeel is van een automatisch en gescript proces. Daarbij wordt al getest of de software voldoet aan alle gestelde voorwaarden. Dat betreft niet alleen unit tests, maar onder meer ook integration en code quality tests.
 
6. Denken aan de toekomst én het verleden
Als het goed is zijn er afspraken over de Java-versie die je mag gebruiken voor ontwikkeling. Toch kan backwards compatible werken je kopzorgen besparen. Bijvoorbeeld als een klant toch nog een oude versie van je applicatie draait en je nieuwe functionaliteit niet werkt. Dat soort lastige problemen is eenvoudig te vermijden. Voorwaarde is dat je rekening houdt met het verleden bij het schrijven van nieuwe code. Neem de tijd om alle obstakels voor oudere versies van de applicatie te testen, identificeren en repareren. Daar worden jij en je klant veel blijer van.

Klaar ben je nooit

Zelfs als je al jaren volgens deze principes werkt ben je nooit klaar met Java. Je team, code en applicaties veranderen voortdurend. Daarnaast heeft Java een wereld van tools, speciale scripts en command line hacks. Die kun je allemaal bij ons leren.
 
Bekijk hier ons hele Java-portfolio.

Tags:
ApplicatieApplicatie ontwikkelingJavajava 7Java 8java certificeringjava cursusJava Design PatternsJava EEJava trainingsoftware developmentsoftware ontwikkelensoftware programmerenSoftware testen
Onderwerpen
Actieve filters: Wis alle filters
Loading...