More Related Content
Similar to Software Craftsmanship @ Ntnu
Software Craftsmanship @ Ntnu
- 1. Software CraftsmanshipGøran HansenAspiringSoftware Craftsman Senior Consultant @ Capgeminihttp://[email protected] http://twitter.com/goeran
- 2. AgendaSoftware CraftsmanshipTDDCapgemini SummerofCodeScrum (Ole Gunnar)Summer ofCode 2009 (Dag Olav og Ole André)Summer ofCode 2010
- 4. Why do wewrite bad code?
- 5. When do wewrite bad code?
- 6.
- 7. Have to getit done!
- 8. ”Get It Done”vs”DoIt Right”
- 9. Hack Away AtCode
- 10.
- 11.
- 12.
- 13.
- 14.
- 16.
- 17.
- 18. Software CraftsmanshipAnd whyyou should practice it
- 19. How Agile CanFail
- 20. How Scrum CanFail
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27. Add a newfeature
- 28.
- 29.
- 30.
- 31. Add a newfeatureHow?
- 32.
- 33.
- 34. It’s not enoughto deliver on time
- 35. What we delivermust also be sustainable
- 36.
- 37.
- 38.
- 39. Add a newfeature
- 40.
- 41.
- 42.
- 43.
- 44. “Agilists assume craftsmanshipOnlyfew people pursue craftsmanship”JurgenAppelohttp://www.noop.nl/2009/05/agile-wrongfully-assumes-craftsmanship.html
- 45. What is SoftwareCraftsmanship all about?
- 46.
- 48.
- 49. It’s about takingpride in our work
- 50.
- 51. It’s about continuouslearning
- 52. It’s about deliberatepractice
- 53.
- 54. A special thankstoCorey Haines, for letting me using his slides.http://www.slideshare.net/openagile/the-craftsman-developer-in-an-agile-worldhttp://www.coreyhaines.com
- 55.
- 56. “Clean code thatworks is the goal of Test-Driven Development (TDD).”- Kent Beck, “Inventor” TDD
- 57.
- 58.
- 59. “You know youare working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem” - Ward Cunningham, Inventor of the Wiki
- 60.
- 61. The Total Costofowninga Mess“As the mess builds, the productivity of the team continues to decrease, asymptotically approaching zero.” - Robert C. Martin, Clean Code
- 62.
- 63. “Clean code thatworks is the goal of Test-Driven Development (TDD).”- Kent Beck, “Inventor” TDD
- 64. Red/Green/Refactor – TDDmantraRed – write a little test that doesn’t work, and perhaps doesn’t even compile at firstGreen – make the test work quickly, committing whatever sins necessary in the processRefactor – eliminate all of the duplication and clean the code
- 65.
- 66.
- 67. TDD == Documentation(ofBehaviour) && Design/Programmingprocess
- 68. WriteCleanCodethatworksBecause it’s expensiveto own bad code Because it’s a good feelingBecause you get a lot more doneBecause it makes you a better programmerBecause it lets your teammates to count on you
- 69. “Clean code thatworks is the goal of Test-Driven Development (TDD).” – Kent Beck
- 70.
- 71.
- 72.
- 73. Studentenes erfaringer fraSummer ofCode 2009
- 74.
- 75. Summer of Code2010Søknadsfrist: 15. februar
- 76. Antall: 5-8 (Trondheim,Stavanger og Oslo)
- 77. Oslo: 16 stkpå vanlig sommerjobb
- 78.
- 79.
- 80. Software CraftsmanshipGøran HansenAspiringSoftware Craftsman Senior Consultant @ Capgeminihttp://[email protected] http://twitter.com/goeran
Editor's Notes
- #2 VelkommenOm meg (28, bachelor NTNU, aktiv foredragsholder)
- #5 Hvorforskriver vi dårligkode? Godtspørsmål…
- #6 Jegtrordetermernaturlig å spørreossselv; nårskriver vi dårligkode?
- #8 Jeg opplever som regel tidspress når jeg må forholde meg til urealistiske tidsfrister, og bare må bli ferdig med funksjonaliteten… ”whatever it takes”Men det er jo ikke akkurat sånn at det står liv på spill når jeg lager en forretningsapplikasjon, men fortsatt er det super viktig at jeg blir ferdig ASAP!
- #9 Uansett tidspress eller ikke har vi som regel to muligheter når vi skriver kodeGet It DoneSkriver kode for å få noe til å fungere, uten å tenke igjennom design. Dette fører selvsagt til at koden blir ustrukturert, vanskelig å lese og forstå. Det er som regel ikke enkelt å forandre den eller legge til ny funksjonalitet.Do It RightSkriver koden på en måte som gjør at den er enkel å lese og forstå. Det er mulig og endre den og den lar seg enkelt utvide med ny funksjonalitet.
- #10 Det enkleste er ofte det beste, iaf. Under tidspress.
- #11 Se for deredette…
- #12 Vi kommer alltid til å jobbe under tidspress i prosjekter…Men se for dere å jobbe i et prosjekt med urealistiske forventninger. F.eks til leveransedato..
- #13 Hver eneste uke må dere forholde dere til alt for korte tidsfrister, og bare få koden til å fungere “no matter what”.
- #18 Er dette smidig?Det hjelper lite å ha en smidig prosjekt, dersom koden vi jobber med ikke lar seg endre. Dersom kunden vår ønsker ny funksjonalitet, og vi bruker flere måneder på å levere den – kan vi da kalle oss smidig?
- #21 Scrum sier ingenting om tekniske aktiviteter som TDD, ContinuousIntegration, Parprogrammering etc.Alle prosjektet begynner bra, og man jobber effektiv i noen sprinter, men så begynner det å gå saktere og saktere å legge til ny funksjonalitet…Når man endrer noe som allerede fungerer, slutter noe annet å fungere. Det tar utrolig lang tid å legge til ny funksjonalitet.. Og ny kode fører ofte til at gammel kode må endres, og da slutter igjen noe som har fungert før å fungere..Noen som vet hvorfor dette skjer?Dette kalles forresten for teknisk gjeld (WardCunningham). Når man får koden til å fungere (Get It Done) for å bli ferdig i tide, pådrag man seg gjeld pga. Dårlig design. Som I den virkelige verden, må man også her passe seg for å ikke låne for mye. Dersom man gjør det, får man mindre penger å rutte med – man får lavere likviditet.Der som man implementerer koden på en god måte (Get It Right), pådrar man seg ikke teknisk gjeld pga. man har et bra design.Man kan betale ned på gjelden gjennom å forbedre designet på kode som er implementert bare for å fungere.
- #33 Selv om vi er både selvorganiserende, tar ansvar og leverer I tide, kan vi fortsatt levere dårlig kode selv om vi jobber i Scrum.Dette får som sagt store konsekvenser for fremtiden.. Det blir vanskelig å vedlikeholde datasystemet. Huk at mesteparten av levetiden til et datasystem er vedlikehold – ikke utvikling.
- #34 Hvordan kan vi være smidig dersom koden vår ikke smidig?
- #36 Det vi leverer må også være vedlikeholdbart over lang, lang tid….
- #47 For å bli en bedreutvikler
- #49 For å bli en bedreutvikler
- #50 For å bli en bedreutvikler
- #51 For å bli en bedreutvikler
- #52 For å bli en bedreutvikler
- #53 For å bli en bedreutvikler
- #54 For å bli en bedreutvikler
- #56 Ledende som: alle vet hva TDD er? Hvem praktiserer TDD? Hvor mange skriver unit tester? - Er det vanskelig å skrive testene etter på? - Hvor mye av koden blir testet etterpå? - Refactorer dere?Hvor mange praktiserer compile->run->debug? Hvor mye tid bruker dere i debuggeren? Skyte inn: jeg bruker 5-10% av tiden i debuggeren
- #57 Cleancodethatworks is the goal of TDDsays Kent Beck.Cleancodethatworks is a worthwhile goal for a wholebunchofreasons:It is a predictableway to develop. You know whenyouarefinished, withouthaving to worryabout a longbugtrail It givesyou a chance to learn all ofthelessonsthatthecode has to teachyou. Ifyouonlyslaptogetherthe first thingyouthinkof, thenyou never have time to thinkof a second, betterthing It improvesthe lives oftheusersofyour software It lets yourteammatescountonyou, and youonthem it feelsgood to write it.Be aware: TDD is not all about writing unit tests. It’s a style of development. It’s a tiny and very strict programming process.
- #58 Hva er CleanCode? Vi må alle ha en felles forståelse for hva CleanCode er..
- #59 What is goodcode?Obviously the best code here is the code behind the door to the left. I think this is a good metaphor because it’s easy to relate to. You probably been behind the door to the right yourself? – I have, several times, and I don’t want to be there ever again.If you read code and don’t get surprised while reading it, you probably are reading good code. The less WTF’s you discover, the more expressive and understandable the code is. When we write code like this, I believe we are writing Clean Code. Ward Cunningham has a very specific opinion on what Clean Code is.
- #61 Why?Writing bad code is expensive. You are a programmer and you’ve probably experienced to be slowed down by someone else’s messy code? The degree of slowdown can be significant. When a team starts a new project they usually move very fast in the beginning, and they implement a lot of code. After a year or two they find themselves moving at a snail’s pace. Every change they make to the code breaks two or three other parts of the code. Spørsmål: Har noen opplevd å bli forhindret i å levere i tide pga. dårlig kode? (kode som inneholder mange feil og som er vanskelig å forstå/bruke)
- #62 Robert C. Martin callsthisthe Total CostofOwning a Mess.
- #63 I think lots of developers are capable of writing clean code, but what about the quality? How can we verify that our code is working properly? I think the best tactic for guaranteeing working code is TDD (Test Driven Development).
- #64 Cleancodethatworks is the goal of TDDsays Kent Beck.Cleancodethatworks is a worthwhile goal for a wholebunchofreasons:It is a predictableway to develop. You know whenyouarefinished, withouthaving to worryabout a longbugtrail It givesyou a chance to learn all ofthelessonsthatthecode has to teachyou. Ifyouonlyslaptogetherthe first thingyouthinkof, thenyou never have time to thinkof a second, betterthing It improvesthe lives oftheusersofyour software It lets yourteammatescountonyou, and youonthem it feelsgood to write it.Be aware: TDD is not all about writing unit tests. It’s a style of development. It’s a tiny and very strict programming process.
- #65 I’ll quote Kent Beck (The father of TDD):Red/Green/Refactor – the TDD mantra:- Red – Write a little test that doesn’t work, and perhaps doesn’t even compile at first.- Green – Make the test work quickly, committing whatever sins necessary in the process- Refactor – eliminate all of the duplication creating in merely getting the test to work Preface I TDD by example.
- #66 Note, writing tests after you written production code is not TDD! It’s just unit testing.You do TDD when following the TDD mantra. If write your tests after the production code you’ll discover that it’s harder to test this code. It’s not loosely coupled enough.Spørsmål: hvor mange skrive enhetstester?
- #68 Hjelper å oppdage hvordan koden (API) skal se ut (design prosess)ProgrammeringsprosessDokumenter hvordan koden fungerer – når jeg leser gammel kode så ser jeg alltid på testene før jeg begynner å ser på dokumentasjonskoden. Hvis det finnes gode tester hjelper de meg å forstå hvordan denne koden fungerer Dokumenterer oppførsel
- #70 Note, writing tests after you written production code is not TDD! It’s just unit testing.You do TDD when following the TDD mantra. If write your tests after the production code you’ll discover that it’s harder to test this code. It’s not loosely coupled enough.
- #73 Her snakker Ole Gunnar
- #74 Her snakker Dag Olav og Ole Andre
- #75 Her snakker Dag Olav og Ole Andre
- #76 Her snakker Dag Olav og Ole Andre