We hebben allemaal gehoord over de 80/20-regel, degene die zegt dat 80% van ons succes (effecten) afkomstig is van slechts 20% van onze acties (oorzaken). Welnu, deze universele waarheid heeft ook invloed op softwareontwikkeling, en in dit artikel gaan we een beetje van de grondbeginselen van deze verklaring af.
BPM
Business Process Management, voor het acroniem in het Engels, is (onder andere) een managementdiscipline waarmee u visueel inzicht krijgt in de processen die in een bedrijf (of op veel andere plaatsen) moeten worden uitgevoerd. Een van de belangrijkste kwaliteiten is het feit dat het complexe processen kan analyseren en ze "eenvoudig" kan maken.
Er zijn veel open source-tools waarmee je BPM-diagrammen kunt ontwikkelen, degene die ik voor dit artikel heb gebruikt, is BonitaSoft. Als je wat meer wilt leren over procesmanagement, zijn er veel tutorials op internet en boeken over het onderwerp. Laten we nu teruggaan naar het centrale onderwerp.
Software projecten
Tegenwoordig zijn er veel methodologieën om projecten te ontwikkelen, er zijn agile, traditionele, gemengde, enz. Enz. Een punt dat ze allemaal gemeen hebben, is voorbereiding. Wat bedoel ik hiermee? Dat 80% van uw succes in dit softwareproject zal worden gebaseerd op de eerste 20% van het hele proces, de voorbereiding.
Een project voorbereiden
Dit is iets logisch dat in werkelijkheid heel weinig wordt toegepast (zoals veel andere logische dingen die in de praktijk onlogisch zijn). Als we het hebben over voorbereiding, moeten we het vermogen begrijpen om het probleem te begrijpen, de oplossing te begrijpen en vooral, het proces dat de oplossing van toepassing is. Een van de dingen die het minst worden aangetroffen bij onprofessionele softwareprojecten, is het gebrek aan documentatie over het onderwerp. Dit komt meestal voor bij particuliere bedrijven, omdat de wens om te verkopen groter is dan het creatieproces.
Aangezien veel van degenen die deze artikelen lezen, werken of gerelateerd zijn aan technologie, is het de moeite waard om te vermelden dat als ze op een bepaald moment in hun werkende leven een bedrijf / leverancier vinden dat niet aan een goede voorbereiding voldoet, het bijna 80% zeker is 😛 dat het project het zal niet lukken.
Abstractie is de sleutel
Dit is iets dat ik heb geleerd van mijn tijd met GNU / Linux, en het blijkt keer op keer de sleutel te zijn bij het maken van software. De capaciteit van abstract problemen om ze in meer "eenvoudige" dingen te veranderen is essentieel om elegante code te kunnen genereren, en vooral Duradero. En misschien is dit een van de belangrijkste verschillen tussen grote professionele projecten en projecten die uit de hand lopen. De eersten denken, begrijpen en structureren het proces terwijl de seconden onderhouden werken zonder het te hoeven begrijpen.
toneelspeler
Dit is de naam van het project dat het Gentoo-installatieprogramma ontwikkelt, zoals u zich kunt voorstellen, dit is een vrij complex proces, aangezien het een groot aantal architecturen ondersteunt. Een andere factor waarmee rekening moet worden gehouden, is het aantal configuraties dat het ondersteunt, op kernelniveau, init-systeem, enz. En ik vertel je dit allemaal omdat het ook mijn afstudeerproject is, dat ik moet afronden voordat ik klaar ben met studeren. Het is duidelijk dat ik in zo'n korte tijd (tot juli volgend jaar) geen programma kan maken dat absoluut alle mogelijke opties bevat, maar ik kan er in ieder geval een maken waarmee een functioneel systeem op een heel eenvoudige manier kan worden geïnstalleerd.
Inzicht in het installatieproces
Dankzij de BPM-tools kan een processchema worden gegenereerd dat ons in staat stelt de stappen te begrijpen die nodig zijn voor de succesvolle installatie van Gentoo op een computer.
Eigen. Christopher Diaz Riveros
Ondanks dat het verschillende processen en subprocessen bevat, is het duidelijk behoorlijk samengevat en kan men zien dat we 18 lineaire stappen hebben. Dit is belangrijk omdat een applicatie met een lineaire structuur eenvoudig te implementeren is en tegelijkertijd indien nodig parallellisme kan worden gegenereerd in een of meer van de threads.
Een andere belangrijke factor is dat het ons toelaat abstract sets van processen op type, bijvoorbeeld het definiëren van een kernel-thread stelt ons in staat om te weten dat er specifieke taken in zitten die rechtstreeks verband houden met het proces van het succesvol installeren van een kernel.
Eigen. Christopher Diaz Riveros
Op deze manier wordt elke "complexe" stap een "eenvoudige" op een globale manier, zonder de nodige details te verliezen. Dit vergemakkelijkt de zichtbaarheid van de assemblage zonder het specificatieniveau te verlagen dat nodig is om het proces met succes te voltooien. En we kunnen niet ontkennen dat het gemakkelijker is om de afbeelding te zien dan om het hele Handboek tegelijk te lezen 🙂
Tijd besparen
Een ander duidelijk voordeel is dat door geen direct verbonden programmeertaal te hebben, het mogelijk is om logische analyse uit te voeren zonder noodzakelijkerwijs tijd te verspillen aan het implementeren van de taal. Dit is een voordeel ten opzichte van de hoeveelheid tijd die kan worden besteed aan het implementeren van een functie om erachter te komen dat deze wordt weggegooid omdat er een efficiëntere oplossing is. Zoals wat de oplossingen in pseudo-code zouden zijn (iets dat ook door veel "ontwikkelaars" wordt genegeerd, maar dat niet zou moeten zijn).
Projecten leiden gemakkelijk gemaakt
Rekening houdend met deze concepten wordt projectmanagement (van welke aard dan ook) gemakkelijker, omdat we onze inspanningen richten waar ze echt nodig zijn, en als dit onderdeel correct wordt gedaan, valt de rest onder zijn eigen gewicht. Ik hoop dat het je nieuwsgierigheid helpt en je motiveert om onderzoek te doen naar BPM, algoritmen en wie weet, misschien zal het je aanmoedigen om me te helpen met mijn scriptie 😛 Heel erg bedankt dat je hier bent en we zullen elkaar snel zien. Proost
Hoi. Bedankt voor het delen van uw kennis. Het lijkt me een boeiend onderwerp, maar het vergt veel onderzoek en het in praktijk brengen van de concepten om ze te kunnen internaliseren. In het begin is het probleem verwarrend omdat men het eerder associeert met het identificeren van de vereisten voor een systeem en niet noodzakelijkerwijs met de bedrijfsprocessen van het bedrijf, dat wil zeggen, hoe het bedrijf werkt. Uiteindelijk denk ik dat het meer gaat om de rol die softwareontwikkelaars spelen bij het modelleren van het bedrijf van het bedrijf, om de werking van het bedrijf efficiënter en effectiever te maken.
Hallo Alexander, heel erg bedankt voor het delen. Om de waarheid te zeggen, het is een ietwat ingewikkeld onderwerp om te proberen alles in zo'n kleine ruimte samen te vatten, maar als ik een beetje kan bijdragen om uit de verwarring met je opmerking te komen 🙂 het is waar dat systemen moeten proberen om vereisten op te lossen, dat is het meest mogelijke basisfunctionaliteit, en op dat moment is het waar dat een ontwikkelaar zich op een hoger niveau moet richten.
Kennis van de processen stelt ontwikkelaars in staat om meer dan voldoende systemen te presenteren, waarbij ze voldoende begrijpen als iets dat aan de minimaal mogelijke vereisten voldoet.
De elegantie van de code ligt in het kunnen begrijpen van het volledige proces en het op een diepere manier kunnen genereren, waar de best mogelijke oplossing wordt toegepast, en dit is alleen mogelijk door het proces echt te begrijpen in plaats van de vereiste, zoals je al zei 🙂
Als we het een beetje rond de FOSS modelleren, betekent dit niet alleen dat we de softwarevereiste kennen, maar ook de filosofie erachter, en weten hoe het zal worden onderhouden, door wie, en al die kennis van het proces die niet alleen een efficiënte oplossing genereert. , maar het zal na verloop van tijd mogelijk zijn 🙂
Nogmaals hartelijk dank en groeten.