Vi har alle hørt om 80/20-regelen, den som sier at 80% av vår suksess (effekter) kommer fra bare 20% av våre handlinger (årsaker). Vel, denne universelle sannheten påvirker også programvareutvikling, og i denne artikkelen skal vi spole litt på det grunnleggende i denne uttalelsen.
BPM
Business Process Management, for forkortelsen på engelsk, er en ledelsesdisiplin (blant annet) som lar deg visuelt forstå prosessene som må utføres i en bedrift (eller mange andre steder). Blant de viktigste egenskapene er det at den kan analysere komplekse prosesser og gjøre dem "enkle".
Det er mange open source-verktøy som lar deg utvikle BPM-diagrammer, den jeg har brukt til denne artikkelen er BonitaSoft. Hvis du vil lære litt mer om prosessadministrasjon, er det mange opplæringsprogrammer på internett og bøker om emnet. La oss nå komme tilbake til det sentrale emnet.
Programvareprosjekter
I dag er det mange metoder for å utvikle prosjekter, det er smidige, tradisjonelle, blandede osv. Osv. Et poeng de alle har til felles er forberedelse. Hva jeg mener med dette? At 80% av suksessen din i dette programvareprosjektet vil være basert på de første 20% av hele prosessen, forberedelsen.
Forbereder et prosjekt
Dette er noe logisk som i realiteten brukes veldig lite (som mange andre logiske ting som er ulogiske i praksis). Når vi snakker om forberedelse, må vi forstå evnen til å forstå problemet, forstå løsningen og fremfor alt, prosessen at løsningen gjelder. Noe av det som minst finnes i uprofesjonelle programvareprosjekter, er mangelen på dokumentasjon om emnet. Dette vises vanligvis i private selskaper siden ønsket om å selge overstiger skapelsesprosessen.
Ettersom mange av dem som leser disse artiklene jobber eller er relatert til teknologi, er det verdt å nevne at hvis de på et tidspunkt i arbeidslivet finner et selskap / leverandør som ikke oppfyller et godt forberedelse, er det nesten 80% sikkert sure at prosjektet det ordner seg ikke.
Abstraksjon er nøkkelen
Dette er noe jeg har lært fra min tid ved hjelp av GNU / Linux, og det viser seg gang på gang å være nøkkelen i programvarelagringsprosessen. Kapasiteten til abstrakt problemer for å gjøre dem til mer "enkle" ting er viktig for å kunne generere elegant kode, og fremfor alt langvarig. Og kanskje er dette en av hovedforskjellene fra store profesjonelle prosjekter og prosjekter som vokser ut av kontroll. Førstnevnte tenker, forstår og strukturerer prosessen mens sekundene de holder jobber uten å trenge å forstå det.
stager
Dette er navnet på prosjektet som Gentoo-installatøren utvikler, som du kan forestille deg, dette er ganske komplisert, siden det støtter et stort antall arkitekturer. En annen faktor å ta i betraktning er antall konfigurasjoner den støtter, på kjernenivå, init-system, etc. Og jeg forteller deg alt dette fordi det også er avhandlingsprosjektet mitt, som jeg må fullføre før jeg er ferdig med studiet. Åpenbart kan jeg ikke lage et program som vurderer absolutt alle mulige alternativer på så kort tid (til juli neste år), men i det minste kan jeg generere et som lar et funksjonelt system installeres på en veldig grunnleggende måte.
Forstå installasjonsprosessen
Takket være BPM-verktøyene kan det genereres et prosessdiagram som lar oss forstå trinnene som er nødvendige for en vellykket installasjon av Gentoo på en datamaskin.
Egen. Christopher Diaz Riveros
Til tross for at den inneholder flere prosesser og delprosesser, har den åpenbart blitt ganske oppsummert, og det kan sees at vi har 18 lineære trinn. Dette er viktig fordi et program som har en lineær struktur er enkelt å implementere, og samtidig kan det genereres parallellitet i en eller flere av trådene.
En annen viktig faktor er at det tillater oss abstrakt sett med prosesser etter type, for eksempel ved å definere en kjernetråd, kan vi vite at det er spesifikke oppgaver i den som er direkte relatert til prosessen med å installere en kjerne.
Egen. Christopher Diaz Riveros
På denne måten blir hvert "komplekse" trinn et "enkelt" på en global måte, uten å miste de nødvendige detaljene. Dette letter synligheten til forsamlingen uten å senke spesifikasjonsnivået som er nødvendig for å fullføre prosessen. Og vi kan ikke benekte at det er lettere å se bildet enn å lese hele håndboken på en gang 🙂
Spare tid
En annen åpenbar fordel er at ved å ikke ha et direkte koblet programmeringsspråk, er det mulig å utføre logisk analyse uten å kaste bort tid på å implementere språket. Dette er en fordel i forhold til hvor lang tid det kan brukes på å implementere en funksjon bare for å finne ut at den vil bli kastet fordi det er en mer effektiv løsning. Som hva som ville være løsningene i pseudokode (noe som også ignoreres av mange "utviklere", men som ikke burde være).
Det er enkelt å lede prosjekter
Når vi tar disse konseptene i betraktning, blir prosjektledelse (av noe slag) lettere, fordi vi fokuserer innsatsen der de virkelig er behov for, og hvis denne delen gjøres riktig, faller resten under sin egen vekt. Jeg håper det hjelper nysgjerrigheten din og motiverer deg til å undersøke BPM, algoritmikk og hvem vet, kanskje det vil oppmuntre deg til å hjelpe meg med oppgaven min 😛 Tusen takk for at du kommer hit, og vi ser hverandre snart. Jubel
Hei. Takk for at du delte din kunnskap. Det virker som om det er et spennende emne, men at det krever mye forskningsarbeid og å sette konseptene ut i livet for å kunne internalisere dem. Først er problemet forvirrende fordi man har en tendens til å knytte det mer til siden for å identifisere kravene til et system og ikke nødvendigvis med forretningsprosessene i selskapet, det vil si hvordan selskapet fungerer. Til slutt tror jeg det handler mer om hvilken rolle programvareutviklere spiller for å modellere virksomheten til selskapet, for å gjøre driften av virksomheten mer effektiv og effektiv.
Hei Alexander, tusen takk for at du delte. For å si sannheten er det et litt komplekst tema å prøve å oppsummere alt på et så lite rom, men hvis jeg kan bidra litt for å komme ut av forvirring med kommentaren din 🙂 er det sant at systemer skal prøve å løse krav, at er den mest mulige grunnleggende funksjonaliteten, og på det tidspunktet er det sant at en utvikler bør fokusere på et høyere nivå.
Kunnskap om prosessene gjør at utviklere kan presentere mer enn nok systemer, og forstå nok som noe som oppfyller minst mulig krav.
Kodens eleganse ligger i å kunne forstå hele prosessen, og generere den på en dypere måte, der den beste mulige løsningen blir brukt, og dette er bare mulig ved virkelig å forstå prosessen i stedet for kravet, som du vel nevnte 🙂
Hvis vi modellerer det litt rundt FOSS, innebærer det ikke bare å kjenne programvarekravet, men filosofien bak det, og vite hvordan det vil opprettholdes, av hvem, og all den kunnskapen om prosessen som ikke bare genererer en effektiv løsning ., men det vil være mulig å opprettholde over tid 🙂
Tusen takk igjen og hilsener.