Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (6)
Similar to Software Craftsmanship @ Ntnu
Similar to Software Craftsmanship @ Ntnu (20)
Recently uploaded
Recently uploaded (20)
Software Craftsmanship @ Ntnu
- 1. Software Craftsmanship Gøran Hansen Aspiring Software Craftsman Senior Consultant @ Capgemini http://goeran.no mail@goeran.no http://twitter.com/goeran
- 2. Agenda Software Craftsmanship TDD Capgemini Summer ofCode Scrum (Ole Gunnar) Summer ofCode 2009 (Dag Olav og Ole André) Summer ofCode 2010
- 4. Why do we write bad code?
- 5. When do we write bad code?
- 6. Pressure
- 7. Have to get it done!
- 8. ”Get It Done” vs ”Do It Right”
- 9. Hack Away At Code
- 10. An idea
- 11. ConstantPressure
- 12. Every Week
- 13. Every Month
- 14. Every Year
- 16. Sounds familiar?
- 17. Agile?
- 18. Software Craftsmanship And why you should practice it
- 19. How Agile Can Fail
- 20. How Scrum Can Fail
- 24. Usual Process
- 25. Beautiful System
- 26. Add a feature
- 27. Add a new feature
- 28. Change a feature
- 29. Time Passes
- 30. Looks familiar?
- 31. Add a new feature How?
- 32. Crap Code
- 33. Is not Agile!
- 34. It’s not enough to deliver on time
- 35. What we deliver must also be sustainable
- 36. Beautiful System
- 37. Add a feature
- 38. Clean It Up
- 39. Add a new feature
- 40. Clean It Up
- 41. Time Passes
- 43. Over Time
- 45. What is Software Craftsmanship all about?
- 46. Raising the bar
- 49. It’s about taking pride in our work
- 51. It’s about continuous learning
- 52. It’s about deliberate practice
- 53. Questions?
- 54. A special thanks to Corey Haines, for letting me using his slides. http://www.slideshare.net/openagile/the-craftsman-developer-in-an-agile-world http://www.coreyhaines.com
- 56. “Clean code that works is the goal of Test-Driven Development (TDD).” - Kent Beck, “Inventor” TDD
- 57. Clean Code?
- 58. What’scleancode?
- 59. “You know you are 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. Why?
- 61. The Total Costofowning a Mess “As the mess builds, the productivity of the team continues to decrease, asymptotically approaching zero.” - Robert C. Martin, Clean Code
- 62. How?
- 63. “Clean code that works is the goal of Test-Driven Development (TDD).” - Kent Beck, “Inventor” TDD
- 64. Red/Green/Refactor – 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 and clean the code
- 65. Unit Tests != TDD
- 66. TDD != Testing
- 67. TDD == Documentation (ofBehaviour) && Design/Programmingprocess
- 68. WriteCleanCodethatworks Because it’s expensive to own bad code Because it’s a good feeling Because you get a lot more done Because it makes you a better programmer Because it lets your teammates to count on you
- 69. “Clean code that works is the goal of Test-Driven Development (TDD).” – Kent Beck
- 70. Demo
- 71. Capgemini Summer of Code
- 72. Scrum
- 73. Studentenes erfaringer fra Summer ofCode 2009
- 76. Antall: 5-8 (Trondheim, Stavanger og Oslo)
- 77. Oslo: 16 stk på vanlig sommerjobb
- 79. Other good books http://blog.goeran.no/PermaLink,guid,b0df5924-fb90-4506-b2e7-1e15a5e981c6.aspx http://blog.goeran.no/PermaLink,guid,46f29e55-5369-4dbc-8f60-2bd65e1c5fa4.aspx http://tore.vestues.no/recommended-books/
- 80. Software Craftsmanship Gøran Hansen Aspiring Software Craftsman Senior Consultant @ Capgemini http://goeran.no mail@goeran.no http://twitter.com/goeran
Editor's Notes
- VelkommenOm meg (28, bachelor NTNU, aktiv foredragsholder)
- Hvorforskriver vi dårligkode? Godtspørsmål…
- Jegtrordetermernaturlig å spørreossselv; nårskriver vi dårligkode?
- 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!
- 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.
- Det enkleste er ofte det beste, iaf. Under tidspress.
- Se for deredette…
- Vi kommer alltid til å jobbe under tidspress i prosjekter…Men se for dere å jobbe i et prosjekt med urealistiske forventninger. F.eks til leveransedato..
- Hver eneste uke må dere forholde dere til alt for korte tidsfrister, og bare få koden til å fungere “no matter what”.
- 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?
- 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.
- 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.
- Hvordan kan vi være smidig dersom koden vår ikke smidig?
- Det vi leverer må også være vedlikeholdbart over lang, lang tid….
- For å bli en bedreutvikler
- For å bli en bedreutvikler
- For å bli en bedreutvikler
- For å bli en bedreutvikler
- For å bli en bedreutvikler
- For å bli en bedreutvikler
- For å bli en bedreutvikler
- 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
- 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.
- Hva er CleanCode? Vi må alle ha en felles forståelse for hva CleanCode er..
- 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.
- 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)
- Robert C. Martin callsthisthe Total CostofOwning a Mess.
- 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).
- 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.
- 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.
- 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?
- 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
- 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.
- Her snakker Ole Gunnar
- Her snakker Dag Olav og Ole Andre
- Her snakker Dag Olav og Ole Andre
- Her snakker Dag Olav og Ole Andre