Complete code craft
•Descargar como PPTX, PDF•
4 recomendaciones•1,008 vistas
What is Software Craftsmanship? Can it be considered a craft?
Recomendados
Recomendados
Más contenido relacionado
Similar a Complete code craft
Similar a Complete code craft (20)
Último
Último (20)
Complete code craft
- 2. $ whoami Developer at Redgate Founder of Cambridge Software Craftsmanship Community Co-organiser of DDD East Anglia Get in touch! @alastairs / prognet@alastairsmith.me.uk
- 8. Is Software a Craft? (metaphorically speaking)
- 10. Craft == skill, aptitude, competence, proficiency Professionalism == polished skill, competence
- 11. methodic al
- 12. delibera te
- 13. consider ed
- 15. http://rantswithintheundeadgod.blogspot.co.uk/2014/04/pragmatism-as-dead-end-for-new-atheism.html
- 16. A Software Craftsman’s Toolkit Finding the saws to sharpen
- 17. Technical Tools
- 18. Delivery Tools
- 23. https://pragprog.com/magazines/2010-06/the-mikado-method Zen and the Art of Refactoring
- 24. The Mikado Method, Manning Publications Co.
- 29. Thank you for listening! https://www.flickr.com/photos/uk_parliament/6546233741/
Notas del editor
- What does Craftsmanship mean to you? What do you think of when you hear the word?
- Signatories: Uncle Bob, Micah Martin, Corey Haines, Dave Hoover, JB Rainsberger, Gary Berhardt, Adewale Oshineye, Ron Jeffries, …
- Craftsmanship is a desire to do a job well, for its own sake. It is the desire to take pride in your work. To me professionalism and craftsmanship are essentially synonyms. Programming is creative It's a skill that can be learned and developed to a high degree We experience a sense of achievement in improving Therefore, craftsmanship isn't a luxury, it's actually built into our chosen career!
- Systematic, orderly. E.g. TDD.
- Every step has a purpose, e.g., TDD
- GrahamH Something you have thought about, that is defensible when challenged.
- The very opposite of mindlessness: not an automaton, but an actively engaged participant. Opportunities to learn from your experiences and the wider industry. Challenge your principles and practices, and be prepared to have them challenged by others. Curiosity, not self-doubt.
- This is what Software Craftsmanship is all about! With a mindful attitude, we have the correct mindset to be pragmatic in our choices and decisions at work.
- Skip through these.
- A word on TDD. Not always appropriate; sometimes more is appropriate (e.g. ATDD), sometimes less (e.g. spike-and-stabilise). Also see Monitoring-Driven Development as an evolution. Make it work, then make it right. Red: Just enough of a test to fail Compilation failures count when necessary Run all the tests One expected failure Green Just enough code to pass the failing test – no more Run all the tests Refactor Remove duplication Tidy up
- Know your language well, but know your language’s paradigm better. Message-Orientation: Alan Kay. Classist OO vs. behavioural OO. IMO Behavioural OO is more interesting and powerful. Interfaces are contracts of behaviour, so don’t expose state on your interfaces. GoF advice: Favour composition over inheritance Program to the interface, not the implementation Loose coupling. Strategies, Adapters, Composites and more are your friends. Assume nothing about an implementation so the LSP can work for you. Know your Patterns, they are an OO programmer’s bricks and mortar. Explore Functional Programming, and Patterns will become clearer to you. Respect the spectrum of abstraction: even a class is an abstraction, only instances are concrete.
- All software development is either wrangling legacy code or writing it Methodical, incremental refactoring. Drill down to the simplest change and work back up. Set a refactoring goal Naïve implementation Note all dependencies Revert! The Mikado Graph: Is a record of your thoughts Is an indication of progress Is a focussing tool Is a learning tool: exposes coupling and dependencies between modules
- Pair programming is great, but IMO code review is still needed whether or not you’re pairing. Coaching and mentoring. How I do code reviews. If you are pairing regularly, try mob programming to mix things up a bit.
- A model defined by Christopher Avery as part of his “Leadership Gift” program. Many stages of responsibility, similar to the five stages of grief, or the six stages of debugging. The difference with Personal Responsibility is that at any point before we take responsibility, we have an alternative: quit the situation and abdicate responsibility.
- Personal responsibility in bug fixing: There’s no way that could happen! This is Joey’s code, it’s his fault! Well, if Joey hadn’t used null values in his code, there would be no bug! I’m such an idiot, I saw Joey working on this just last week and I didn’t say anything There's no way we could have done anything different, we're under such pressure to deliver on time that quality goes out the window. I'll have a chat with Joey to explain why nulls should be avoided, and start trialling code reviews as part of our development process. Being mindful will help in taking personal responsibility: being aware of which phase we are in and using that knowledge to reach a productive conclusion more quickly.
- Mindset: Methodical, Deliberate, and Considered Tools: both technical and delivery/process Responsibility: owning your context and involvement in your work The second pillar provides a way to express the other two. Any amateur can use a professional’s tools, but it’s the approach we take to our work that indicates professionalism and denotes craftsmanship.