Software Craftsmanship - It's an Imperative
•
8 j'aime•1,418 vues
Software Craftsmanship Slides
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Software Craftsmanship - It's an Imperative
Similaire à Software Craftsmanship - It's an Imperative (20)
Plus de Fadi Stephan
Plus de Fadi Stephan (20)
Dernier
Dernier (20)
Software Craftsmanship - It's an Imperative
- 1. Software Craftsmanship By Fadi Stephan http://www.agilejourneyman.com/2011/04/software- craftsmanship-impertaive-or.html
- 3. Fadi Stephan AgileJourneyman.com
- 4. Acknowledgment Robert Martin Corey Haines
- 6. OOPSLA 1991 History Towards a Software Architecture Handbook
- 7. OOPSLA 1998 History Software as a Studio Discipline
- 9. History Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
- 10. History Software craftsmanship over CRAP! Craftsmanship over execution • Most software development teams execute, but they don’t take care • We value execution, but we value craftsmanship more
- 11. Manifesto of Software Craftsmanship
- 12. Not only working software, but also well crafted software Not only responding to change, but also steadily adding value Not only individuals and interactions, but also a community of professionals Not only customer collaboration, but also productive partnerships
- 15. SCRUM
- 22. Change Risk Analyzer and Predictor CRAP(m) = comp(m)^2 (1 - cov(m)/100)^3 + comp(m)
- 26. Care
- 27. I will practice 2 hours every day I will practice 2 hours every day I will practice 2 hours every day I will practice 2 hours every day I will practice 2 hours every day I will practice 2 hours every day Practice
- 31. I pity the fool who doesn’t write test cases! Test Driven Development
- 32. I pity the fool who breaks the build! Continuous Integration
- 33. I pity the fool who doesn’t collaborate Pair Programming
- 34. t QA Should Pride Find Nothing
- 36. Boy Scout Rule
- 37. Extract till You Drop
- 38. No Argument is the Best Argument
- 48. Decouple
- 49. Baby Steps
- 50. YAGNI
- 52. Short Iterations 2 to 4 weeks
- 53. Never Be Blocked
- 55. Test Through the Right Interface
- 56. Avoid Debugging
- 57. Slow Down To Go Fast Productivity Clean Code Bad Code Time
- 60. Principle 9 Continuous attention to technical excellence and good design enhances agility
- 61. Manifesto
- 63. Metaphors
- 64. Language
- 67. Coding Dojos
- 70. Craftsman Swaps
- 72. Craftsman Spikes
- 74. Software
- 80. Pictures • http://www.flickr.com/photos/psd/2423294079/sizes/l/in/photostream/ • http://www.flickr.com/photos/sakeeb/4647211575/sizes/m/in/photostream/ • http://www.flickr.com/photos/24322735@N07/2393833499/sizes/m/in/photostre am/ • http://www.flickr.com/photos/wwworks/4471608005/sizes/m/in/photostream • http://www.flickr.com/photos/timrich26/3308513067/sizes/m/in/photostream/ • http://imgur.com/y7Hm9?full • http://www.flickr.com/photos/das_butzele/227637183/sizes/z/in/photostrea m/ • http://www.flickr.com/photos/fotoecke/5177140233/sizes/m/in/photostream / • http://www.flickr.com/photos/drinksmachine/3732782275/sizes/m/in/photos tream/ • http://www.flickr.com/photos/popilop/331357312/sizes/z/in/photostream/ • http://www.flickr.com/photos/58289610@N00/3610407879/
- 81. Pictures • http://www.flickr.com/photos/25507200@N07/3120849218/ • http://imgur.com/y7Hm9?full • http://lostechies.com/gabrielschenker/files/2011/03/giant_2.jpg • http://lostechies.com/derickbailey/files/2011/03/OpenClosedPrinciple2_2C596E1 7.jpg • http://lostechies.com/derickbailey/files/2011/03/LiskovSubtitutionPrinciple_52BB 5162.jpg • http://lostechies.com/derickbailey/files/2011/03/InterfaceSegregationPrinciple_6 0216468.jpg • http://lostechies.com/derickbailey/files/2011/03/DependencyInversionPrinciple_0 278F9E2.jpg • http://www.flickr.com/photos/70981241@N00/3979767112/
- 82. Pictures • http://www.flickr.com/photos/11904001@N00/3983980813/ • http://www.flickr.com/photos/7821771@N05/4679360979/ • http://www.flickr.com/photos/97041449@N00/5261698908/ • http://www.flickr.com/photos/37164718@N02/5365226277/ • http://www.flickr.com/photos/71962092@N00/2874328851/ • http://www.flickr.com/photos/49715404@N00/3267627038/
Notes de l'éditeur
- Picture:http://www.flickr.com/photos/drhurn/1985687/sizes/m/in/photostream/
- Picture: http://www.flickr.com/photos/psd/2423294079/sizes/l/in/photostream/
- About me
- Most of this presentation is based on the work of Robert Martin and Corey Haines
- OOPSLA 1991Object-Oriented Programming, Systems, Languages & Applications ConferenceBruce Anderson workshop “Towards a Software Architecture Handbook”Dedicated to developing a handbook for software architectsRichard Helm, Ralph Johnson, John Vlissides and Erich Gamma met here Collaborated for couple of years to produce “Design Patterns” - GOF
- OOPSLA 1998Bruce Anderson workshop “Software as a Studio Discipline”Discuss whether developing software is a careful blend of artistry and disciplinePete McBreen inspiredIn2001, published book “Software Craftsmanship”Main theme: Software engineering has run its course Building software systems requires set of skills and experiences beyond just book learning, training courses, methodologies, and certifications
- Book presented a craftsman paradigm in which apprentice software developer learns from journeyman like other craftsman based professionsSoftware is a craft: part art, part skill Developers should be measured on quality of work, ability to deliver value to business and be accountable for what they produce. At the time it was published, it did not generate much noise or interest and did not become a hit like the GoF book.Picture: http://www.flickr.com/photos/25507200@N07/3120849218/
- Agile 2008 – TorontoKeynote address by uncle BobReviewed Agile manifestoProposed fifth value to agile manifesto: Craftsmanship over crapHuge stage to bring up the same concepts again and created a lot of discussion
- A week later Robert Martin revised it to craftsmanship over executionMost software development teams execute, but they don’t care. We value execution, but we value craftsmanship more.“We're tired of writing crap. We are tired of embarrassing ourselves and our employers by delivering lousy software. We have had enough of telling our customers to reboot at midnight. We don't want bug lists that are a thousand pages long. We don't want code that grows more tangled and corrupt with every passing day. We're tired of doing a bad job. We want to start doing a good job.”http://cleancoder.posterous.com/software-craftsmanship-things-wars-commandmenDid not result in change to manifesto, but started a movement of its own. December 2008, group of aspiring software craftsmen got together and tried to solve some problems they were facingCame up with a statement of things they believe in and crafted another manifesto, the Software Craftsmanship manifesto
- Software Craftsmanship manifesto
- They felt that we are heading in a bad direction. The state of software development was going downhill.
- Theory vs. practiceMismatch with teaching and what is needed forworkStrong theoretical knowledge but can’t write good codePicture: http://www.flickr.com/photos/sakeeb/4647211575/sizes/m/in/photostream/
- Popularity of Scrum. Scrum focuses on process but does not prescribe technical practices. Ken Schwaber said that we made a fundamental assumption that was wrongDevelopers smart enough to come up with their own practicesButdevelopers spent careers working in large cycles. They were used to it. waiting for 9 months before coding or before QANow they have to figure out how to do things in 30 days or even in 2 weeks.Agile and Scrum requires skilled developers that know how to keep code base healthyDelivering software every 2 to 4 weeks only possible if build up and keep code highly maintainablePicture: www.mountaingoatsoftware.com/scrum
- Robert Martin bad code video
- Place holder
- Big ball of mud most popular way to design and architect softwareIncludes Greenfield projects that have full benefit of hindsight regarding bad design approaches of pastPicture: http://www.flickr.com/photos/24322735@N07/2393833499/sizes/m/in/photostream/
- Code unreadable and looked like spaghetti code jungle
- Become sloppy Use duck tape to fix thingsThe whole code is covered with duck tape. Picture: http://www.flickr.com/photos/wwworks/4471608005/sizes/m/in/photostream/
- In a minefieldAnything you touch might break and explodeNow easier to do it all over again than to read and figure out other people’s codePicture: http://www.flickr.com/photos/timrich26/3308513067/sizes/m/in/photostream/
- Need tools like crap4j - Change Risk Analyzer and PredictorCRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m) m = method comp(m) = Cyclometric complexity of method m. cov(m) = Test code coverage for method m. Crap gap measure
- Most interesting man in the worldPicture: http://imgur.com/y7Hm9?full
- Software craftsmen: good software does not come from processComes from people who care about itPeople have pride in their workStand by what they doWilling to learn from others to improveBy sharing they bring up knowledge of entire team and companyBuilding code requires more than theoretical knowledge, it requires tacit knowledge and experience.
- We CareWe consider it our responsibility to gain the trust of the businesses we serve; therefore, we take our customer's problems as seriously as they do and stake our reputation on the quality of the work we produce.We PracticeWe consider it our responsibility to write code that is defect-free, proven, readable, understandable and malleable; therefore, we follow our chosen practices meticulously even under pressure and practice our techniques regularly.We LearnWe consider it our responsibility to hone our craft in pursuit of mastery; therefore, we continuously explore new technologies and read and study the work of other craftsmen.We ShareWe consider it our responsibility to perpetuate the craft of Software; therefore, we enlist apprentices to learn it and actively engage other craftsmen in dialogue and practice.
- We Care about quality. We stake our reputation on the quality of the work we produce.We CareWe consider it our responsibility to gain the trust of the businesses we serve; therefore, we take our customer's problems as seriously as they do and stake our reputation on the quality of the work we produce.
- We Practice: We practice our techniques regularly and follow our practices even under pressure in order to write defect-free, proven, readable, understandable and malleableWe PracticeWe consider it our responsibility to write code that is defect-free, proven, readable, understandable and malleable; therefore, we follow our chosen practices meticulously even under pressure and practice our techniques regularly.
- We Learn: we continuously explore new technologies, read and study the work of other craftsmen.We LearnWe consider it our responsibility to hone our craft in pursuit of mastery; therefore, we continuously explore new technologies and read and study the work of other craftsmen.
- We Share: we look for newcomers and actively engage other craftsmen in dialogue and practiceWe ShareWe consider it our responsibility to perpetuate the craft of Software; therefore, we enlist apprentices to learn it and actively engage other craftsmen in dialogue and practice.Picture: http://www.flickr.com/photos/das_butzele/227637183/sizes/z/in/photostream/
- Disciplines
- TDD – verifies that our code works and makes it possible to refactor and constantly improve code over time.TDD: Follow 3 rules: 1) not allowed to write production code until you have a failing unit test, 2) you are not allowed to write more of unit test than is sufficient to fail (not compile is failing), 3) you are not allowed to write more production code than is sufficient to pass. This forces us to keep the code executing all the time. Tests make the software flexible and maintainable.
- CI: Use tools like Hudson, CruiseControl, Bamboo, and TeamCity. If build fails, immediately fix build.
- Pairing: If you don’t want to code pair, at least make sure team is communicating, sharing and working closely together.
- Pride and attitude that QA should find nothing
- Principles
- Apply the boy scout rule: Always leave camp ground cleaner than way you found it. That is, whenever you work on a class or function, spend some extra time to refactor it and clean it a little.Picture: http://www.flickr.com/photos/fotoecke/5177140233/sizes/m/in/photostream/
- Apply Extract till you drop: Function size should be small. Keeping extracting until you can no longer extract function. This takes all the concepts in the function puts them in well named places.
- No argument is best argument. Functions should have smallest number of arguments possible. Try not to exceed 2 arguments. Do not pass Booleans as arguments; instead create two well named functions.Picture: http://www.flickr.com/photos/drinksmachine/3732782275/sizes/m/in/photostream/
- Use long names to be as descriptive as possible.
- Avoid duplication. Do not copy and paste.Picture: http://www.flickr.com/photos/popilop/331357312/sizes/z/in/photostream/
- Design Patterns
- SOLID PrinciplesS SRP Single responsibility principle the notion that an object should have only a single responsibility. O OCP Open/closed principle the notion that “software entities … should be open for extension, but closed for modification”.L LSP Liskov substitution principle the notion that “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”. I ISP Interface segregation principle the notion that “many client specific interfaces are better than one general purpose interface.”D DIP Dependency inversion principle the notion that one should “Depend upon Abstractions. Do not depend upon concretions.”[Dependency injection is one method of following this principle.
- Picture: http://lostechies.com/gabrielschenker/files/2011/03/giant_2.jpg
- Picture: http://lostechies.com/derickbailey/files/2011/03/OpenClosedPrinciple2_2C596E17.jpg
- Picture: http://lostechies.com/derickbailey/files/2011/03/LiskovSubtitutionPrinciple_52BB5162.jpg
- Picture: http://lostechies.com/derickbailey/files/2011/03/InterfaceSegregationPrinciple_60216468.jpg
- Picture: http://lostechies.com/derickbailey/files/2011/03/DependencyInversionPrinciple_0278F9E2.jpg
- http://www.flickr.com/photos/70981241@N00/3979767112/Decouple from others: write stubs to ensure your code can run and to define your interface
- http://www.flickr.com/photos/11904001@N00/3983980813/Work in small incrementsUse progressive widening: Add a small feature from top to bottom (GUI to database)Use progressive deepening: Get something working in one layer and then move it down to other layers. 1st make it work, then make it right, then make it fast.Avoid grand redesigns. They generally do not work very well. A “tiger” team will constantly be trying to catch up with maintenance team.
- YouAin’tgonna need it. Avoid turgid viscous architectures. They do harm than good. They slow you down. Don’t try to create a solution for all possible (imaginable) cases. Just try to solve the problem at hand use a simple architecture. Use good coding techniques (like decoupling and SRP) and adding in new cases as they are need should be easy.Picture: http://www.flickr.com/photos/97041449@N00/5261698908/
- Abstract away volatility: look at what is likely to change and separate it from what is not likely to change. (do not mix gui with business rules).
- Short iterations (1 or 2 weeks). Plan, code, testing, documentation (complete cycle resulting in deployable software.Participate in the definition process by demonstrating working code.
- Commission instead of omission. It is better to experiment than to wait.Never be blocked: always find some way to make progressPicture: http://www.flickr.com/photos/7821771@N05/4679360979/
- Automate everything. Playing with system should be explorative testing. The other vast majority of testing should be automated. Builds should be automated. Deployments should be automated.Check out the book “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation” by Jez Humble and David Farley
- Test through the right interface.Do not test business rules through the GUI. Test GUIconnected to a dummy (mock) layer.Picture: http://www.flickr.com/photos/37164718@N02/5365226277/
- Don’t jump into the debugger. Look at the code 1st. Use TDD. Debugger should be last resort.Picture: http://www.flickr.com/photos/71962092@N00/2874328851/
- Clean code: Only way to go fast is to slow down a minute and write clean code. Readable, obvious, small functions, good namesDon’t write bad code: It does not only slow down others months from now but will slow you down immediately.
- Software craftsmanship is about pride in work, team work, mentorship, improving skills, practicingYet there is some disagreement
- Not everyone agreesDan North, and David HarveyArgue software craftsmanship manifesto is weakJust adds riders or extensions to agile manifestoMost already covered in agile principles
- Principle #9: continuous attention to technical excellence and good design enhances agility.
- 2nd, manifesto is tameManifesto - a statement of belief,a call-to-arms, feisty, opinionated, and brash.Marxand Angels communist manifestoFuturist manifestoSCUM manifestoAll compelling, persuasive, controversial and polarizingShould be something we can disagree withNo reasonable person can disagree with software craftsmanship manifestoNo one can say they don’t care about adding value, create community of professionals, having productive partnerships and writing quality software. Not much of a manifesto
- Manifesto is attack on software engineering and scientific researchManifesto is giving permission new generation to ignore all lessons learned from software engineeringLessons like the works of DeMarco, Yourdon, Parnas, Dijkstra, Hoare, Weinberg.
- Language matterschoosing inappropriate metaphors, like craftsman, apprentice, journeyman, increases gap between development and business.Software developers have their own definition of craftsmanship, butwhat matters is perception of customersAssociate craft with quality at a flea-market or craft fair - not something can really rely onhttp://www.flickr.com/photos/58289610@N00/3610407879/
- Terms "Master", "Journeyman", and "Apprentice“ bring up secretive guilds of middle ages with ritual, mysticism, and intrigueSoftware craftsmen should be egoless, humble, with focus on outcome rather than code or process
- Manifesto brought people together and made it easier for them to roll out some ideas on how to practice
- Code katas - Dave Thomas from pragmatic programmersSmall problems to solveUncle Bob switched to practice on a solution insteadLike martial arts and how you repeat small motions and practice them until they become natural reflexesDo it over and over again until it becomes reflexKatacasts.com – Corey Haines has various screencasts known as katacast that show folks practicing a small kata
- Example Bowling Kata, Poker Kata, Supermarket Kata, Tennis KataPicture: http://www.flickr.com/photos/49715404@N00/3267627038/
- Code retreats started worldwideDevelopers get together on Saturday for full day of practiceWork on Conway’s game of life using technique “TDD as if you meant it” Focuses on TDD being all about evolutionary designPair-up, work on it for 45 minutes, then delete code, swap pairs and do it again
- 2 companies swap employee for weekEmployees learn practices of another company and come back and try to improve their own environment
- Craftsman journey – you go to company for 1 week and learn what they doInstead of going to conference, company will give you time off to go and work and learn what others are doing
- Craftsman spikes are side projects that you use to practice craftsmanshipCompanies offers employees 20% time to work on side projects
- Software craftsmanship conferences established and 2 held each year, one in the UK and one in the USSeveral Software Craftsmanship User groups started
- What does all this mean to you?
- Contact Info