• 1
  • 2
2009-12-06, 16:07
  #1
Medlem
Hur skall man tänka och koda för att undvika spagettikod?
Citera
2009-12-06, 16:09
  #2
Medlem
MissBs avatar
spagettikod?
Citera
2009-12-06, 16:36
  #3
Medlem
Citat:
Ursprungligen postat av MissB
spagettikod?
http://en.wikipedia.org/wiki/Spaghetti_code
Citera
2009-12-06, 16:58
  #4
Medlem
pikzels avatar
Bästa tipset är nog att tänka innan du börjar skriva koden. Om du kodar samtidigt som du funderar ut en lösning tenderar det att bli spaghettikod. Annars är det väl generellt bra att läsa lite om att återanvända kod och så.
Citera
2009-12-07, 01:02
  #5
Medlem
Börja med att skriva tester och skriv därefter kod som uppfyller testerna. Du kommer att märka att din kod snudd på automatiskt blir bättre designad när den är skriven för att kunna testas.
(korta versionen på svar )
Citera
2009-12-11, 21:09
  #6
Medlem
Vill du bara ha lite tips och pointers är det bra att sätta sig in i design patterns. Det finns massa böcker om detta. Ett bra boktips är Head first design patterns som är både rolig och innehållsrik.
Det bästa tipset är nog att försöka kolla in hur andra personer har gjort när de har skrivit något. Kolla runt på "the www".

Lite off topic men...
Vill du bli riktigt grym skall du lära dig mycket om utvecklings metoder och mjukvaru-design. Ian Sommerville har en bra bok i ämnet som heter Software Engineering. Denna bok tar upp en massa olika saker, kan nog vara lite "overkill". Behandlar allt från kravprocesser och implementation till testning och underhåll, m.m.

Andra bra böcker som snuddar ämnet är
The Pragmatic programmer
Kent Becks eXtreme Programming Explained

Lite info på wikipedia
http://en.wikipedia.org/wiki/Design_...mputer_science)
http://en.wikipedia.org/wiki/Softwar...opment_process

Lycka till
Citera
2009-12-12, 15:35
  #7
Medlem
seb-s avatar
Välskriven objektorienterad kod (lasagnekod ) är motsatsen till s.k. spagettikod. Nu kanske du undrar hur man skriver bra objektorienterad kod...ja, här följer ett par tips:

  • Skriv löskopplade komponenter som inte har några starka beroenden till [alla] andra klasser i systemet. På så sätt blir de enklare att enhetstesta och återanvända i andra miljöer.

  • Separera presentationen (gränssnittet) från affärslogiken och håll affärslogiken/affärsmodellen fri från externa system så som databaser, webbtjänster, o.s.v. Alltså strukturera din kod så att du har flera löskopplade lager. På så sätt blir det betydligt enklare att byta ut databaskopplingar (ex. byta från SQL till Oracle) och låta externa system integrera med ditt system, samt förstås blir det enklare att enhetstesta.

  • Undvik copy & paste-repetition av din kod. Använd basklasser för att ha en enda implementation, gärna i samband med generics (.NET) eller templates (C++). På så sätt slipper du rätta buggar och utföra underhåll på 17 olika ställen, och du återanvänder kod på ett mycket smidigare sätt.

  • Använd någon form av DI-container i din kod som ansvarar för de olika beroenden dina komponenter har och vill du byta ut en implementation mot en annan så görs det på ett enda ställe och en enda gång, och du slipper oroa dig för vem som instansierar vad, o.s.v.

  • Skriv kod som på ett snyggt och effektivt sätt försöker efterlikna den verkliga världen. När du skriver en klass eller komponent, tänk då på vilka egenskaper den faktiskt har i verkligheten och skriv din kod därefter. Detta är i synnerhet sant om du skriver affärsentiteter. Exempelvis en person i verkligheten har ett namn, efternamn, ålder/födelsedatum, födelseort, o.s.v. På samma sätt ska din Person-entitet ha dessa egenskaper (eller bara de som din implementation kräver).

Sedan kan jag rekommendera att du läser lite böcker och artiklar om bl.a. domän- och testdriven utveckling för att få lite mer insikt i vad jag avser med "löskopplat". Lycka till!
__________________
Senast redigerad av seb- 2009-12-12 kl. 15:37.
Citera
2009-12-17, 10:52
  #8
Medlem
kh31d4rs avatar
Citat:
Ursprungligen postat av seb-
Välskriven objektorienterad kod (lasagnekod ) är motsatsen till s.k. spagettikod. Nu kanske du undrar hur man skriver bra objektorienterad kod...

varför ska den vara objektorienterad? jag har då sett kod som inte varit ett dugg objektorienterad som varit strukturerad och prydlig, och jag har sett objektorienterad kod som varit fullständigt obegriplig pga att den varit rörig.
Citera
2009-12-19, 14:21
  #9
Medlem
seb-s avatar
Citat:
Ursprungligen postat av kh31d4r
varför ska den vara objektorienterad? jag har då sett kod som inte varit ett dugg objektorienterad som varit strukturerad och prydlig, och jag har sett objektorienterad kod som varit fullständigt obegriplig pga att den varit rörig.

http://en.wikipedia.org/wiki/Object-...ed_programming

Trodde det var ganska mainstream i dag att OOP är något som är det som gäller för 2000-talets programmering (i synnerhet med .NET ramverkets frammarsch) i de allra flesta fallen (kanske bortsett från viss spel- och hårdvaruutveckling). Objektorienterad kod är i praktiken mer läsbar, begriplig och lättförstådd om den nu förstås är skriven på ett snyggt sätt och läsaren förstår objektorienterad programmering. Med funktionsorienterad kod blir det inte lika lätt att återanvända kod eller skapa logiska relationer mellan olika kodstycken eller kodbitar; i stället blir det en massa copy & paste vilket försvårar underhållet. Vidare är det inte lika lätt att skriva abstrakt kod vilket underlättar för framtidsscenarion då produkten vidareutvecklas och utökas med ny funktionalitet och enhetstestning blir förstås nästintill omöjlig utan relativt små, löskopplade komponenter. Om man nu ens kan enhetstesta funktionsorienterad kod, d.v.s...

Och när du nämner "strukturerad och prydlig" funktionsorienterad kod och "fullständigt obegriplig och rörig" objektorienterad kod - kan du visa mig kodexempel på vad det är du avser?
Citera
2009-12-19, 15:21
  #10
Medlem
Weeblies avatar
Citat:
Ursprungligen postat av seb-
http://en.wikipedia.org/wiki/Object-...ed_programming

Trodde det var ganska mainstream i dag att OOP är något som är det som gäller för 2000-talets programmering (i synnerhet med .NET ramverkets frammarsch) i de allra flesta fallen (kanske bortsett från viss spel- och hårdvaruutveckling). Objektorienterad kod är i praktiken mer läsbar, begriplig och lättförstådd om den nu förstås är skriven på ett snyggt sätt och läsaren förstår objektorienterad programmering. Med funktionsorienterad kod blir det inte lika lätt att återanvända kod eller skapa logiska relationer mellan olika kodstycken eller kodbitar; i stället blir det en massa copy & paste vilket försvårar underhållet. Vidare är det inte lika lätt att skriva abstrakt kod vilket underlättar för framtidsscenarion då produkten vidareutvecklas och utökas med ny funktionalitet och enhetstestning blir förstås nästintill omöjlig utan relativt små, löskopplade komponenter. Om man nu ens kan enhetstesta funktionsorienterad kod, d.v.s...

Och när du nämner "strukturerad och prydlig" funktionsorienterad kod och "fullständigt obegriplig och rörig" objektorienterad kod - kan du visa mig kodexempel på vad det är du avser?

De flesta riktigt stora Open Source-projekt är skrivna i C (som bekant inte är ett OO-språk). För att bara nämna några: GCC, Apache HTTP Server, Python, X.Org Server

Problemet med OO är att man som utvecklare oftast överdesignar systemen. Välskriven OO-kod är per definition också "super generell", vilket kostar extra tid och arbete att implementera (och därmed blir kontraproduktiv).

En "Windows"-klass känns inte komplett om man inte kan ändra om storlek, position, transparens, Z-ordning, m.fl. Men kanske kommer man under hela projektets gång egentligen enbart att använda sig av "setPosition" och "getPosition"?

Alltför ofta gör OO att man försöker att designa sina objekt inför framtida krav. Och ärligt talat; hur många här brukar ta stora OO-komponenter från gammal kod in till nya projekt?

De flesta argumenten för OO passar minst lika bra in på att enbart skriva modulärt (vilket man gör i alla stora C-projekt). Det är sällan OO per sig (d.v.s. att man sätter objekt i fokus) som ger en kod av högre kvalitet.

Det enda undantaget som jag kan komma på och som där OO definitivt har sin plats är GUI-relaterad kod.
Citera
2009-12-19, 15:44
  #11
Medlem
"Spagettikod" är bara bullshit. Alla pratar om den men ingen har sett den. Jag har efterlyst verkliga exempel men inte fått se några.

Det är bara en sådan där verklighetsfrämmande sak som analfixerade muppakademiker tjatar om för att de inte har bättre vett.
Citera
2009-12-19, 15:59
  #12
Medlem
tror inte spagettikod är ett sådant problem längre, man har lärt sig att inte använda goto.

Här är ett exemepel i basic på ett väldigt enkelt program som man ändå inte kan se direkt vad det gör pga av goto:
Kod:
10 dim i
20 i 
0
30 i 
1
40 
if <> 10 then goto 90
50 
if 10 then goto 70
60 
goto 30
70 
print "Program Completed."
80 end
90 
print " squared = " i
100 
goto 30

Samma program i strukturerad programmering
:

dim i
for 1 to 10
    
print " squared = " square(i)
next
print "Program Completed."

function square(i)
    
square i
end 
function 

taget från http://www.experiencefestival.com/a/...les/id/5477896
ett av de översta resultatet på google när man sökte på spaggetikod exempel
__________________
Senast redigerad av acw 2009-12-19 kl. 16:05.
Citera
  • 1
  • 2

Skapa ett konto eller logga in för att kommentera

Du måste vara medlem för att kunna kommentera

Skapa ett konto

Det är enkelt att registrera ett nytt konto

Bli medlem

Logga in

Har du redan ett konto? Logga in här

Logga in