Hoe het beste software schrijven in je eentje?*

zaterdag 3 maart 2007 18:45

Je kunt gewoon eeerst aan de hand van classe diagramme je applicatie ontwerpen, en vanuit daar steeds verder werken.

Het is ook handig om meteen je tests in te bouwen. Maar dit heeft niet zoveel te maken met je probleem.

Het beste is dus gewoon om eerst een ontwerp te maken en dit uit te werken. Plannen en ontwerpen scheelt een heleboel tijd. Dan is het type van de code nog maar een 2e.

[ Voor 13% gewijzigd door Depress op 03-03-2007 18:28 ]

Acties:

zaterdag 3 maart 2007 19:13

Topicstarter

Ik denk dat ik idd aan XP ga doen, nu moet alleen nog even een partner zien te vinden

Nee geintje

Gewoon de documenten minimaal houden en de design simpel houden (dwz de requirements zijn simpele verhaaltjes en het design bestaat uit sequence- en class diagrammetjes)

Ik was sowieso van plan om de tijd tussen releases kort te houden (1 nieuwe feature en eventueel een paar bugfixjes => release!)

Acties:

CubicQ

Comp_Lex schreef op zaterdag 03 maart 2007 @ 18:16:
Je kunt niet echt een iteratief UP-like (RUP, UPEDU, etc) proces gebruiken, omdat je dan ook documentatie moet schrijven, maar dan wordt in je eentje werken echt een hell. Daar gaat uren tijd inzitten die je beter aan iets anders kan spenderen. Waterval is ook uitgesloten, want als het behoorlijk groeit dan kan je tegen problemen aanlopen op het gebied van "change managment" (i.e. het wordt op den duur heel moeilijk om veranderingen door te voeren) en er moet daarbij ook documentatie geschreven worden.

Niet documenteren omdat dat tijd kost die je beter ergens anders aan kan spenderen heeft niet zo veel te maken met in je eentje werken. Ook als je met meerderen werkt kost het schrijven van documentatie tijd.

En het is eigenlijk altijd zo dat je een goede afweging moet maken tussen de hoeveelheid documentatie: te weinig is niet goed, en te veel ook niet.

De 'optimale hoeveelheid' documentatie is denk ik meer afhankelijk van:
- de hoeveelheid niet-standaard zaken in de applicatie
- de verwachte levensduur van de applicatie
- de verwachte hoeveelheid wijzigingen achteraf (en dan zou ik eerder zeggen: hoe meer wijzigingen er gedurende de jaren plaats zullen vinden, hoe meer documentatie nodig is)
- hoe flexibel is de opdrachtgever
- hoe belangrijk is de applicatie
- hoe makkelijk is de applicatie testbaar
- en vast nog wel veel meer...

dan het aantal personen dat de software schrijft.

zaterdag 3 maart 2007 19:22

Acties:

zaterdag 3 maart 2007 20:40

Als je de documenten/documentatie minimaal gaat houden, is het vaak alleen voor je zelf duidelijk wat je er mee bedoelt. Wanneer een andere programmeur met je code aan de slag moet is hij eerst enkele dagen bezig met een beetje begrijpen van de code voordat hij aan het echte programeer werk toe is.

Ik weet niet in welke taal je werkt, maar in VS2005 kun je met een class diagram je applicatie ontwerpen. De sigantures van de methoden etc wat je daarin maakt worden al vast voor je gemaakt. Scheelt ook weer tijd, je houd overzicht. Met deze Klasse diagram kun je makkelijk relatie tonen tussen verschillende klasse. Het is gewoon van groot belang dat je ook echt documenteerd. Ik doe nu de opleiding Software Engineer, en daar hameren ze ook op de documentatie en ook het testen(Dit is ook belangrijk).

Acties:

Verwijderd

wanneer ik een projectje start die mogelijk groot gaat worden probeer ik altijd zo veel mogelijk klein te beginnen en dan steeds wat er om heen of er naast. ik probeer dan ook altijd alles zo veel mogelijk OO te houden en dan goed modulair houden. dan kan je je focussen op een klein deel tot dat af is, en vervolgens een volgens 'blok' schrijven. hoe die manier heet.... geen idee

maar het is idd puur wat je zelf lekker vind werken... doe je weinig documentatie en merk je dat je verdwaalt in je eigen software is het tijd voor meer documentatie... of anders georganiseerde software. (bijvoorbeeld duidelijke verdeling in files/classes/etc

zaterdag 3 maart 2007 21:33

Acties:

zaterdag 3 maart 2007 22:48

Verdelen van classes is vind ik een pré. Zelfs voor elke klasse een eigen bestand. Zo hou je alles goed gescheiden en hoef je niet in bestanden te zoeken waar je code staat. Beter nog zelfs is een klasse diagram alla VS2005. Deze doet het automagisch voor je en kun je makkelijk snel naar je code toegaan.

En zoals ik al zei, documentatie is belangrijk, want als je over 1 jaar een update moet schrijven heb je echt geen flauw idee waar je moet zijn. Ook al werk je in je eentje! Andere projecten verdringen dan de structuur van je applicatie en dan wens ik je veel ontwikkel plezier

Acties:

djc

Ik zou gewoon alsnog een version control system en een bug tracking system gebruiken (ik gebruik Trac, dat fijn integreert met Subversion, maar dat is lang niet de enige oplossing). Op die manier kan je in de commit messages wel even wat gegevens noteren bij elk stuk code dat je toevoegt aan je codebase. Het bug tracking system kan nuttig zijn om openstaande issues te documenteren, zodat je die niet per ongeluk vergeet, en zodat je goed bij kan houden hoe je vorderingen zijn.

Rustacean

zondag 4 maart 2007 00:09

Acties:

whoami

Gebruik een versie-controle systeem, zorg ervoor dat je unit-tests hebt, die eigenlijk ook al min of meer als documentatie kunnen dienen; je tests 'zeggen' nl. wat de code moet doen, en mocht er ooit iemand bijkomen op je project, kan hij aan de hand van die tests ook zien hoe hij de code moet gebruiken.
Verder zorg je gewoon voor duidelijke variable- & functie-namen, schrijf je commentaar waar het nodig is (waar het niet vanzelfsprekend is om te weten wat een stuk code doet door enkel die code te lezen), en zorg ervoor dat die comments in sync blijven.
Diagrammetjes en documenten zijn allemaal wel mooi, maar wees er van bewust dat je die ook 'in sync' moet houden met je code. Maw, als je je design veranderd, verander dan ook de documenten/diagrammen.

https://fgheysels.github.io/

zondag 4 maart 2007 02:37

Acties:

zondag 4 maart 2007 03:03

-= Tja =-

en mensen die hun code allemaal direct laten volgen uit een uml diagrammen verklaar is ter plekke voor gek. UML is leuk voor kennis overdracht, lekker kliederen, en zo nu en dan voor formele documentatie. Maar verder.. let it be.. techniek die totaal misbruikt wordt.

Acties:

Apache

amateur software devver

K'vind het analoog aan de richtlijnen van xp dat als er documentatie nodig is je gewoon die code moet herschrijven zodat ze heel is zonder documentatie.

Ik werk ook steeds test driven voor mijn core logic, en daarna probeer ik zo snel mogelijk iets werkend de hebben, iteratief verder bouwen op één werkend stuk is aangenamer dan een kern iteratief verder ontwikkelen dan met alles op hetzelfde niveau zodat je pas enkel helemaal op het einde ermee kan werken zoals de client dat doet, dit leid ook tot dat je zelf vaker met de UI werkt en irritante zaken zelf zal opmerken.

Wat ik zelf de laatste x zeer nuttig vond was mylar, een eclipse plugin om task driven aan je project te werken, vond ik zelf zeer nuttig, je hebt nl een todo lijst waarmee je je planning beheerst plus ook heel wat plaats om bvb specifieke ideeën die je hebt over een bepaald punt neer te schrijven tot wanneer je ze nodig hebt, als m'n opdrachtgever nog een punt van commentaar had kon het meteen bij de juiste taak geplaatst worden, en een taak kan gekoppelt worden aan open files.

Mylar integreert verder ook nog met trac zodat wanneer er een bug report (ticket) binnenkomt je een commit kan koppelen aan die ticket.

Meer over mylar hier: http://wbeaton.blogspot.c...easons-to-love-mylar.html

Verder kan je in een solo project nog altijd "lekker je eigen ding doen", de methodologiën zijn al niet meer zeer strict, maar in een solo project kan je nog altijd het meest dynamisch aan de slag, je kan je aanpassen aan je opdracht, aan je opdracht gever, je tijd constraints, ... en slechts in grote lijnen zaken te lenen uit de methodologie(en) die je toepast.

K'had een opdracht voor iemand die zelf nog programmeert in vb6, ik kreeg carte blanche qua technologië maar wilde wel gebruik maken common ground om te vermijden dat ik aan de slag moest om ui prototypes, tekst voorstellen van functionele eisen op te stellen, k'heb uit mijn db tool gewoon een erd laten rollen, doorgemailed en op basis daarvan zijn alle resterende functionele eisen en misvattingen naar voren gekomen.

Version control is nuttig, ook in een one man project om bvb branches te maken, rollbacks als er iets verkeerd gaat, history te hebben bij je files, handig als er toch ooit nog iemand komt om mee samen te werken, makkelijk om vanaf verschillende computers bvb pc/laptop te werken of als eerste backup bij ongevallen

Als er toch documentatie geschreven word, al dan niet op vraag van de opdrachtgever niet vergeten dat je daar ook iteratief aan kan werken, het is niet het waterval model en het moet niet in één keer juist en af zijn. Ik ken genoeg mensen die beginnen met _al_ hun use-cases op te stellen en _alle_ objecten eenmalig willen identificeren wat er dan later bvb toe leid dat ze methodes in objecten gaan creeëren die er helemaal niet thuishoren maar dat ze zeker zijn van hun stuk dat ze alles hebben dat ze geen nieuw object willen creeëren dat wel effectief die responsibilities toegewezen dient te krijgen.

If it ain't broken it doesn't have enough features

zondag 4 maart 2007 09:21

Acties:

zondag 4 maart 2007 13:20

Topicstarter

Ik heb al een account op Sourceforge aangemaakt, dus ik ben al in bezit van een SVN repository, bugtracking systeem en een developer forum. Verder was ik ook al van plan om te testen met unittesting, duidelijke variablenamen en functienamen en de code goed voorzien van commentaar. Ik ben verder zelf ook wel bewust van het feit dat ik documenten in sync moet houden met de code (en vice versa). Ik denk dat jullie even teveel aannames maken in de richting "hij heeft er geen klap verstand van", maar dat is logisch aangezien ik niks over mezelf heb verteld. Dat is mijn fout

Acties:

Verwijderd

Alarmnummer schreef op zondag 04 maart 2007 @ 02:37:
en mensen die hun code allemaal direct laten volgen uit een uml diagrammen verklaar is ter plekke voor gek. UML is leuk voor kennis overdracht, lekker kliederen, en zo nu en dan voor formele documentatie. Maar verder.. let it be.. techniek die totaal misbruikt wordt.

Zou je kunnen toelichten waarom je dit slecht vind? Wat is er mis mee om eerst je class diagram grotendeeld te ontwerpen, inclusief alle attributen en methodes en om vervolgens enkel de signatuur alvast te laten genereren?

zondag 4 maart 2007 13:24

Acties:

SeatRider

Hips don't lie

M-ThijZ schreef op zaterdag 03 maart 2007 @ 18:19:
Kies gewoon een ontwikkel methode die je goed ligt. Ga aub niet denken dat 'het zaakje snel in elkaar hacken' een oplossing is. Misschien is extreme programming een aanpak die je zal bevallen?

Extreme programming in je eentje? http://nl.wikipedia.org/wiki/Extreme_Programming

Nederlands is makkelijker als je denkt

zondag 4 maart 2007 14:20

Acties:

zondag 4 maart 2007 15:11

Als je shizofreen bent is dat geen probleem

Maar @ hierboven ergens dat test al groot deel documentatie is ben ik het niet mee eens.

Je documentatie verteld iets over je code, en met andere code kun je niet documenteren. Misschien met kleine makkelijke functies etc, maar met grotere code is dit echt niet te doen. Dan raak je ook absoluut de draad kwijt, tenzij je superman bent natuurlijk.

Acties:

zondag 4 maart 2007 15:13

-= Tja =-

Verwijderd schreef op zondag 04 maart 2007 @ 13:20:
[...]
Zou je kunnen toelichten waarom je dit slecht vind? Wat is er mis mee om eerst je class diagram grotendeeld te ontwerpen, inclusief alle attributen en methodes en om vervolgens enkel de signatuur alvast te laten genereren?

Deels omdat UML niet gemaakt is om op dit niveau te gaan werken en deels omdat je feedback mist. Ontwerpen van code is een organisch process, and alles eerst ontwerpen en dan uitgenereren is alles behalve organisch (waterval). Waterval gaat vaak mis doordat je feedback mist, je ontwerp is gebaseerd op gebrek aan kennis in het begin van het ontwerp (frozen ignorance).

Mensen die UML op code niveau gebruiken hebben het duidelijk niet begrepen!

Acties:

zondag 4 maart 2007 15:25

-= Tja =-

SeatRider schreef op zondag 04 maart 2007 @ 13:24:
[...]

Extreme programming in je eentje? http://nl.wikipedia.org/wiki/Extreme_Programming

extreme programming bevat goeie elementen, maar eigelijk heb ik zo mijn twijfels erover. Iedere methodiek die zo alles of niets te werk gaat, is in mijn boek geen verstandige methodiek.

Persoonlijk kijk ik liever naar een bredere set met methodieken: namelijk de hele agile hoek. Pak wat je nodig bent, en laat liggen wat je niet nodig bent. Per project krijg je dan weer een unieke combinatie met practices die je gebruikt.

ps:
zo nu en dan pairen vind ik erg handig. Maar ik heb er een hekel aan om het de hele tijd te doen.

[ Voor 11% gewijzigd door Alarmnummer op 04-03-2007 15:17 ]

Acties:

zondag 4 maart 2007 15:38

-= Tja =-

Depress schreef op zondag 04 maart 2007 @ 14:20:
Als je shizofreen bent is dat geen probleem

Maar @ hierboven ergens dat test al groot deel documentatie is ben ik het niet mee eens.

Je documentatie verteld iets over je code, en met andere code kun je niet documenteren. Misschien met kleine makkelijke functies etc, maar met grotere code is dit echt niet te doen. Dan raak je ook absoluut de draad kwijt, tenzij je superman bent natuurlijk.

Ben ik het niet helemaal mee eens. Je test voor een groot deel wat in je documentatie staat beschreven. Wil je de details zien van een stuk documentatie, kijk dan naar een test.

vb:
ik ben op dit moment bezig met een concurrency library, en per methode documenteer ik wanneer een interrupted exception ongeworpen kan worden. Als een thread al met een interrupt flag binnen komt., onder welke voorwaarden krijg je dan een interrupt exception?

vb;

Java:

public void await() throws Interruptedexception{
  if(open)
       return;

   mainLock.lockInterruptibly();
   try{
        while(!open)
           isOpencondition.await();
   }finally{
      mainLock.unlock();
   }
}

stel dat open op true staat, dan kan je meteen verder gaan (zonder een interrupted exception op te werpen). Deze functionaliteit test ik in mijn test, en voeg ik toe aan mijn documentatie.

Java:

void testOpen_startInterrupted(){
    latch = newLatch();
    //voer een await uit, en zorg er voor dat die thread zijn interrupt flag is gezet
    AwaitThread awaitThread = scheduleAwait(START_INTERRUPTED);
    joinAll(awaitThread);
    //controle dat er geen interrupt is geweest
    awaitThread.assertIsFinished();
    //controle dat de interrupt status wel is gebleven
    awaitThread.assertHasInterruptStatusAtEnd(true);
}

En dit leg ik ook vast in de documentatie:

code:

1	If the latch already is open, and the thread is interrupted, no interruptedexception is thrown.

Maar ik ben het met je eens dat je niet alles in tests kunt vastleggen omdat sommige documentatie ook uitleg bevat over hoe classes toegepast moeten worden, of waar je rekening mee moet houden, of wanneer andere classes een beter alternatief zijn.

[ Voor 15% gewijzigd door Alarmnummer op 04-03-2007 15:33 ]

Acties:

zondag 4 maart 2007 15:46

Topicstarter

Ik ga natuurlijk niet alle elementen van het XP proces gebruiken

Maar XP bevat wel elementen die ik kan gebruiken voor mijn eigen custom proces.
Ik zat namelijk eerst te kijken of ik een standaard kon toepassen, maar dat gaat in mijn geval niet lukken aangezien sommige standaarden vereisen dat je met een groep mensen samenwerkt. In mijn geval kan ik geen groep mensen samenstellen.

Deels omdat UML niet gemaakt is om op dit niveau te gaan werken en deels omdat je feedback mist. Ontwerpen van code is een organisch process, and alles eerst ontwerpen en dan uitgenereren is alles behalve organisch (waterval). Waterval gaat vaak mis doordat je feedback mist, je ontwerp is gebaseerd op gebrek aan kennis in het begin van het ontwerp (frozen ignorance).

Mensen die UML op code niveau gebruiken hebben het duidelijk niet begrepen!

Ik ben het hiermee eens. Je moet niet UML gaan gebruiken om alleen maar een class diagram te maken. Je moet eigenlijk met UML veel meer zaken vooraf doen voordat je een class diagram gaat maken. Vandaar dat ik ook van plan ben om Sequence diagrammen te maken aangezien je daar dingen in kwijt kan die je niet in een class diagram kan stoppen, zoals users, UI's en databases. Eigenlijk is dat ook niet genoeg, maar het moet er maar mee doorgaan.

Acties:

zondag 4 maart 2007 15:49

-= Tja =-

Comp_Lex schreef op zondag 04 maart 2007 @ 15:38:Ik ben het hiermee eens. Je moet niet UML gaan gebruiken om alleen maar een class diagram te maken. Je moet eigenlijk met UML veel meer zaken vooraf doen voordat je een class diagram gaat maken. Vandaar dat ik ook van plan ben om Sequence diagrammen te maken aangezien je daar dingen in kwijt kan die je niet in een class diagram kan stoppen, zoals users, UI's en databases. Eigenlijk is dat ook niet genoeg, maar het moet er maar mee doorgaan.

Lees mijn 1e opmerking over UML nog een keer goed door en kijk of je dit antwoord kunt rijmen met jouw antwoord.

Acties:

djluc

Is het commercieel bedoeld of is het gewoon een projectje voor je zelf waar je zo optimaal mee aan de slag wilt?

zondag 4 maart 2007 16:18

Acties:

zondag 4 maart 2007 16:49

Topicstarter

Het is eerst een projectje voor mijzelf, totdat het opvalt bij de massa. Dan sla ik waarschijnlijk een commerciele weg in.

Acties:

djluc

Dan gewoon de snelste manier kiezen. Je algoritmes/interfaces e.d. zijn waardevol. De code implementatie in principe niet. Met een kleine investering schrijf je het geheel mooi met documentatie mocht het opgepakt worden door de mass.

dinsdag 6 maart 2007 22:31

Acties:

Nick_S

++?????++ Out of Cheese Error

Comp_Lex schreef op zondag 04 maart 2007 @ 16:18:
Het is eerst een projectje voor mijzelf, totdat het opvalt bij de massa. Dan sla ik waarschijnlijk een commerciele weg in.

'Nae King! Nae quin! Nae Laird! Nae master! We willna' be fooled agin!'

woensdag 7 maart 2007 16:37

Acties: