[Alg] Ingewerkt worden, maar de code is een puinhoop

[beany]

Ik ben sinds 1 oktober in dienst gekomen bij mijn nieuwe werkgever. De bedoeling is dat ik applicaties voor hun ga maken. Ik ben de 1e programmeur binnen dat bedrijf, ze zijn inmiddels wel begonnen om een 2 tal collega's van mij om te scholen zodat ik strakkies hulp krijg. Opzich erg leuk allemaal, ook erg uitdagend! En ik zie dat ook helemaal zitten...

Echter...

Het bedrijf heeft al een aantal applicaties draaien, die door een extern bedrijf zijn gemaakt. Het zijn er in totaal een stuk of 50. Elke applicatie opzich is niet heel erg groot, meestal maar een handje vol schermen, en soms nog minder dan dat(1 of 2 schermen). Een klein aantal is wat groter(tot een max van 10 schermen). De applicaties opzich zijn niet erg bijzonder ingewikkeld. Het zijn redelijk eenvoudige dingen die moeten gebeuren(magazijn retouren registreren etc).

De bedoeling is dat ik in C# nieuwe applicaties zou gaan bouwen, maar dat ik eerst ingewerkt zou worden door het externe bedrijf wat de huidige applicaties heeft gemaakt zodat ik de C++ applicaties kan onderhouden en uitbreiden. Geen probleem, ben geen super ster in C++ maar kan me wel aardig redden. So far, so good...

Nu ben ik afgelopen dinsdag bij dat externe bedrijf begonnen(klein bedrijf, totaal 4 man). Ik heb in veel projecten gekeken wat er gaande was, en hoe ze dingen deden. En ik heb nogal wat dingen geconstateerd:

• Er zijn GEEN functionele en technische ontwerpen aanwezig. De man bij het externe bedrijf vindt FO's en TO's niet nodig namelijk
• De code is praktisch niet gedocumenteerd. Hier en daar een verdwaalde comment. Verder is het goed de code lezen om te begrijpen wat er eigenlijk gebeurt
• Er is geen datamodel aanwezig, en er staat nergens welke tabellen bij welk project horen. Idem voor de stored procedures. En het is me nogal een waslijst aan tabellen en stored procedures(dik over de 200 sowieso)
• In de code wordt gebruik gemaakt van globale variabelen. Dit om bijvoorbeeld record id's door te geven naar een nieuw scherm( ).
• Als error detectie en afhandeling word gebruik gemaakt van if(bOK) constructies wat leidt tot enorme IF constructies. Er is in geen enkel project een try/catch te vinden. Meldingen naar gebruikers dat er iets mis is gegaan... mja, sporadisch
• In 95% van alle projecten wordt er een connectie naar de database gelegd. Deze code om dit te doen is bij elk project toegevoegd! Exact dezelfde code die 50x aanwezig is! Leuk als er een bug in zit of er een uitbreiding op die code moet komen.
• Sommige functies zijn wel 800 regels lang. Van alles en nog wat is onder elkaar gekwakt. Bepaalde generieke dingen(zoals het updaten van het programma) staat gewoon in de OnInitdialog. Ja de code, niet een aanroep naar een functie. Die code is ook in meerdere projecten aanwezig. Er is daar dus copy/paste gedaan.
• Er is geen enkele scheiding tussen de gui en de business logic. Alles word direct in de event handlers afgehandeld(database acties e.d.).
• Er wordt gebruik gemaakt van temp tabellen om data op te slaan. Transacties zijn volgens hun gevaarlijk en onhandelbaar. Die temp tabellen worden overigens direct vanuit een event aangemaakt.

Goed, er zijn nog wel wat punten, maar dit zijn toch wel de belangrijkste die ik tot nu toe heb gezien. Waarom dit topic? Nou, ik weet eigenlijk niet wat ik er mee moet. De eigenaar van dat externe bedrijf reageert geirriteerd als ik voorzichtig een vraag stel waarom iets op een bepaalde manier is gedaan. Ik krijg bijna altijd als antwoord 'dit is zoals wij dit hier doen, en jij hebt je daar maar aan te houden. Zo niet, dan denk ik dat ik je baas ga bellen om te mededelen dat ik met jou niet kan samenwerken'.

Ik heb mijn manager voorzichtig laten weten dat er een aantal dingen niet goed zitten, en daar wil hij volgende week over praten. Ze hangen nogal aan dat externe bedrijf, en ze geloven hem blind in alles wat hij zegt.

Dus mijn vragen zijn dit: de dingen die ik heb geconstateerd, zijn dat echt dingen die niet kunnen(ik wil het gewoon van anderen horen, ter bevestiging) en hoe kan ik dit het beste aanpakken(politiek gezien). En ik ben geen super held in C++, kunnen bepaalde dingen die ik heb genoemd niet anders in C++(kan het me niet voorstellen, maar wie weet)?

[Zoijar]

beany schreef op zaterdag 08 oktober 2005 @ 13:32:
Dus mijn vragen zijn dit: de dingen die ik heb geconstateerd, zijn dat echt dingen die niet kunnen(ik wil het gewoon van anderen horen, ter bevestiging)

Klinkt niet als kwaliteit software in ieder geval. Sommige dingen als functioneel ontwerp ed. zou ik niet te zwaar aan tillen; zeker niet voor relatief hele kleine applicaties. Maar dingen als commentaar, documentatie, 800-regel functies, vreemde globale vars, etc. is niet echt netjes. Of het "niet kan" moet je bedrijf maar beoordelen. Misschien werkt het al jaren lang super goed en snel; dan ga je het niet helemaal omgooien. Duur en fout gevoelig.

en hoe kan ik dit het beste aanpakken(politiek gezien). En ik ben geen super held in C++, kunnen bepaalde dingen die ik heb genoemd niet anders in C++(kan het me niet voorstellen, maar wie weet)?

Natuurlijk kan het veel netter. Politiek gezien, als je er net komt werken en niet zoveel ervaring hebt etc kan je misschien beter je mond houden Even met je eigen baas overleggen idd, dat externe bedrijf zal niets willen weten van "een programmeurtje dat net bij hen komt kijken". Uit je bezwaar en laat het daarbij. Hopelijk wordt er naar geluisterd. Als je echter een gerenomeerd C++ consultant bent met 15+ jaar ervaring kan je zeggen dat je zo niet werkt: zij eruit of jij. Maar ik haal uit je verhaal niet dat dat het geval is.

Het zal je verbazen hoeveel bedrijven dit soort code gebruiken... Hoeveel rommel er op de markt is. Dat komt door onbegrip van opdracht gevers, die willen niet een duur ontwerp en robuste code...ze hebben het liever goedkoop. Werkt toch ook prima? Komt ook nog voort uit die hele IT hype van een paar jaar geleden. Iedereen was ineens programmeur. Nu merken de bedrijven die lekker goedkope programmeurs hebben ingehuurd dat minder meer is...

[beany]

als je er net komt werken en niet zoveel ervaring hebt etc kan je misschien beter je mond houden

Niet heel veel ervaring in C++, wel heel veel ervaring in C#, Delphi, VB6, PHP, ASP en Perl. Het is dus niet zo dat ik een beginnende programmeur ben. Mijn vele ervaring is ook de reden dat ze me hebben aangenomen.

[whoami]

Tja, ik zou zeggen: probeer je best te doen in die applicaties die je moet onderhouden. Het is niet leuk zo'n dingen (ik spreek uit ervaring; ik heb ook eens in een projectteam gewerkt waar er vrijwel geen commentaar was in de code, waar er geen transacties gebruikt werden, waar er geen foreign key constraints tussen tabellen zaten, ed).
Als je eens een aanpassing moet doen, of een fix moet doen in die applicaties, dan kan je het quick'n dirty doen, of, als je wat meer tijd hebt, kan je hier en daar eens iets refactoren.

Zorg er iig voor dat de nieuwe applicaties die jij moet ontwikkelen heel wat beter zijn qua kwaliteit.

Verwijderd schreef op zaterdag 08 oktober 2005 @ 14:12:
[...]

Heb je ook een fatsoenlijke IT opleiding?

Dat doet er nu toch niet toe ?

[ Voor 14% gewijzigd door whoami op 08-10-2005 14:16 ]

[NMe]

Verwijderd schreef op zaterdag 08 oktober 2005 @ 14:12:
Wat betreft de code... als je toch from scratch mag beginnen zou ik niet te veel aan de C++ code zitten rommelen, probeer er achter te komen wat een klein beetje de bedoeling is, door middel van zelf een eigen ontwerp te maken. Als dat klaar is, is de C# code schrijven nagenoeg een eitje...

Het leuke is dat als je een klein beetje weet wat de bedoeling is en hoe het door je voorganger is opgelost, je dan nog niet genoeg weet. Een beetje inwerken in het bedrijf is altijd handig, zodat je feel krijgt voor hoe bepaalde dingen gedaan moeten worden. Bovendien: wanneer bekende valkuilen gedocumenteerd zijn, dan ga je zelf niet diezelfde fout maken. Het ontbreken van fatsoenlijke documentatie is dus funest voor elk project, zeker als een nieuw persoon hier ineens verantwoordelijk voor is. Ik zit momenteel in ongeveer dezelfde situatie, en ik kan je vertellen dat het niet lollig is.

[H!GHGuY]

zoals enWee zegt:

- maak voor jezelf een duidelijke analyse over hoe hun programma's in elkaar zitten: databanktoegang daar (zus en zo), dit daar, dat daar.
- filter daaruit de herbruikbare dingen
- herbouw hun applicaties in een mum van tijd op een goeie, onderhoudbare manier.
(eventueel kun je 1 groot programma maken die alle functionaliteit van hun programma's overneemt)

[beany]

Zoijar schreef op zaterdag 08 oktober 2005 @ 13:56:
Klinkt niet als kwaliteit software in ieder geval. Sommige dingen als functioneel ontwerp ed. zou ik niet te zwaar aan tillen; zeker niet voor relatief hele kleine applicaties.

FO's en TO's zijn wel degelijk van belang... ook al zijn het kleine applicaties, het zijn er wel 50! En die rommelen allemaal in de database, en doen allemaal een stukje afhandeling van bedrijfs processen. Als het 1 klein projectje zou zijn, dan is het nog wel te overzien. In dit geval is er totaal geen overzicht.

whoami schreef op zaterdag 08 oktober 2005 @ 14:15:

Als je eens een aanpassing moet doen, of een fix moet doen in die applicaties, dan kan je het quick'n dirty doen, of, als je wat meer tijd hebt, kan je hier en daar eens iets refactoren.

Zorg er iig voor dat de nieuwe applicaties die jij moet ontwikkelen heel wat beter zijn qua kwaliteit.

Dat was ik ook van plan. Maar die man van dat externe bedrijf wil dus dat ik een nieuw project ga maken als inwerk opdracht. En dan precies zoals zij het daar doen Niets is zo erg als code MOETEN kloppen die totaal nergens op lijkt. Hij wil dus dat ik me compleet aan hem aanpas, ga werken zoals hij werkt.

[webfreakz.nl]

Het klinkt misschien stom maar kan je niet die code herprogrammeren in je vrije-tijd (of is die bij jou ook al schaars ) ? En als het dan af is aan het bedrijf waar je voor werkt laten zien dat het beter/hetzelfde werkt en aan dat 'externe' bedrijf laten zien dat dit efficiënter is?

Just my 2 cents....

[Verwijderd]

HIGHGuY schreef op zaterdag 08 oktober 2005 @ 14:21:
[...](eventueel kun je 1 groot programma maken die alle functionaliteit van hun programma's overneemt)

Ik zou - bijv. voor de db connectie en vele andere snipplets - een library bakken welke bij elke applicatie zou moeten werken

[H!GHGuY]

Verwijderd schreef op zaterdag 08 oktober 2005 @ 14:27:
[...]


Ik zou - bijv. voor de db connectie en vele andere snipplets - een library bakken welke bij elke applicatie zou moeten werken

dat is ook wat ik bedoelde. Ik maak nu ook een programma met een library aan basisfuncties waarin ik dan eender welke form kan laden, en die dan gebruik laten maken van mn library

[whoami]

beany schreef op zaterdag 08 oktober 2005 @ 14:26:
[...]


Dat was ik ook van plan. Maar die man van dat externe bedrijf wil dus dat ik een nieuw project ga maken als inwerk opdracht. En dan precies zoals zij het daar doen Niets is zo erg als code MOETEN kloppen die totaal nergens op lijkt. Hij wil dus dat ik me compleet aan hem aanpas, ga werken zoals hij werkt.

Da's natuurlijk wel minder... Je kan natuurlijk ff dat ene project op hun manier doen, en daarna doe je toch alles jouw manier.
Of, je wacht ff af wat het overleg met jouw manager teweeg brengt.

[beany]

off-topic: Ik heb geen IT opleiding. Maar ik heb wel 10 jaar ervaring als programmeur(betaald, daarvoor heb ik hobby matig flink wat jaren zitten programmeren)...

webfreakz.nl schreef op zaterdag 08 oktober 2005 @ 14:26:
Het klinkt misschien stom maar kan je niet die code herprogrammeren in je vrije-tijd (of is die bij jou ook al schaars ) ? En als het dan af is aan het bedrijf waar je voor werkt laten zien dat het beter/hetzelfde werkt en aan dat 'externe' bedrijf laten zien dat dit efficiënter is?

Just my 2 cents....

Mijn tijd is ook schaars ja

Maar, ik heb daar ook aan zitten denken. Ik weet dat ik binnen een week(na het gewone werk dus, in de avond uurtjes) een middel grote applicatie kan bouwen zoals het dan wel moet(of iig code die leesbaar en onderhoudbaar is). Ik weet alleen niet wat de politieke consequenties daarvan zijn.

[ Voor 4% gewijzigd door beany op 08-10-2005 14:32 ]

[Verwijderd]

Weet je baas eigenlijk iets van code?

[NMe]

Modbreak:

Een aantal berichten is afgesplitst naar [rml][ Alg] Ervaring vs. opleiding[/rml].

[beany]

Verwijderd schreef op zaterdag 08 oktober 2005 @ 14:33:
Weet je baas eigenlijk iets van code?

Nee... helemaal niets... hij weet dat er dingen bestaan zoals C++ en C# maar daar houd het ook bij op.

[Verwijderd]

webfreakz.nl schreef op zaterdag 08 oktober 2005 @ 14:26:
Het klinkt misschien stom maar kan je niet die code herprogrammeren in je vrije-tijd (of is die bij jou ook al schaars ) ? En als het dan af is aan het bedrijf waar je voor werkt laten zien dat het beter/hetzelfde werkt en aan dat 'externe' bedrijf laten zien dat dit efficiënter is?

Ik zou er voor uit kijken zo iets te doen. Niet alleen kost dat veel (vrije) tijd, het levert ook veel ergernis op als men het niet wil accepteren. Bovendien is het verschrikkelijk moeilijk aan te tonen dat het beter is. Tuurlijk kan je laten zien dat het anders is, maar dat is niet hetzelfde. Men ziet vaak vooral de nadelen, en heeft twijfels over de voordelen. Er is niet voor niets het spreekwoord: 'wat de boer niet kent, vreet hij niet'.

De kans is groot dat (zeker bij een nieuw iemand) er nog geen vertrouwensband is opgezet. Als ze iets hebben dat al lange tijd (redelijk) goed werkt, en je komt ineens met een hele vervangings-actie aan, dan zullen ze dat niet willen doen (laat staan durven).

Ik heb ook in een situatie gezeten waar het bedrijf niet echt zicht had op wat er allemaal fout ging, en veel verbeterpunten gesignaleerd. Helaas was de traagheid van het bedrijf (door zijn grote massa waarschijnlijk) zo groot, dat het jaren duurt om iets wezenlijks te veranderen. Uiteindelijk heb ik toen besloten dat ik niet happy zou zijn als ik mezelf aan hun werkwijze aan zou passen, en elders een nieuwe 'uitdaging' gevonden.

Volgens mij is het ook vrij standaard om 'slechte' code te zien. Het is niet verwonderlijk dat bijna iedereen regelmatig klaagt over software. Er is veel, heel veel, slechte software in omloop. Omdat managers vaak hebben gezien dat mensen die het zogenaamd beter weten uiteindelijk ook niets opgelost hebben, durven ze de volgende grote wijziging niet meer aan. Overigens is ook iedere programmeur anders, en zit er veel verschil in werkwijze/coding style. Je ziet zoiets typisch eerst als 'slechter', terwijl het misschien alleen 'anders' is.

Ik zou in ieder geval heel voorzichtig zijn als ze echt niet willen luisteren en je min of meer verplichten om op een 'slechte' manier te werken. Natuurlijk kan ik dat vanuit hier niet beoordelen, ik heb de informatie immers maar van een kant (de jouwe). Ik denk wel dat als er nu al geen speld tussen de deur te krijgen is, de kans dat dat (op korte termijn) verandert erg klein is. Afhankelijk van je mogelijkheden en wat je wilt moet je dan nagaan of je wel op de juiste plaats zit...

Just my 2 cents....

Met de mijne erbij wordt de TS nog eens miljonair. Kan ie meteen zijn baan opzeggen

P.S. Kijk eens naar eXtreme Programming (XP) praktijken. Dingen als continuous refactoring zijn een mooi hulpmiddel om binnen de grenzen van wat mogelijk is een slechte applicatie langzaamaan te verbeteren van binnenuit.

(edit: TS zegt:

Ik weet dat ik binnen een week(na het gewone werk dus, in de avond uurtjes) een middel grote applicatie kan bouwen zoals het dan wel moet

Als je zoiets in een week in de avonduurtjes doet, dan kan het nooit een middelgrote applicatie zijn. (Of reken je relatief in vergelijking met de groep van 50 applicaties die je eerder al noemde?) Bouw je zoiets dan ook met voldoende commentaar, testen, design etc.? Want daar doelde je eerder op dat dat nodig is.)

[ Voor 10% gewijzigd door Verwijderd op 08-10-2005 14:47 ]

[Alarmnummer]

Ik zou in ieder geval niet meteen overal aan beginnen te trekken (met als gevolg dat je het lastig gaat krijgen). Ik zou proberen om alle applicaties in beeld te krijgen en wat het doel ervan is. Op het moment dat je met de c++ applicaties aan de slag moet, zou ik me niet laten verleiden om meteen maar dingen aan te gaan passen (als je niet oppast dan houd het niet meer op). Hoe brak die zooi ook is, het werkt schijnbaar en daar zou ik het dan ook bij laten. Alleen als je veel aan een oude applicatie moet doen, en het is een puinzooi, dan zou ik eerst proberen om wat facades op te zetten tussen de oude en de nieuwe code. Op die manier hou je de ellende nog een beetje onder controle. En verder is het uiteraard handig om documentatie aan te vullen (als je er achter bent gekomen wat iets doet).

Het voordeel is dat je straks ook met c# aan de slag kunt en aangezien daar in het bedrijf nog niets voor is, heb je de kans om dit wel goed op te zetten.

[edit]
Opmerkingen maken over iemand zijn code zullen niet veel mensen je in dank afnemen (zeker niet als je er net bent).

[ Voor 30% gewijzigd door Alarmnummer op 08-10-2005 14:54 ]

[webfreakz.nl]

Aan de ene kant snap ik het verhaal helemaal hoe het precies loopt:

"Oh daar hebbie die nieuwe programmeur weer, die denkt dat ie alles beter weet, dé nerd!"

maar aan de andere kant moet het natuurlijk wel beheersbaar blijven(qua documentatie & classes enz...) . Maar als het natuurlijk zó een kleine applicatie is dan is dat soms ook helemaal geen vereiste (wat een woord ) lijkt me

[beany]

Verwijderd schreef op zaterdag 08 oktober 2005 @ 14:43:
(edit: TS zegt:
[...]
Als je zoiets in een week in de avonduurtjes doet, dan kan het nooit een middelgrote applicatie zijn. (Of reken je relatief in vergelijking met de groep van 50 applicaties die je eerder al noemde?) Bouw je zoiets dan ook met voldoende commentaar, testen, design etc.? Want daar doelde je eerder op dat dat nodig is.)

Middelgroot in relatieve vergelijking met de groep van 50 applicaties ja. En dan reken ik er ook een weekend bij. Inclusief commentaar, testen(incl. unit testing) en een fo en een to. Ofterwel: een middelgrote applicatie daar is een kleine applicatie in de grote mensen wereld

[Alarmnummer]

Verwijderd schreef op zaterdag 08 oktober 2005 @ 14:43:
[...]
Volgens mij is het ook vrij standaard om 'slechte' code te zien. Het is niet verwonderlijk dat bijna iedereen regelmatig klaagt over software. Er is veel, heel veel, slechte software in omloop. Omdat managers vaak hebben gezien dat mensen die het zogenaamd beter weten uiteindelijk ook niets opgelost hebben, durven ze de volgende grote wijziging niet meer aan. Overigens is ook iedere programmeur anders, en zit er veel verschil in werkwijze/coding style. Je ziet zoiets typisch eerst als 'slechter', terwijl het misschien alleen 'anders' is.

Ik denk dat maar een klein percentage van de developers een goed systeem op kunnen zetten. Mijn ervaring (ook bij het bedrijf waar ik nu werk) is dat mensen niet geinteresseerd zijn (dus liever geen literatuur). Als het werkt, dan werkt het en iederen minuut vandaag bespaard is beter dan 2 minuten morgen.

*is lichtelijk geirriteerd door die mentaliteit*

[ Voor 9% gewijzigd door Alarmnummer op 08-10-2005 14:59 ]

[Macros]

Als ik jou was zou ik meteen weer gaan soliciteren! Het heeft geen nut om bij bedrijven te blijven die afschuwelijk stom zijn. Ik zou zeggen dat ze die klote software ergens kunnen steken waar de zon niet schijnt en weg gaan. Geen nut om werk te doen wat niet leuk is, niet leuk kan worden en waar je gedwongen wordt om misdaden te plegen (afschuwlijk slechte software schrijven).

[Verwijderd]

Misschien nog een ideetje voor het inwerken:
Ga zo gedetailleerd mogelijk commentaar aan niet triviale code toevoegen (zo als jij denkt dat het werkt) en laat het controleren door programmeurs die er iets meer van afweten (bijvoorkeur de mensen die er aangewerkt hebben als deze er nog zijn) zo zul je gedwongen worden er achter te komen over het wel en wee en kun je toch feedback krijgen...

[webfreakz.nl]

Alarmnummer schreef op zaterdag 08 oktober 2005 @ 14:58:
[...]

Ik denk dat maar een klein percentage van de developers een goed systeem op kunnen zetten. Mijn ervaring (ook bij het bedrijf waar ik nu werk) is dat mensen niet geinteresseerd zijn (dus liever geen literatuur). Als het werkt, dan werkt het en iederen minuut vandaag bespaard is beter dan 2 minuten morgen.

*is lichtelijk geirriteerd door die mentaliteit*

Ik heb ook liever de mentaliteit:

"doe het goed, of doe het niet"

dus dan maar morgen 1 minuut later klaar

[Zoijar]

Maak trouwens ook niet de fout door te denken dat omdat de code slecht is de programmeurs daar ook dom (moeten) zijn. Dit is vaak niet het geval, ik heb de meest briljante mensen de meest brakke code zien schrijven. Dat even als sidenote.

Verder, je kan het herschrijven, maar verlies niet je oorspronkelijke doel uit ogen: de code beter, begrijpelijker en makkelijker uitbreidbaar maken. Even mezelf als voorbeeld: ik schrijf het lieftst hele elegante, hoog niveau C++ code, door gebruik te maken van technieken als generic programming, iterators, veel templates; kortom een soort STL/boost stijl van programmeren. Als ik dat nu op die code daar zou toepassen, dan zit het er heel dik in dan niemand binnen het bedrijf de code meer begrijpt. Het is dan heel netjes, en goed extendable, alleen kan helaas (? evil grin) niemand dat doen behalve ik zelf. Is de code dan beter geworden? In theoretische zin wel, maar in de praktijk kan niemand er nu meer iets mee, en als ik het bedrijf verlaat zullen ze de code opnieuw moeten maken. Verkijk je dus niet altijd op "de beste" manier, maar zoek de meets praktische middenweg.

[beany]

Alarmnummer schreef op zaterdag 08 oktober 2005 @ 14:58:
[...]

Ik denk dat maar een klein percentage van de developers een goed systeem op kunnen zetten. Mijn ervaring (ook bij het bedrijf waar ik nu werk) is dat mensen niet geinteresseerd zijn (dus liever geen literatuur). Als het werkt, dan werkt het en iederen minuut vandaag bespaard is beter dan 2 minuten morgen.

*is lichtelijk geirriteerd door die mentaliteit*

Klopt... alleen wat ze wel vaak vergeten is dat het korte termijn politiek is. Want op de lange termijn zal het ze tijd(en dus geld) opleveren wanneer projecten op een fatsoenlijke manier worden gedaan. Ik weet dat je een project niet kan doen PRECIES zoals het hoort. Daar is vaak de tijd en het geld niet voor. Echter, probeer wel enigsinds in de buurt te komen. En dat externe bedrijf komt totaal niet in de buurt. Nog een voorbeeldje: ze gebruiken geen classes, alleen die door Visual Studio(ze werken nog met versie 6 overigens) zijn gegenereerd. Andere classes zijn totaal niet te vinden, wat dus geresulteerd heeft in spaghetti code.

[Verwijderd]

Zoijar schreef op zaterdag 08 oktober 2005 @ 15:09:
Als ik dat nu op die code daar zou toepassen, dan zit het er heel dik in dan niemand binnen het bedrijf de code meer begrijpt. Het is dan heel netjes, en goed extendable, alleen kan helaas (? evil grin) niemand dat doen behalve ik zelf. Is de code dan beter geworden?

Dat zegt meer over jouw dan over je code, zorg voor documentatie:
- liefst in de code d.m.v. commentaar aangezien de code niet zo gauw wordt weggegooit.
- Als je vreemde (taal)constructies gebruikt die niet 1,2,3 herkenbaar zijn, zet er dan iig wat keywords neer
- Je zegt dat je code netjes is, maar voor niemand te lezen. Dit is een vette tegenspraak want nette code is voor iedereen leesbaar

[Alarmnummer]

beany schreef op zaterdag 08 oktober 2005 @ 15:23:
[...]
Klopt... alleen wat ze wel vaak vergeten is dat het korte termijn politiek is. Want op de lange termijn zal het ze tijd(en dus geld) opleveren wanneer projecten op een fatsoenlijke manier worden gedaan. Ik weet dat je een project niet kan doen PRECIES zoals het hoort. Daar is vaak de tijd en het geld niet voor. Echter, probeer wel enigsinds in de buurt te komen. En dat externe bedrijf komt totaal niet in de buurt. Nog een voorbeeldje: ze gebruiken geen classes, alleen die door Visual Studio(ze werken nog met versie 6 overigens) zijn gegenereerd. Andere classes zijn totaal niet te vinden, wat dus geresulteerd heeft in spaghetti code.

Dat is idd een dikke puinzooi.

Sinds mijn komst is de structuur van de applicaties (bij het bedrijf waar ik werk) wel zwaar verbeterd doordat we een betere gemeenschappelijke codebase hebben en we een aantal standaard 'architecturen' hebben (afhankelijk van de eisen). Op die manier weet ik dat projecten inhoudelijk niet zo snel een ononderhoudbare puinzooi worden. En veel projecten zet ik ook de 1e lijnen, scripts etc van op. Dus op die manier hou ik het nog een beetje in toom (vooral kleine webapplicaties)

Het is alleen jammer dat van alles in de gemeenschappelijke code base wordt geflikkerd wat gewoon niet goed generiek is gemaakt en waarvan de consequenties op lange termijn enorm naar zijn (oftewel je blijft later steeds met die verkeerde beslissingen van het begin in aanraking komen). En dit fixen is erg complex omdat er zo veel projecten van afhankelijk zijn. Soortement van 'herding cats'. Ben blij dat ik ook een aantal libraries heb lopen waar anderen niet in komen en waarvan ik de kwaliteit ook kan bewaken.

[ Voor 8% gewijzigd door Alarmnummer op 08-10-2005 15:31 ]

[Verwijderd]

beany schreef op zaterdag 08 oktober 2005 @ 14:26:
Dat was ik ook van plan. Maar die man van dat externe bedrijf wil dus dat ik een nieuw project ga maken als inwerk opdracht. En dan precies zoals zij het daar doen Niets is zo erg als code MOETEN kloppen die totaal nergens op lijkt. Hij wil dus dat ik me compleet aan hem aanpas, ga werken zoals hij werkt.

Dat is natuurlijk onzin. Jij bent daar niet aangenomen om ineens volgens een andere methodiek te gaan werken. Als zij hun applicaties volgens een manier hebben laten bouwen en door jou laten onderhouden, prima; maar als jij iets nieuws in elkaar moet zetten is het volslagen onzinnig om jouw normale methodiek te 'downgraden'... Ga in ieder geval niks tegen je zin in doen. Als jij hen niet kan overtuigen van de voordelen van jouw aanpak (waar je natuurlijk wel even de moeite voor moet nemen!) vertel ze dan vriendelijk dat ze de verkeerde programmeur hebben aangenomen voor de job.

[Zoijar]

Verwijderd schreef op zaterdag 08 oktober 2005 @ 15:24:
Dat zegt meer over jouw dan over je code, zorg voor documentatie:
- liefst in de code d.m.v. commentaar aangezien de code niet zo gauw wordt weggegooit.
- Als je vreemde (taal)constructies gebruikt die niet 1,2,3 herkenbaar zijn, zet er dan iig wat keywords neer
- Je zegt dat je code netjes is, maar voor niemand te lezen. Dit is een vette tegenspraak want nette code is voor iedereen leesbaar

Wat is een "vreemde taal constructie"? Voor mij, voor iemand anders? Moet ik standaard code documenteren? Neem bv dit voorbeeld van recht-toe-recht-aan generic programming in C++:

C++:

  template <class VertexListGraph, class Order, class Degree, 
            class Marker, class BucketSorter>
  void 
  smallest_last_ordering(const VertexListGraph& G, Order order, 
                         Degree degree, Marker marker, 
                         BucketSorter& bucket_sorter) {
    typedef typename graph_traits<VertexListGraph> GraphTraits;

    typedef typename GraphTraits::vertex_descriptor Vertex;
    //typedef typename GraphTraits::size_type size_type;
    typedef size_t size_type;

    const size_type num = num_vertices(G);
    
    typename GraphTraits::vertex_iterator v, vend;
    for (tie(v, vend) = vertices(G); v != vend; ++v) {
      put(marker, *v, num);
      put(degree, *v, out_degree(*v, G));
      degree_buckets.push(*v);
    }
... etc

Heel standaard allemaal. Netjes, extendable, doet niets vreemds dat gedocumenteerd moet worden... en toch denk ik dat veel mensen het niet aan kunnen passen. Dat is wat ik bedoel. (dat je hele team dus wel met de nieuwe code moet kunnen werken, en niet alleen jij. Jij kan het wel netter en mooier maken, maar als de andere dit niveau niet hebben en er daarom niets meer mee kunnne, dan gebruiken ze toch niet jouw code en schrijven het zelf opnieuw)

[ Voor 9% gewijzigd door Zoijar op 08-10-2005 17:30 ]

[Verwijderd]

beany schreef op zaterdag 08 oktober 2005 @ 14:26:
Dat was ik ook van plan. Maar die man van dat externe bedrijf wil dus dat ik een nieuw project ga maken als inwerk opdracht. En dan precies zoals zij het daar doen Niets is zo erg als code MOETEN kloppen die totaal nergens op lijkt. Hij wil dus dat ik me compleet aan hem aanpas, ga werken zoals hij werkt.

Serieus; Ik zou me afvragen waar je voor staat...
Beargumenteer je ontevredenheid eerlijk en open aan je manager. Als hij een drol is dan kun je rotten, en dan is het pech, zoek een bedrijf wat kwaliteit op prijs stelt en openstaat voor verbetering;

Wat die kerel van het externe bedrijf betreft:
Ik zou nooit geen opdracht gaan maken zoals het niet moet, laat 'm de t*r*ng krijgen ofzo?
Natuurlijk heb je bij software ontwikkeling altijd meerdere manieren om dingen op te lossen, maar als er geen "best programming practice" of iets wat er in de verte op lijkt te vinden is, dan zou ik me toch gaan afvragen of je hier je energie in wilt stoppen (aan kwijt wilt raken).

Suc6

[farlane]

Verwijderd schreef op zaterdag 08 oktober 2005 @ 15:24:
Dat zegt meer over jouw dan over je code, zorg voor documentatie:

Dan heb jij denk ik niet die code van Zoijar gezien. Als ik die zie dan weet ik dat het zoals hij zelf ook zegt, elegante code is van hoog niveau. Maar in de praktijk heb je daar niets aan. Het moet werken, en het moet zo simpel mogelijk zijn. Als ik een universitaire studie moet gaan volgen om een stuk code te begrijpen die 2 strings aan elkaar plakt dan heeft de maker ervan iets verkeerd gedaan.

Persoonlijk kan ik die elegantie wel op prijs stellen, en ik vnd het ook heel interessant, maar je hebt er niets aan als niemand begrijpt hoe het werkt.

[farlane]

Verwijderd schreef op zaterdag 08 oktober 2005 @ 20:07:
Ik zou nooit geen opdracht gaan maken zoals het niet moet, laat 'm de t*r*ng krijgen ofzo?

Poepoe, wat hebben we een grote mond.
Heb jij uberhaupt praktijk ervaring met dit soort dingen? Als je overal tegenaan gaat staan trappen kom je echt nergens. Dit soort dingen verander je niet in een nacht. ( Wat wil niet zeggen dat je er niets tegen kunt doen. )

Bovendien, als jij kunt kiezen tussen je hypotheek betalen of een huurhuis zoeken wordt de keus ook wat makkelijker.

[ Voor 12% gewijzigd door farlane op 10-10-2005 09:03 ]

[alienfruit]

Ik heb juist vandaag het probleem dat een programmeur bij de klant vind dat ik teveel commentaar heb in de code . Who cares

[Alarmnummer]

alienfruit schreef op maandag 10 oktober 2005 @ 12:17:
Ik heb juist vandaag het probleem dat een programmeur bij de klant vind dat ik teveel commentaar heb in de code . Who cares

Dat ligt eraan. Op het moment dat je de kleinste dingen van commentaar loopt te voorzien, dan vind ik te veel commentaar ook een slechte zaak (het is gewoon vervelend ruis).

[alienfruit]

Ja, het is commentaar dat voor mijzelf handig is, bijv. opmerkingen en notities over wijzigingen in de workflow van de syntax highlighter. Ik bedoel ik wil wel wat commentaar hebben over de werking van de selection container, de klasse die de tekst tekent etc. Ik vind het wel handig om een beschrijving van de workflow van het tekenproces bij de hand te hebben in de code. Ik vind dat nou niet iets wat ik wil gaan nazoeken in de technische documentatie

Okay, commentaar zo van nu ga ik x met y vergelijken of het true is of nu gaat we dat controleren op b enzo. Lijkt mij inderdaad ook niet zinvol.

[Basszje]

Ik zou vooral niet teveel de kont tegen de kribbe gaan gooien, want daar maak je geen vrienden mee en los je ook niets mee op. Zoals al gezegd indien je iets aan moet passen kijk dan of je een beetje kan opruimen en dingetjes beter opzetten over het gedeelte waar je mee bezig bent. Verder veel vragen waar wat staat en wat je niet begrijpt en rustig aan eens beginnen over een wat beter onderhoudbaar model.

Misschien kan je een voorstel doen om de structuur eens in kaart te brengen of iets dergelijks. Dit soort toestanden zijn meestal een gevolg van iedere keer wat kleins toevoegen aan het geheel zonder dat er een goed globaal plan is. Iets wat je in de meeste bedrijven wel zult tegenkomen gewoon door 'loop van de tijd'.

Het is niet per definitie slecht, maar op een gegeven moment komt er gewoon een tijd om 'op te ruimen'.

[Verwijderd]

Ik denk dat je een paar stappen zal moeten maken.

1) Probeer voor jezelf te bepalen of je in de omstandigheden goed kan functioneren. De beloftes en ideeen van je nieuwe werkgever maken je enthousiast, maar je zult altijd moeten functioneren binnen de bestaande context, en zoals jij die omschrijft, is het een enorm rampgebied.

Als jij dat kan accepteren en er nog steeds zin in hebt, dan moet je doorgaan naar het volgende punt. Als je echter een behoefte hebt aan vaste structuur en ondersteuning door de omgeving, dan zit je misschien volledig op de verkeerde plaats. Ken je eigen mogelijkheden en beperkingen op dit gebied.

2) Bedenk wat jij het beste zou kunnen doen voor het bedrijf. Is dat het opnieuw opzetten van de hele ICT structuur, is dat het stuk voor stuk vervangen van de applicaties of bijv. de applicaties geleidelijk verbeteren? Jij kan dat het beste beoordelen.

3) Schrijf een adviesrapport voor jouw baas, waarin je een voorstel doet met hoe de huidige situatie volgens jou het best aangepakt zou moeten worden. Wees daarin eerlijk over het spanningsveld tussen jou en de medewerker van het externe bedrijf. Zinspeel eventueel op het inwinnen van een extern advies van een onafhankelijke partij om jouw baas te overtuigen van jouw vertrouwen in jouw analyse.

Iets wat je absoluut moet vermijden in dit advies is het direct of indirect beschuldigen van mensen, maar als constatering van feiten en de daarna best te volgen acties. Als je baas vraagt om "waarom", probeer dan de technische discussie te vermijden. Stuur heel voorzichtig aan op het accepteren van de huidige situatie en hoe het beste verder gegaan kan worden. Als je baas alsnog overtuigd moet worden, kom dat met een heel simpele fout waarvoor een triviale betere oplossing is, en leg dat uit. Bereid dit dus voor. Het is beter dat jouw baas de grenzen van zijn kennis erkent en gaat vertrouwen op jou.

Een ander ding dat je moet vermijden is het aanzetten tot een revolutie. Mensen en bedrijven vinden verandering moeilijk, en een geleidelijke verandering is daarom veel beter, zeker als je na iedere fase merken dat alles weer een klein beetje beter is. Met iedere verbetering komt meer vertrouwen en voor jou meer grip op de interne situatie.

Richt je in het rapport op de ervaring van de gebruikers en je baas, niet op technische aspecten.

4) Als je een mandaat hebt gekregen om jouw advies uit te mogen voeren, schrijf dan voor jezelf een concreet plan van aanpak, waarbij je voor ieder deelproject beschrijft wat het concrete doel is, hoeveel tijd je denk nodig te hebben, wat de resultaten zullen zijn, en wat de risico's zijn. Zorg voor tussentijdse voortgangsrapportages en -overleggen met jouw baas, voornamelijk om hem vertrouwen te geven in wat jij doet.

Zoals je al leest gaat het hier veel meer om intermenselijke zaken dan om technische aspecten. Kom dus niet aan met de lijst die je hierboven hebt genoemd, want dan vervreemd je mensen, maar praat in termen die zij begrijpen.

Bij iedere stap moet je weer opnieuw bedenken of je wel goed kan functioneren binnen de beperkingen van jouw situatie. Zo niet, dan moet accepteren dat het mission impossible is en uitkijken naar een betere, haalbare uitdaging.

Succes

[D4Skunk]

Nog eens .02 €

* D4Skunk zegt : Welcome to the real world

Alhoewel het voor jou misschien wel broodnodig lijkt om de code te herwerken, zal je dit ook aan het management moeten uitleggen. Wat je moet uitzoeken is de potentiële opbrengst die jij kan hebben door nu code te herwerken.
Als je bv 1 manjaar nodig hebt om de code te refactoren, en de totale planning voor aanpassingen aan de bestaande code over een termijn van 3/5 jaar zijn bv 2 maand, dan is de rekening snel gemaakt. Die 3 tot 5 jaar is eerder een richtlijn dan een concreet cijfer, en is in de meeste bedrijven de gemiddelde duur dat een app draait in een firma.
Je moet niet denken in termen van goed/niet goed, maar eerder in termen van kost/opbrengst. Wanneer je dit zo verkoopt aan je baas, zal je waarschijnlijk ook veel meer begrip van zijn kant krijgen, en spreek je ook voor hem verstaanbaar : xxx euro investeren om yyy euro potentiële kosten te vermijden.

Een optie die ik bij mijn klanten veelal toepas, is het modulair opbouwen van applicaties : ik begin met (minder dan) de gevraagde basisfunctionaliteit, en gaandeweg bouw ik alle modules errond op.
Alles in 1 keer herschrijven/aanpassen zou ik niet aanraden, gezien dat meestal na een tijdje enorm boring wordt, en je van zo'n grote onoverzichtelijke projecten moeilijk een concrete planning kan opbouwen. Probeer maar eens op een verstaanbare manier de vooruitgang te rapporteren, om maar te zwijgen van je eigen motivatie.

Veel succes !

[farlane]

Verwijderd schreef op maandag 10 oktober 2005 @ 13:09:
.... advies ...

Goed advies imho, je kunt merken dat hier iemand uit/met ervaring spreekt.

[beany]

Dank jullie allen voor de adviezen... ik ga morgen de manager bellen om een afspraak te maken voor een gesprek. Jullie adviezen hebben geholpen bij het bepalen wat ik moet doen, en hoe ik het moet doen. Ik zal hier posten wat uiteindelijk het resultaat is geworden

[Alarmnummer]

En wat wil je gaan doen?

[Verwijderd]

Als ik nog 1 advies mag geven.. constateer de situatie. Beschrijf hem zo helder en duidelijk mogelijk. Geef aan waarom je daar een probleem in ziet. Geef aan wat de risico's zijn.

Geef dit aan je manager. Doet hij er iets mee? Mooi. Vaak schrikken managers wel als de ernst van de situatie rustig en duidelijk en zonder ruis aan ze uitgelegd wordt.

Doet hij er niets mee? Dan kun je twee dingen doen. De eerste is de makkelijke weg: ga een andere baan zoeken en laat ze hun rotzooi zelf opruimen. De 2e is periodiek melden dat dat probleem volgens jou bestaat, en dat er iets aan gedaan moet worden. Niet elke dag, maar, zeg, 1 keer per maand.

Als het daadwerkelijk zo'n puinhoop is als jij hier stelt, ontstaan de problemen waar jij bang voor bent vanzelf. Op dat soort momenten kun je een soort verkapt 'told you so' uithalen, alhoewel ik als ik jou was niet glunderend vooraan zou gaan staan.

Continu en zonder tussenruimte je standpunten herhalen, dwarsliggen, trachten te dwingen dat iets anders gebeurd, enzovoort.. zet dat alsjeblieft uit je hoofd. Het enige wat je daarmee bereikt is dat jij ongelukkig bent, dat je baas ongelukkig is, dat jullie ruzie krijgen en dat je uiteindelijk ontslag neemt of ontslagen wordt.

Ik kan wel een soortgelijk iets noemen... sinds ik bij mijn huidige werkgever werkzaam ben, vraag ik al om budget en tijd voor anti-virus software. Niet elke dag, maar zo af en toe als ik een lijstje moet maken met taken die ik nog moet doen, dan staat het er tussen.

In de tijd dat ik er gewerkt heb, zijn er al meerdere malen virusinfecties geweest. Sterker nog, er staat op dit ogenblik minstens 1 besmette PC in het netwerk die niet ontsmet kan worden, omdat dat de werking zou verstoren, en daar geen tijd voor is. Een anderhalve maand geleden is er een applicatie aan een (grote) klant opgeleverd, waar een virus in de installer zat. Ik heb in de tussentijd al zeker 5 keer een paar uur aan diverse computers moeten besteden wegens masale virus en anti-spyware infecties.

Toch.. ik kan nu wel elke dag stampvoetend het kantoor binnenrennen en zeggen dat dit toch echt niet zo kan, maar daar bereik ik niets mee.

Ik ben bv. nu bezig met een 'verlanglijstje' op te stellen voor zaken die nog aangeschaft moet worden. Uiteraard staat daar de anti-virussoftware weer bij. De tijd + het geld om een goed anti-virus beleid op te zetten is mijn doel. Ik denk dat het uiteindelijk wel gaat komen, maar zal daar toch geduld voor moeten opbrengen.

[Verwijderd]

Het enigste "voordeel" wat ik kan bedenken van geen commentaar gebruiken is misschien ook wel dat je jezelf moeilijk vervangbaar maakt binnen een bedrijf/project/etc. Tenzij het een kleine moeite is weer van scratch af aan te beginnen

Vergelijk het eens met het volgende: Een baas van je vraagt aan je om werkinstructies te schrijven.

Hetgeen wat je dan doet is jezelf vervangbaar maken. M.a.w, een vorm van mogelijke toekomstige broodroof

Wat betreft de topicstarter zijn probleem, gewoon melden wat je er van vind. Straks wordt je er zelf nog op afgerekend en denken ze dat het aan jouw kunnen ligt

[ Voor 19% gewijzigd door Verwijderd op 10-10-2005 22:58 ]

[Verwijderd]

farlane schreef op maandag 10 oktober 2005 @ 08:59:
[...]

Dan heb jij denk ik niet die code van Zoijar gezien. Als ik die zie dan weet ik dat het zoals hij zelf ook zegt, elegante code is van hoog niveau. Maar in de praktijk heb je daar niets aan. Het moet werken, en het moet zo simpel mogelijk zijn. Als ik een universitaire studie moet gaan volgen om een stuk code te begrijpen die 2 strings aan elkaar plakt dan heeft de maker ervan iets verkeerd gedaan.

In de praktijk werkt het toch iets genuanceerder als jij het nu doet voortkomen. Elegantere code is dikwijls juist -makkelijker- om te lezen. Simpelheid zit hem niet in het soort code dat alleen beginners met goed fatsoen kunnen schrijven.

Het lijkt een contradictie, maar dergelijke "simpele" code is -juist- complex om te lezen. Beginners/prutsers zien (nog) niet de grotere abstractie lijnen in hun code, en zetten nodeloos veel condities, uitzonderingen en dubbele zaken in hun code. Het gevolg is dat je werkelijk hoofdpijn krijgt als je de betekenis van de code probeerd de achterhalen.

Een voorbeeld is de beginner die een loop schrijft, waarbij in de body van de loop meerdere if statements staan waarna de index meerdere keren wordt opgehoogd. Beginners kunnen zo'n loop nog niet strak in 1 iteratie statement vangen, zoals een prof. dat wel kan. Het kost iets meer moeite, en je zal er wat langer over doen (lees aantal refactor pogingen), maar de simpelste code is die waar aan uiteindelijk het langste is gezeten.

Het soort code waar de TS het over heeft is duidelijk van de verkeerde soort simpelheid. Men kwakt en copy-paste er telkens van alles bij zonder een keer fatsoenlijk te refactoren. Zogenaamd onder het mom van "de code moet simpel" blijven. Wat dat betreft zijn mensen zoals farlane de ergste. Als iemand toegeeft code van laag niveau te schrijven dan is dat 1 ding, maar als iemand beweert dat de code van laag niveau juist goed is omdat het simpel is, en simpel goed is (terwijl het dus eigenlijk nodeloos hoog complexe code is), dan loop je de boel gewoon te belazeren en de toekomstige onderhouders van die code zit je dan gewoon een oor aan te naaien.

[Gwaihir]

TS: zoals ik het lees ben jij aangenomen en worden je collega's opgeleid zodat het bedrijf zijn afhankelijkheid van dat externe bedrijf kan afbouwen. Klinkt allemaal nogal alsof de partij die toch al aan het kortste eind gaat trekken nog even zo krampachtig mogelijk vast houdt. Ik denk dat je met je eigen chef een en ander waarschijnlijk beter zult kunnen bespreken dan je nu verwacht en deze je best een manier wil bieden je te bewijzen zonder volledig van stijl te hoeven veranderen. Serieus: als jij over enkele maanden je bewezen hebt en door je proeftijd heen bent en die man is nog zo stom om dat telefoontje te plaatsen, dan denk ik dat je chef tegen dat externe bedrijf zegt: "Oh, geen probleem hoor. We kunnen het ondertussen prima zonder jullie af." Dus: nu effe door de zure appel heenbijten en goed met je eigen chef in gesprek blijven.

[seamus21]

Ok TS, Je hebt op technisch vlak al een aantal zaken geconstateerd die beter kunnen aan de code. Alleen zal het management, zoals al eerder gezegd, zich daar geen raad mee weten. Als je naar je baas toestapt en ze wijst op de nadelen die aan dit soort manier van programmeren zitten en de tijd (kosten) die er mee gemoeid zijn om zoiets te onderhouden dan zullen ze waarschijnlijk minder snel geneigd zijn om jou ook op die manier te laten programmeren.

Probeer dus alle voordelen van een goede documentatie en betere code op een rijtje te krijgen en deze over te brengen op je baas.

[farlane]

Verwijderd schreef op dinsdag 11 oktober 2005 @ 00:26:
Wat dat betreft zijn mensen zoals farlane de ergste. Als iemand toegeeft code van laag niveau te schrijven dan is dat 1 ding, maar als iemand beweert dat de code van laag niveau juist goed is omdat het simpel is, en simpel goed is (terwijl het dus eigenlijk nodeloos hoog complexe code is), dan loop je de boel gewoon te belazeren en de toekomstige onderhouders van die code zit je dan gewoon een oor aan te naaien.

Ik ben met een groot deel van je post wel eens maar hier had toch ff een moment van 'Scuse me?'.

Dat ik de code van Zoijar van hoog niveau vind maar te ingewikkeld om in de praktijk toe te passen wil niet zeggen dat ik zelf code van laag niveau schrijf volgens mij ? Ik zie dat niet terug in mijn post iig.
En dan nog, mijn punt was dat simpele code juist niet van laag niveau is: goede code is zo simpel mogelijk. Dat is wat anders als wat jij zegt met 'goede code is simpel'.


[edit]
Ik vind dit 'Wat dat betreft zijn mensen zoals farlane de ergste.' erg vijandelijk overkomen of ligt dat aan mij?

[ Voor 10% gewijzigd door farlane op 11-10-2005 08:52 ]

[beany]

Alarmnummer schreef op maandag 10 oktober 2005 @ 20:36:
En wat wil je gaan doen?

Nou, ten eerste wil ik de situatie proberen te schetsen in manager taal, ondersteund door een aantal zaken die ik op papier heb staan(en er komt nog meer op papier).

Ten tweede wil ik de manager duidelijk maken dat op deze manier werken het uiteindelijk schadelijk is voor het bedrijf. Op de lange termijn gaat het bedrijf dit gewoon geld kosten.

Daarnaast is het ook zo dat ik een nieuw project moet gaan doen op de manier zoals er bij dat externe bedrijfje wordt gewerkt. Het stuit mij zwaar tegen de borst dat ik dus code moet gaan schrijven EN opleveren die kwalitatief zwaar bedroevend is. Dat wil ik, in iets andere bewoordingen natuurlijk, ook duidelijk gaan maken. Want uiteindelijk is het wel zo dat wanneer er iets mis gaat in de applicatie die ik gescheven heb, ik er op aangekeken word!

Ik ben er overigens ook achter gekomen waarom die code om met de database te werken in ELK project apart aanwezig is. Hij wil namelijk niet alle applicaties opnieuw testen als er iets in die code is gewijzigd. Dus als er een bug fix is gemaakt, word dat alleen in de applicatie gedaan waar de bug naar voren is gekomen, de rest laat hij ongemoeid

edit: oh ja... de reden waarom er geen datamodel is: 'de tabellen willen nog wel eens veranderen, en dan moet het datamodel ook gewijzigd worden en dat is niet echt werkbaar'. En toen ik vroeg hoe ik er dan achter moest komen welke tabellen er in welke stored procedures gebruikt worden antwoorde hij 'je kan ook met de windows verkenner search zoeken op een tabel naam, dan zie je vanzelf wel welke SP's welke tabellen gebruiken' (alle SP's staan als tekst bestand bij het project in een apart map)

[ Voor 17% gewijzigd door beany op 11-10-2005 09:26 ]

[Alarmnummer]

Volgens mij heeft henk_DE_man ook wat te lang achter zijn pc gezeten. Je opmerking was idd een beetje lomp tov farlane.

Ik denk dat jullie beide op dezelfde lijn zitten, maar door de discussie een 'overdreven' mening erover hebben.

Code voor standaard applicaties moet gewoon 'eenvoudig' zijn. Dat wil niet zeggen dat copy paste werk goed is en dat je maar structuurloze applicaties moet maken (alles behalve dat) Maar wel dat je bij applicaties rekening houd met het gemiddeldnivo van een team. Op het moment dat 1 iemand te slechte of te geavanceerde code schrijft kunnen anderen er niet mee uit de voeten en dan heb je gewoon een probleem.

[ Voor 20% gewijzigd door Alarmnummer op 11-10-2005 09:44 ]

[beany]

Nou... manager heeft pas 25 oktober tijd Word dus echt uitzitten die handel!

[Verwijderd]

beany schreef op dinsdag 11 oktober 2005 @ 09:19:
[...]
Daarnaast is het ook zo dat ik een nieuw project moet gaan doen op de manier zoals er bij dat externe bedrijfje wordt gewerkt. Het stuit mij zwaar tegen de borst dat ik dus code moet gaan schrijven EN opleveren die kwalitatief zwaar bedroevend is. Dat wil ik, in iets andere bewoordingen natuurlijk, ook duidelijk gaan maken. Want uiteindelijk is het wel zo dat wanneer er iets mis gaat in de applicatie die ik gescheven heb, ik er op aangekeken word!

Nou vraag ik me wel af wat je bedoelt met "een nieuw project moet gaan doen op de manier zoals er bij dat externe bedrijfje wordt gewerkt". Ik neem aan dat je baas niet zegt dat je crappy code moet gaan schrijven, dus hoe bepaalt hij dan wel de manier waarop jij het project gaat doen?

[beany]

Ik zit momenteel bij dat externe bedrijfje om ingewerkt te worden. Al noemt hij het 'opleiden'

Ik moet dus binnenkort beginnen aan nieuw project voor mijn werkgever, die ik ook hier zal maken. De man van het externe bedrijfje zal mijn nieuwe project dus bekijken, beoordelen en pas in productie laten gaan als het naar ZIJN zin is. Ofterwel: gedwongen prut code bakken

[Verwijderd]

farlane schreef op dinsdag 11 oktober 2005 @ 08:47:
[...]
Dat ik de code van Zoijar van hoog niveau vind maar te ingewikkeld om in de praktijk toe te passen

Ik doelde niet specificiek op de code van Zoijar. Zoijar is zoals we allemaal weten nogal gek van C++ templates . Echt generic programming is inderdaad een geavanceerd concept wat lang niet iedereen goed onder de knie heeft.

Waar ik meer op doelde was dat met gebruik van een gemiddelde set van language features, de structuur dusdanig is dat het mischien meer moeite kost om te bedenken, maar uiteindelijk kleiner en/of eleganter is. Ik dacht dat mijn loop voorbeeldje dat al voldoende duidelijk aangaf, maar nog een voorbeeld is het verschijnsel dat beginners vaak verschillende situaties apart gaan uitprogrammeren, terwijl ze makkelijk in 1 common case genomen kunnen worden.

Laatst kwam ik nog zoiets typisch tegen: iemand schreef een stukje code die een datatype op het scherm neerzette. Nu had dat datatype de mogelijkheid van een soort filter. Wat deed die iemand nou, voor de datatype in filtering mode werd de hele afrduk code bijna identiek nog maals geschreven. Je kon ook 'zoeken' in dat ding. Ook hiervoor werd de hele afrduk code -nogmaals- opgeschreven. Het toppunt was dat er ook nog gezocht -en- gefilterd kon worden, en je raad het al, bijna identieke code stond er NOG een keertje. Elke versie dupliceerde een regeltje of 20 met slechts enkele regels per specifieke situatie.

Ik heb de programmeur erbij geroepen, en uitgelegd dat je EERST de toe te passen operaties op het datatype toepast, en dan EENMALIG het afdrukken doet, waarbij die afdruk code absoluut geen rekening hoeft te houden met de "mode" van dat datatype.

Die persoon bleef echter volhouden dat dat de code nodeloos complex zou maken en dat dit zo veel makkelijker was. Ja, inderdaad makkelijker om op te schrijven. Je doet gewoon 4x copy-paste, en zet bij elke versie 1 of 2 extra regeltjes. Het is echter een HEL om dergelijke code te lezen, en schier onmogelijk om het te onderhouden.

Eigenlijk had ik hem ter plekke moeten ontslaan, maar ik heb toch maar even het voorbeeld gegeven en de code anders geschreven. Goed, het was inderdaad even puzzelen om de juiste combinaties van views (want dat zijn het eigenlijk) op dat type goed te krijgen, maar met relatief iets meer inspanning heb ik nu een versie van de code die heel universeel de verschillende operaties op dat type kan uitvoeren in elke gewenste combinatie, met een afdruk code die er maar 1 keer staat.

Hierbij gebruik ik geen rare of moeilijke taal features (heb je niet eens zo veel in Java) en ziet de code er enorm helder uit. Gewoon een kwestie van kijken naar de overeenkomsten tussen verschillende brokken code, en die dan vangen in 1 generieker brok.

Hierbij staat simpel dus niet voor simpel als in (sterk) vereenvoudigde code, maar simpel als in dat de programmeur geen zin heeft om er langer dan 1 seconde over na te denken.

En dan nog, mijn punt was dat simpele code juist niet van laag niveau is: goede code is zo simpel mogelijk. Dat is wat anders als wat jij zegt met 'goede code is simpel'.

Helemaal met je eens. Zo simpel mogelijk, maar niet simpelder dan dat!
Ik dacht dat je meer doelde op het helaas te vaak gebruikte mantra:

lage kwaliteit code = simpel => dus goed

[edit]
Ik vind dit 'Wat dat betreft zijn mensen zoals farlane de ergste.' erg vijandelijk overkomen of ligt dat aan mij?

Dat kwam inderdaad een beetje cru over en dat was niet echt de bedoeling. Sorry...

[Verwijderd]

beany schreef op woensdag 12 oktober 2005 @ 15:16:
Ik zit momenteel bij dat externe bedrijfje om ingewerkt te worden. Al noemt hij het 'opleiden' [afbeelding]

Ik moet dus binnenkort beginnen aan nieuw project voor mijn werkgever, die ik ook hier zal maken. De man van het externe bedrijfje zal mijn nieuwe project dus bekijken, beoordelen en pas in productie laten gaan als het naar ZIJN zin is. Ofterwel: gedwongen prut code bakken

Als ik jou was zou ik me hier hevig tegen verzetten. Jij bent het fundamenteel oneens met de ontwikkelwijze van deze kerel, dus het 'opleiden' is niet aan jou besteed.

Jouw baas zal misschien niet de technische argumenten hiervoor kunnen begrijpen, dus het zal waarschijnlijk ook zinloos zijn om het in die termen uit te leggen, maar als hij jou niet op je woord gelooft als jij zegt dat je naar eigen inzicht wil kunnen ontwikkelen en niet binnen een keurslijf van iemand waarmee jij fundamenteel van mening verschilt over de technische invulling van je werk, dan kun je beter opstappen dan aanmodderen.

[beany]

MrX, de secretaresse van mijn manager belde me vandaag... met de vraag of 25 oktober mij schikte om te komen praten over dit alles... eerder kon niet...

Ik baal er toch wel van hoor... denk je leuke baan gevonden te hebben, krijg je dit gedoe... pffffffffff

[farlane]

Verwijderd schreef op woensdag 12 oktober 2005 @ 22:49:
Ik doelde niet specificiek op de code van Zoijar. Zoijar is zoals we allemaal weten nogal gek van C++ templates . Echt generic programming is inderdaad een geavanceerd concept wat lang niet iedereen goed onder de knie heeft.

I know. Ik ging door op het voorbeeld dat was aangekaart omdat het zo'n duidelijk voorbeeld is. Maar Alarmnummer heeft het beter verwoord dan ik in zijn post hierboven ergens.

Waar ik meer op doelde was dat met gebruik van een gemiddelde set van language features .... etc.

Ik ben het helemaal met je eens.

Dat kwam inderdaad een beetje cru over en dat was niet echt de bedoeling.

Dat vermoeden had ik al. np

[farlane]

beany schreef op woensdag 12 oktober 2005 @ 23:22:
MrX, de secretaresse van mijn manager belde me vandaag... met de vraag of 25 oktober mij schikte om te komen praten over dit alles... eerder kon niet...

Ik baal er toch wel van hoor... denk je leuke baan gevonden te hebben, krijg je dit gedoe... pffffffffff

Wens je veel succes en wijsheid . ik hoop dat je er op een of andere manier uit gaat komen. Heb wel de ervaring dat als je doorzet, de meeste mensen op een gegeven moment wel inzien dat de ideeen die je hebt zo gek nog niet zijn.

Ik bedoel, als jouw manier van werken ook een goed werkend produkt oplevert kan die externe man dat wel beoordelen als slecht, maar jouw als manager ziet dat het werkt gaat hij toch ook vragen stellen?

Ben het wel eens met MrX dat als je echt dingen moet gaan doen waar je compleet niet achter staat je beter eieren voor je geld kunt kiezen en de biezen pakken.

Zo blijkt maar eens te meer dat de meeste problemen niet van technische aard zijn, maar puur met persooonlijkheden te maken heeft, grappig.

[beany]

Zo, en dan nu even een update:

Ik heb ontslag genomen. Ben net terug van een gesprek met de manager. Ik had een heel verhaal op papier gezet, en met elk punt was hij het eens. Voor de hele technische aspacten gaat hij op advies van mij een second opinion halen, en dat is dan om sterk te staan tegen over dat externe bedrijfje. Hij heeft nog wel heel veel moeite gedaan om mij te houden. Maar het is denk ik beter voor mij dat ik er weg ben!

Iedereen hier bedankt voor de feedback en de adviezen!

En dan nu kijken of ik een leuke toko kan vinden

[ Voor 6% gewijzigd door beany op 25-10-2005 11:28 ]

[kasper_vk]

Ik heb dit topic met belangstelling (en medeleven) gevolgd en ik moet zeggen: ik bewonder je lef.

Wat ik me afvraag (alles vanaf nu is mosterd na de maaltijd, dat begrijp ik, maar toch): heb je ontslag genomen voordat je dat gesprek had of erna?
En heb je dan geen vreemd gevoel, zo van: "mogelijk blijkt dat ik 'gelijk' had, maar daar kan ik zelf niet meer het voordeel of de eer voor opstrijken". En als dank voor je eerlijke en (waarschijnlijk) verfrissende blik op de situatie mag je nog naar ander werk gaan zoeken ook.

[jelmervos]

Kleven er veel nadelen aan zelf ontslag nemen?

[Skaah]

beany schreef op dinsdag 25 oktober 2005 @ 11:27:
Zo, en dan nu even een update:

Ik heb ontslag genomen. Ben net terug van een gesprek met de manager. Ik had een heel verhaal op papier gezet, en met elk punt was hij het eens. Voor de hele technische aspacten gaat hij op advies van mij een second opinion halen, en dat is dan om sterk te staan tegen over dat externe bedrijfje. Hij heeft nog wel heel veel moeite gedaan om mij te houden. Maar het is denk ik beter voor mij dat ik er weg ben!

Iedereen hier bedankt voor de feedback en de adviezen!

En dan nu kijken of ik een leuke toko kan vinden

Wow, respect dat je dat durfde te doen!

[whoami]

Kaassoevlee schreef op dinsdag 25 oktober 2005 @ 12:18:
Kleven er veel nadelen aan zelf ontslag nemen?

Als je nog geen andere job hebt, wel ja...

[T-MOB]

Kaassoevlee schreef op dinsdag 25 oktober 2005 @ 12:18:
Kleven er veel nadelen aan zelf ontslag nemen?

Geen recht op WW is de beroerdste... (in combinatie met ^^^ dan natuurlijk )

[ Voor 10% gewijzigd door T-MOB op 25-10-2005 12:32 ]

[Verwijderd]

Stoer dat je voor jezelf gekozen hebt. Succes met het vinden van een leuke baan (waarbij ik bewust niet zeg: de perfecte baan, want die bestaat niet).

[pjvandesande]

Een man met ballen, dat ben je

Heel veel succes met het vinden van een baan waar je wel goed in past en waar het niet zo'n klere zooi is!

[Rukapul]

T-MOB schreef op dinsdag 25 oktober 2005 @ 12:31:
[...]

Geen recht op WW is de beroerdste... (in combinatie met ^^^ dan natuurlijk )

Als starter heb je tegenwoordig toch al nauwelijks recht op WW, zowel in hoogte als in duur. Waarschijnlijk zou je alleen recht hebben op een paar maand 70% van het minimumloon. Bovendien zou het aanvragen hiervan zoveel tijd en energie kosten dat het meer loont om actief te solliciteren en op andere wijze tijdelijk even wat inkomsten te genereren.

TS heeft doortastend voor zichzelf gekozen en die houding zal vast ook opvallen bij volgende sollicitatiegesprekken. Succes in elk geval.

Het enige wat me niet duidelijk is waarom TS niet bij werkgever zou blijven werken als 2nd opinion positief voor hem uit zou vallen, het andere bureau buiten de deur wordt gezet en TS zegmaar de vrije hand voor nieuwe ontwikkelingen zou krijgen. Was dat geen optie?

[ Voor 10% gewijzigd door Rukapul op 25-10-2005 13:27 ]

[beany]

Ik heb tijdens het gesprek ontslag genomen. Er is me verteld wat het traject zou zijn, en daar voelde ik weinig voor. Er zou een half jaar besteed worden aan het documenteren van alles(!). Iemand anders zou de FO's gaan doen, en ik zou dan van de bestaande applicaties de TO's mogen gaan doen. Na dat half jaar zou ik aan nieuwe projecten mogen beginnen, maar de huidige applicaties zouden niet overnieuw worden gedaan. Tevens komt er ook nog bij dat het externe bedrijf NIET buiten de deur word gezet. Die blijft dus altijd een flinke invloed hebben. Het schijnt namelijk dat de directeur van het bedrijf voor 50% eigenaar is van het externe bedrijf

Kaassoevlee schreef op dinsdag 25 oktober 2005 @ 12:18:
Kleven er veel nadelen aan zelf ontslag nemen?

Uhuh... geen inkomsten... Geen recht op WW...

@Rukepul: Geen optie dus... externe bedrijf blijft!

[P_de_B]

Dat ze hebben aangegeven dat ze wat zien in je voorstellen vind ik al heel wat, ze gaan zelfs in de toekomst je adviezen opvolgen! Ik denk dat je niet reele verwachtingen hebt als ze ook even hun voor de buitenwereld goed werkende code opnieuw gaan schrijven. Ze zouden gek zijn als ze dat wel zouden doen.

[beany]

P_de_B, ik ben het met je eens. Maar ik heb geen zin om maaaanden lang troep te documenteren, daarna paar projectjes nieuw te mogen doen... en vervolgens is het grote werk gedaan en is de uitdaging voor mij weg. Dan maar liever even geen poen en zometeen een job waar ik meer lol zou hebben.

[beany]

Wederom een update:

Ik heb inmiddels een nieuwe baan gevonden... Leuke toko, een ex-collega en tevens goede vriend van mij werkt daar. Die heb ik dus eerst enigsinds uitgehoord en het zit allemaal goed daar!

Maar ik was net bij thuiskomst ook enigsinds verbaasd, dat ik namelijk 3 mailtjes vond in mijn inbox met daarin uitnodigingen om te komen praten over een baan naar aanleiding van DIT TOPIC!

GoT rules

[prototype]

Gefeliciteerd beany
Ik heb het topic op de zijlijn gevolgd, en ik moet zeggen dat ik me er echt in terug kan vinden. Net als jij heb ik bij de twee keren dat ik in een dergelijke situatie verkeerde de eer ook aan mezelf gehouden en ben opgestapt, NADAT ik talloze pogingen -helaas tevergeefs- heb gedaan om collega's/baas ervan te overtuigen dat het anders moest, eveneens ongeveer in de fase van inwerken. Heel herkenbaar dus

[pjvandesande]

Gefeliciteerd beany, heel veer succes op je nieuwe werk!

Happy coding!

[ Voor 13% gewijzigd door pjvandesande op 26-10-2005 13:02 ]

[Nick The Heazk]

Congrats.
Ook ik heb het topic gevolgd zonder 2 eurocents te droppen. Ik ben namelijk net begonnen met mijn opleiding, dus voor mij is dit allemaal wel interessant.

Toch nog een kleine bijdrage in verband met slechte codeerstijl. Als ik de mentalliteit van sommige mensen in mijn richting zie sta ik daar niet versteld van. Een kort maar krachtig voorbeeld:

Student: "Heb jij dat gele Java boek?"
Ik: "Jazeker, leest wel vlot overigens"
Student: "Ah ik niet, ze hebben dat vorig jaar niet gebruikt dus dan koop ik dat niet"

Nu is het zo dat de cursus eigenlijk een beknopte versie van het boek is. Dus jah, dan ben je niet geïnteresseerd in de lessen vraag ik me dan af?

[prototype]

Nick The Heazk schreef op woensdag 26 oktober 2005 @ 13:03:
Congrats.
Ook ik heb het topic gevolgd zonder 2 eurocents te droppen. Ik ben namelijk net begonnen met mijn opleiding, dus voor mij is dit allemaal wel interessant.

Toch nog een kleine bijdrage in verband met slechte codeerstijl. Als ik de mentalliteit van sommige mensen in mijn richting zie sta ik daar niet versteld van. Een kort maar krachtig voorbeeld:

Student: "Heb jij dat gele Java boek?"
Ik: "Jazeker, leest wel vlot overigens"
Student: "Ah ik niet, ze hebben dat vorig jaar niet gebruikt dus dan koop ik dat niet"

Nu is het zo dat de cursus eigenlijk een beknopte versie van het boek is. Dus jah, dan ben je niet geïnteresseerd in de lessen vraag ik me dan af?

Ach, voor sommige vakken heb je daadwerkelijk niet het boek nodig om het met een goed cijfer af te ronden. Ik ben er al een paar keer mee weggekomen. Een boekje lezen geeft nog niet de garantie dat je het begrijpt, en bij zoiets als programmeren telt ervaring ook erg mee.

[mulder]

Een boekje lezen geeft nog niet de garantie dat je het begrijpt, en bij zoiets als programmeren telt ervaring ook erg mee.

Sttttttt don't go there!!!!

[Nick The Heazk]

Een boekje lezen geeft nog niet de garantie dat je het begrijpt, en bij zoiets als programmeren telt ervaring ook erg mee.

Dat is zeker waar, maar het handeld hier om mensen die nog nooit - in eender welke taal - geprogged hebben. Furthermore is de cursus zelf wel vrij beknopt. Eigenlijk meer een samenvatting van het boek. Door enkel de cursus te leren kun je de stof niet doorgronden. (Getuige de vele problemen die mensen hebben met bv. for-loops)