Fotografiju Alfonsa Moralesa na Unsplash-u

"Problem sa softverom"

Oduvijek su me zanimali pronalaženje novih vrijednih knjiga softverskog inženjerstva i u svom članku „Top 5 savremenih knjiga softverskog inženjerstva“ sastavio sam popis mojih trenutnih favorita. "Problem sa softverom: Zašto pametni inženjeri pišu loš kod" Adama Barra (2018.) - da sam ga ranije pročitao - vjerojatno bih ga uvrstio na taj popis. Ovo je pregled i priče iz mog osobnog iskustva povezanih s nekim sadržajem knjige.

Korijenski uzroci

Barr u osnovi predstavlja dugu povijest informatike i tehnologije i kritički raspravlja o činjenici da postoji malo zajedničkog dogovora o standardima i zdravim pristupima SE. Navodi:

Za razliku od drugih inženjerskih disciplina, stjecanje diplome iz softverskog inženjerstva ne jamči razumijevanje poznatog korpusa programskih alata i tehnika jer takvo nešto ne postoji.

Knjiga ne sadrži puno konkretnih savjeta poput "Ako ovako oblikujete svoje metode, poboljšat ćete dizajn softvera i napisati manje lošeg koda". Umjesto toga, autor se usredotočuje na neke temeljne uzroke i objašnjava zašto je stanje u industriji ovakvo kakvo je danas. (Spoiler: Između ostalog, izjava GOTO i programski jezik C odgovorni su za puno loših stvari koje su se dogodile u softveru.)

Prvih nekoliko poglavlja pročitali smo pomalo dugonožno, a meni se drugo poluvrijeme činilo zanimljivijim i misaonijim. To je vjerojatno samo zbog činjenice da sam se, unatoč nekim ranim izlaganjem BASIC-u u Commodoreu C64 i Amiga 500 dana kao klinka, više mogao povezati s novijim dostignućima iz mog profesionalnog iskustva. Međutim, čak i prva poglavlja navode uvidljive dijelove istraživačkih studija SE:

"Postoji jedinstveni aspekt održavanja koji se naziva" oporavak znanja "ili" razumijevanje programa ". To postaje glavna komponenta troškova kako softver stari (pretpostavimo 50% poboljšanja i ispravljanja kvarova)." Polovina budućih troškova održavanja potrošit će se za učenje pojedinosti o vašem programu koje ste u međuvremenu zaboravili!

ili

"... Stoga većina programera ne može učinkovito testirati vlastite programe jer se ne mogu dovesti do oblikovanja potrebnog mentalnog stava: stava koji žele iznijeti pogreške."

Izazovi

Sve u svemu, stvarno sam uživao u uravnoteženom, promišljenom stilu pisanja i Barrovom ogromnom znanju i industrije i istraživanja. On primarno ispituje osnovno pitanje "Je li razvoj softvera doista težak ili ga proizvođači softvera nisu dobri u tome?" Također, sviđa mi se što ne tvrdi da zna sve odgovore, što je u njegovom slučaju svakako oblik poniznosti i poniznosti. (Vratit ću se na to na kraju članka.) Autor ističe neke svoje osobne izazove, uzrokovane nedostatkom standardnog znanja o SE i koji se odražavaju u izjavama kao što su:

Mogla bih mentorirati ljude kako se kretati vodama korporativnog života, ali to je bio generički savjet koji mogu dobiti od bilo koga. Kao i drugi, moje je vodstvo bilo nejasno: "Pa i ja se u ovom slučaju sjećam da je ovakva stvar funkcionirala u redu, pa zašto ne bih pokušao s tim?"

Kontekst

Učinak konteksta u SE projektima i fenomen koji spominje „nazvan Gell-Mannov amnezija“ postaje još jasniji kada Barr kaže:

Ako ste članovima jednog Microsoftovog tima rekli o inženjerskom iskustvu drugog tima, oni će odmah moći identificirati - zbog svog znanja o internim datotekama Microsofta - načine na koji se taj drugi tim razlikuje od njihovog tima i stoga otpustiti Smjernice nisu relevantne. U međuvremenu, oni bi rado usmerili upute za Scrum, čak i ako bi to bilo potpuno neprimjenjivo za njihov tim, jer nisu bili svjesni detalja okoline u kojoj je bio uspješan.

U poglavlju „Dizajnersko razmišljanje“ on pokriva teme poput prednosti dizajna uzoraka i objašnjava u kojim situacijama oni mogu biti korisni, na primjer, kada je vjerojatno da želite modificirati ili proširiti kôd u budućnosti (budući da se mnoštvo uzoraka usredotočuje o budućoj proširivosti). Njihova primjena može biti besmislena, ukoliko buduće promjene modula nisu vjerojatne, u tom slučaju bi one samo donijele složenost. Štoviše, ovo poglavlje sadrži reference na zabavne pojmove istaknutih ljudi poput Spolskog (npr., „Arhitektonski astronaut“ - netko tko vidi svugdje šire apstrakcije i obrasce…) ili druga duhovita zapažanja:

Iako se utemeljeni softverski arhitekti u ovom trenutku smatraju boljim od onih koji nemaju kisik, činjenica da arhitekti trebaju kontinuirano uranjanje u trenutni projekt svog tima još je jedan znak da nema dovoljno prihvaćenog znanja i rječnika oko softverskog inženjerstva.

Autor naglašava da "razumni savjeti" knjiga poput "Čisti kod" i "Pragmatični programer" ne predstavljaju "specifične pristupe". Dizajn softvera jedinstven je u smislu da su razvijeni sustavi jedva usporedljivi. Budući da se često bavimo potpuno novim domenama i poslovnim problemima, kvaliteta dizajnerskih rezultata snažno varira čak i za vrlo iskusne ljude. Barr tvrdi da "kada skinete gluposti s dizajna softvera, preostaju vam obrasci dizajna, a ne mnogo drugoga".

Pomalo povezan s kontekstom, u poglavlju "Vaš omiljeni jezik" spominje da je glavni problem s našim mnoštvom različitih programskih jezika i njihovim zamišljenim dizajnom da postoji vrlo malo smjernica o tome kada je za rješavanje određenog jezika jedan bolji od drugog. problem. I opet kasnije, u poglavlju „Agile“, imamo samo malo znanja o tome kada su upravo agilne softverske metodologije i prakse poput Scruma zaista vrijedne. Poglavlje završava:

Iako Agile može malo olakšati probleme, to ne pomaže teškim problemima. To je privlačno programerima, ali da bi softverski inženjering više postao inženjerska disciplina, potrebno je nešto drugo.

Istraživanje

Kad sam proveo nekoliko godina na istraživanju i podučavanju na Sveučilištu, nakon što sam pročitao relevantne radove ili „Izrada softvera“ (jedna od rijetkih knjiga koja pokušava dovesti istraživanje SE u širu publiku), iznenadio sam se kada sam saznao koliko istraživanja u SE zapravo postoji. Međutim, često sam bio nezadovoljan zaključcima budući da ste potajno očekivali univerzalne odgovore poput „Ne, TDD nije koristan“ ili „Da, obrasci dizajna su korisni“ - argumenti koje ste se nadali da ćete upotrijebiti u svojim sljedećim razgovorima s kolegama kako biste ih uklonili. njihovi vjerski argumenti i anegdotski dokazi. Naravno, zahvaljujući ograničenjima eksperimentalnih dizajna, odgovori su često bili slični "Da, pod tim uvjetima i u tom specifičnom kontekstu, to može imati smisla ...". Nadalje, često sam smatrao da nacrti studije nisu baš dobro zabilježili stvarnost razvoja softvera (što je jedan od glavnih izazova u SE na temelju dokaza).

Kodiranje Dojoa

Posebno mi se svidjelo završno poglavlje "Budućnost" i autorove prijedloge o tome što zapravo možemo učiniti za poboljšanje situacije i, naravno, puno Barrovih ideja ima veze s obrazovanjem, kako predajemo SE na sveučilištu i kako su studenti pripremljeni za poslove u industriji. Poglavlje je inspirativno i kad se ponovno osvrnem na svoje vlastito akademsko iskustvo, jaz između akademije i industrije uvijek me muči. Barr navodi Weinberga koji piše:

Programi softvera koji se rade na sveučilištima ne moraju biti održivi, ​​upotrebljivi ili testirani od strane druge osobe.

U pokušaju da malo smanjim taj jaz, ono što smo tada radili i ja, smislili smo novi koncept kolegija za naše studente pod nazivom „Kodiranje dojoa“. Glavna ideja bila je uspostaviti višednevni intenzivni seminar kako bi sudionike podučio onome što smo kasnije smatrali važnim za rad u industriji i onome što inače ne bi naučili u nastavnom planu i programu informatike. Tako smo razmislili, smislili ideje, ispisali letak koji bi trebao privući studente i izgradili interaktivni sustav za podučavanje tema poput čitljivosti koda, mirisa koda, refaktoringa itd. Cijeli smo uskrsni praznici potrošili dizajnirajući ovaj sustav u stvarnom vremenu koji bi mogao predstaviti interaktivni vježbe s automatskim evaluacijama i pokušao je ugraditi sve što smo tada znali o temi, uključujući materijale iz knjiga poput "Code Complete" ili "Refactoring".

Još uvijek sam ponosan na koncept i tečaj je bio uspješan (barem u smislu povratnih informacija i popularnosti), ali koliko znam, do danas je to bio jednokratni napor. Nadalje, seminari poput „Kodiranje dojoa“ ne bi pomogli problemu što studenti obično ne moraju raditi sa „većim dijelovima softvera“, koji bi ih, prema Barru, rano izložio programima koji su „izgrađeni iz veza preko API-ja“. granice ”i time ih suočavaju s važnim razvojnim aktivnostima kao što su čitanje, razumijevanje i uklanjanje pogrešaka značajno velikog sustava.

Specijalizacija

Mnogo se toga može poboljšati u nastavnim programima CS-a i SE-a, a kako Barr tvrdi, specijalizacija bi mogla pomoći jer je cijelo područje postalo preširoko i komplicirano da bi se sve dobro razumjelo. Umjesto da teme poput kompajlera, grafike i naprednih struktura podataka - teme s dobro istraženim osnovama - budu obavezne, studenti na preddiplomskom studiju mogli su se odlučiti usredotočiti na svoje željene predmete. To bi tada pomoglo oblikovanju njihovog profila budućim poslodavcima i stupnju veće vjerodostojnosti. Barr piše:

Trenutno se na softverske inženjere koji dolaze s fakulteta smatraju da je moguće djelovati; očekuje se da svaki programer, ako se utvrdi kompetentnim bilo kojim postupkom zapošljavanja, može raditi na bilo kojem dijelu programa. Kako softver postaje sve složeniji, ljudi imaju više smisla specijalizirati se na različitim područjima.

Intelektualna poniznost

Napokon, moj najdraži savjet koji se spominje u knjizi, a koji se u prošlosti čuo negdje drugdje, jest „Ponizni se poboljšaju“, ističući točku ako ostanete znatiželjni i nastavite učiti dok imate stav „Unatoč godinama iskustva, mislim da „Ne tvrdim da sam stručnjak za tu temu i uvijek se mora znati više“. Iako taj savjet može zvučati jednostavno, često sam bio zapanjen time kako visoki kandidati koji se prijavljuju za poziciju u SE-u ocjenjuju vlastite razine vještina (molimo kandidate da ispune "obrazac za samoprocjenu" prije tehničkog intervjua). Moj dojam je da je to obično znak seniorke kada ljudi sa značajnim iskustvom ne daju sebi najviše ocjene u određenim područjima - što ukazuje na to da ostaju intelektualno ponizni i da bi u stvari mogli biti oni koji najbolje poboljšaju svoje vještine.