Szakmát csinálunk a szoftverfejlesztésből

Fórumok

A szoftverfejlesztés nem szakma: nincsenek olyan általánosan elfogadott szabályai, amik betartása esetén valószinűleg nem fogod elrontani.
Elkezdtünk hát azon gondolkodni, hogyan nézne ki a fejlesztés, ha szakma lenne.
Megmutatjuk, hol tartunk a gondolkodásban, és mit fogunk csinálni, hogy ellenőrizzük a hipotéziseinket.
https://www.meetup.com/Budapest-Kode-Konveyor-Meetup-Group/events/26442…

Hozzászólások

1. De ráértek.
2. Igazatok van, elszaladtak a dolgok.
3. Nem csak a szoftveriparral van gond, az asztalos iparnak sincsenek szabályai azon kívül hogy szép legyen és tartós.
4. Mivel nehezen kézzelfogható a szoftver, így a mérőszám is nehéz, miszerint mennyire jól van megcsinálta. (Mi tudjuk hogy mitol tud rossz lenni, de a megrendelő nem). Pont mint ahogy az USA felkéri a NASA-t, hogy valamit kutasson fel. És ha nem az van ott, attól még siker. De vajon megérte a bealdozott pénz?

Kösz a biztatást!

3. Vannak szabályok arra, hogy hogyan rajzolod elő a cuccot. Hogy nem tartod a vésőt magad felé. Hogy felveszed a pormaszkot, ha csiszolsz. Nekünk is ott van a Clean Code meg a TDD, csak senki nem használja. És mint kiderült, ez a kettő szükséges, de nem elégséges.
4. tesztlefedettség, komplexitás, policysértések száma, mutációs lefedettség

3. persze meg az Agile, és társai.

- Rakjunk MI-t a software-be.
- Jó ki ért hozzá?
- Senki, de ha Agilisen csináljuk tuti sikerül

Attól, hogy valami clean code, vagy tab-ot használunk space helyett...stb. még nem lesz jó valami. Attól még lehet zseniálisan jó és csapnivaló is.

Szerintem ne akarjuk formalizálni a fejlesztést, még talán a kódolást se nagyon (mondjuk azért az nem hátrány ha a team megegyezik, hoy akkor most clean code vagy mi legyen ha már ennél a példánál voltunk).

A nagy formalizálásból csak az lenne, hogy formális nyelvek, touring gép meg minden. Ami Adott esetben lehet segít, de azért egy webfejlesztést azzal csinálni picit overkillnek érzem.
Az a baj, hogy ha formalizálod, akkor kell egy olyan szabályrendszer ami egyértelmű, ami meg oda fog vezetni, hogy vagy van egy szabálykönyved, tele "jógyakorlattal", és annak a bevezetésére vannak "jógyakorlatok", de hogy azt meg tudd csinálni, ahhoz kell valami, amire szintén van "jógyakorlat" :D
Másik út, hogy matematikát használsz, akkor meg ott vagy a formáls nyelvek, touring gépek, petri hálóknál, valamint szigorú algoritumselméletnél. Ami szerintem nem hátrány, ha a fejlesztő ezeket tudja és érti, de azért "nem mindenhez" érdemes használni
Valamint ezzel kiszórod a juniorokat és olyan belépési küszöböt állítasz fell, ami nagyon sokakat kizár.
Kíváncsi lennék, hogy a hup-on lévő fejlesztők milyen %-a tudná ezt megugrani, attól függetlenül, hogy mondjuk nagyon jó fejlesztő. Nem hiszem, hogy nagy lenne a korreláció. :D

A gépészet terén is a kezdeti időkben voltak a tervezéstől-reszelőtolásig szakik. Aztán az eltelt évszázadok alatt fokozatosan kialakultak a tervezői és kivitelezői szintek. Köztük az interfész a szabványos műszaki rajz lett. Ezzel a gépészeti dokumentáció is létrejött.

Az informatika úgy látom, ugyanezen úton indul. Tervezéstől-kódírásig egyszemélyben akarjuk. Közben nem születik meg a fentiekhez hasonló dokumentáció sem ("minek").
Aztán ha a termék alkotója kilép a cégtől, más nem vagy igen nehezen tudja átvenni supportra a terméket.

Két okból nincs és nem is lesz dokumentáció, szerintem:

- Egyrészt a LEAN előbb utóbb minden bizniszbe beépül még a virágárushoz is, és ennek az a lényege hogy csak arra költsön a cég ami a core biznisz. Minden más kuka vagy ha izomból sem lehet kukázni mert kell (pl. IT*.*) akkor az szükséges rossz amire mindenféle ráfordítást minimalizálni kell, aztán azt felezni minden évben. Minden cég akinél a core biznisz nem az IT annak az IT összes szeglete "Muda II". Nem hogy többet nem fognak fizetni érte de a LEAN terjedésével a jövőben a töredékét sem akarják majd kifizetni annak amit ma még kifizetnek. A mai ismert felhőszolgáltatásoknak a jövőben sokkal olcsóbbnak kell lenniük, ha máshogy nem megy akkor a funkcionalitás csökkenésével, jönnek majd a mikro-szoftverkomponensek (akár felhős akár nem) hogy ezekből mindenki pont azt legózhassa össze ami épp lefedi a Muda II igényét, felhős verzió esetén júser oldalról nulla CPU, RAM, STORAGE, stb. felesleggel, hogy a júzer fillérre pont annyit fizessen csak amennyit elhasznál 1-1 szoftver funkciójából. Például a Photoshop bérlésnek is el kell jutnia addig, hogy nem az egész szoftver bérlése után fizet a júzer hanem csak a ténylegesen használt menüpontok és azok futási ideje után. És az is még csak a kezdet lesz. :) Aztán majd számít az is, hogy mekkora méretű, színmélységű, stb. képet szerkeszt, stb. A jövőben azt tudom elképzelni, hogy emberek megírnak majd mikroszolgáltatásokat szabványosított ki-/bemenettel és melléraknak egy árat/hó. Aztán lesz egy (vagyis 3 különböző, Google, MS, Amazon) bazinagy AI aminek a júzer megmondja hogy mit szeretne és mennyiért, az AI egyszeri díjért meg ezekből a szabványos interfészű mikroszolgáltatásokból összekukázza és összedrótozza azt amit a júzer kér, annyiért/hó, ámen. Ha ez lefedi a Muda II szintű szükséges rossz típusú szoftverigények 80%-át (és mért ne fedné le), akkor ez már önmagában felfordít mindent és az AI majd generál dokumentációt ahhoz amit összedrótozott. És ehhez nem a fejlesztőket kell szabványosítani hanem a szoftver interfészeket/tárolókat ami még megvalósítható is lehet akár. Ezt mondjuk én nem fogom megérni de a gyerek talán.

- Másrészt az agilitás pont arról szól, hogy elsősorban nem az számít hogy mikor lesz kész (azaz mennyibe kerül majd) hanem az, hogy pont olyan legyen amilyennek lennie kell, de mivel az utolsó napig senki nem tudja milyennek kell lennie ezért akár 2 hetente fordulhat 180 fokot az irány. Azt meg úgysem győzi senki dokumentációval. Amikor meg már készen van akkor (nyilván végül a "becsült" költségek többszörösébe kerülő fejlesztés miatt) meg senki nem fogja még pluszban azt is kifizetni hacsak nem multi cég a megrendelő, meg hát minek, működik, készen van. Ez utóbbiak vezetői szinten egyébként is döntéshozást vezérlő varázsszavak. A "tesztelés" szó már vezetői szinten sincs benne a szótárban, ha meg jól megnyúlik az agilitás akkor egyébként is a tesztelés lesz a dokumentáció után a második, amin spórolni lehet. Az előző pontban említett legózó AI amúgy pont fainul teljesíti azt, hogy kérek valamit lesz valami aztán kérem kicsit másképp és tetszőleges iteráció után végül rámondom hogy ez így jó. És kész is az agilis szoftverlegózás AI-al. A szoftver projektek maradék 20%-a (pl. hadronütköztetőbe vagy az ezzel egyenértékű magyar jövedéki törvény alá tartozó vállalkozások ügyvitele) meg marad kézzel hajtott soha véget nem érő fejlesztés.

Arról, hogy mi lesz a jövő nagyon teoretikus vitázni. Mondjuk nagyon jól esik. :)
Az tény, hogy "valami as a Service" jellegű jövőre van esély. A probléma szerintem kicsit összetetteb. Ezek a csilivili új metodikák és azok mutációi kicsit olyan érzést kelt, hogy bármit csinálsz, az már "múltheti". :)

Az elgondolásod feltételez egy stabil, beállt üzletmenetet. Ha ezt elfogadom, akkor pár ponton az AI-t illetően vitatkoznék, de összeségében igazad van.
Viszon amennyire én látom a 21. század arról szól, hogy nekem legyen még több releváns infóm, mint a versenytársamnak, mert akkor ha nem szúrom el, akkor én nyertem. Ebbe a szemléletbe kevésbé fér bele az amit írtál. Persze biztos lesznek komponensek, amit akár össze is drótozhatok. Csak felmerül pár kérdés. Példáúl az, hogy milyen biztonságban van így az információm, valami direkt, vagy közvetett módon a versenytárs értesülhet-e róla. Ki lesz az, aki a az új csilivili algoritmust amivel az előnyt biztosítja azt ki írja meg? Kiraknám a felhőbe?

Én értem, hogy mindennek le akarják tólni az árát, de ha valamelyik cég veszi a fáradságot és csinál valami sokkal jobbat, mint a konzerv megoldás és azt nem lesz nehéz, mert azt mindenki unalomig ismeri, akkor a versenytársak ott fognak állni ingben, gatyában. Tulajdonképpen az K+F+I-t helyetesítenéd konzerv megoldásokkal. Nah szerintem ma az IT pont az ellenkező irányba megy.

Dokumentációban addig sem jutnak el, hogy N pontban összefoglalják, hogy mi az ami fontos... Nagyon vicces ezeket a juzereket szapportálni meg üzemeltetni ám. :)
- Nemmegy. (nem a titkárnő, hanem egy elvileg képzett és talán diplomás fejlesztő)
- Kérünk akkor valami pontos hibaüzit, logrészletet, hol jön hiba.
- X nemmegy, oldjátok meg ASAP.
Innen jön a loop...

Ez máris mindennek ellentmond és gyanítom ezt a LEAN nevű csodát is masszívan félreértelmezik. :) Ami a legdurvább, hogy olyan helyen is látom ahogy csapatva faragják az IT kiadást, ahol az a core biznisz. Node ők tudják, remekül menedzselik, egy ideig.

Ne csodálkozz, valaki ebben a topicban már utalt az értő olvasásra.

Szerintem sokmindent félreértenek. Már már vallásos hit van bizonyos dolgokkal kapcsolatban. A SiliconValey-ban figurázták ki nagyon aranyosan a TAB vs Space kérdést. De ugyanez igaz, a clean code-tól elkezdve az Agile-ig mindenre.
Egyik nagy kedvencem az: "...és akkor írtam rá egy optimális kódot." Aztán ha megkérdezed, hogy mi szerint optimális és hogyan látta be, akkor természetesen te vagy a negatív, aki nem képes elismerni az ő zsenijét és tuti irigy vagy. :)

A dokumentációval kapcsolatban van egy látszólagos ellentmondás. Egyrészt szükséges a szoftver megértéséhez -> a hozzányúláshoz, másrészt a LEAN azt mondja, hogy ne írj olyan dokumentációt, ami azonnal elavul, ahogyan leírtad.
Az agilis architektúra ezt a látszólagos ellentmondást úgy oldja fel, hogy a dokumentáció jól formalizált, csak annyi van belőle, amiből közvetlenül következik a következő tervezési szint, a tervezési szintek közötti inkonzisztenciát pedig automatikusan ellenőrizzük, a konzisztenciasértés pedig ugyanakkora probléma, mint egy syntax error a kódban.
Mi ezt úgy oldjuk meg, hogy a felső tervezési szintek architektúra modellben vannak, amit egy metamodell definiál.
A modell és a kód között a konzisztenciát a tesztesetek annotációján keresztül biztosítjuk.
A modell metamodellnek való megfelelőségét, valamint a tesztesetek és a modell közötti megfelelőséget automatikusan ellenőrizzük, a modellben természetes nyelven leírt viselkedések és a tesztesetek közötti konzisztencia biztosítása az emberi review fő feladata, a tesztesetek és a produkciós kód között pedig teljes mutációs lefedettséget követelünk meg.
A végfelhasználói dokumentáció szerkezetét a modellből, tartalmát pedig a tesztesetek definíciójábol generáljuk (utóbbit csak review-n keresztül lehet változtatni).

Ha jól értem kreáltok a tervezési fázisban egy metamodellet, valamilyen formátumban. Ez alapján írtok egy kódot, és úgy próbáljátok meg kitalálni, hogy a kód az azt írja le ami a modell, hogy csináltok sok tesztet és amennyiben stimmel, akkor örülés van.
Sarkítom.
Először terveztek, majd megvalósítjátok és teszteltek. Ez nekem úgy tűnik mint a régi jól bevállt recept, kicsit szebb szavakkal megfogalmazva.
Kérdés: Hogyan biztosítjátok, hogy a tesztesetek lefedjék az elvárt és a nem elvárt működési eseteket. Mert ha ezt nem tudod megmutatni, akkor kb ott vagy mint a kiinduló pontnál, amit meg akartál reformálni. Tulajdonképpen elmodnható, ha betartod az IT egyik alapelvét, miszerint: Ne légy hülye! Ez amit leírtál tökéletesen fog működni. Amenyiben nem és ez akaratlanul is sokszór előfordul, ezt szeretnétek megváltoztatni, akkor nem látom, hogy ez mitől védene meg jobban.

Viszont szerintem ebből a leírásból látszik, merre lenne érdemes menni. A tervezést nem szabad elszúrni, valamint szerintem a matematikai alapú tervezés lenne egy érdekes irány. A probléma ott van, hogy ezt nem tudod kiadni, hogy írják meg, mert erre nem hősök, hanem szuperhősök kellenének. A nagy kérdés, hogy ebből hogyan generálunk valamit ami megegyezik az eredetivel, de élő munkavállaló is tudja értelmezni és implemnentálni, ne kelljen hozzá matematikus, hogy implementálja. Mert ezek után lehet írni algoritmust arra, hogy a kódot matematikává alakítja és belátja, hogy a kettő megegyezik. Viszont ez csak akkor út, ha valami kritikus dolgot csinálsz. A Marika2020kft webshopjához ez nem kicsit overkill.

Tudom, hogy manapság ez az automatizáljunk, formalizáljunk nagyon nagy divat, lásd pl RPA. (ami tök jó is). Írtó jó kutatási terület, akár cégeknek is. Nagyon tetszik is a téma. De szerintem ezt egyenlőre adott üzleti területekre lehetne csak formalizálni, és valószínű annak egy részére, ha ez bonyolúlt terület. Szerintem nem sokáíg lesz már magában IT, mint gyüjtőfogalom, sőt szerintem a fejlesztés se. Szerintem ezen folyamatok management-je is változni fog. Ha nagyon sarkítani akarok, akkor az van most IT management területen, hogy vannak problémák, amikkel a cégek bírkóznak, aztán ha valakinek sikerül megoldani, akkor mindenki azt kezdi el hypolni, és késhegyre menő viták vannak, de mire odajutnak már minden másképpen működik. Kb olyan mint az unlimited podcastban mesélte a Kéri László, hogy mikor írták le a rádióbol az angol szöveget sértésekig elmenő vita folyt, hogy azt az angol szót hosszú vagy rövüd ü-val írják. :D

A metamodell nem a tervezési fázisban készül, hanem hamarabb: az módszertani alap.

A technológiai architektúra terv dolga, hogy minden alap működési és hibakezelési viselkedést lefedjen olyan részletezettséggel, hogy egy viselkedésből néhány teszteset következzen.
A review dolga annak biztosítása, hogy egy viselkedést (ami a kiadott feladat) a tesztesetek (ami a kifizetési egység) teljesen lefedjenek. Mivel a teszteset a kifizetési egység, ezért a kóder arra van motiválva, hogy minél több tesztesetet készítsen: lefedjen minden működést.

Az, hogy hol húzzuk meg a határt a tervezés és a kódolás között, alapvető folyamatszervezési kérdés: a kódolás párhuzamosítható, a tervezés pedig nem. Az egyik út a formális helyességbizonyítás ("matematikai alapú tervezés") lett volna. Az nagyon későre teszi ezt a határvonalat. Mint ahogyan a BDD is, ami tulajdonképpen ugyanaz, csak a formalizmus nem matematikai, hanem kód és adatalapú. Ez pont az a különbség, amire Uncle Bob azt mondta, hogy a programozás nem matek, hanem tudomány.

Mi azt választottuk, hogy a tervezés kimenete informális nyelven, de nagyon részletesen leírt viselkedésekből (és formálisan leírt adatstruktúrákból és interfészekből) áll. Így sokkal hamarabb kerül át a feladat a kódolásra -> jobban párhuzamosítható, és marad a kóder számára is olyan feladat, ami intelligenciát igényel, ha nem is sokat.

Korábban ezt írtad:
"Mi ezt úgy oldjuk meg, hogy a felső tervezési szintek architektúra modellben vannak, amit egy metamodell definiál."
Most meg:
"A metamodell nem a tervezési fázisban készül, hanem hamarabb: az módszertani alap.
A technológiai architektúra terv dolga..."

Most akkor, hogyan is van pontosan? (mindkét megoldásnak van értelme)

"kóder arra van motiválva, hogy minél több tesztesetet készítsen: lefedjen minden működést."

Ha jól értem a darabszámra fizetsz. Ezzel szerintem pont ellene hat a célnak, mert lehet lefedi az összes esetet, de könnyen lehet, hogy szaporodik a tesztesetek száma, de lehet sokkal kevesebbel is meg lehetne csinálni. Ez persze nem törvényszerű, de egyáltalán nem biztos, hogy ideális lesz a tesztek eredményének eloszlása, valamint nem biztosítja, hogy lefedik minden működést.

Uncle Bob idézésében abban tévedsz, hogy a programozás mérnöki tudomány. A mérnöki tudományok nyelve a matematika. Tehát a programozás nyelve a matematik. Ez egyéblént a funkcionális programozás kapcsán szivárog vissza.

Technikailag a metamodell és a modell egyben van. Van egy metamodellünk, és a tervezést úgy kezdjük, hogy azt elővesszük, majd mellérajzoljuk a modellt.
A lényeg az, hogy a metamodell már megvan, amikor egy adott szoftver tervezését elkezdjük, mert az a módszertani alap.

A kóder nem tud végtelen mennyiségű tesztesetet előállítani, mert akkor redundánsak lesznek a tesztek. Van olyan szabályunk, hogy csak indokolt tesztesetek lehetnek.

Uncle Bob arról a különbségről beszél, hogy a matematikai módszer egzakt: ha valamit bebizonyítasz, akkor 100%ig bizonyos lehetsz benne, hogy az úgy van. A tudományos módszer viszont arra alapul, hogy a kísérletek valamilyen szinten valószínűsítik, hogy egy tudományos hipotézis megállja a helyét. Teljes bizonyosságot a teljes domainre elérni nem tudsz, de tudsz elegendően biztos lenni a dolgodban. Ebből a szempontból a "mérnöki tudomány" kifejezés oximoron: a tudománynál az van, amit az előbb mondtam, a mérnökök viszont úgy használják a tudományos eredményeket, mintha 100%-osan biztos matematikai tételek lennének, és a mérnökségnek semmi köze a hipotézisek validálásához.

Szerintem a dokumentáció szükségessége nem kérdés, más kérdés, hogy kifizeti-e a megrendelő, hogy megkapja.
De mivel annyira szerteágazó a fejlesztésnek nevezett folyamat, hogy egységesíteni, azon túl, hogy minden szerepeljen benne.
Teljesen más egy dokumentáció ha annyi matek van benne, hogy megzavarodsz, vagy mondjuk egy webes applikáció fejlesztése.
Az, hogy mit tartalmazzon a dokumentáció sem lehet egységeset mondani, csak kb olyan szinten, mint, hogy annó az ált. isk-ben megtanultuk, hogy a dolgozatban van bevezetés, tárgyalás, befejezés. (itt nyilvány: tervezés, struktúra...stb.)
De, hogy milyen módszerrel legyen valami már nem feltétlenül. Pl van olyan projekt, ahol érdemes Petri hálót tolni, mert könnyen meg tudod mutatni, hogy nincs mondjuk holtpont az algoritmusodban, de a szokásos példámnál, valami egyszerűbb webes appnál csak szivatás lenne, ha ilyen elő lenne írva, mert értelme kb 0 lenne (csak azért nem 0 mert akkor legalább a tervező gyakorol).

A dokuemntációt szoftverfejlesztő írja vagy olyan aki régen az volt, azaz az ára ugyanannyi mint a fejlesztésnek (aka. nem egy 200e nettós doksi manager). Így a terv elkészítésének 5m Ft-os ára (de akár 500e Ft is), "felesleges", inkább haladjon a projekt. "Majd közben kitaláljuk" jeligére.

Szerintem ezt így nem lehet kijelenteni. Nagyon projektje válogatja. Az n+1. hasonszőrű alkalmazásnál valóban kevesebb a létjogosultsága, igazából pár jó komment elég lehet. Az is lehet, hogy van valami nagyobb project ahol akár PhD-s is írja a doksi egy részét, de ugyanakkor lehetnek az implementációs dokumentációnál olyan részek amit símán odaadhatsz egy 200e-s juniornak, mert sokat tanul belőle és a melót megcsinálja. A nagy kérdés, hogy jól találták-e el a dolgot. Ha valami újszerű csilivili matek megvalósító résznél van pár komment, akkor az nyilván nem jó, viszont pl egy buborékos rendezést nem kell kommentelni, mert mindenkinek a könyökén jön ki.

A szoftvernél a terv maga a termék. Csak az a terv tekinthető késznek, ami automatikusan végrehajtható, nem kell már hozzá emberi gondolkodás. Az pedig már maga a forráskód.

Azért nem lehet szabványosítani, mert a programozó nem gép által is elvégezhető munkát végez. Neki kell a terv részleteit befejeznie.

A tesztlefedettségre, komplexitásra, policysértésre, stb biztonságkritikus rendszerek esetén már vannak szabványok. A probléma csak az, hogy önmagukban nem hozzák el a megváltást. És drága is teljes mértékben megfelelni nekik. Ezért IMHO felesleges egyszerűbb projektek esetén erőltetni ezeket.

Szerintem a fejlesztés egy szint után művészet :).

Szerintem meg az állításodból akár törölhető is lenne az "egy szint után" kitétel.

A fejlesztés művészet. Az emberi tulajdonságok egy többé-kevésbé körülhatárolható kombinációja szükséges ahhoz, hogy valaki jól csinálja, vagy akár csak kedve legyen hozzá.

Az más kérdés, hogy az egyszerűbb dolgok szakmunkaként is végezhetők. Talán erre gondolhatott itt a költő, amikor a "szakma" kifejezést használta.

---
Science for fun...

Amit ma programozásnak nevezünk, az 3-4 teljesen különböző szakma elemeinek ad hoc összekutyulása.
Ettől van az, hogy sok, egymásnak ellentmondó emberi tulajdonság szükséges hozzá. Ami miatt szuperhősök kellenek hozzá, hogy kicsit is jól csinálják.
Mint a művészetnél általában.

"Ami miatt szuperhősök kellenek hozzá,"

Erről jut eszembe. Beszélgetés egy barátommal:

Ő: -- Nemrég sikerült pár nagyon jó embert felvennem.
Én: -- Szomorúan hallom ezt, mert ezek szerint szükséged van rá, hogy jók legyenek.

A barátommal rengeteget beszélgetünk szervezetfejlesztésről. Teóriám szerint minél inkább különleges emberekre van szükséged, annál szarabb az egész szervezettséged a cégnél (operatív munkákról beszélek). BTW teóriám létezik a gyakorlatban is: pl nálunk.

Igazán felsorolhatnál néhány "egymásnak ellentmondó" emberi tulajdonságot, ami a programozáshoz kell.

Elképzelhető, hogy a homályos megfogalmazások miatt teljesen félreértek (vagy félregondolok) valamit, de nekem az az érzésem, hogy ti elkezdtétek feltalálni a melegvizet.

A programozáshoz okos, értelmes emberek kellenek. Élettani kutatások bizonyítják, hogy ez a típusú intelligencia az egyik olyan tulajdonság, amiben az emberiség a legnagyobb variabilitást mutatja.

Ha jól értem a másoknak adott hozzászólásaidat, ti "rájöttetek", hogy bizonyos szabályok betartásával ez a variabilitás kiküszöbölhető a szoftverfejlesztés rendszeréből.

Meglepődés lesz ebből! :-)

---
Science for fun...

Kreativitás vs. monotonitástűrés
Dolgok átlátása vs. precizitás a részletekben

A szorosan vett kódolásban az egyetlen valamennyi intelligenciát kívánó rész az, hogy egy metódushoz képes legyél megadni egy olyan input-output halmazt(*) ami reprezentál egy kijelentő mondatot az adott metódussal kapcsolatban. Ez kb. ekvivalens az értő olvasás képességével. Értem én, hogy ha valaki ma szétnéz az FB-n, akkor az értő olvasás is szuperképességnek tűnik, de azért lássuk be, hogy nem az.
A trükk éppen az, hogy minden mást (architektúra, üzleti és technikai domain tudás), ami hagyományosan a programozás művészetének része, más kell tudjon, és mindenki csak egyet ezekből.
Meglepődés biztos, hogy lesz (és persze az ördög a részletekben van), csak az a kérdés, hogy ki fog meglepődni.

*: output alatt értve az exceptionöket is.

"Kreativitás vs. monotonitástűrés
Dolgok átlátása vs. precizitás a részletekben"

Ezekben a párokban számomra semmiféle ellentmondás nem látszik.

Bennem például mind a négy tulajdonság megvan.

Nem keresek állást, de ha jól értem, nálatok egyértelműen a "túlképzett" kategóriába esnék. :-)

---
Science for fun...

Szerintem az építőipart picit túlmisztifikálja. Van egy kivételező mérnök barátom, akinél látom, hogy építés közben kell újratervezni a csomópontokat, mert volt amit engedett a gép a valóság meg nem vagy leginkább a valóságban van egy sokkal egyszerűbb és olcsóbb megoldás, kb ez a folyamat (csomópont újratervezés) termeli a profitot. Szóval, ha így nézzük az építőmérnök is kertész.

Vagy 20 éve én is szerettem volna csinálni egy programozói kamarát. Mint az orvosok építészek bírók. Elmondtam lelkesen pár operatornak (VMS), pár DBA -nak ( Oracle) és pár programozonak (Cobol / Fortran).

A VMS -es azt mondta, minek. VMS az Isten.
A DBA azt mondta SQL szabvány, Oracle az Isten.
A programozók azt mondták a specifikáció és a tesztelés mondja meg van-e esélyed jól megírni. Mert ha egyik sincs, hiába a kamara.

És akkor Delphi, Java stackel, JS még nem is volt, éreztem korai.

Most meg már késő. :-)

A "kamara" dolog azért trükkös, mert az a legfelső control loop az egészen. Amíg nincs meg a többi, addig értelmetlen összehozni, ha pedig megvan, akkor késő.
A megoldás nálunk az, hogy más struktúrákat használunk újra, amelyek fenntartására az első lépéstől van motiváció.
Szerintem az egész ügy komplexitására tök jellemző, hogy a kb 400 daily standupunk közül kb hármon volt szó ennek az ügynek különböző aspektusairól, mindannyiszor annyira különböző irányból, hogy lehet, fel sem ismernéd. A legutolsó az volt, amikor mellesleg, érdekességként megemlítettem a megoldást. Amit persze követett a megoldásról szóló könyvre mutató link megosztása, mert volt a csapatban, aki a nevét sem hallotta.

A futószalag tök jó eszköz, ha sok ugyanolyan dolgot akarunk előállítani.

Általában akkor van ez, amikor újra fel akarják találni a dolgokat. Jó, mondjuk itt bejön például a GPL, és az, hogy egy cég nem fertőzheti meg a kódbázisát vele, akkor nincs mit tenni.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

https://en.wikipedia.org/wiki/No_Silver_Bullet Ez azért még mindig tartja magát valahogy, pedig nem mai darab. Plusz olyan gyorsan változik minden, hogy nem lesz egyszerű olyan szabályokat alkotni, amik 5 évet túlélnek (szerintem). Na jó a Joel teszt a mai napig rendben van, viszont nem is garantál semmit. Ezek is érdekesek lehetnek még: Why Software Projects need Heroes Beyond Agile: the Studio Model
Egy összefoglalót mindenképp írjatok! :)

"""
there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity.
"""

A kulcsszó a "no single development" lehet. A teljes szoftverfejlesztési folyamatot néztük át, és az üzleti analízistől a kódoláson át a reviewig mindenben kellett változtatni ezt-azt. Pedig naivan úgy kezdődött, hogy csak a kódoláshoz nyúlunk.

"és az üzleti analízistől a kódoláson át a reviewig mindenben kellett változtatni ezt-azt"

Már megbocsáss de nem lehet, hogy ennek az az oka, hogy minden szoftver kicsit másra való? :-)

Szóval mi is volt itt tulajdonképpen az a nagy "aha!" élmény, ami arra indított benneteket, hogy megosszátok a közzel a felismeréseteket?

---
Science for fun...

Egy előző életemben volt olyan, hogy kollégákat kerestünk, de nem voltak.
Ez volt az egyik motiváció: kicsit beteg dolog, hogy gyakorlatilag csak olyan embereket érdemes alkalmazni, akik ismernek 4-5 technológiát, ás képesek átlátni rendkívül bonyolult rendszereket emiatt annyit kell nekik fizetni, mint egy kisebb cégnél a CEO-nak, és így is több hónap, mire képesek értelmes munkát végezni (vagy kiderül, hogy mégis alkalmatlanok).
Ezért úgy alakítottuk ki a rendszert, hogy a kódoláshoz sokkal kevesebb tudás kell, mint ami ma egy programozónak van. Az egyetlen probléma az, hogy teljesen másmilyen. Nem kell domain- vagy architektúra tudás, a nyelvnek is elég az alapjait ismerni. De kell TDD, Clean Code, plusz van egy pár oldalas doksink arról, hogy milyen elemek vannak, hol találhatóak, hogyan nevezzük őket, és hogyan néznek ki. Mindez hozzávetőlegesen 150 órányi tanulást igényel nulláról, ami nem túl sok. A gond az, hogy a tananyag nincs még kész hozzá, és pont ezek a dolgok azok, amiket csak a legjobb programozók tudnak, miközben nekünk a dolog validálásához pont azok kellenének, akiknek minden más kihívást jelent, de ezek csak egy kicsit. A tananyag fejlesztésébe meg akkor tennénk bele az erőforrást, ha levalidáltuk, hogy működik a dolog.
Szóval nem kollégákat keresünk, hanem olyan embereket, akik egy-két pár órás munka erejéig képesek hülyének tettetni magukat, és értelmes visszajelzést adni arról, hogy hol kell csiszolnunk a rendszert.
Persze, biztosan kellenek még kollégák hosszabb távon, de jelenleg nem tervezünk felvételt, és kódert kb. soha nem fogunk felvenni. A terv ugyanis az, hogy a kóderek önállóak lesznek: akkor vesznek le munkát, amikor akarnak, annyit, amennyit akarnak, és amint átment a kód a review-n, azonnal fizetünk. És azok valszeg nem ti lesztek, mert akinek megvan a tudása hozzá, annak már van olyan munkája, amit nem fog ezért otthagyni.

Szerintem mindannyian a kreatív rész miatt szeretünk programozni. A szalagmunka pedig nem az.
Viszont most nem tudjuk, pontosan hogyan fog kinézni ez a szalagmunka. Ennek a kitalálása pedig szerintem érdekes.
Naponta 500 csavart meghúzni a szalag mellett unalmas, de ha csak kettőt kell, az egy érdekes kaland.

Ebben igazad van, ez a része nagyon tetszik amit csináltok. Felismertétek, hogy rengeteg probléma van a fejlesztés körül, mind management oldalról, mind munkaerő oldalról. Én csupán azt nem látom, hogy az az út amit választottatok az jó, vagy sem. Ezért is megyek bele kicsit provokatívabban a kérdésbe. Az, hogy formalizálni akarod a folyamatot az nagyon izgalmas, de szerintem nem ez a probléma gyökere, hanem a tervezésben lévő problémák. Szerintem ha azt raknánk rendbe, sokmindent megoldana. Természetesen akkor az egész utánna való folyamatra hatással lenne, szóval ott is sokat kell változtatni. De hangsúlyozom, marha nagy respect, hogy foglalkoztok ezzel a témával.

Én is csak szubjektíven vagyok biztos benne, hogy jó úton járunk, ezért akarom validálni.
A tervezésben lévő problémákkal is foglalkozunk; a kóderség újradefiniálásához nincs szükség metamodell alapú modellezésre meg automatikus modellvalidációra.
Az egy másik dolog, hogy a tervezési folyamattal kapcsolatos alapokat már a 80-as években lerakták (TCSEC és CC), csak azóta is mindenki magasról nem használja.

OK, azt hiszem, most értettem meg.

Ti egy olyan fejlesztési módszert akartok kitalálni, ami a lehető legteljesebb mértékben kettéválasztja a szoftverfejlesztésben a gondolkodást és a megvalósítást.

A tényleges kódsorokat begépelő fejlesztő nálatok soha semmiféle átttekintéssel nem fog rendelkezni a projekt egészéről vagy akár értelméről, csak azt a kis szegmenst látja, amit éppen csinál, de érteni igazából azt se érti.

Mint összeszerelő munkás a gépsor mellett: behajtja a csavart, de ha nem árulják el neki, mi az a munkadarab, akkor nem tudja kitalálni, hogy fúrógép vagy műhold.

Érdekes ötlet...

Emlékeztet arra, amikor a felsőoktatásban bevezették a minőségbiztosítást. :-)

És persze azzal kapcsolatban is vannak erős sejtéseim, hogy hol fog ez az egész megrogyni, de ne legyen igazam.

---
Science for fun...

Én részleteiben nem értek egyett azzal amit kitaláltak, mert szerintem rengeteg buktatója van és lényegében nem új. Viszont az, hogy ezzel közösségben foglalkoznak az szerintem nagyon jó dolog. Kb ez az érv random opensource projektnél elő szokott jönni, hogy minek. Szerintem nagyon sokat fognak tanulni belőle és összeségében hozni fog, még akkor is ha ez a konkrét elképzelés mégsem annyira jó.
Nekem egyébként pont az jön le, hogy láttak sok bukott projektet és van igényük arra, hogy ezen változtassanak, nem pedig ülnek a langyos híg ...-ban és várják a sültgalambot, mondván mindenki így csinálja. Abból tuti nem lesz innováció. Ebből lehet, még akkor is ha szerintem ez a konkrét ötlet nem az.

A saját tapasztalatom az, hogy az ilyen régies túlszervezett projektek mindig elbuktak vagy hatalmas erőforrásigényük volt.
Ezzel szemben agilis módszerekkel tipikusan ötöd/tized akkora költségvetéssel csináltuk meg a dolgokat sokkal jobbra.
A gond akkor szokott lenni, amikor egy projekt vezetői valamiért nem tartják elég szorosan az agilis alapelveket.
Tipikusan multiknál látom ezt, ahol valahogy "eljátszák" hogy pl. scrumot alkalmaznak. De igazából csak értelmetlen rituálék szintjén.

Ezzel maximálisan egyetértek. A Scrum egy olyan keretrendszer ahol megpróbálták (és szerintem egész jól sikerült) megtalálni azt a szükséges minimumot ami a felhasználó által vágyott és működőképes végtermék előállításához kell. Eddigi tapasztalatom szerint a korrekten kivitelezett waterfall ennél eggyel rosszabb: a felhasználó azt kapja amit leírt, nem azt amire igazából vágyik.

És persze ott van a bármilyen módszer leple alatt elkövetett káosz, ellógás, összehazudozás. Az ellen nem véd semmi.

--
Gábriel Ákos

Igazából szerintem ott buknak el ezek a túlszervezési, túltervezési próbálkozások, hogy leveszik a felelősséget a programozó válláról. Robotként kódolja le a dolgot, anélkül, hogy visszajelezne, ha valami nem stimmel. Nem is tudna, mert nem is látja át a dolgot. Még az autógyártásban is felismerték ezt évtizedekkel ezelőtt. Lásd: Toyota Kata

Sok modern probléma esetén ha azt akarod, hogy mindent értsen a kóder, akkor nagyon magasan képzet ember kell. Viszont sok olyan része van egy projektnek, ahol nem kell érteni. Az viszont igaz, hogy nagyon nagy ciki tud lenni, nincs olyan rész, amit a fejlesztő ért. Szerintem meg kell találni egy egészséges egyensúlyt.

Szerintem egyetértünk, egyensúly kell. Kellenek tervek, tudnunk kell, hogy mi a cél, merre megyünk. De a túl sok szabály, túltervezés, túlszervezés eredménye tapasztalatom szerint vagy biztos bukás vagy iszonyatos költség- és időigény.
És sokkal olcsóbb egy jó kóder, mint 3 rossz.

Jó ez az autógyártásos példa, de jelenleg a szoftverfejlesztés kicsit olyan, mintha az autóiparban a mérnökök szerelnék össze az alkatrészeket és az autót.
Mivel a szoftver nem anyagi természetű, így nem teljesen összehasonlítható, de rohadt nagy erőforrásigénye van annak, hogy a favágó munkát is mérnökökkel csináltatjuk.

A build-et nem a mérnökök készítik, hanem a számítógép. Így a build naponta több százszor is elkészülhet. A mérnökök viszont ~jól tudnak automatizálni dolgokat, így ez annyira nem is rossz (szerintem). A favágó munka egy részére is vannak kód/boilerplate generátorok, template metaprogramming, frameworkok, stb... Persze biztos lehet ezt jobban is, mint ma, majd kiderül :)

Inkább ez a felfogás kerül át az autógyártásba (illetve minden gyártásba), már ott is egyre inkább számítógépek+robotok csinálják a buildet.

Szerintem, ha már futószalag az analógia, akkor a szoftver esetében maga a szoftver a futószalag és a felhasználó analóg a szalagmunkással és/vagy a termék vásárlójával.
Szóval egy szoftvercég igazából futószalagokat tervez és kivitelez. Persze a futószalagokat is lehet futószalagon gyártani (lásd: licencértékesítés, mint pl. Microsoft).

Jó ez az autógyártásos példa, de jelenleg a szoftverfejlesztés kicsit olyan, mintha az autóiparban a mérnökök szerelnék össze az alkatrészeket és az autót.

Pontosan.
A rendes futószalagos megoldás, ahol a robotoknak nagyon alap munkájuk van és nem nagyon kell érteni semmihez, az sem jobb, mert ki szeretne hosszú távon ilyen munkát végezni?
Én abban hiszek, hogy nagyon egyszerű dolog legyen a fejlesztés, átlátható, érthető, könnyen módosítható, de mégis érdekes.
Erre leginkább a lego a legjobb hasonlat.

Szerintem tobb okbol is meg fog bukni:
- Ugy 10-15 eve volt mar ilyen ugy hivtak model driven development. Nagy hype volt korulotte sok nagy ceg rengeteg energiat fektetett bele megsem lett jo es sikeres.
- Nem erre halad a vilag. A szoftverfejlesztes sokat fejlodott. Amire 10-15 eve 15-20 ember kellett azt ma megcsinalja 5-10 jo szakember fele ido alatt jobb minosegben. A frameworkok lefedik a szoftverfejlesztes technikai reszet, es keves kodolast igenyelnek. De magasan kepzett szakembereket kivannak, aki ertik a frameworkok mukodeset es ossze tudjak integralni a kulonbozo serviceket.
- A Software as a Service modell mindent megvaltoztatott. Az egy felhasznalora vetitett koltseg drasztikusan lecsokkent. Szerintem el fog tunni az egyedi software fejlesztes, vagy csak specialis teruleteken marad meg. Altalaban szolgaltatasokat fogunk irni vagy/es integralni meglevo szolgaltatasokat. Regebben minden alkalmazasnak sajat authentikacios modulja volt, ma mar par sok configuracio es integralodik egy meglevo AD-hoz.
- A celcsoport ki lesz aki hasznalja ezt a dolgot. Ezek a sajat fejlesztesu magikus cuccok halalra vannak itelve. Ha valami nagyon egyedi, akkor a nagy ceges architectek nem biznak benne es nem engedik be az infrastrukturaba(es igazuk is van). Akkor kinek lehet eladni ez a dolgot, kis Kft-nek akinek mindegy csak olcso legyen, abbol nem lehet megelni. Ha standard dolgokra epul, akkor meg lehet annyi munka van verziok karbantartasaval hogy kell a sok jo szakember aki karbantartja.
Nem akarom elvenni a kedveteket tole, de ez egy vakvagany. A softwarefejlesztes draga dolog, ahogy autot gyartani is draga. De mindketto gyartasa egyre hatekonyabb. Es egyre tobb ember engedheti meg maganak hogy vegyen vagy hasznaljon(car sharing) egy autot.

Azért én felvetnék pár szempontot, ami árnyalhatja a véleményed.
Security szempontbon mennyire jó, ha olyan helyen vannak a céges adataid amit nem te kontrolálsz?

Majdnem igazad van, mindenre is van framework, de a 21 században arra is gondolni kell, hogy miként nyered ki az adataidból az információt. Nem csak a sebességre gondolok, az sem elhanyagolható szempont, hanem arra is, hogy minnél több információd legyen, lehetőleg olyan is ami a versenytársaknak nincs, és ezek minősége sem utolsó szempont.

Nah ezek a szempontok meg inkább az egyedi software felé billentik a mérleg nyelvét.

Security szempontbol nem attol fugg hogy van-e controlod vagy nincs, hanem hogy milyen security mernokok dolgoznak nalad es milyenek a service providernel. Mibol gondolod, hogy te jobban meg tudod ezt oldani mint akinek sokkal tobb penze, eroforrasa van ra.
Az hogy milyen adatot hogyan dolgozol fel, nincs osszefuggesben azzal hogy hol tarolod. Sot a felhos rendszerben konnyebben elered, migralod, feldolgozod az adataidat. Mit er ha nalad vannak az adataid, de 2 ev mire bevezetsz egy datawarehouse megoldast, es a vegen derul ki hogy a felet sem tudja mint amit kene. Lehet hogy a felhos szolgaltatasok nem 100% fedik le a te igenyeidet, de olcson, kis kockazattal, gyorsan nyujtanak megoldast. Es ez kell az uzletnek, nem valamikor majd elkeszulo ursiklo ami majd elvisz a holdra. Ezert jott letre az Agilis softwarefejlesztes.

Márha 100%-ban megbízol a felhő szolgáltatódban, akkor igaz, ha elhiszed, hogy mivel sokak ezek közül, az információból élnek leginkább, de becs szó, hogy nem néznek bele az adataidba és nem elemzik. Ha ez megvan, akkor tényleg jobb felhőbe rakni.

A második résznél arra akartam utalni, hogy vannak esetek amikor nem jó a konzerv megoldás. Az, hogy ezt public felhőbe, saját helyen tárolod az mindegy. A software ami elemzi az adatokat és információt szolgáltat, annak a lényegi része nem lehet konzerv. Persze sok sallang lehet az, és akkor lehet koncentrálni a lényegi kérdésere. Azt, hogy ezt milyen módszertan szerint fejleszted az meg megint egy másik kérdés. Véleményem szerint a feladatra éppen a legalkalmasabbat kell választani, mint ahogy programozási nyelvet is.

De legalább előtte megnézted az erkölcsi bizonyítványát; felírtad a kedves nevét, címét, adatait; magyar rendőrség, bíróság jó esetben meg tudja találni...

Míg egy ilyen felhőszolgáltató egy szép napon azt mondhatja, hogy sajnos a kumulusz elfogyott, így jártál, panaszoddal fordulj a fal felé.

A felhőszolgáltatóval SLA-s szerződésed van, aminek ugyanúgy érvényt szerezhetsz az igazságszolgáltatásban, mint a lelépő rendszergazda ellen. Pontosan ugyanez van, csak éppen egy felhőszolgáltató képes is majd tízmilliókat fizetni, ha hibázott, és megítéli neki a bíróság, míg a rendszergazda vagyona az okozott kárt nem fogja fedezni.

A helyzet az, hogy teljes biztonság nincs. Ez persze ma már egy nagyon nagy közhely. Nem csak a külső támadásoktól kell véden a rendszert, hanem sok helyen a rendszergazdáktól is védik, pl osztott jelszó...stb. A lényeg, hogy minimalizáljuk amenyire lehetséges az adatvesztést, vagy adatszivárgást, mert abba mint ahogy helyesen mondtad símán tönkremehet a cég. Ha a saját datastorehouse-od leég, de sikerült elmigrálni az adatokat, az kellemetlen költség, de valószínű túléli a cég. Ha elvesznek az adatok, azt majdnem biztos, hogy nem. Persze a story nagyon sok összetevős sok topicot tele lehetne vele írni.

Ne keverjük a "nem lett belőle semmi" és az "épp túl van a through of disillusion-on" állapotokat.
A Low Code megoldások szerinted mik, ha nem a model-driven development alkalmazásai?
A Black Belt Judo rendszere pl.

A model-driven developmentnél az van, hogy a modellel szemben nagyon erős constraintek vannak, ráadásul ezek a constraintek lépcsőzetesen, a tervezési fázis előrehaladtával jönnek be.
A szokásos architektúratervezők ezt nem nagyon tudják kezelni, mert annak ellenére, hogy vannak szép frameworkok, az architektúra, mint szakma sem tart még ott, hogy teljesen látsszanak a szakma szabályai. Nem kis mértékben azért, mert ezek egy része a programozást szolgálja ki, aminek pedig mint tudjuk alig-alig ismerjük a szabályait.

A nem lett belole semmi az hogy "rendes" szoftware-t nem ebben irnak. A "Low code" megoldasok arra jok hogy Bela a sajat Kft-jenek es a kozepiskolas Petike megcsinaljak benne egy ket egyszeru programot. Megvan a letjogosultsaga es hasznalati terulete, mint anno az Access-nek, gyorsan ossze lehet vele dobni feluleteket meg alkalmazasnak latszo dolgokat. Nincs ezzel baj csak ez nem az egyedi softwarefejlesztes jovoje.

Szerintem a sofwarefejleztesnek megvannak a szabalyai. Aki komolyan foglalkozik vele az tudja is. A csunya rossz kodot mindenki felismeri, ez ellenkozoje mar nehezebb, megmondani egy kodrol hogy jo-e? Mas kell egy atomeromu vezerlesenek es mas egy 2 hetig tarto marketing kampanyt kiszolgalo kodnak vagy egy prototipusnak. Es a ketto kozott nagyon szeles a sprektrum bejonnek az uzleti es penzugy szempontok is. Hiszen ne feledjetek el, csak abbol lehet fizetni a fejlesztest ami profitot hoz a software.

Nem az a mondás, hogy más lesz az eredménye, hanem az, hogy tök más folyamat mentén kell csinálni.
De ez a folyamat a szoftvereknek legalább egy nagyon nagy részére ugyanaz.
Az "aha!" élmény pedig az, hogy a szoftverfejlesztés ahogy ma űzik, nem működik: drágán és lassan rossz minőséget prdukál, mi pedig azt gondoljuk, hogy rájöttünk, hogyan lehet egyszerre gyorsabb, jobb és olcsóbb. Igen, mind a három egyszerre.

Node ha ab ovo igénytelenség és hajszolás van fent, akkor a fejlesztői szinten hiába ügyesek, meg szeretnék betartani a metódust (hogy stílszerű legyek...), akkor ez hogy fog menni? Én tökre őrülnék, hogy ha a körültekintő tervezés, meg szép kivitelezés meglenne mindenhol, de jellemzően nem szánnak rá pénzt, oldmegésműködjön mentalitás van sajnos. Rögtön hozzáteszem, hogy van egy két üdítő kivétel, de fehér holló szintűek sajnos.

A szakmaiság egyik fontos eleme az, hogy nemet kell mondani azokra a dolgokra, amik szakmailag nem vállalhatóak.
Fentebb a dokumentációval kapcsolatban vázoltam a minőségbiztosítás egyik szeletét. Gyakorlatilag az van, hogy minden tervezési/kivitelezési szintre van egy formális done definition (tehát nem a tartalomra, hanem a formára vonatkozó), amit (a review kivételével) automatikusan ellenőrzünk, a mai szokásokhz képest eléggé szigorúan, és addig nincs kész valami, amíg annak meg nem felel.
A business analysis eredményét pedig a megrendelő signoffolja, tehát legrosszabb esetben az történhet, hogy kap egy olyan szoftvert, ami nagyon magas minőségben pontosan azt a hülyeséget csinálja, mint amit ő megrendelt.
Ez a koncepció, most épp azt próbáljuk ellenőrizni, hogy ez hol leakel.

Szakmát csinálni a fejlesztésből nagyjából egyenlő a fejlesztés robotizációjával. Lesz erre igény, de lesz igény a művészi szintre is, amit SOHA nem fogsz tudni szabályokkal keretek közé szorítani.

> Sol omnibus lucet.

Bedobjak még 2 ötletet? :D

- nincs az IT szakmának "kamarája" (kötelező tagdíjjal pl. :) )
- nincs szakszervezet...
- és nincs még szakma etikai kódexe sem

Hoppá, 3 lett belőle... Na ki unatkozik nagyon?

Nem akarlak elkeseríteni, de a szoftverfejlesztést előbb fogja átvenni egy AI.

Az AI-nak a legnagyobb esélye arra van, hogy a megírt teszteset alapján elkészítse a produkciós kódot: ez a legegyszerűbb lépése a folyamatnak, és elég sokat tudunk a dolog algoritmusáról.
Számítok rá, hogy ez 5-10 éves távlatban megvalósul.
A feladat többi része viszont olyan, hogy az az AI, amelyik képes rá, nem azzal fog szarozni, hogy embereknek szoftvereket írjon.

Szerintem nem teljesen vagy tisztában mi is az AI. Sokkal inkább egy szakértői rendszer, ami adott feladatra van kihegyezve, ennek a hangolása és a paraméterei viszont olyan bonyolúlt, hogy embernek nehéz átlátnia. Különböző algoritmusok készítenek egy modellt adott feladatra. Tehát ha csinálunk egy AI-t a mai fogalmaink szerint, ami alapvető programozási problémákat valósítanak meg, annak lövése sem lesz arról, mi az, hogy foglaljon a usernek asztalt a vacsorához, és fordítva.

Természetesen ez változhat, de ott még nagyon nem tartunk.

Van fogalmam róla, mi az az AI. Nem lepne meg, ha kiderülne, hogy én már akkor tanultam róla, amikor te ovis voltál. Az én állításom az, hogy a teszteset és afölötti tervezési szinteken az értelmes megoldás elkészítéséhez nem domain specifikus, hanem általános intelligencia kell, aminek része pl. a természetes nyelv megértése.
A tesztesetből kód készítése az, amihez nem kell általános intelligencia, ezért mondtam, hogy szerintem az meglesz pár éven belül.

A probléma ezzel az, hogyan tanítod be. Milyen minőségű a kód, amiből tanul, van-e benne rejtett hiba. Van-e rejtett hiba a generált kódban és ha ez később jön fel, akkor mennyire javítható a kód. Arra milyen AI-t csinálsz, vagy mennyire olvasható, hogy ember tudja javítani. Mennyire tudod letesztelni az AI-t, hogyan mutatod meg, hogy mennyire jó, megbízható az a kód amit generál. Rengeteg sok kérdés van, és egyáltalán nem ez van az AI fókuszában.

Félre ne értsél, szerintem is fogja segíteni AI a fejlesztést, de nem hiszem, hogy ez lesz az első terület és nem is biztos, hogy az AI lesz benne a legnagyobb poén.

A sw fejlesztés nem szakma, hanem egy termelési folyamat, ami sokféle szakmát fog egybe. Van viszont még sok cég, tapasztalatom szerint külföldön is, ahol strukturálatlan ez a folyamat, és a középkori céhek módjára generalista csodapistikék csinálnak mindent is. Nem ezt az állapotot kell tanulmányozni, inkább az érdekes, hogyan lehet belőle a következő szintre továbblépni, és kialakítani a munkamegosztást. Akkor megjelennek a szerepkörök, és egyből láthatóak lesznek a szükséges - és a formális (felső)oktatásban is megismerhető - szakmák.

Ez hulyeseg. Rengeteg szakteruletnek vannak szabvanyai... autopiar, repuloipar, stb...

A szoftverfejlesztés nem szakma: nincsenek olyan általánosan elfogadott szabályai, amik betartása esetén valószinűleg nem fogod elrontani.

Sajnos nincsenek általánosan elfogadott szabályai, pedig nagyjából egyetlen szabály betartásával lehetne könnyen érthető, könnyen karbantartható, könnyen módosítható, magas színvonalú programokat készíteni.
Sajnos azt az egy szabályt nem hogy nem tartják be, hanem minden eszközzel ellene mennek.
A probléma abból fakad, hogy bár a legtöbb fejlesztő ismeri ezt az egy szabályt, de nem tudja, hogy ez mennyire fontos szabály és nem alkalmazza szinte soha sem, vagy csak nagy ritkán.

Ez az egy szabály: a KISS (Keep It Stupid Simple), de jobban leírja az Occam borotvája.
Lefordítva: ha egy feladatra van két (vagy több) jó megoldásunk, akkor mindig az egyszerűbbet válasszuk.

Pár példa:


konkrét	                  < absztrakt
nem polimorfikus függvény < polimorfikus függvény
kompozíció                < öröklés
külön adat és függvény    < egységbe zárás
totális függvény          < parciális függvény
determinisztikus függvémy < nem determinisztikus függvémy
pure függvény             < impure függvény
immutable változó	  < mutable változó
lineáris kód végrehajtás  < vezérlési szerkezetek

Már a legkisebb egységeknél elkezdjük a bonyolítást, majd kezdjük nem átlátni, ezért bevezetünk a bonyolultság kezelése miatt újabb és újabb technikákat (pl. Design Patterns, DI, DIc), amikkel még tovább bonyolítjuk a dolgokat.

Egyetlen dologban nem értek egyet: hogy ez lenne az egyetlen szabálya a szakmának.
Amúgy tényleg így van: nagyon sok dologról már többen azt mondják, hogy azok a szakma szabályai. A probléma az, hogy ebben nincs egyetértés, az meg pláne hiányzik, hogy be is tartsuk őket.
És sajnos ebből az is következik, hogy vannak olyan szabályok, amiket azért nem lehet még felismerni, mert a felismerésükhöz szükséges lenne a már meglévő szabályok betartása.
Nekünk van ilyenből egy oldalnyi.

Meg kell nézni más szabályokat és a legtöbbről kiderül, hogy ennek a szabálynak vagy a vetülete vagy éppen az ellenkezője.
Úgy is mondhatom, hogy a fenti szabállyal lehet validálni a többi szabályt. Ezért is gondolom a fenti szabályt a legfőbbnek.

Pl.
1. Hacsak lehet kompozíciót válassz az öröklődés helyett. Validálja.
2. Dependency inversion principle. Invalidálja.

Az első példa nem azt jelenti, hogy rossz az öröklődés, csak azt, hogy ha ugyanolyan jó a kompozíció és az öröklődés, akkor inkább a kompozíciót válasszuk (mert az az egyszerűbb). Ritka esetekben jó lehet az öröklődés is.

A második példánál a fenti szabály nem azt mondja, hogy minden esetben rossz a DI principle, csak azt, hogy általában rossz.

"High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces)."
Ha ugyanolyan jó az adott feladatra, hogy a felsőbb szintű modul függ az alsóbbtól, mint ha nem, akkor az az egyszerűbb. Ha az adott feladatnál cél, hogy a felsőbb szintű modul, az alsóbb szintű modul több megvalósításától is függjön egyszerre, akkor kell a Dependency Inversion-t választani.
Manapság ennek pontosan az ellenkezője történik. Szinte minden egyes osztályunk absztrakciótól függ (interface), holott sohase lesz abból több megvalósítás.

" általánosan elfogadott szabályai, amik betartása esetén valószinűleg nem fogod elrontani."
Melyik az a "szakma", ahol a szabályok maradéktalan betartása elég a termék használhatóságához?

Itt azért van egy hatalmas különbség: a lábméret a feladat erejéig fixnek tekinthető és viszonylag jól definiáltan lemérhető. Ezzel szemben a felhasználói igény nemcsak, hogy időben változik, de ráadásul sok esetben ő maga sem tudja (és maga sem tudja, hogy nem tudja), vagy erőteljes ellentmondások vannak benne (ami lehet annál bonyolultabb, minthogy valaki azt mondja, hogy fehér, más pedig azt, hogy fekete).

Nekem nincsenek nagy szoftverfejlesztési projekt tapasztalataim, de ami van, abból a specifikálást érzem az első számú nehéz diónak. És ha azt vesszük, hogy ez mindennek az alapja, valahol itt kell elkezdeni. Szép elv a KISS, sokszor igaz is (de nem mindig), de addig el is kell jutni.
A specifikálás olyan, amihez önmagában több "szakma" szükséges lehet. Ez pedig oda vezet, hogy nehéz fix "protokoll"-t kidolgozni a fejlesztésre, mert vannak projektek, ahol ilyen szintű komplexitást soha nem fognak megfizetni (és nem is lenne feltétlenül indokolt - lásd KISS, ami nemcsak a szűken vett fejlesztésre lehet igaz, hanem a projekt irányítására is). Ha pedig igény szerint differenciálódik a szakmai metodika, akkor valószínűleg túlságosan sok eljárás jöhet képbe és oka fogyottá válik az egész.

De tegyük fel, hogy van egy feladat meghatározás, ami alapján el lehet kezdeni dolgozni. Vannak projektek, amik komoly tervezést igényelnek, vannak, amik nem. Némelyek sok szoftveres szakágat igényelnek, vannak, amelyek nem.
Egy épület kivitelezése is hasonló: vannak mini projektek, amiket a kőműves megcsinál "fejből" (vagy sikerül, vagy nem), vannak lakóházak és vannak nagyobb monstrumok (amelyek szintén vagy sikerülnek vagy nem - a siker mércéje nem az, hogy összedől vagy sem, hanem mennyire használható). Kérdés, hogy ezzel az analógiával mire lehet jutni? Én azt látom, hogy a gyártási technológiák (például beton mennyi ideig köt) és az alkalmazás technológiák (adott tetőablakot miként kell beépíteni) a fixek, azon kívül azért elég sok a variáció. Mind a tervezés szintjében, mind a kivitelezés módjában.

szerk: a lábról sablon is készíthető. ami hatalmas előny lehet egy extrább cipő esetén.

Én nagyjából így látom a sarokpontokat:

Vannak az inputok és vannak az outputok. Ezek közt logikai(oksági) ÉS időbeli kapcsolat van.

Van/lehet egy interaktív interface, ami ezt a két alapvető relációt paraméterezheti, illetve az időbeli kapcsolatot aszinkron folyamatoknál terhelheti egy valószínűségi változó.

... és ott legbelül a kombinatorikus káosz vigyorog.

A változó feltételrendszert most ne is vonjuk be, csak egy jól definiált feladatról beszélek.

> Sol omnibus lucet.

Azért érzitek magatokat felhatalmazottnak, hogy kezdeményezzetek szakmát e tárgykörben mert megvan a megfelelő képesítésetek ehhez? Vagy csak, mert egy hiányt akartok pótolni, és amúgy is tök jó ötlet ötletelni a sör fölött?
Egyébként ennek az első lépése a (szak)szervezeti tömörülés. Azt csináljátok meg inkább!
Ez az ötlet most ott tart, ahol tartania kellene miután egy (érdek)szövetség létrejött, és deklarálni akarják a jogi és szakmai szabványi hátteret. A kutya nem fog komolyan venni semmi alulról jövő kezdeményezést, ami nem erős tagsági háttérrel rendelkező, a jogszabályi keretek között működő szakmai szervezet.

Nem érezzük magunkat felhatalmazottnak: a felhatalmazás olyan dolog, amit csak másoktól lehet megkapni.
Úgy érezzük, hogy gondolkodtunk eleget a dolgon ahhoz, hogy legyenek olyan sejtéseink, amikben mi biztosak vagyunk.
A szakszervezet/kamara pedig olyan dolog, ami csak úgy tud működni, ha a tagjai működtetik. Miközben nem tud létrejönni amíg nem működik, mert akkor senki nem kapcsolódik hozzá.

Hm... Nem tudom megvan-e az agilis módszertan eredete?
Kb (kicsontozva):
- Sör +ötletelés
- Tovább gondolkodás, tökéletesítés
- Csapból is kifolyás
Semmi szervezet, jogyszabály és hasonlók.

Itt is ilyesmi kezdeményezést érzek és szerintem nem is rossz az irány.
Hogy végül jogyszabály lesz (hivatalos szakma) vagy nem az sok dologtól is függ még.
Mindenesetre autó és közlekedés is előbb volt (sokkal), mint kresz és hivatalos gk vezető szakma....

Ha jól értem, sikerült újrafeltalálni a modell alapú fejlesztést.

A szoftverfejlesztés nemcsakhogy szakma, de még példaképül is szolgálhat más szakmáknak, pl. egy építészmérnök miért ne mondhatná, hogy ő ugyan nem ért a kőhöz, fához, betonhoz és téglához, viszont jól ismeri a divatos szalmaház-orientált-építkezést. Egyékbént meg úgy hallotta, a lépcsőket betiltotta egy tekintélyes mester, járjon mindenki liften.

LOL A lépcsőépítés keresztülhugyozza a jól megtervezett ipari standardokat: ki kell lyukasztani a födémet, problémákat okoz a statikában is, ami miatt a teljes falazatot újra kell számolni. Azt a usert, aki ilyet kér el kell küldeni a picsába, mert még a végén azt is ki fogja találni, hogy a lakásban akar szarni is!!!

'edesek' az ilyen naiv otletek...de kellemesen lehet az idot tolteni vele, mar ha raertek persze.
(csak szolok: esetleg mire kidolgozzatok, mar teljesen uj ipari kornyezet lesz ami szepen tullep az 'altalanosan' elfogadott szabalyaitokon)

"Elkezdtünk hát azon gondolkodni, hogyan nézne ki a fejlesztés, ha szakma lenne."

Én is csatlakoznék, hogy csináljunk szakmát a szoftverfejlesztésből, a százalékomról majd privátban megegyezünk... :-)

Pár gyors ötlet, a többit később:

Legyen az, hogy kitalálunk valami komplex, elméleti, bürokratikus szabályrendszert, vizsgakövetelményeket, amiket meg kell csinálni, hogy valaki
szoftverfejlesztő lehessen (QBASIC programozás, DOS alapismeretek, Oracle DB ismeretek és amiért a támogató cégek sokat fizetnek, hogy benne legyen). Kell olyan rész mindenképpen, amit be kell magolni, de semmilyen gyakorlati haszna sincs, hogy ne lehessen csak úgy levizsgázni, ha tudsz programozni. Természetesen csak az általunk vagy a partnereink által vizsgáztatott szakember tekinthető szoftverfejlesztőnek, az összes többi: kókler. Jelentőst pénzt kérünk a vizsgáért, ami nekünk jön be, egy keveset kap a vizsgáztató partner cég. Íratunk képzési anyagokat, lesznek könyvek, munkafüzetek, amik szükségesek, hogy le lehessen vizsgázni és oktatni lehessen. Pár évente meg kell újítani a vizsgát, így lesz folyamatos bevétel. Közben lobbival meggyőzzük az államot és a nagy multi cégeket, hogy csak valódi szoftverfejlesztőket alkalmazzon, akiknek megvan ez a papírja, így mindenkit rákényszerítünk erre. Lesz digitális nyilvántartás a cégek felé, ahol lehet ellenőrizni a vizsga valódiságát. Ennek az üzemeltetése jó sokba fog kerülni. Alapítunk szoftverfejlesztői kamarát, lesz kötelező tagsági díj a tagoknak. Kap mindenki tagsági kártyát, amivel lehet pár partner cég webshopjában pár százalékkal olcsóbb szoftvereket venni. Cégként lehet bronz, ezüst, arany, platina szinten támogatni a szoftverfejlesztői kamarát, óriási összegekért. Tartunk konferenciákat a szakmáról, a partner termékeket bemutatva. Írunk etikai kódexet, milliónyi szabályrendszert, mindezt honlapon, vizsga és egyéb termékeket webáruházba kirakva. Dől a lé, és már végre van hivatalos szoftver fejlesztő az országban, mindenki nyert, ugye?

Sakk-matt,
KaTT :)

"A szoftverfejlesztés nem szakma: nincsenek olyan általánosan elfogadott szabályai, amik betartása esetén valószinűleg nem fogod elrontani."

Ha egy kicsit is értenétek hozzá akkor nem írnátok le ekkora baromságot.
Fejlesztettetek már valaha egyáltalán valódi igények alapján, megrendelőnek ???
--- törölve ---

Lesz valami előadás, vitaindító? Ki(k) fognak előadni?

1. Tényleg jó sok időtök van.
2. Nagyobb applikációkhoz is nyúltatok már hozzá így? Mondjuk olyanokhoz amiket '72-ben kezdtek el, folyamatosan követik vele az üzleti elvárásokat és folyamatosan változott alatta a technológia?
3. Mit szól a megrendelő amikor metamodellhez hasonló varázsszavakat beszélsz, neki meg áll az appja és óránként 3-4 milió euró a kiesés?
4. Nekem ez olyan tankönyvszagú ami tele van olyan definiciókkal amivel meg lehet fogni a beosztottat vagy az ügyfelet