Archief - Avondschool programmeren gebrek aan analyse

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Piecemaker

Legacy Member
Kben dus bijna afgestudeerd in avondschool programmeren, en blijkbaar heeft avondschool schandalig weinig analyse in de lesrooster zitten: in 1 semester van het 2e jaar 1 vak analyse met vooral algemene zaken en een beetje UML. Als ik dan naar de meeste dagscholen kijk, is het analysepakket veel groter: ze hebben bijvoorbeeld een project dat ze met behulp van een goede analyse moeten uitwerken, waar de nadruk dan wel licht op de analyse en minder op het project zelf.

Zijn er scholen (avondonderwijs) waar je zo'n bijkomende cursus kan volgen???

Moto

Legacy Member
Tja ge kunt ook denken: waarom iets leren dat ge in de praktijk toch niet vaak tegenkomt :p

Bubbling Zombie

Legacy Member
Obliv` zei:
Wij genereren er code op

Yeah, dat hebben ze hier in't begin ook bij ons gedaan. Jammergenoeg niet door competente mensen ... dus ik ben al de hele tijd dingen in de stijl van

Code:
public List<Stuff> AllStuff{
  get {
      if (_allstuff == null) {
          _allstuff = new List<Stuff>();
          _allstuff.AddRange(OtherStuff);
          _allstuff.AddRange(StillOtherStuff);
      }
      return _allstuff;
  }
}

aan het oplossen. TOF ZE. Dan heb ik liever dat ze 't ff manueel schrijven en fucking nadenken terwijl ze da doen. DE-GOU-TANT. Oja, en programming to interfaces is geen schande.

GRAAAAH

Curahee Q

Legacy Member
Zijn UML's ook ni interessant wanneer ge met een groot project zit? Dan kan nen andere programmeur toch direct zien wa er allemaal inzit en wa mé wa verbonden is?

Wacko Santa

Legacy Member
Ik denk ook wel dat bij grotere projecten de analyse redelijk noodzakelijk kan zijn. Ook als je rekening wil houden met verschillende principes in het programmeren. Ik kan best begrijpen dat vele programmeurs UML mar niets vinden en er liever direct tegenaan willen vliegen, maar volgens mij is de kracht van UML zeker niet te onderschatten.

Jerre Muesli

Legacy Member
Zeker! En als de analyse ECHT goed gedaan is mag je als programmeur bij wijze van spreken als een kip zonder kop staan programmeren wat er beschreven staat in het klasse diagram. Maar ja, wanneer is er ooit tijd genoeg om een echt goede analyse te maken hè :D

Bubbling Zombie

Legacy Member
x4xk3 zei:
Zeker! En als de analyse ECHT goed gedaan is mag je als programmeur bij wijze van spreken als een kip zonder kop staan programmeren wat er beschreven staat in het klasse diagram. Maar ja, wanneer is er ooit tijd genoeg om een echt goede analyse te maken hè :D

vooral niet om het aan te passen na change requests.

- CooKie -

Legacy Member
Ik volg ook avondschool programmeren ( vb.net ) maar gelukkig zit in nu in't tweede jaar toegepaste informatica .. waar we dus al analyse gekregen hebben.

't is idd handig als ge grote projecten hebt als degelijke personen de analyse doen.

Mijn ervaring verteld mij da avondschool pak trager is dan hoger onderwijs mja. :)

Oldskooler

Legacy Member
Analyse is (spijtig genoeg) overrated.

Op school zag je steeds ingewikkelde schema's en vreemde formules.

ALs je gaat werken, krijg je een onozel word-documentje toegestuurd, vol met onsamenhangende brol dat nog geen 5% beschrijft van wat het moet worden.

Mss dat het op andere bedrijven anders is, maar bij ons trekt het op geen ballen.
Bij mij komt het er steeds op neer, dat ik afga op een afbeelding (die eveneens op geen ballen trekt), en me een weg doorheen een gigantisch doolhof baan, door zelf alles voor de helft uit te zoeken.

Of vaak is het gewoon mondeling, zitten ze daar een hele uitleg te doen over veel te complexe materie, zitten ze zichzelf constant te verbeteren, twijfelen ze zelf aan alles...
en jij moet maar beginnen.

Naar de structuur van de databank wordt nooit verwezen, ah ja, geen kat die nog weet hoe die in elkaar zit, alles bij elkaar zo'n 200 tabellen, zoek het zelf als programmeur maar uit...

Of hoe uiteindelijk alles toch weer veranderd moet worden, nog geen enkel scherm in onze applicatie is onveranderd gebleven, omdat men telkens van gedacht verandert, of omdat ze eindelijk eens onderzocht hebben, hoe het wel moest.

Vorige week was nog het strafste van al, 2 dagen met iets bezig geweest, ik stel een vraag, hij ging dat eens bekijken...komt hij tot de conclusie dat dat niet nodig is, en totaal anders moet.....

Obliv`

Legacy Member
@Oldskooler

Dan zijn ze op dat bedrijf toch wel behoorlijk fout bezig hoor. Zo'n toestanden heb ik nog nooit meegemaakt. Als het nu een kleiner bedrijf is waar er enkel een business analyst en geen technical analyst is het wel logisch dat er nie naar een database model verwezen wordt.

Als de functional requirements ook al op geen bal trekken is het natuurlijk wel de verantwoordelijkheid van de programmeur om op het tafel te slaan en om duidelijkheid te vragen hé?

Bubbling Zombie

Legacy Member
Obliv` zei:
@Oldskooler

Dan zijn ze op dat bedrijf toch wel behoorlijk fout bezig hoor. Zo'n toestanden heb ik nog nooit meegemaakt. Als het nu een kleiner bedrijf is waar er enkel een business analyst en geen technical analyst is het wel logisch dat er nie naar een database model verwezen wordt.

Als de functional requirements ook al op geen bal trekken is het natuurlijk wel de verantwoordelijkheid van de programmeur om op het tafel te slaan en om duidelijkheid te vragen hé?

Als ik het mij goed herinner werk jij in een IT bedrijf? Als je in een bedrijf werkt waar IT maar een ondersteunende functie heeft is da allemaal minder vanzelfsprekend. Oldskooler: I feel your pain, is ook zo bij ons hoor :)

Ice

Legacy Member
Oldskooler heeft mooi de werking van een interne IT dienst beschreven se :)
Werk nu ook bij een IT bedrijf en je merkt het verschil wel duidelijk.

Obliv`

Legacy Member
@Bubbling Zombie: ja ik werk in een IT bedrijf. Ik heb doorvoor nog wel ergens anders gewerkt waar IT een ondersteunende functie had. Maar het gebrek aan professionaliteit en know how op verschillende vlakken heeft me dat bedrijf doen verlaten.

Ik was in de veronderstelling dat Oldskooler het had over analyses bij een IT bedrijf. De analyses gemaakt door analisten van een bedrijf waar de IT afdeling ondersteunend is, zijn inderdaad meestal niet veel soeps :).

Massis

Legacy Member
Oldskooler zei:
Analyse is (spijtig genoeg) overrated.

Op school zag je steeds ingewikkelde schema's en vreemde formules.

ALs je gaat werken, krijg je een onozel word-documentje toegestuurd, vol met onsamenhangende brol dat nog geen 5% beschrijft van wat het moet worden.

Mss dat het op andere bedrijven anders is, maar bij ons trekt het op geen ballen.
Bij mij komt het er steeds op neer, dat ik afga op een afbeelding (die eveneens op geen ballen trekt), en me een weg doorheen een gigantisch doolhof baan, door zelf alles voor de helft uit te zoeken.

Of vaak is het gewoon mondeling, zitten ze daar een hele uitleg te doen over veel te complexe materie, zitten ze zichzelf constant te verbeteren, twijfelen ze zelf aan alles...
en jij moet maar beginnen.

Naar de structuur van de databank wordt nooit verwezen, ah ja, geen kat die nog weet hoe die in elkaar zit, alles bij elkaar zo'n 200 tabellen, zoek het zelf als programmeur maar uit...

Of hoe uiteindelijk alles toch weer veranderd moet worden, nog geen enkel scherm in onze applicatie is onveranderd gebleven, omdat men telkens van gedacht verandert, of omdat ze eindelijk eens onderzocht hebben, hoe het wel moest.

Vorige week was nog het strafste van al, 2 dagen met iets bezig geweest, ik stel een vraag, hij ging dat eens bekijken...komt hij tot de conclusie dat dat niet nodig is, en totaal anders moet.....

Ik zit nu bij ne klant op een behoorlijk groot project (in het hoofdschema zitten 1200+ tabellen), 't merendeel van de mensen weet wel hoe alles aan elkaar hangt, maar aangezien ik consultant ben, is het voor mij ook behoorlijk onoverzichtelijk.

Gelukkig zijn er wel de nodige analysebestanden en ERD schema's om mij wat te helpen. Bovendien worden sommige change requests ZO goed geanalyseerd dat zelfs omschreven wordt welke code fout is en door wat ze moet vervangen worden, zo erg dat ik zelfs soms gewoon ctrl+c ctrl+v kan doen van de analyse...

ma ik heb het ook al wel een paar keer voorgehad dat ik met iets bezig ben dat dan niemeer blijkt gebruikt te worden. Nu komt dat pas aan het licht als er iemand naar de code gaat kijken, want de wijzigingen zijn dingen die de klant vraagt.
Als da voorkomt laat ik da gewoon weten aan de projectleider en die bespreekt het met de klant, en dan weet ik de dag erop of ik eraan moet verder werken of niet...

wat ik minder tof vind is op basis van nederlandstalige user manuals & screenshots, engelstalige technical designs maken van bestaande schermen (die slecht/niet gedocumenteerd waren en dat nu wel moeten zijn)

dibo

Legacy Member
Bleh, analyses waarbij de developer zelf niet meer moet nadenken zijn belachelijk. :p
Dan kan die analyst het beter zelf meteen in de code aanpassen.

Massis

Legacy Member
dibo zei:
Bleh, analyses waarbij de developer zelf niet meer moet nadenken zijn belachelijk. :p
Dan kan die analyst het beter zelf meteen in de code aanpassen.

jah over't algemeen is da vrij lame, ma als ge een stukske code voorgeschoteld krijgt (PL/SQL) dat vol van de afkortingen staat, vindt ge da nie zo erg :p

iey, itn, acn, aln, iss, ... en nog een paar duizend van die :p Oracle standard = alles zijn 3-letter afkortingen
eer da ge uitgezocht hebt welke afkorting naar welke tabel verwijst zijde al een héél stuk verder...
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan