mboost-dp1
Microsoft udvikling og klassiske tools
Et lille indspark til hvem, hvordan og hvorledes man er mest effektiv. Blandt andet om man skal bruge fancy GUI tools, eller editor og ikke mindst omkring managed code.
Det hele set fra MS folk synspunkt.
http://www.computerworld.com/s/article/9141465/Mic...
Faktisk meget hyggelig læsning, og måske og en stærk indikator at man ikke bare kan sige C# er bedst eller VS08 altid at foretrække.
Det hele set fra MS folk synspunkt.
http://www.computerworld.com/s/article/9141465/Mic...
Faktisk meget hyggelig læsning, og måske og en stærk indikator at man ikke bare kan sige C# er bedst eller VS08 altid at foretrække.
Med GUI tools menes der automatiske værktøjer til f.eks. at genere kode ud fra UML.
Forstå dem ret, et IDE er stadig at foretrække fordi det jo stadigvæk i bund og grund er en text-editor (og Visual Studios er den bedste af dem alle), med en række ekstra værktøjer til versionsstrying som ER vigtigt.
Og det kommer da heller ikke bag på nogen at sige "right tool for the right job". Det er typisk de folk som IKKE koder C# der ikke forstår den del.
Bare kig på Linux, og se hvor mange nørder der stadigvæk skriver userland GUI tools i C, for at optimere så programmet kører 2 millisekunder hurtigere, men med resultatet at ingen kan genbruge deres kode :p
Forstå dem ret, et IDE er stadig at foretrække fordi det jo stadigvæk i bund og grund er en text-editor (og Visual Studios er den bedste af dem alle), med en række ekstra værktøjer til versionsstrying som ER vigtigt.
Og det kommer da heller ikke bag på nogen at sige "right tool for the right job". Det er typisk de folk som IKKE koder C# der ikke forstår den del.
Bare kig på Linux, og se hvor mange nørder der stadigvæk skriver userland GUI tools i C, for at optimere så programmet kører 2 millisekunder hurtigere, men med resultatet at ingen kan genbruge deres kode :p
#3
Det ville ikke overraske mig, Visual Studio's text editor har mange features fra Emacs, blandt andet 2-tast genvejene, som f.eks. Ctrl+E, F
Jeg undre mig stadig over alle de Java folk som absolut vil lave de genveje om til Eclipse genveje med ReShaper.
Men selvom man er glad for Emacs, vil jeg stadig mene at debuggers, versions-styring integration (Team Server i Emacs?), og lign. værktøjer er ret vigtige for struktureret udvikling.
Jeg kan ikke se problemet i at samle ens værktøjer i samme platform (= Visual Studio) , frem for at benytte forskellige værktøjer til hver ting (Emacs, SVN via. Terminal, random debugger værktøjer til forskellige sprog, bla bla bla.)
Det ville ikke overraske mig, Visual Studio's text editor har mange features fra Emacs, blandt andet 2-tast genvejene, som f.eks. Ctrl+E, F
Jeg undre mig stadig over alle de Java folk som absolut vil lave de genveje om til Eclipse genveje med ReShaper.
Men selvom man er glad for Emacs, vil jeg stadig mene at debuggers, versions-styring integration (Team Server i Emacs?), og lign. værktøjer er ret vigtige for struktureret udvikling.
Jeg kan ikke se problemet i at samle ens værktøjer i samme platform (= Visual Studio) , frem for at benytte forskellige værktøjer til hver ting (Emacs, SVN via. Terminal, random debugger værktøjer til forskellige sprog, bla bla bla.)
Windcape (4) skrev:
Men selvom man er glad for Emacs, vil jeg stadig mene at debuggers, versions-styring integration (Team Server i Emacs?), og lign. værktøjer er ret vigtige for struktureret udvikling.
Jeg kan ikke se problemet i at samle ens værktøjer i samme platform (= Visual Studio) , frem for at benytte forskellige værktøjer til hver ting (Emacs, SVN via. Terminal, random debugger værktøjer til forskellige sprog, bla bla bla.)
Hvilke af de ting som du nævner er ikke tilgængelige i Emacs?
Windcape (4) skrev:
Jeg undre mig stadig over alle de Java folk som absolut vil lave de genveje om til Eclipse genveje med ReShaper.
Hvis det er JetBrain's værktøj du snakker om er det ReSharper ikke ReShaper.
Jeg tvivler en del på at det er Eclipse genvejene der er skyld i at folk bruger det.
Det er ikke engang nævnt på:
http://www.jetbrains.com/resharper/index.html
Jeg har aldrig selv prøvet ReSharper, men jeg ved at Jon Skeet flere gange har anbefalet produktet, så jeg tror på at det giver noget brugbart,
På et niveau jeg synes er acceptabelt, alle de ting jeg nævnede.arne_v (5) skrev:Hvilke af de ting som du nævner er ikke tilgængelige i Emacs?
Og så har jeg slet ikke nævnt ulemperne ved Emacs ;)
http://clausjoergensen.dk/media/files/ym.jpg
Ups ja, tastefejl.arne_v (6) skrev:Hvis det er JetBrain's v;rktøj du snakker om er det ReSharper ikke ReShaper.
Det som er godt i ReSharper er dets refactoring værktøjer. Men mange vælger det også fordi det får Visual Studio til at "være" Eclipse/IDEA, noget jeg ikke bryder mig om, da jeg lærte Visual Studio før Eclipse.
Og jeg synes at Jon Skeet er farvet på samme måde. Folk kan bedst lide at arbjede på den måde de kender, og vil helst ikke lære noget nyt. Det er forståeligt, men for os som så lærer Visual Studio først, så er Java udviklernes tankegang om hvordan et IDE skal fungere, ret fjernt.
Vi har fået en fuld licens til ReSharper fra skolen, men jeg bryder mig som sagt ikke om det, da det sløver mit IDE alt for meget ned.
Og modsat mange andre, kan jeg godt lide et responsivt IDE. Jeg kan virkelig ikke forstå hvordan folk kan holde Eclipses langsomme autocomplete ud.
Microsoft's top developers prefer old-school coding methods
Oversæt til
Microsoft's oldest developers prefer old-school coding methods
Min far vil også helst kode COBOL direkte på serveren i OS/400 uden nogen form for versions-styring eller dokumentation. Det har han gjort i 30 år. Så hvorfor laver om på det.
Ikke et overbevisende argument, hvis man spørger mig.
Danske Bank er f.eks. også for nyeligt gået over til IBM Rational (Eclipse), for at få bedre versions-styring og refactoring værktøjer til deres udviklere, som før brugte en terminal til OS/400.
Hvad man vi så udlede af det?
P.S. Er distinguished engineer stadigvæk "lav hvad du mener er bedst for dit firma" ?
Windcape (8) skrev:Oversæt tilMicrosoft's oldest developers prefer old-school coding methods
Min far vil også helst kode COBOL direkte på serveren i OS/400 uden nogen form for versions-styring eller dokumentation. Det har han gjort i 30 år. Så hvorfor laver om på det.
Jeg synes ikke at den beskrivelse passer specilet god til de herrer: Don Box, Jeffrey Snover og Butler Lampson.
WCF og PowerShell er jo ikke ligefrem gamle teknologier.
For meget arbejde, og for lidt respons, i forhold til et mere grafisk orienteret værktøj.arne_v (9) skrev:Hvad mener du konkret er problemet med SVN og GDB integrationen i Emacs?
Nu er PowerShell jo også lavet til små batch jobs, og ikke enorme løsninger med tusinde linjers kode.arne_v (10) skrev:WCF og PowerShell er jo ikke ligefrem gamle teknologier.
Jeg ser ingen fordele i deres ideer om "gamle" kode metoder. Kun at det kræver mere indlæring, mere at huske på, mere manuelt arbejde, og mere spildt tid. Samt at det slet ikke harmonere med store skærme og hurtigere maskiner.
Windcape (11) skrev:
WCF og PowerShell er jo ikke ligefrem gamle teknologier.
Nu er PowerShell jo også lavet til små batch jobs, og ikke enorme løsninger med tusinde linjers kode.
Min pointe var at de ikke var gået i stå.
Windcape (11) skrev:
Jeg ser ingen fordele i deres ideer om "gamle" kode metoder. Kun at det kræver mere indlæring, mere at huske på, mere manuelt arbejde, og mere spildt tid. Samt at det slet ikke harmonere med store skærme og hurtigere maskiner.
Jeg kan heller ikke se nogen fordel ved dem.
Men man skal bare ikke gå og tro at smarte værktøjer gør en stor forskel.
Altså man skal ikke gå og tro at Emacs i stedet for Notepad gør en forskel?arne_v (13) skrev:Men man skal bare ikke gå og tro at smarte værktøjer gør en stor forskel.
Vi snakker smartere værktøjer, som erstatter i forvejen smarte værktøjer.
Og hvis man ikke tror på at bedre værktøjer gør en forskel, hvordan kom vi så nogen sinde ud af stenalderen?!?
Windcape (14) skrev:Altså man skal ikke gå og tro at Emacs i stedet for Notepad gør en forskel?
Den er formentlig også beskeden.
Problemet i software udvikling er ikke at skrive kode.
Don Box ville formentligt være mere produktiv med notepad end 95% af udviklerne med VS 2010.
I et andet spørgsmål henviste jeg til nogle videnskabelige undersøgelser af produktivitet. Fra hulkort til GUI IDE har givet en forøgelse på 33% i produktivitet. Forskellen mellem en middelmådig IDE og en god IDE er minimal.
Windcape (14) skrev:Og hvis man ikke tror på at bedre værktøjer gør en forskel, hvordan kom vi så nogen sinde ud af stenalderen?!?
Måske værktøjer har en større betydning for produktion af diverse våben, bygninger etc. end for software udvikling.
#16
God pointe. Betydningen af IDE ved skrivning af ny kode er minimal, men de kan være en stor hjælp ved vedligeholdelses arbejde - både til at skaffe sig overblik og til at lave konsistente multi fils rettelser.
Den med mindre fejl tror jeg ikke på. Der skrives stadig masser af kode med fejl i. IDE'er fanger stort set kun de samme fejl som compileren også fanger.
God pointe. Betydningen af IDE ved skrivning af ny kode er minimal, men de kan være en stor hjælp ved vedligeholdelses arbejde - både til at skaffe sig overblik og til at lave konsistente multi fils rettelser.
Den med mindre fejl tror jeg ikke på. Der skrives stadig masser af kode med fejl i. IDE'er fanger stort set kun de samme fejl som compileren også fanger.
Samt at man typisk kan klare sig med mindre kendskab til det overordnet system. Og at det hjælper meget til at lære systemet dybere at kende.arne_v (17) skrev:God pointe. Betydningen af IDE ved skrivning af ny kode er minimal, men de kan være en stor hjælp ved vedligeholdelses arbejde - både til at skaffe sig overblik og til at lave konsistente multi fils rettelser.
Object-Browseren i Visual Studio er ihvertfald ret så handy ;-)
Rigtigt, men i visse systemer kan man jo ikke kompilere uden videre.arne_v (17) skrev:IDE'er fanger stort set kun de samme fejl som compileren også fanger.
Og jeg ville altså ikke være glad for at skulle bruge 5 minutter på at finde ud af at jeg manglede et semi-kolon på linje 95.
Jeg kan ikke forestille mig at kode uden syntax highlighting.
Ved pilot-udvikling til indlæring af nye teknologier, som f.eks. WPF, WCF eller lign. finder jeg stadigvæk mit IDE som en betydelig styrke.arne_v (17) skrev:Betydningen af IDE ved skrivning af ny kode er minimal,
Det minimere hvor meget det er nøvendigt at lære før man kan begynde at være produktiv med en ny teknologi, eller nyt API.
Windcape (18) skrev:Rigtigt, men i visse systemer kan man jo ikke kompilere uden videre.
Der er nogle problemer hvis man udvikler på et andet system end hvor koden skal compiles.
Men det betraget jeg som et problem ved det valgte/givne setup.
Windcape (18) skrev:
Og jeg ville altså ikke være glad for at skulle bruge 5 minutter på at finde ud af at jeg manglede et semi-kolon på linje 95.
Jeg kan ikke forestille mig at kode uden syntax highlighting.
Du kan sikkert ikke forestille dig det.
Men du ville sikkert hurtigt kunne vænne dig til det.
Det er ikke så svært.
Windcape (19) skrev:Ved pilot-udvikling til indlæring af nye teknologier, som f.eks. WPF, WCF eller lign. finder jeg stadigvæk mit IDE som en betydelig styrke.
Det minimere hvor meget det er nøvendigt at lære før man kan begynde at være produktiv med en ny teknologi, eller nyt API.
Det kan være lidt farligt at bruge sin IDE's forslag til at kode udfra. Nogen gange skal man altså sætte sig idt ind i hvad det er man laver.
For et par timer siden var der en i cljp som havde brugte Eclipse til at hjælpe sig til at få noget kode skrevet og var end op med:
date.set(Calendar.YEAR, 2007);
date.set(Calendar.MONTH, 4);
date.set(Calendar.DAY_OF_MONTH, 30);
og fik nogle ikke forventede resultater.
(for de ikke Java kyndige: en eller anden valgte i sin tid at lade måneder i Java være 0 baseret, således at måned 4 er May ikke April)
Jeg kan dog ikke se pointen i at vænne sig til det.arne_v (20) skrev:Du kan sikkert ikke forestille dig det.
Men du ville sikkert hurtigt kunne vænne dig til det.
Det er ikke så svært.
Hvorfor gøre ting besværligt, bare fordi man kan?
Nogen gange tror jeg altså at folk vælger "hacker" løsninger, fordi det virker mere sejt at gøre det på den besværlige gammeldags måde.
Rent pragmatisk er der jo ingen jordisk grund til at ikke have syntaks highlighting. Man kan finde highlighters til selv de mest obskure sprog.
Windcape (22) skrev:Jeg kan dog ikke se pointen i at vænne sig til det.
Hvorfor gøre ting besværligt, bare fordi man kan?
Når du har vænnet dig til det er det ikke specielt besværligt.
Windcape (22) skrev:
Nogen gange tror jeg altså at folk vælger "hacker" løsninger, fordi det virker mere sejt at gøre det på den besværlige gammeldags måde.
Rent pragmatisk er der jo ingen jordisk grund til at ikke have syntaks highlighting. Man kan finde highlighters til selv de mest obskure sprog.
Jo, men den dag eller måske kl. 4 om morgenen hvor de skal fixe en bug over en ekstrem langsom telnet på et system hvor en totalt standard vi er eneste editor, så er det godt at kunne.
Been there, done that. (Dengang jeg udviklede i PHP).arne_v (24) skrev:Jo, men den dag eller måske kl. 4 om morgenen hvor de skal fixe en bug over en ekstrem langsom telnet på et system hvor en totalt standard vi er eneste editor, så er det godt at kunne.
Men at vænne sig til det, er jo implicit at man gør det HELE TIDEN, i stedet for kun en sjælden gang imellem.
Var det størrere ændringer, ville jeg mene at et versionsstyring system er på plads, og så er det ligegyldigt hvilken editor man benytter ;-)
Hans fejl for ikke at bruge sit IDE godt nok ;-)arne_v (25) skrev:Men han kiggede altså ikke på tooltip.
Plus, ikke at bruge sin debugger godt nok. En god debugger kan lave solskin på regnvejsdage. (*indsæt kritik af Eclipses debugger her*).
Windcape (26) skrev:Var det størrere ændringer, ville jeg mene at et versionsstyring system er på plads, og så er det ligegyldigt hvilken editor man benytter
Version stsyring skal bruges uanset om det er større ændringer eller kun et enkelt tegn som ændres, men derfor skal ændringen stadig laves.
Det som jeg finder underligt er at når man snakker udviklings værktøjer så kommer der altid en masse kritik af emacs. Men det sjove er jo netop at emacs kan det samme som VS08, det gør det bare på en anden måde.
For nogle er VS08 det rigtige, men vi er altså en del som arbejder mest effektivt i emacs, og det hænger jo nok sammen med at mennesker er forskellige og vi tænker på forskellige måder. Nogle folk tænker projekter i linier af kode, andre i objekter og nogle igen tænker i meget grove bokse af funktionalitet. Det er sådanne ting der indvirker på hvordan man har det med et udviklings værktøj.
I et projekt jeg arbejder på er der emacs, vim, eclipse, vs08 og sikkert også nogte andet hejs, Vi compiler og tester til 3 forskellige platforme, og der er ikke noget der gør at man kan sige at den ene gruppe af folk laver flere fejl end den anden, eller er mindre/mere effektive. Det at vi compiler til 3 forskellige platforme, gør faktisk at vores kode får en meget høj kvalitet da der er mange små nemme ting man ikke lige må.
Og som mest væsentlige faktor, det er ikke indtastningen af programlinierne der tager den store mængde tid. Her er det algoritme, datastrukturere, arkitektur (high/low),filtre og andre ting som tager den store arbejdsindsats.
Og som der også bliver pointeret i artiklen, så hjælper det jo ikke noget at kun kan køre med ABS, hvis man ikke altid har det.
Derudover er det jo fint vi kan højne abstraktionen for vildt, men det er jo ikke gratis og artiklen indikere også lidt at de her gutter rent faktisk tror på at der kommer et punkt hvor abstraktion bliver et negativt ord igen. Hvilket jeg synes er meget interessant fordi det kan godt være det gør man hurtigere kommer 80% af vejen,men det er ikke det samme som man kommer hurtigere alle 100%.
For nogle er VS08 det rigtige, men vi er altså en del som arbejder mest effektivt i emacs, og det hænger jo nok sammen med at mennesker er forskellige og vi tænker på forskellige måder. Nogle folk tænker projekter i linier af kode, andre i objekter og nogle igen tænker i meget grove bokse af funktionalitet. Det er sådanne ting der indvirker på hvordan man har det med et udviklings værktøj.
I et projekt jeg arbejder på er der emacs, vim, eclipse, vs08 og sikkert også nogte andet hejs, Vi compiler og tester til 3 forskellige platforme, og der er ikke noget der gør at man kan sige at den ene gruppe af folk laver flere fejl end den anden, eller er mindre/mere effektive. Det at vi compiler til 3 forskellige platforme, gør faktisk at vores kode får en meget høj kvalitet da der er mange små nemme ting man ikke lige må.
Og som mest væsentlige faktor, det er ikke indtastningen af programlinierne der tager den store mængde tid. Her er det algoritme, datastrukturere, arkitektur (high/low),filtre og andre ting som tager den store arbejdsindsats.
Og som der også bliver pointeret i artiklen, så hjælper det jo ikke noget at kun kan køre med ABS, hvis man ikke altid har det.
Derudover er det jo fint vi kan højne abstraktionen for vildt, men det er jo ikke gratis og artiklen indikere også lidt at de her gutter rent faktisk tror på at der kommer et punkt hvor abstraktion bliver et negativt ord igen. Hvilket jeg synes er meget interessant fordi det kan godt være det gør man hurtigere kommer 80% af vejen,men det er ikke det samme som man kommer hurtigere alle 100%.
Gå til top
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.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund