mboost-dp1

unknown
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
'One week after i released Emacs, i got an mail saying: "I found a bug, heres a fix".
And another one saying: "Heres a file that add's a new feature".
And anther, and another, until they where pouring in on me.
Even making use all the help i was getting was huge job.
Microsoft doesn't have this problem...'
--Richard Stallman
And another one saying: "Heres a file that add's a new feature".
And anther, and another, until they where pouring in on me.
Even making use all the help i was getting was huge job.
Microsoft doesn't have this problem...'
--Richard Stallman
I mine øjne er den oplagte forklaring en bedre process i OSS miljøet. I samme øjeblik kildekode gøres tilgængelig svarer det til et grundigt code-review. Brug af code-reviews er gang på gang påvist at højne kvaliteten. Der er desværre bare alt alt for få projektledere der har boller nok til at afsætte tid til bedre udviklingsprocesser.
#2:
Øh? Hvad har RS citatet med debugging at gøre??? Udover måske at debugging bliver gjort af andre hvis man er heldig?
#2:
Øh? Hvad har RS citatet med debugging at gøre??? Udover måske at debugging bliver gjort af andre hvis man er heldig?
Pally: Ja, problemet er snarere at de fleste proprietære udviklingsfirmaer idag ikke er uptodate med udviklingprocessor og brandslukning i høj grad præger projekterne.
Og er man allerede nået til brandslukning, så har man simpelthen ikke tid/overskud til at få foretaget et grundigt code-review.
Ikke at OSS projekter er bedre hvad angår udviklingsprocesser, men de har en fordel på dette punkt at alle kan debugge sourcekoden. Det jeg så oplever på dette punkt er at man typisk kun gidder debugge det som vedrører en selv .. altså har man fundet en fatal fejl, som man er nød til at ha fixet, så bruger man tiden på at finde frem til den og få den rettet, men man gennemgår ikke sourcekoden/projektet systematisk.
Jeg er overbevist om at et betalt code-review af et 3. parts firma vil afdække en langt størrer mængde af bugs i projektet på kortere tid end ved OSS software.
Problemet er bare at de færreste firmaer invistere tid og penge til at få disse reviews foretaget.
Men jeg tror en del firmaer modnes meget kraftigt i disse år, der er meget stor fokus på udviklingsprocesser på studierne idag og inden al for længe tror jeg vi vil se flere udviklingsfirmaer der nærmer sig CMM Niveau 3, hvor vi i Danmark pt. kun har Systematic på det niveau.
Og er man allerede nået til brandslukning, så har man simpelthen ikke tid/overskud til at få foretaget et grundigt code-review.
Ikke at OSS projekter er bedre hvad angår udviklingsprocesser, men de har en fordel på dette punkt at alle kan debugge sourcekoden. Det jeg så oplever på dette punkt er at man typisk kun gidder debugge det som vedrører en selv .. altså har man fundet en fatal fejl, som man er nød til at ha fixet, så bruger man tiden på at finde frem til den og få den rettet, men man gennemgår ikke sourcekoden/projektet systematisk.
Jeg er overbevist om at et betalt code-review af et 3. parts firma vil afdække en langt størrer mængde af bugs i projektet på kortere tid end ved OSS software.
Problemet er bare at de færreste firmaer invistere tid og penge til at få disse reviews foretaget.
Men jeg tror en del firmaer modnes meget kraftigt i disse år, der er meget stor fokus på udviklingsprocesser på studierne idag og inden al for længe tror jeg vi vil se flere udviklingsfirmaer der nærmer sig CMM Niveau 3, hvor vi i Danmark pt. kun har Systematic på det niveau.
Pally:
Der er også alt for mange der ikke udfører codereviews ordentligt.
Hos en tidligere arbejdsgiver var der tvunget code review af alt, og de foregik normalt sådanne her
Brian:Hej john kan du lige review dette kode
John:yep,
--John kigger hurtigt på koden
John:Det er okay
Slut. Det skal siges at John ikke nødvendigvis havde det fjerneste kendskab til den del af koden.
Desværre er der for mange projektledere der går får meget op i deadlines og for lidt op i kvalitet :(
Der er også alt for mange der ikke udfører codereviews ordentligt.
Hos en tidligere arbejdsgiver var der tvunget code review af alt, og de foregik normalt sådanne her
Brian:Hej john kan du lige review dette kode
John:yep,
--John kigger hurtigt på koden
John:Det er okay
Slut. Det skal siges at John ikke nødvendigvis havde det fjerneste kendskab til den del af koden.
Desværre er der for mange projektledere der går får meget op i deadlines og for lidt op i kvalitet :(
@Pally
Det siger du næsten selv.
Ved at lave fri adgang, er der mange der ar mulighed for at kigge det igennem.
Og selvom mange kun retter de ting de selv finder generende, så ER der faktisk mange der finder det interessant at vedligeholde et projekt og hjælpe maintaineren.. ;)
Det siger du næsten selv.
Ved at lave fri adgang, er der mange der ar mulighed for at kigge det igennem.
Og selvom mange kun retter de ting de selv finder generende, så ER der faktisk mange der finder det interessant at vedligeholde et projekt og hjælpe maintaineren.. ;)
#7
Nu kløver jeg måske ord her, men RS siger i en af hans sædvanligt bombastiske udtalelser at han har fået meget konstruktivt feedback pga. den generelle tilgængelighed. Det har intet med *debugging* at gøre. Hans kode kunne stadig meget vel være forfærdeligt at debugge.
Pointen er at hvis man som udvikler (eller designer for den sags skyld) ved at ens kode/dokumentation/design skal underkastes et ordenligt review, det være sig internt, externt; ja så laver man ud fra almindelig faglig stolthed et bedre stykke arbejde.
Reviews er en PROCESS der forbedrer kodens kvalitet, blandt andet dens læselighed og dermed dens 'debuggelighed' (SHEESH! Find et godt dansk ord for det...). OSS i sig selv indfluerer ikke på denne kvalitet.
Nu kløver jeg måske ord her, men RS siger i en af hans sædvanligt bombastiske udtalelser at han har fået meget konstruktivt feedback pga. den generelle tilgængelighed. Det har intet med *debugging* at gøre. Hans kode kunne stadig meget vel være forfærdeligt at debugge.
Pointen er at hvis man som udvikler (eller designer for den sags skyld) ved at ens kode/dokumentation/design skal underkastes et ordenligt review, det være sig internt, externt; ja så laver man ud fra almindelig faglig stolthed et bedre stykke arbejde.
Reviews er en PROCESS der forbedrer kodens kvalitet, blandt andet dens læselighed og dermed dens 'debuggelighed' (SHEESH! Find et godt dansk ord for det...). OSS i sig selv indfluerer ikke på denne kvalitet.
#8 Pally
"Nu kløver jeg måske ord her, men RS siger i en af hans sædvanligt bombastiske udtalelser at han har fået meget konstruktivt feedback pga. den generelle tilgængelighed. Det har intet med *debugging* at gøre. Hans kode kunne stadig meget vel være forfærdeligt at debugge."
Teoretisk set ja.
Men der er sjældent ret mange der gider hacke på projekter hvor det er alt for spaghetti-agtig kode.. ;)
"Pointen er at hvis man som udvikler (eller designer for den sags skyld) ved at ens kode/dokumentation/design skal underkastes et ordenligt review, det være sig internt, externt; ja så laver man ud fra almindelig faglig stolthed et bedre stykke arbejde."
Ja selvfølgelig.
"Reviews er en PROCESS der forbedrer kodens kvalitet, blandt andet dens læselighed og dermed dens 'debuggelighed' (SHEESH! Find et godt dansk ord for det...). OSS i sig selv indfluerer ikke på denne kvalitet."
Nej det er på sin vis rigtigt.
Men for at kunne tiltrække hjælp, er det nødvendig at skrive pæn og overskuelig kode.
Hvis man ikke gør det vil du enten ikke få nogen hjælp, eller også bliver dit projekt forked og skrevet ordentligt af en anden.. ;)
"Nu kløver jeg måske ord her, men RS siger i en af hans sædvanligt bombastiske udtalelser at han har fået meget konstruktivt feedback pga. den generelle tilgængelighed. Det har intet med *debugging* at gøre. Hans kode kunne stadig meget vel være forfærdeligt at debugge."
Teoretisk set ja.
Men der er sjældent ret mange der gider hacke på projekter hvor det er alt for spaghetti-agtig kode.. ;)
"Pointen er at hvis man som udvikler (eller designer for den sags skyld) ved at ens kode/dokumentation/design skal underkastes et ordenligt review, det være sig internt, externt; ja så laver man ud fra almindelig faglig stolthed et bedre stykke arbejde."
Ja selvfølgelig.
"Reviews er en PROCESS der forbedrer kodens kvalitet, blandt andet dens læselighed og dermed dens 'debuggelighed' (SHEESH! Find et godt dansk ord for det...). OSS i sig selv indfluerer ikke på denne kvalitet."
Nej det er på sin vis rigtigt.
Men for at kunne tiltrække hjælp, er det nødvendig at skrive pæn og overskuelig kode.
Hvis man ikke gør det vil du enten ikke få nogen hjælp, eller også bliver dit projekt forked og skrevet ordentligt af en anden.. ;)
"Hvis man ikke gør det vil du enten ikke få nogen hjælp, eller også bliver dit projekt forked og skrevet ordentligt af en anden.. ;)"
Herligt koncept .. som igen betyder en usikkerhed for ens projekter i OSS verdenen, self. gælder også i den proprietære verden at folk kan kopiere koncepter fra dit projekt (ligger det for meget op af, bryder det dog copyrightloven), men i OSS verdenen giver man ligefrem konkurrenten byggeklodserne.
Så ka du jo påstå at det ikke er en konkurrent (at alle hjælper alle og bla bla hippi 70'er tankegang :o)), men virkeligheden er nok for de fleste at de føler sig godt og grundigt taget i røven hvis der kommer en og smider en bedrer udgave på markedet af ens produkt og dermed i hovedtræk overtager konceptet.
#8: Enig, det minder faktisk om mange af de rapporter der er kommet frem på det sidste .. nu tænker jeg specielt på "Open Source er mere stabilt!" og nu også "Open Source er altid hurtigst at debugge!" .. så vidt jeg kan se svarer det lidt til at sige at en hvid mand altid har flest penge. Altså, at man holder 2 ting op imod hinanden, der ikke nødvendigvis har nogen sammenhæng.
Herligt koncept .. som igen betyder en usikkerhed for ens projekter i OSS verdenen, self. gælder også i den proprietære verden at folk kan kopiere koncepter fra dit projekt (ligger det for meget op af, bryder det dog copyrightloven), men i OSS verdenen giver man ligefrem konkurrenten byggeklodserne.
Så ka du jo påstå at det ikke er en konkurrent (at alle hjælper alle og bla bla hippi 70'er tankegang :o)), men virkeligheden er nok for de fleste at de føler sig godt og grundigt taget i røven hvis der kommer en og smider en bedrer udgave på markedet af ens produkt og dermed i hovedtræk overtager konceptet.
#8: Enig, det minder faktisk om mange af de rapporter der er kommet frem på det sidste .. nu tænker jeg specielt på "Open Source er mere stabilt!" og nu også "Open Source er altid hurtigst at debugge!" .. så vidt jeg kan se svarer det lidt til at sige at en hvid mand altid har flest penge. Altså, at man holder 2 ting op imod hinanden, der ikke nødvendigvis har nogen sammenhæng.
#10 Sguft
["Hvis man ikke gør det vil du enten ikke få nogen hjælp, eller også bliver dit projekt forked og skrevet ordentligt af en anden.. ;)"
Herligt koncept .. som igen betyder en usikkerhed for ens projekter i OSS verdenen, self. gælder også i den proprietære verden at folk kan kopiere koncepter fra dit projekt (ligger det for meget op af, bryder det dog copyrightloven), men i OSS verdenen giver man ligefrem konkurrenten byggeklodserne.]
Hvis et projekt ikke kører i en retning brugerne kan lide eller udviklerne er ved at køre et projekt i sænk, er det da fair nok hvis en eller flere af dem forker det i den retning der passer dem.. ;)
Fortalere for properitært lukket software, vil sikkert pege fingre af denne aktivitet.
Men nu er det vi gør ikke noget vi selv har fundet på.
Det har mange paralleler i den virkelige verden.
Det drejer sig om at tage de sunde og fornuftige dele, og bruge dem i et nyt projekt.
[Så ka du jo påstå at det ikke er en konkurrent (at alle hjælper alle og bla bla hippi 70'er tankegang :o)), men virkeligheden er nok for de fleste at de føler sig godt og grundigt taget i røven hvis der kommer en og smider en bedrer udgave på markedet af ens produkt og dermed i hovedtræk overtager konceptet.]
Det måde fri software samfundet arbejder på, er meget lig den naturlige måde vi mennesker altid har udviklet os.
Faktisk har denne måde rødder lang tid før hippitiden, hvis endelig vi skal snakke på det plan.
Den properitære lukkede tankegang derimod hvor alle har sig selv nærmest, begyndte først at vinde alvorligt indpas i midten/slutningen af halvfjerserne.. ;)
["Hvis man ikke gør det vil du enten ikke få nogen hjælp, eller også bliver dit projekt forked og skrevet ordentligt af en anden.. ;)"
Herligt koncept .. som igen betyder en usikkerhed for ens projekter i OSS verdenen, self. gælder også i den proprietære verden at folk kan kopiere koncepter fra dit projekt (ligger det for meget op af, bryder det dog copyrightloven), men i OSS verdenen giver man ligefrem konkurrenten byggeklodserne.]
Hvis et projekt ikke kører i en retning brugerne kan lide eller udviklerne er ved at køre et projekt i sænk, er det da fair nok hvis en eller flere af dem forker det i den retning der passer dem.. ;)
Fortalere for properitært lukket software, vil sikkert pege fingre af denne aktivitet.
Men nu er det vi gør ikke noget vi selv har fundet på.
Det har mange paralleler i den virkelige verden.
Det drejer sig om at tage de sunde og fornuftige dele, og bruge dem i et nyt projekt.
[Så ka du jo påstå at det ikke er en konkurrent (at alle hjælper alle og bla bla hippi 70'er tankegang :o)), men virkeligheden er nok for de fleste at de føler sig godt og grundigt taget i røven hvis der kommer en og smider en bedrer udgave på markedet af ens produkt og dermed i hovedtræk overtager konceptet.]
Det måde fri software samfundet arbejder på, er meget lig den naturlige måde vi mennesker altid har udviklet os.
Faktisk har denne måde rødder lang tid før hippitiden, hvis endelig vi skal snakke på det plan.
Den properitære lukkede tankegang derimod hvor alle har sig selv nærmest, begyndte først at vinde alvorligt indpas i midten/slutningen af halvfjerserne.. ;)
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.