Projektstruktur med programmering i fokus (m. PHP som exmpel)
 

Hej,

Lite kort:
Sitter väldigt ofta med många projekt som inte alls behöver vara något komplext. Mitt problem är nog att "allt ska vara perfekt" innan jag är nöjd med det och känner att detta är något jag skulle vilja publicera. Eftersom jag kommer utgå från PHP i mina exempel (då det är mest känt för mig, vilket också innebär att det kommer vara mer åt webbutvecklingshållet) så hoppas jag inte, att det på något sätt påverkar vad det är ja vill komma fram till.

Låt oss ta ett HTML dokument som ett exempel.

Det är uppbyggt ungefär så här: (doctype) html, head, body, html-slut

För de som jobbar eller jobbat med webbutveckling så programmerar man oftast inte hela projektet i samma fil, utan delar upp det i olika filer samt mappar. Jag har tidigare och använder mig fortfarande av "includes" för att lägga in html/head/title etc och avsluta mina dokument med en "end-include".

Nu har jag börjat funderat på att programmera i något typ av Objekt Orienterad Programmering PHP och kom fram till följande idag, och undrar om det är ett sätt som folk arbetar på, eller om det är så man ska arbeta (kanske man inte är så norsk, skämt åsido)?

PHP-koden (som kanske räknas som objektorienterad?):
HTML-koden:
Resultatet:
En paragraf.

Kan detta vara ett bra tillvägagångssätt om man har flera projekt man arbetar med?
HTML element används ju dagligen på webbsidor, så att ha fördefinierade funktioner för det, är det bra?

Vill ni dela med av er hur ni försöker få era projekt så organiserade så som möjligt.. med fokus på programmering?

Din kod bör ha så lite sidoeffekter som möjligt. Du bör m.a.o inte printa ut något i din metod.

Jag använder ramverk. Både på klientsidan (bootstrap) och serversidan (Django).

Att bygga ett eget ramverk, som jag tolkar det som att du gör, kan ha sina fördelar och nackdelar. Fördelarna är att du kan precis all kod i ditt ramverk. Nackdelen är att du får ingenting byggt åt dig och bedömt inte samma säkerhet eller kodkvalité som du hade fått om du hade valt ett större ramverk.

Om det är just html-output du vill pyssla med, så lyssna på CotopaXi: använd ett befintligt ramverk.

Är det något annat du är ute efter så får du nog förtydliga frågan lite :)

Det kan vara trevligt att bygga ett eget ramverk också men OM man inte är 100% säker på att det endast kommer att användas av en själv så bör det dokumenteras noga allteftersom (det är tråkigt och bökigt att dokumentera kod i efterhand). Fördelen med att bygga eget är framför allt att man kan göra det mer effektivt och slipper allt onödigt som man inte använder. Det är också bra träning men kanske inte det första man ska ge sig på :)

En trevlig medelväg är att bygga ett "eget" ramverk utgående från komponenter i exempelvis Symfony där man enkelt man göra sig av med allt man inte vill använda:

http://fabien.potencier.org/article/...ponents-part-1

Det går alldeles utmärkt att bygga sitt eget ramverk. Primärt gör man det för att långsiktigt effektivisera utvecklingsjobbet och höja kvaliteten på sin egen kod.

Det går givetvis att använda ett befintligt ramverk, men då lär man sig inte så mycket, dessutom måste man först lära sig ett antal olika ramverk för att testa vilket som passar bäst för ens behov.

Jag har alltid som utgångspunkt att bygga egna ramverk för min kod. Men jag kanske börjar med top-down-modell i stället för en bottom-up-modell.

Dvs jag tänker ut de funktionella komponenter jag vill använda och sen löser jag det tekniska efter hand som det behövs, med stegvis förfining, det har funkat för mig (men jag varierar mig så vissa tekniska komponenter bygger jag också bottom-up).

Skilj ut de komponenter som är till för att kapsla in HTML så de går att återanvända oavsett vilken typ av funktionell komponent du använder.

Det funktionella är ju oftast det som skiljer mellan de projekt man bygger.

Ska du bygga ett HTML-ramverk på ett bra sätt så bör du tänka på att Element är en generalisering av exemplevis DIV, BODY, HEAD mfl taggar. Det betyder att om man vill vara ortodox inom objektorientering så ska DIV vara en egen klass, PARAGRAF en egen klass m.m.

Man kan ju i BODY lägga många olika DIV och DIV kan vara nästade i varandra.

Skilj även på detaljklasser och listklasserna, det är inte samma sak, då det är helt olika egenskaper på listor och detalj/informationsklasser.

Det kan vara en hög tröskel att få till ett användbart ramverk, men när man väl har rätt struktur så blir det kollosalt enkelt att använda, bygga ut och modifiera, det är enligt min mening mycket av det som är poängen med objektorientring.

Där håller jag inte med.
Om man använder ett bra ramverk och verkligen sätter sig in i hur det fungerar(läser källkoden) lär man sig väldigt mycket, men framför allt lär man sig rätt. De flesta ramverk prioriterar best practices och hög kvalitet i koden så långt det är möjligt vilket gör att lär sig att skriva bra kod själv när man utökar och utvecklar i ramverket. Det finns inte, åtminstone inte enligt mig, något bättre sätt att lära sig än att kolla på bra kod och använda den om man vill lära sig rätt och skriva bra kod.

Givetvis lär man sig mycket att experimentera och bygga eget också, men risken är att man då lär sig fel och får dåliga vanor när man kodar. Börjar man med ett ramverk utan väldigt goda kunskaper om mjukvaruarkitektur så kommer man mes största sannolikhet också få skriva om hela ramverket eller kasta det när man blivit en duktigare utvecklare. Det är inget jag kan rekommendera oavsett vilken kunskapsnivå man ligger är på. Jag egentligen inte någon poäng med att skriva egna ramverk från grunden alls. Det är ett enormt jobb att hålla sitt egna ramverk modernt och up to date.

En väldigt intressant trend är det som tartareandesire skrev om ovan, dvs att man plockar komponenter ifrån olika ramverk och på så sätt syr ihop ett eget ramverk där man plockat de bästa modulerna för varje uppgift. I och med att Composer blivit en standard kan man numera på ett väldigt smidigt sätt hantera dessa beroenden och uppdatera komponenterna separat från sin egen "app"- eller "core"-kod. Man får då både extremt flexibel kod som man har väldigt mycket kontroll över samtidigt som den inte är så jobbig att underhålla. Modulerna uppdateras löpande av tredje part och har redan bra dokumentation vilket förenklar enormt mycket.

Givetvis har man en stor fördel av att kika på annan kod, men du måste först hitta ett ramverk som heter duga och har bra kod från grunden. Det finns många ramverk som är halvmesyrer och som visar på många dåliga kodvanor som inte är objektorienterade alls.

Men i princip så håller jag med dig om att man ska titta på andras bra kod för att lära sig mer.

Men man behöver ändå skriva sitt eget ramverk för de applikationer man skriver. Jag har alltid en grund att jobba vidare med så jag skapar "wrappers" runt vissa externa klasser som jag vill kunna byta ut utan att skriva om hela min kod.

Men det är viktigt att skapa sin struktur så man bygger applikationerna i "komponenter" så man inte gör sig beroende av externa ramverk som man inte har kontroll på. Detta gäller mer för större applikationer. Gör man bara ganska små applikationer, där den egna koden är minimal i relation till den totala kodmassan, så kan man givetvis ha stor hjälp av att enbart använda tredjeparts-ramverk.

Men om du ligger i framkant i den tekniska utveckling av kodstandards kan man inte använda externa ramverk, de bygger ju på gammal känd teknik. Skriver man miljontals rader applikationskod så kan det hända att man har behov av nya sätt att tänka som inte tillverkarna av ramverken tänk på eller implementerat ännu. Då måste man ha egna ramverk. Därmed inte sagt att all kod måste vara egen, man kan mycket väl som Tartaren skriver blanda efter det som passar äst, dvs använda best practices. Men man jobbar med några viktiga principer:

- Objektorientring så långt det är möjligt
- Komponenttänkande
- Återanvändning i tanken redan från början (dvs använd gärna befintliga ramverk om det adderar värde)
- Wrappers kring klasser som kan tänkas behöva bytas i ett senare skede
- Skilj på tekniska ramverk och domänspecifika/verksamhetsspecifika ramverk
- Använd best practices
- Börja på en grov nivå och använd stegvis förfining
- Förbättra den egna koden kontinuerligt
- Var konsekvent
- Skapa ditt eget ramverk utifrån best practices (bygg gärna vidare på andras ramverk som du gillar)
- Utveckla din egen kompetens och jobba aktivt för at skapa nya sätt att tänka

Detta är generella principer som kan tillämpas på alla (av mig kända) objektorienterade programspråk (inkl PHP, Ruby, Python, C#, C++, mfl).

Jag håller inte heller riktigt med. Det är väldigt sällan det finns anledning att skriva sitt eget ramverk. I väldigt specifika och annorlunda applikationer eller väldigt intensiva och förhållandevis enkla applikationer är det försvarbart. Men annars finner jag det alltid bättre att använda ett väl underhållet och strukturerat ramverk istället för att försöka göra jobbet som 10-tals personer gjort under en lång tidsperiod själv.

Dock är det ju viktigt att ramverket är flexibelt och har en bra struktur där du faktiskt kan byta ut delar mot dina egna komponenter. I vissa språk är sådana ramverk väldigt sällsynta och där går jag ifrån min syn på det. Men så fort du rör dig i populära OSS-språk som PHP så har du flertalet bra alternativ. Oavsett om du vill ha ett väldigt lätt ramverk eller ett väldigt komplett så har du bra ramverk som är lätta att utöka/förändra och har gjort 90% av grovjobbet åt dig.

T ex skulle du säkerligen om du valde ett bra ramverk komma in på tanken att skapa HTML direkt via objekt är en klumpig och komplicerande practice. Visst finns det edge cases där det kan vara smidigt - men i de allra flesta fall skapar det mycket ont till liten nytta.

Med det sagt är det ingen skada att skapa ett eget ramverk för att utöka sin egen kompetens. Men det är förhållandevis dödfött att bli ett bra ramverk de första åren om man inte haft erfarenhet av välskrivna ramverk och hur de underlättar ditt arbete.

Väldigt intressanta diskussioner!

Jag kodar i mestadels PHP.

Tycker ConnyWesth tänker ganska precis som jag tänker och var ungefär vad jag menade med denna tråd.

Jag har inte menat at skriva "superavancerade" ramverk utan enklare ramverk för att skriva ut början av t.ex. HTML-dokument (då jag inte applikationsutvecklar) och även slutet för HTML dokumentet.

För tillfället så använder jag mig av två PHP-funktioner för de flesta av mina projekt (enklare projekt) och de är:

1. Skriver ut allt från DOCTYPE till början på BODY.
(Brukar göra någon custom header som jag kan använda mig av i första fuktionen, oftast väldigt olikt designade)
2. Avslutar andra funktionen med </BODY> och eventuell "close" av databas.

Jag har länge tänkt på detta med klasser och PHP men aldrig riktigt förstått mig på det.

Om jag fårstår dig rätt Conny:
- Skulle det vara möjligt att skapa en klass som skapar html_start->html-end, för att sedan i PHP-dokumentet (med själva webbplatsstrukturen) kunna klistra in metoder/objekt/funktioner från denna klass?

Eller är de bättre att strukturera upp det som jag gjort tidigare?

EDIT: Jag använder mig av "ramverk" ungefär på samma sätt som templates/mallar i Word, när jag kodar CSS med speciella margins för headers, text, etc. (som går att återanvändas i olika projekt för bra artiklar etc.)

Tror det är lättare att förklara om jag skriver "kod-aktigt":

PHP-dokument (Om detta är klasser från ett "funktionsdokument"):

Vet inte hur bra det där är skrivet men skulle det vara möjlit att göra något sådant? Ser väldigt bökigt ut för tillfället men man kanske bara måste hitta sitt eget.

Sen kommer man ju självklart alltid få skriva vissa funktioner/metoder för projekt men hade tänkt det som en bas för HTML i första hand.

Jag föredrar att inte använda fördefinerade ramverk då jag hellre söker och försöker lösa problemen själva. Det kanske är dumt och tar längre tid men ser programmering som en hobby.

En kock kanske har en egen kockbok ;) (ändrar mig till amatörkock då jag sa hobby innan) :P

För mig känns det som att du försöker skriva en templating engine, i PHP. Sånt är trevlig, men ska jag säga, det finns flertalet sådana, i mikro till giganter.

Om du på en vanliga simpel PHP sida vill wrappa en header och footer med potentiella variabler, så skulle jag skapa en PHP-fil, som styrs av en PHP-class och metoder samt argument till metoderna. Du sätter då default-argument, som kan överstyras vid behov.

Grovt exempel

På så sätt så har du iaf möjlighet att i framtiden överstyra alla sidor i ett nafs.

Fast, jag kanske helt missförstått och repeterar vad andra sagt :)

Menar du att du vill styra CSS via PHP-objekt? Om jag vore du så skulle jag verkligen försöka separera frontend och backend så väldigt mycket som är praktiskt möjligt. Det blir både lättare att underhålla och att vidareutveckla. Det betyder att du använder SASS/Stylus/* om du behöver "ramverk" för CSS. Använder du det också för templates så är det enklaste att du använder ett väl utvecklat template-språk. Du har enklare versioner såsom mustache och handlebars (finns till många språk) eller mer välutvecklade versioner som twig, smarty, dwoo (dessa är alla endast för PHP såvitt jag vet) etc. Använder du någon av de mer utvecklade versionerna är det desto enklare att utöka med egna taggar och plugins. Du får då en bra översikt av din HTML och samtidigt möjligheten att utöka den med flexibel kod där det behövs.

Bra liknelse med en kock, jag gillar att laga mat. Ska jag laga något mer utförligt jag inte har en aning om hur jag ska gå tillväga med så lagar jag från olika recept de första gångerna... då har jag lite koll på vilka ingredienser som kan passa och kan ett par variationer som funkar. Då har man en bra utgångspunkt att variera och förändra ifrån.

Skriver för övrigt recipes rätt mycket just nu, fått till ett bra gäng riktigt användbara cookbooks som jag laddar upp med min knife. Har också planer på att börja använda ett test kitchen. På tal om matlagning :)

Tror du är inne på rätt spår..

Jag brukar använda en "View" klass ,
som hanterar olika template filer.

T.ex kan en sid template se ut så här:

<div>
<h1><?php echo $this->h1 ;?></h1>
<p><?php echo $this->content;?></p>
</div>

Sidans controller instansierar ett objekt

$page= new View("sida1.php");
$page->content = "Innehållet";
$page->h1 ="header";

Och sen brukar jag ha en template för själva layouten, det binds samman så här rent principiellt typ:

$master= new View("Master.php");

$master->content = $page->render();


Master.php :

<head>
<title>test</title>
</head>
<body>
<main><?php echo $this->content;?></main>
</Body>


Det är även bra att undvika att skapa objekt direkt från en controller , så det ser ut så här i praktiken..

class Page extends \MyLib\ControllerAbstract
{

public function index()
{

$this->view->h1 = "h1";
$this->view->content = "xx..";

$this->masterView->doc_title = " dokument titel "; // bra om man även kan modifiera master sidan direkt så här typ

return $this->view; // $this->view är en instans av "View" klass
}

}

Om du tänker verksamhetsspecifikt (domain-driven-development, DDD) så kan man bygga en uppsättning klasser som följer strukturen på "verksamheten" eller "domänen". Helt utan koppling till HTML över huvud taget.

Sen kopplar man ihop det hela med "tekniska" klasser som lägger på HTML-taggar där det behövs.

Man kan givetvis koppla ihop detta med en rad andra externa ramverk efter tycke och smak.

Det finns dessutom olika skiktningsmodeller:

MVC - Model-View-Controller (Gammal modell som använts i mer än 20 år)

eller

MVVM Model-View-ViewModel (Modernare variant som anpassats till många olika GUI-device). Se http://en.wikipedia.org/wiki/Model_View_ViewModel för mer info.

Det finns en annan paradigm som kallas test-driven-utveckling (TDD) men den har ett grundläggande tankefel, det går nämligen aldrig att "testa" fram bra kvalitet i en applikation. Kvaliteten måste man designa in från början genom att ha järnkoll på arkitekturen och verksamhetens krav, det är inte testerna som är kraven som många TDD förespråkare hävdar.

Jag är som sagt mer anhängare av DDD-paradigmen med arkitekturell design.

Givetvis ska man testa koden utförligt, men det är inte alltid möjligt att testa allt man behöver testa genom automatiska tester, det skulle kosta för mycket att bygga såna automatiska tester, så projektet skulle bli olönsamt. Man behöver en kombination av automatiska testrutiner och manuella för att optimera ekonomin i projekten.

Minst sagt konstig syn på TDD, du borde testa att jobba med det ett par dagar så du får lite bättre koll på det. Dels så går det alldeles utmärkt att tillämpa både DDD och TDD i samma projekt. Precis som TDD passar med i princip alla andra utvecklingsmetoder eller patterns förutom riktigt kass kod. TDD har inget med din design att göra, även om dålig design är svår att testa ordentligt.

Det finns heller ingen pragmatisk TDD-förespråkare som säger att du ska ha 100% code coverage eller för den delen inte använda andra testmetoder.

Med MVVM ska man tänka på att den inte fått så stor spridning ännu. En annan potentiell uppstickare är HMVC. Både är värda en titt om man tycker att MVC-modellen har brister för en speciell applikation (tänk på att många MVC-ramverk i princip låter dig använda HMVC).

Det beror på vad din definition av kvalitet är. Är det t.ex. löst kopplade komponenter, abstraktion och tydlig separation? I så fall: jo, det kan man visst.

Tillsammans utgör ju testerna en levande spec av systemet och det inkluderar verksamhetens krav. Klart att man måste ha koll på verksamhetens krav, det är ju det man ska bygga och skriva tester för! Eller fattar jag inte vad du menar?

Så tänkte jag också men så lät jag det sjunka in lite. :)
Skall man vara strikt skall ju TDD forma koden och det verkar krocka med DDD som jag förstår det. Det kanske är det Conny menar?

Tester kan man såklart ha i DDD också.

Håller inte med. Läser du ut TDD som en test driven design så har du gått ifrån dess ursprungliga mening och borde därmed ta tid att förklara vad du menar.

Jag menar inte att man kan strunta i arkitekturen utan mer att man har den i åtanke när man kodar. I TDD utgår man (läs. jag) från testerna, klasserna designas löpande i takt med att beroenden tillkommer; DDD verkar ha vissa förutbestämda klossar som man utgår från. Vet inte om min bild är skev men det är så jag ser på det.

Såsom jag ser det förändrar det bara vad och hur man testar. Du testar inte states utan beteende. Det finns mycket att läsa om kombinationen TDD DDD - dess svårigheter och best practices. Det finns även en mängd exempel-projekt på github som ger lite hints om man är mer praktiskt lagd.

Dock skulle jag vilja säga att DDD sällan (dvs mer än aldrig men mindre än ofta!) är sunt och TDD alltid är sunt.