Hur kommer man i mål med ett programmeringsprojekt?

Har du några tips på hur man lyckas få färdigt ett program?

Det finns säkerligen 1000 gånger mer påbörjade programprojekt jämfört med hur många som slutförts.

Vad bör man tänka på när man drar igång för att komma imål?
Vad skall man tänka på under tiden utvecklingen sker och hur slutför man det?

B

Ett program som är användbart för en större grupp personer, men folk får gärna visa lite kreativitet och tolka det själva

vb: Helt klart är det så, många av de utvecklingsmiljöer som företag saluför fokuserar också väldigt hårt på att det skall vara lätt och "komma igång". Innan Visual C++ 1.0 kom ut på marknaden så var det Borland som regerade, men så kom Visual C++ 1.0 och den hade något som kallades för "App Wizard", det var en guide som snabbt skapade upp skalet för ett program och det var otroligt säljbart.

Idag när de saluför utvecklingsmiljöer så handlar det ofta och att underlätta kodande, själva inknappandet av kod skall vara så enkelt som möjligt vilket egentligen bara lurar användaren för att knacka kod är oftast en rätt liten del och det finns alltid klipp och klistra vilket räcker väldigt långt.

Eftersom det är så lätt och komma igång så tänker man inte till innan utan får göra det i efterhand och det tar MYCKET längre tid och rätta en felaktig design av koden när man hållit på ett tag i jämförelse med att tänka till innan.

Några tips om hur man kommer i mål:

- Försök skaffa någon testare och som använder programmet
Gör minsta möjliga, kanske med endast en användbar funktion och försök få några och använda sig av ditt program. Det blir mycket roligare för programmerarna om det som de gör används samtidigt som de får input om vad som fungerar eller inte fungerar. En programmerare brukar ogilla kraftigt och sitta och testa sitt eget program som en användare med så det slipper man.

- Du kommer att skriva ditt program två gånger (MINST)
Har du aldrig gjort ett sådant program som du nu ger dig på att göra så VET DU INTE hur du skall göra. Först gången du gör programmet så lär du dig, när du gjort programmet första gången så har du lärt dig hur du SKULLE ha gjort och då börjar du skriva programmet på riktigt. Lägg därför ner minimalt med tid på första versionen, skit och dokumentera mer än nödvändigt och ödsla inte för mycket tid på lösningar eller buggrättningar. Skjut från höften och se hur det blir, det är ändå bara lärokod.
Att försöka sitta och bygga programmet från det första man gjort är dömt och misslyckas om programmet bara är något större.

- Använd versionshanteringssystem

- Se till och ha roligt
En programmerare som trivs med jobbet är säkerligen tio gånger mer produktiv än en som inte trivs.
Det är inte roligt och rätta svåra buggar, det är inte roligt och rätta ANDRAS buggar.
Det är däremot roligt och bygga nytt, det är roligt och skriva rätt.
Försök tänka på detta när designen görs av koden. Förstår man hur spagettikod undviks och kan utnyttja objektorienterad struktur så bygger en programmerare nytt hela tiden. Det krävs kanske 10% mer arbete när viss typ av funktionalitet läggs till med det tjänar man igen många gånger om. Delar i programmet kan lyftas bort och bytas ut mot annat nyskrivet.

- Var mycket noga med att skriva självdokumenterande kod
Hur ofta läser du kommentarer?? Nästan aldrig skulle jag gissa. Programmerare läser inte kommentarer, de läser kod. Enda gången man läser kommentarer är när variabler och andra namn är så fruktansvärt dåligt skrivna så de är omöjliga och förstå.
Lägg inte in onödiga kommentarer och försök att separera kommentarerna från koden. En komplicerad funktion bör ha en bra beskrivning innan funktionen börjar.
Självdokumenterande kod innebär att man lägger ner lite tid på namnen, vad en funktion heter, vad ett objekt kallas eller namn på variabler.

- Skriv lättläst och välstrukturerad kod
Programmerare och förmodligen du läser kod, det är koden som fokus ligger på och därför är det mycket viktigt att denna är lättläst och välstrukturerad. I C++ går det och skriva 20 rader som kan ta timmar och tyda. Programmeraren som gjort dem tycker kanske han/hon varit jättesmart med lösningen men den fungerar inte eftersom ingen orkar lägga ner tiden på att förstå. Kommer någon annan och hittar en bugg så kommer de skriva om eller möjligen ta bort funktionaliteten.
Tänk alltid på att du inte skriver koden för att du skall kunna läsa den, du skriver koden för andra.

Varför skall man sitta och gräva i OSS-projekt?

Jo jag har läst massor av källkod.
Syftet med tipsen var annars att få färdigt ett projekt, är man fem involverade personer i projektet samt att de har så dålig koll på vad andra gör samt kodar så illa att det krävs rikligt med dokumentation så kommer de med 100% säkerhet att misslyckas få färdigt programmet.

Bidra? Vill man bidra med andra projekt så självklart måste man gräva i kod men tråden handlade om att gå i land med eget projekt.

Skall man gå iland med opensource (hur många har gjort det...) så vet man nog rätt bra hur det skall gå till om man nu vill gå iland med ett sådant projekt. I princip alla de saker jag beskrev måste då vara uppfyllda och utöver det så bör man ha bra dokumentation (open source kräver mer diciplin än "privata" projekt). Oftast är det annars så att någon suttit och hållt på med ett projekt så kanske någon annan kunnig programmerare börjat använda det och så har den även börjat bidra med kod.
Sitter ju inte direkt folk på kö och väntar på att få hjälpa till

Skrev jag det? jag skrev att man skall dokumentera men det viktigaste är att koden är självdokumenterande.
Mycket vanligt är annars när det är flera som kodar om man dokumenterat att dokumentationen inte stämmer med koden eftersom någon ändrat i efterhand och kanske inte tänkt på att uppdatera dokumentationen.

OT:
det kallas för diskussion, vid en diskussion så har man inte alltid samma åsikt. ibland kan saker missförstås m.m. då brukar man påpeka, jag uppskattar om någon påpekar om jag har fel med men tar mig även rätten och försvara åsikter vilket inte är samma sak som jag inte kan bli överbevisad.
Det är alltid viktigt och ifrågasätta sin åsikt om man vill komma frammåt.
Har bara arguemterat mot(?) en sak vilket igentligen inte är någon motargumentation

När det gäller kommentering så är det självklart mycket bra, man kan aldrig kommentera förmycket (tror jag), men samtidigt är det viktigt att ett projekt är roligt och att koden är bra skriven. Är man flera som kodar ihop och någon inte fattar samt då får svaret "läs i kommentarerna" eller möjligen att den läser men kommentarerna inte är uppdaterade så är det ett problem.
Programmerare brukar heller inte gilla och dokumentera mer än nödvändigt.

Själv brukar jag använda ett verktyg som heter doxygen för mina kommentarer och skriver rätt mycket sådana. detta eftersom doxygen kan skapa upp väldigt mycket genom att parsa koden och plocka ut saker.

Det borde även innebära att de kodar illa, kan man inte se på själva källkoden vad som görs utan måste ha kommentarer för att fatta trots att man jobbar i samma projekt så behöver de få riktlinjer om hur man skriver kod som är lättläst.

Själv lägger jag alltid mycket tid på att ge variabler rätt namn, att klasser mm också får bra namn och tillämpar en variant av hungarian notation.

Kan man vara bra systemarkiktet utan att programmera? Och det måste vara trist för programmerarna och inte få delta i designen av koden fast känner till att om det är konsulter från flera bolag som jobbar med system så får det ibland bli lite andra regler än vad som är optimalt för att få fram produkten.

En teoretiker som läst på massa designer av kod och bara har lite programmeringsvana som sitter och designar kod finns nog stor risk att det kanske inte blir så bra som han/hon tror.

Helt ok! Självklart är detta ett ämne som jag kan en hel del om då det är ett stort intresse, är man intresserad så söker man ju alltid mer information för det går aldrig och bli fullärd. Men samtidigt så ser man chanser till och berätta en del grejjer som är viktiga och tänka på om man inte vill lära sig den "hårda vägen".

fog och Phod:

Hur känslig får man lov och bli, tycker man någon har fel så tyck det. Ibland käftar man emot men går det inte och ändra så lämna det bara.
Tänk om alla skulle bry sig så mycket som en del som råkar få lite kritik angående val av språk ibland kan bli, de skulle inte få hålla på med annat än att bry sig.

En känslig javaprogrammerare tröttnar nog på det "tjatet" efter ett inlägg, frågan är varför personen läser och tar åt sig