[Conny Westh]

I avsaknad av bättrre begrepp så använder jag begreppet "Prpofessionell" resp "icke-professionell"-applikation i bemärkelsen "kvalitet", "skalbarhet", "integration", "transparens", "säkerhet", "förvaltningsbarhet", i just detta resonemang, rätt eller fel, men det är oftast ganska grundläggande krav på applikationer i de projekt jag jobbat med. Det är liksom implicita krav (BIASS) eller underförstådda krav som är så självklara att man i de sammanhangen inte ens diskuterar dem. Därav begreppet "professionella" v.s. "icke-professionella".

Jag ville lyfta fram:

- Hård typning
- Kompilering
- Objektorientering

Som viktiga begrepp för att höja elelr säkerställa kvaliten i applikationerna. Dit hör givetvis även en genomtänkt metodik.

"Kvalitet" kan inte "testas"-fram i en applikation.

Begreppet "kvalitet" måste vara med redan från krav, alanys och design. Sedan är begreppen "Hård typning, Kompilering och Objektorientering" en del av kvalitetsprocessen vid kodningengsprocessen.

Slutligen ska den designade kvaliten verifieras genom testningen, därför är det viktigt med kontinuerliga tester under hela utvecklingsprocessen. Metodiken är dock lika viktig oavsett vilka typer av programspråk som används.

Jag var noga med att INTE driva det här som något relionskrig om programspråk utan betonar vikten att använda sakliga argument för olika kvalitativa egenskaper på valet av utvecklingsmiljö.

Många programspråk finns implementerade under olika utvecklingsmiljöer och det finns olika "klassbibliotek" som kan kopplas ihop med respektive utvecklingsmiljö.

Trenden går mer mot att de olika utvecklingsmiljöerna går mot någon form av intermediate-språk på binärnivå som ligger i botten på flera utvecklingsmiljöer som exempelvis Javas byte-kod och .NET-plattformens "managed"-kod (Intermidiate Language). På sikt kommer vi troligen se någon typ av grundstandard för dessa. Så all kod som skapas av kompilatorer automatiskt kommer att fungera ihop med alla "semi-kompilerade" moduler från alla programspråk, givetvis exklusive native-kod.

Då kommer troligen alla programspråk att tvingas uppnå viss "gemensam" grundfunktionalitet och att de därutöver är helt problemorienterade.

[dotvoid]

Ursprungligen postat av ConnyWesth

Jag ville lyfta fram:

- Hård typning
- Kompilering
- Objektorientering

Som viktiga begrepp för att höja elelr säkerställa kvaliten i applikationerna. Dit hör givetvis även en genomtänkt metodik.

"Kvalitet" kan inte "testas"-fram i en applikation.

Jag håller inte med alls. Jag håller med om att kvalitet är något som måste vara med hela vägen. Testningen är definitivt en oerhört viktig del i kvalitetsarbetet. Jag håller absolut inte med om att kvalitet kräver hård typning, kompilering eller objektorientering. Jag håller med om att det finns fördelar i många situationer.

Ursprungligen postat av ConnyWesth

Jag var noga med att INTE driva det här som något relionskrig om programspråk utan betonar vikten att använda sakliga argument för olika kvalitativa egenskaper på valet av utvecklingsmiljö.

Bra. För jag gillar ju inte sånt Jag har jobbat med (programmerat både systemen i sig och integration) av ekonomi- och logistiksystem som används av riktigt stora företag (Campbells Soup, Kelloggs, Telenor, Vodafone, etc) byggda i skittråkiga uråldiga språk/verktyg som definitivt hör en annan tidsålder till enligt mig. Lustigt nog skapar utvecklare funktionalitet i en fantastisk hastighet med mycket hög kvalitet mha dessa språk. Jag har sett stora konsultföretag försöka ersätta dessa system med moderna objektorienterade fina blanka bling-bling-system och misslyckas fatalt. Det beror på att språken och verktygen är skapade för ett syfte.

Detsamma med PHP. PHP skapades för ett visst syfte och passar alls inte överallt. Det finns ett visst bagage som är mindre smickrande men erfarna programmerare undviker allt detta vilket oerfarna inte gör. Vad gäller .NET har jag i de miljöer jag rör mig inte ännu sett ett bra exempel. Därför kan jag inte säga något om .NET oavsett det rör sig om C# eller annat språk.

Det är alltså inte språket i sig som löser problem. Det är personer, metodik och hur man använder sig av språket och verktygen kring det. Jag tror (hoppas) egentligen att vi är rätt överens där. Dessutom har jag nog aldrig sett ett seriöst (professionellt?) system som inte över tid byggs upp av många olika delar i olika språk. Få system kan förbli isolerade.

[Conny Westh]

Ursprungligen postat av dotvoid

Jag håller inte med alls. Jag håller med om att kvalitet är något som måste vara med hela vägen. Testningen är definitivt en oerhört viktig del i kvalitetsarbetet. Jag håller absolut inte med om att kvalitet kräver hård typning, kompilering eller objektorientering. Jag håller med om att det finns fördelar i många situationer.

Vad jag menar med att man inte kan "testa fram kvalitet" är att:

- Det går inte att testa fram kvalitet i en applikation som i grunden har en bristfällig design, eller bristfällig utvecklings-/produktionsmiljö.

Testning är givetvis OEHÖRT viktigt för att säkerställa den PLANERADE kvaliten. Men om man inte planerar för en viss kvalitet så kan inte testningen lösa det problemet. Testningen kan två saker:

- Dels verifiera att den planerade kvaliteten blir den leverade kvaliteten
- I begränsad omfattning upptäcka vissa oönskade sidoeffekter som man inte tänkt på

Problemet med testningen är att den kan aldrig höja systemets kvalitet över den nivå som systemet är planerat och designat för. För att uppnå en bättre kvalitet måte man helt enkelt gå tillbaks till ritbordet och göra om designen. I vissa fall måste man gå tillbaks så långt som till kraven.

I vissa fall till och med designa om verksamheten i sig eftersom man hittat brister i den grundläggande verksamheten. Då kan inget system i världen rädda den verksamheten hur väldesignat det än är.

[danjel]

Ursprungligen postat av ConnyWesth

I avsaknad av bättrre begrepp så använder jag begreppet "Prpofessionell" resp "icke-professionell"-applikation i bemärkelsen "kvalitet", "skalbarhet", "integration", "transparens", "säkerhet", "förvaltningsbarhet", i just detta resonemang, rätt eller fel, men det är oftast ganska grundläggande krav på applikationer i de projekt jag jobbat med. Det är liksom implicita krav (BIASS) eller underförstådda krav som är så självklara att man i de sammanhangen inte ens diskuterar dem. Därav begreppet "professionella" v.s. "icke-professionella".

Jag ville lyfta fram:

- Hård typning
- Kompilering
- Objektorientering

Som viktiga begrepp för att höja elelr säkerställa kvaliten i applikationerna. Dit hör givetvis även en genomtänkt metodik.

"Kvalitet" kan inte "testas"-fram i en applikation.

Begreppet "kvalitet" måste vara med redan från krav, alanys och design. Sedan är begreppen "Hård typning, Kompilering och Objektorientering" en del av kvalitetsprocessen vid kodningengsprocessen.
...

Jag har svårt att se bra argument för detta, dvs att "Hård typning" och "Kompilering"
har något med de kvalitetsaspekter du lyfter fram..man måste se till sammanhanget vilken typ av applikation man utvecklar..

Har det något att att göra med "skalbarhet"..? Nej, varför skulle det det? Skalbarhet är oberoende av teknikvalet i sig.

"Kvalitet" ett väldigt otydligt begrepp i sig, vad menar man, att det skulle vara färre "buggar"
i hårt typade kompilerade program? De buggar som är svåra och dyra att lösa har inget att göra med kod som inte kompilerar eller "datatyp" relaterade buggar ..

Den i särklass viktigaste kvalitetsfaktorn är ofta "väldesignade" program dvs genomtänkt skiktning av en applikation i olika lager och korrekt användande av objekt orienterade principer för att hantera affärslogiken ..det löser ofta per automatik dessa punkter:
"kvalitet", "skalbarhet", "integration", "transparens", "säkerhet", "förvaltningsbarhet"...

[Conny Westh]

Ursprungligen postat av danjel

Jag har svårt att se bra argument för detta, dvs att "Hård typning" och "Kompilering"
har något med de kvalitetsaspekter du lyfter fram..man måste se till sammanhanget vilken typ av applikation man utvecklar..

Jag har gett en enkel argumentation hur "Hård typning" respektive "Kompilering" ger betydande fördelar vid utvecklingsarbete lite tidigare i denna tråd. det går bra att läsa tråden från början så klaranar nog ett och annat argument. Annars är du välkommen att komma med SAKLIGA argument varför du anser att "Hård typning" respektive "Kompilering" inte har något med kvalitet i utvecklingsarbetet att göra.

Jag har aldrig läst eller hört någon som kommit fram med ett enda sakligt argument.

Ursprungligen postat av danjel

Har det något att att göra med "skalbarhet"..? Nej, varför skulle det det? Skalbarhet är oberoende av teknikvalet i sig.

Det var väl dagens dummaste kommentar; "Skalbarhet har inget med teknikvalet att göra!", MY GOD, vet du vad du pratar om över huvud taget???

Ursprungligen postat av danjel

"Kvalitet" ett väldigt otydligt begrepp i sig, vad menar man, att det skulle vara färre "buggar"
i hårt typade kompilerade program? De buggar som är svåra och dyra att lösa har inget att göra med kod som inte kompilerar eller "datatyp" relaterade buggar ..

Kvalitet är ett mångfacetterat begrepp, jag gjorde tt förtydligande vad jag anser hör till begreppet kvalitet, det är inte uteslutande av andra kvalitetsaspekter, men en delmängd.

Man fokuserar på olika kvalitetsaspekter i olika projekt, men jag räknade upp någr aav de mest elementära som jag stöter på i många av de projket jag arbetar med.

Ursprungligen postat av danjel

Den i särklass viktigaste kvalitetsfaktorn är ofta "väldesignade" program dvs genomtänkt skiktning av en applikation i olika lager och korrekt användande av objekt orienterade principer för att hantera affärslogiken

Just det, det är det jag resonerat kring hela tiden.....

Ursprungligen postat av danjel

..det löser ofta per automatik dessa punkter:
"kvalitet", "skalbarhet", "integration", "transparens", "säkerhet", "förvaltningsbarhet"...

Målet är: "kvalitet", "skalbarhet", "integration", "transparens", "säkerhet", "förvaltningsbarhet".

Strategin för att nå målet är: Genomtänkta program med god struktur!