|
Elke softwareontwikkelaar weet te programmeren, maar niet elke programmeur kan software ontwikkelen De meesten kunnen gemakkelijk leren koken, maar wanneer een groot aantal mensen moet worden gevoed, huren we een chef in. Misschien zeggen sommige mensen liever niet meer “ontwikkelaar”, maar een software-engineer, omdat een engineer – het klinkt trots! Of niet? Gelukkig gaat dit artikel niet over termen. Als je mijn term niet leuk vindt, vervang dan je eigen term: “software-auteur”, “software-master” … en zelfs “applicatie-maker”! Als ik “softwareontwikkelaar” zeg, bedoel ik een persoon voor wie het schrijven van kwaliteitssoftware een beroep is. Iemand die wetenschappelijke benaderingen en statistieken gebruikt in zijn werk en zijn beroep beschouwt als meer dan alleen geld verdienen. Om ontwikkelaar te worden, is programmeren niet voldoende. Iedereen kan leren programmeren – het is gemakkelijk. Bijna iedereen kan eenvoudige programma’s schrijven die voor specifieke mensen op specifieke machines werken, maar niemand kan garanderen dat dezelfde programma’s onder verschillende omstandigheden zullen werken. Ik vind deze analogie leuk: iedereen kan onder de douche zingen voor zijn eigen entertainment, maar je zet geen nummers op met opnames van dit gezang op een feestje – je wendt je tot het werk van professionele muzikanten. Programmeren in zijn eenvoudigste vorm is het verzenden van instructies naar de computer om wat actie uit te voeren met wat inputgegevens om wat output te verkrijgen. Software-ontwikkeling daarentegen is het ontwerpen, schrijven, testen en ondersteunen van computerprogramma’s om problemen voor veel gebruikers op te lossen; het gaat erom robuuste, veilige oplossingen te creëren die de tand des tijds zullen doorstaan en enkele van de voorheen onbekende problemen aanpakken die in een gebied liggen dat dicht bij de voor de hand liggende oorspronkelijke problemen ligt. Softwareontwikkelaars bestuderen de op te lossen problemen grondig, begrijpen volledig hoe hun voorgestelde oplossingen werken, hoe deze oplossingen beperkt zijn en hoe ze worden gekenmerkt in termen van gegevensprivacy en beveiliging. En als iemand het probleem niet begrijpt, mag hij er geen oplossing voor ontwikkelen. Oplossingsgerichte aanpak Softwareontwikkelaars schrijven niet alleen programma’s als hun taak, ze denken ook in het voldoen aan behoeften en het oplossen van problemen. En dit is belangrijk, want niet elke taak vereist het schrijven van een programma: in sommige gevallen is het voldoende om een bestaand programma te gebruiken of meerdere programma’s te combineren. En door proactief te handelen, kunt u soms de noodzaak om dit probleem helemaal op te lossen kwijtraken: het ontwikkelen van goede programma’s houdt vaak planning in om te voorkomen Voor complexe taken moet je verschillende programma’s schrijven. In sommige gevallen heb je programma’s nodig die parallel lopen, in andere gevallen heb je programma’s nodig die opeenvolgend lopen. Soms is het voldoende om gebruikers te trainen om een probleem op te lossen.
Voordat de code wordt geschreven, stelt de ontwikkelaar de volgende vragen: Welke taken probeer ik op te lossen? Hoe kun je het probleem oplossen zonder te programmeren? Wat kan er worden gedaan om het schrijven van code gemakkelijker te maken om een probleem op te lossen? Code kwaliteit Programma’s van hoge kwaliteit zijn gemakkelijk te lezen en te begrijpen, ze kunnen gemakkelijk worden uitgebreid, ze werken goed met andere software en hun ondersteuning verandert niet in een nachtmerrie. Codekwaliteit mag niet worden aangetast; het gebruik van snelle maar slordige beslissingen vanwege een strakke deadline, buitensporige opwinding, opwinding, irritatie, etc. is onaanvaardbaar. Een van de belangrijkste aspecten van softwareontwikkeling is het helemaal opnieuw ontwerpen van een uitbreidbaar product. Het aanpassen van apps nadat ze zijn vrijgegeven, is een feit om in het reine te komen. Gebruikers zullen steeds meer functionaliteit nodig hebben, ze willen het gebruik van de applicatie nog gemakkelijker maken. Een applicatiecomponent is op zichzelf meestal niet erg nuttig. Softwarevoordelen beginnen wanneer meerdere componenten met elkaar communiceren, gegevens uitwisselen en samenwerken om gegevens en interfaces aan gebruikers te presenteren. En met dit in gedachten moet je programma’s ontwikkelen. Welke berichten accepteert de software? Welke evenementen worden bijgehouden? Welke berichten geeft het? Hoe wordt gegevensoverdracht geverifieerd en geautoriseerd? Een ander belangrijk aspect bij het schrijven van goede programma’s is duidelijke code, niet het aantal tests of het nummer in het codedekkingsrapport. Alles is hier eenvoudig. Denk: kunnen anderen de code lezen? Of, nog beter, kunt u de code vandaag zelf schrijven en een paar weken later begrijpen? De leesbaarheid van de code is veel belangrijker dan het lijkt. Helaas zijn er geen handige indicatoren om dit kenmerk te beoordelen. Het kan nuttig zijn om bewezen programmeertechnieken en -patronen te onthouden, maar vaak niet genoeg. Een goede ontwikkelaar met ervaring ontwikkelt simpelweg een intuïtie die je vertelt hoe leesbaar de code is. Hier is een goede vergelijking: het is niet voldoende om een grote woordenschat te hebben om beknopte tekst te schrijven. Met elk programma zal er op een gegeven moment zeker iets fout gaan. Het belangrijkste kenmerk van goede software is de mogelijkheid om een reeds uitgebracht programma eenvoudig te repareren. Als het programma tijdens bedrijf een fout genereert, moet daar een duidelijke melding over zijn, die ergens centraal wordt vastgelegd – zodat fouten kunnen worden gevolgd. Wanneer een nieuwe fout wordt gemeld, moet de persoon die verantwoordelijk is voor het oplossen ervan in staat zijn om op elk moment te debuggen, verbinding te maken met het systeem en informatie te krijgen over de uitvoeringscontext, en ook het verwachte gedrag van een systeemonderdeel te controleren. Werkomgeving en testen Wanneer een ontwikkelaar een programma schrijft, zorgt hij ervoor dat het werkt in veel verschillende omgevingen, op machines met verschillende bronnen en in verschillende tijdzones. De software moet draaien op schermen van verschillende groottes en oriëntaties, met beperkt geheugen en een laag verwerkingsvermogen. Als software bijvoorbeeld is geschreven voor een webbrowser, zou deze moeten werken op alle grote browsers. Bij het maken van klassieke software zou het in de meeste gevallen moeten werken op zowel Mac- als Windows-platforms. Als de applicatie die u maakt afhankelijk is van het ontvangen van gegevens, moet deze blijven werken, zelfs als de gegevensverbinding een tijdje traag is of zelfs helemaal afwezig. Om een softwarecomponent te schrijven, proberen ontwikkelaars elk denkbaar scenario na te denken en te plannen om ze te testen. Ze beginnen met het zogenaamde standaardscenario (of “gelukkig pad”), waarin niets onverwachts gebeurt, en alle mogelijke problemen onderweg – wat belangrijk is – worden gedocumenteerd en er wordt voor elk een test gepland. Sommige ontwikkelaars beginnen met het schrijven van ’testcases’ die dergelijke scenario’s simuleren. Vervolgens schrijven ze functionele code die deze testcases doorstaat. Ontwikkelaars moeten de vereisten voor software begrijpen, die vaak dubbelzinnig en onvolledig zijn. De vaardigheid van een ontwikkelaar zit niet in hoe hij de oplossing schrijft, maar eerder in welke oplossing hij geschikt acht. Kosten en efficiëntie In de meeste gevallen kan de ontwikkelaar het probleem snel oplossen. Als u denkt dat het inhuren van ervaren programmeurs duur is, denk er dan over na: hoe meer ervaring een programmeur heeft, hoe sneller hij een functionele, nauwkeurige, betrouwbare oplossing zal creëren die gemakkelijk te onderhouden is. En dit betekent op lange termijn lagere kosten. Bovendien moet rekening worden gehouden met de “exploitatiekosten” van het programma: alle software verbruikt computerbronnen en deze zijn niet gratis. De ontwikkelaar schrijft een efficiënt programma dat niet onnodig pc-bronnen gebruikt. Om dit te doen, kan hij bijvoorbeeld veelgebruikte gegevens cachen – en dit is slechts een van de waarschijnlijk duizenden tools en methoden die helpen om de efficiëntie en snelheid van het programma te verhogen. Misschien biedt een beginnende programmeur een goedkope oplossing, maar het werken met deze oplossing kan u en uw klanten veel meer kosten dan wanneer u onmiddellijk een ervaren ontwikkelaar inhuurt die er in de eerste plaats naar streeft een effectieve oplossing te vinden. Het gebruiksgemak Goede software is ontworpen met het oog op computergebruikerservaring (UX) en het is een vrij breed onderwerp met veel onderzoek en resultaten. Hoe meer lessen uit deze onderzoeken worden geleerd, hoe beter de software zal worden gebruikt. Betrouwbaarheid, veiligheid en beveiliging Misschien wel het belangrijkste aspect dat professionele ontwikkelaars van hobbyisten onderscheidt, is dat professionals weten dat ze de verantwoordelijkheid hebben om veilige, beveiligde oplossingen te creëren. Een softwarecomponent moet bestand zijn tegen slechte gegevens, onjuiste toestanden en onjuiste interacties. Het is ZEER moeilijk om zo’n veerkracht te bereiken – daarom lezen we constant over hoe iemand stierf door een softwarefout.
Gebruikers voeren “slechte” en onjuiste gegevens in de software in. Iemand zal dit met opzet doen – om de software te hacken en de bronnen te krijgen die deze software vertegenwoordigt. De werknemer die naar verluidt verantwoordelijk was voor de inbreuk op de beveiliging bij het Amerikaanse kredietbureau Equifax, dat door de aanvallers werd uitgebuit, werd ervan beschuldigd zijn werk niet te doen: hij moest weerstand bieden tegen “slechte” en kwaadaardige gegevens in alle software, die openlijk namens het bedrijf werd gepubliceerd. … De beveiligingsuitdaging gaat niet alleen over “slechte” en kwaadaardige gegevens, maar ook over normale gegevens. Als een gebruiker bijvoorbeeld zijn wachtwoord is vergeten, hoe vaak kan hij dan proberen het in te voeren? Moet ik het blokkeren na uitputting van invoerpogingen? Wat als iemand opzettelijk een gebruiker probeert te blokkeren? Moeten gebruikers een wachtwoord kunnen verzenden via een niet-versleutelde verbinding? Wat als iemand probeert in te loggen vanaf een ongebruikelijke locatie? Wat te doen als je vermoedt dat je automatisch inlogt? Hoe beschermt u uw gebruikers tegen cross-site scripting en cross-site aanvraagvervalsing, man-in-the-middle-aanvallen en eenvoudige sociale phishing? Hoe een back-upstrategie ontwikkelen in het geval van een DDoS-aanval op servers? De genoemde problemen vormen slechts een klein deel van de vele problemen waarmee rekening moet worden gehouden bij het ontwerpen. Beveiligde programma’s slaan vertrouwelijke informatie op, niet in platte tekst, maar als versleutelde eenrichtingsgegevens met moeilijk te kraken algoritmen. Dit is een back-upbescherming in het geval van hacking van software en ongeoorloofde toegang tot gegevens: hackers krijgen versleutelde gegevens, die in de meeste gevallen nutteloos zijn. Een applicatie kan een foutstatus krijgen en moet worden gerepareerd: zelfs de beste programma’s hebben onverwachte problemen. Als je hier bij het plannen geen rekening mee houdt, ben je geen professionele ontwikkelaar, maar gewoon een programmeur met onveilige programma’s. Softwarefouten zijn moeilijk te identificeren. Onze geest is beperkt in zijn vermogen om bekende gebreken te voorspellen en te voorkomen. Daarom waarderen softwareontwikkelaars goede tools waarmee ze de juiste code kunnen schrijven en veilige software kunnen maken. Gebruikte tools We hebben natuurlijk meer tools nodig en we hebben betere tools nodig. Bij softwareontwikkeling zijn tools belangrijk, maar worden ze vaak over het hoofd gezien. Stel je eens voor dat we nog steeds FTP moesten gebruiken voor implementatie! Stel je netwerk debugging en het oplossen van prestatieproblemen voor zonder browsergebaseerde ontwikkelaarstools! Stel u voor hoe uw JavaScript-codeerefficiëntie zal afnemen als u ESLint en Prettier niet gebruikt! Als u om de een of andere reden bij de ontwikkeling van JavaScript slechts één plug-in voor de code-editor hoeft te verlaten, kiest u ESLint. De taalkeuze is belangrijk. Typeveiligheid is belangrijk. Het beste dat de JavaScript-taal is overkomen, is TypeScript (en Flow). Statische code-analyse is belangrijker dan u denkt. Als je het niet gebruikt, ben je in feite kwetsbaar voor mogelijke onbekende problemen in de toekomst. Schrijf geen code zonder statisch typen. Als de gekozen taal geen statisch typen heeft, moet je ofwel de taal wijzigen of er een transcompiler voor zoeken: vandaag zijn ze al slim genoeg om met opmerkingen in de code te werken, en het lijkt mij dat voor talen die statisch typen niet ondersteunen, transcompilers snel zullen worden standaard gereedschap. Een softwareontwikkelaar worden Het is onmogelijk om te leren hoe u software binnen een paar maanden, zes maanden of zelfs een jaar kunt ontwikkelen. Softwareontwikkeling is niet voor iedereen weggelegd, maar iedereen moet leren hoe hij zijn eigen problemen met computers kan oplossen. Als u kunt leren hoe u eenvoudige programma’s kunt schrijven, doe dat dan. Als u kunt leren hoe u eenvoudige softwareservices kunt gebruiken, doe dat dan. Als je kunt leren om open source software te gebruiken, heb je krachtige tools binnen handbereik. Taken veranderen in de loop van de tijd, dus ook de softwareontwikkeling. De uitdaging voor dit beroep in de toekomst is om gewone mensen in staat te stellen computers te gebruiken zonder een half dozijn jaar aan opleiding te besteden. Het is noodzakelijk om gebruikers eenvoudige en begrijpelijke tools te bieden waarmee ze zelfstandig eenvoudige problemen kunnen oplossen. En dan zullen de ontwikkelaars doorgaan met het bouwen van betere tools, het oplossen van grotere bekende problemen en doen wat ze kunnen om onbekende problemen te voorkomen.
Neem contact met ons op en we bespreken verschillende mogelijkheden. E-mail: info@webdevelopmentapp.com |
| https://webdevelopmentapp.com/nl/development.html |
