[Conny Westh]

Ursprungligen postat av Kimppa

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.)

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.

[Clarence]

Ursprungligen postat av ConnyWesth

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).

[dAEk]

Ursprungligen postat av Clarence

Minst sagt konstig syn på TDD [...]

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å.

[Clarence]

Ursprungligen postat av dAEk

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.

[dAEk]

Ursprungligen postat av Clarence

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.

[Clarence]

Ursprungligen postat av dAEk

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.

[dAEk]

Ursprungligen postat av ConnyWesth

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.

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.

Ursprungligen postat av ConnyWesth

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.

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?