Wrong confirmation ID

Email
Favorite
Favorited ×
Download
Embed
Private Content
Copy and paste this code into your blog or website Copy Customize… Close
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

+ Follow

Software Craftsmanship @ Ntnu

by goeran on Feb 04, 2010

1,825 views

Talk about Software Craftsmanship, TDD and Capgemini Summer of Code

More…

Talk about Software Craftsmanship, TDD and Capgemini Summer of Code

Less

5 Embeds 124

http://blog.goeran.no	108
http://www.slideshare.net	13
https://www.mturk.com	1
http://blog-goeran-no.heroku.com	1
http://feeds2.feedburner.com	1

Statistics

Favorites: 3
Downloads: 0
Comments: 0
Embed Views: 124
Views on SlideShare: 1,701
Total Views: 1,825

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

3 Favorites

darkrho 2 years ago
Kevin Li 2 years ago
Samnang Chhun , Software Developer at Yoolk Inc. Tags craftsmanship tdd 2 years ago

Software Craftsmanship @ Ntnu — Presentation Transcript

Software Craftsmanship
Gøran Hansen
Aspiring Software Craftsman Senior Consultant @ Capgemini
http://goeran.no
mail@goeran.no
http://twitter.com/goeran
Agenda
Software Craftsmanship
TDD
Capgemini Summer ofCode
Scrum (Ole Gunnar)
Summer ofCode 2009 (Dag Olav og Ole André)
Summer ofCode 2010
Why do we write bad code?
When do we write bad code?
Pressure
Have to get it done!
”Get It Done”
vs
”Do It Right”
Hack Away At Code
An idea
ConstantPressure
Every Week
Every Month
Every Year
Sounds familiar?
Agile?
Software Craftsmanship
And why you should practice it
How Agile Can Fail
How Scrum Can Fail
Scrum Assumptions
Developers Self-Organize
Responsible Developers
Usual Process
Beautiful System
Add a feature
Add a new feature
Change a feature
Time Passes
Looks familiar?
Add a new feature
How?
Crap Code
Is not Agile!
It’s not enough to deliver on time
What we deliver must also be sustainable
Beautiful System
Add a feature
Clean It Up
Add a new feature
Clean It Up
Time Passes
Clean Architecture
Over Time
“Agilists assume craftsmanship
Only few people pursue craftsmanship”
- JurgenAppelo
http://www.noop.nl/2009/05/agile-wrongfully-assumes-craftsmanship.html
What is Software Craftsmanship all about?
Raising the bar
It’s about mastery
It’s about taking pride in our work
It’s about discipline
It’s about continuous learning
It’s about deliberate practice
Questions?
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
Test-Driven Development
“Clean code that works is the goal of Test-Driven Development (TDD).”
- Kent Beck, “Inventor” TDD
Clean Code?
What’scleancode?
“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
Why?
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
How?
“Clean code that works is the goal of Test-Driven Development (TDD).”
- Kent Beck, “Inventor” TDD
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
Unit Tests != TDD
TDD != Testing
TDD == Documentation (ofBehaviour) && Design/Programmingprocess
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
“Clean code that works is the goal of Test-Driven Development (TDD).” – Kent Beck
Demo
Capgemini Summer of Code
Scrum
Studentenes erfaringer fra Summer ofCode 2009
Summer ofCode 2010
Summer of Code 2010
- Søknadsfrist: 15. februar
- Antall: 5-8 (Trondheim, Stavanger og Oslo)
- Oslo: 16 stk på vanlig sommerjobb
- SD&M Tyskland
Curriculum
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/
Software Craftsmanship
Gøran Hansen
Aspiring Software Craftsman Senior Consultant @ Capgemini
http://goeran.no
mail@goeran.no
http://twitter.com/goeran

Software Craftsmanship @ Ntnu

by goeran on Feb 04, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

5 Embeds 124

Statistics

Software Craftsmanship @ Ntnu — Presentation Transcript