Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

A journey to_be_a_software_craftsman

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Nächste SlideShare
Test driven development
Test driven development
Wird geladen in …3
×

Hier ansehen

1 von 89 Anzeige

A journey to_be_a_software_craftsman

Herunterladen, um offline zu lesen

Why should we practice XP engineering practices?
What kind of engineering practices should we practices?
How do we practice XP engineering practices?

Why should we practice XP engineering practices?
What kind of engineering practices should we practices?
How do we practice XP engineering practices?

Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie A journey to_be_a_software_craftsman (20)

Anzeige

Aktuellste (20)

Anzeige

A journey to_be_a_software_craftsman

  1. 1. 소프트웨어 장인으로 가는 길 ( A Journey to Be a Software Craftsman) - Practicing Engineering Practices Jaehoon Oh (jaehoon@nethru.co.kr)
  2. 2. Software Craftsmanship Engineering Practice
  3. 3. Software Craftsmanship Software Craftsman CraftsmanCraftsmanship
  4. 4. https://www.youtube.com/watch?v=mRLLhwXyqSA Craftsman
  5. 5. Cambridge Dictionary - A person who is skilled at a particular craft Longman Dictionary - Someone who is very skilled at a particular craft Craftsman 장인[匠人] - 손으로 물건을 만드는 일에 종사하던 사람 - 예술 작품을 만드는 사람을 비유적으로 이르는 말
  6. 6. Someone who is very skilled at software development. Software Craftsman
  7. 7. How does a craftsman prove that he is a skilled person? QUALITY
  8. 8. How does a Software Craftsman show that he is a skilled person? QUALITY
  9. 9. http://blog.castsoftware.com/titanic-dilemma-the-seen-versus-the-unseen/ Readability Flexibility Testability Maintainability Cohesion Coupling EfficiencyCorrectness Maintenance Cost External Quality Internal Quality (Code Quality) Software Quality Iceberg Test Review
  10. 10. Craftsmanship ? 장인정신 ≠
  11. 11. Craftsmanship Cambridge Dictionary - Skill at making things Longman Dictionary - The special skill that someone uses to make something beautiful with their hands
  12. 12. Software Craftsmanship Cambridge Dictionary - Skill at making things Software Longman Dictionary - The special skill that someone uses to make something Software beautiful with their hands
  13. 13. Agile Brief History Waterfall Model ( Winston W. Royce) (1970) Concept of “Adaptive Software Development” ( Edmends, E.A) (1974) Rapid App Development (James Martin) (1991) Scrum (Ken Schwaber, Jeff Sutherland) Adaptive Software Development(ASD) (Jim Highsmith, Sam Bayer) FDD (Jeff De Luca) DSDM (DSDM Consortium) XP(Kent Beck, Ward Cunningham, Ron Jeffries) Crystal Clear (Alistair Cockburn) Lean SW Development (Mary & Tom Poppendieck) (2003) Agile Manifesto (2001) Software Craftmanship Manifesto (2008) (1995) (1996) https://www.visual-paradigm.com/guide/agile-software-development/what-is-agile-software-development/
  14. 14. Software Craftsmanship Manifesto Raising the Bar As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value: Not Only Working Software But Also Well-Crafted Software Not Only Responding To Change But Also Steadily Adding Value Not Only Individual And Interactions But Also A Community Of Professionals Not Only Customer Collaboration, But Also Productive Partnerships That is, in pursuit of the items on left we have found the items on the right to be indispensable.
  15. 15. Question #1. Why? Why should we practice Engineering Practices? Question #2. What? What kind of Engineering Practice should we practice? Question #3. How? How do we practice Engineering Practices?
  16. 16. Question #1. Why? Why should we practice Engineering Practices?
  17. 17. Software Craftsmanship Manifesto Raising the Bar As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value: Not Only Working Software But Also Well-Crafted Software Not Only Responding To Change But Also Steadily Adding Value Not Only Individual And Interactions But Also A Community Of Professionals Not Only Customer Collaboration, But Also Productive Partnerships That is, in pursuit of the items on left we have found the items on the right to be indispensable.
  18. 18. Productivity - Business Plan Productivity
  19. 19. Productivity - Reality Productivity
  20. 20. Productivity Gap Productivity
  21. 21. Why is development productivity getting decreased more and more?
  22. 22. http://blog.castsoftware.com/titanic-dilemma-the-seen-versus-the-unseen/ Readability Flexibility Testability Maintainability Cohesion Coupling EfficiencyCorrectness Maintenance Cost External Quality Internal Quality (Code Quality) Technical Debt
  23. 23. Quality Gap Productivity
  24. 24. Craftsman’s Responsibility Productivity
  25. 25. How can we keep the development productivity as high as we want?
  26. 26. Question #2. What? What kind of Engineering Practice should we practice?
  27. 27. Software Craftsmanship Manifesto Raising the Bar As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value: Not Only Working Software But Also Well-Crafted Software Not Only Responding To Change But Also Steadily Adding Value Not Only Individual And Interactions But Also A Community Of Professionals Not Only Customer Collaboration, But Also Productive Partnerships That is, in pursuit of the items on left we have found the items on the right to be indispensable.
  28. 28. Relationships Between Engineering Practices 7 8 8 6 6
  29. 29. + Legacy Code Refactoring
  30. 30. Refactoring
  31. 31. Refactoring is a discplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.
  32. 32. Refactoring - Cost Per Feature
  33. 33. Refactoring You should prove that you didn’t change the existing behaviors when you refactor code.
  34. 34. Refactoring and Test Suppose that you have changed a line of code. There are about 10,000 functionalities in your SW. How many functionalities should you test?
  35. 35. Test Driven Development
  36. 36. Software Behavior Redefinition of Testing Specified Unspecified
  37. 37. Tester Programmer Requirement Specification Analysis Design Code Test Analysis TC Design Test Execution Fix Bug Test Execution Fix Bug Test Execution ... How do we collaborate? Test Test
  38. 38. https://www.infoq.com/news/2009/12/testing-or-checking/ http://www.skylinetechnologies.com/Insights/Skyline-Blog/July-2013/Test-Planning-Part-1-Improving-Your-Test-Results 시스템이 요구사항대로 동작하는지를 검증하는 것은 테스팅인가?
  39. 39. Software Testing Redefinition of Testing Specified Unspecified Confirmation Verification Validation Exploration Discovery Investigation Learning Confirming existing behaviors Finding new information Checking!!! Testing
  40. 40. Who is responsible for that the implementation meets specifications?
  41. 41. Programmer Test ⇒ Programmer Check Programmer should prove that the implementation meets specifications by checking its’ behavior.
  42. 42. Tester Programmer Requirement Specification Analysis Design Code Test Analysis TC Design Test Execution Fix Bug Test Execution Fix Bug Test Execution ... How do we have to collaborate? Test Test Check Check Check
  43. 43. Programmer Check Strategies Strategy Description Debug Driven Development Manual Test No Automated Test Use Debugger Test After Development Write test code after writing production code Test First Development Write all test cases before writing production code Test Driven Development Write a failing test case, make it pass and refactor
  44. 44. TDD Cycle Writing a Failing Test Make It Pass Refactor Requirement (User Story) Production Code ( Solution Space ) Test CodeProblem Space
  45. 45. Test Code Requirement (User Story) function f(x) Abstract (Easy to misunderstand) Specific ( Easy to understand)
  46. 46. TDD Cycle Writing a Failing Test Make It Pass Refactor Requirement (User Story) Problem Space 1. Easy 2. Simple 1. Simple 2. Fast 1. Find a Logic 2. Make it duplicate 3. Remove Duplication 1. Change small 2. Run Test 3. Go Back If fail
  47. 47. Make It Pass TDD Cycle TC1 TC1 TC2 TC1 TC2 TC3 TC1 TC2 TC3 Writing a Failing Test TC1 TC1 TC2 TC1 TC2 TC3 TC1 TC2 TCn TC3 TCn Refactor TC1 TC1 TC2 TC1 TC2 TC3 TC1 TC2 TC3 TCn TC1 TC2 TC3
  48. 48. TDD - Knowledge # of Test Case Amount of Knowledge Requirement Solution
  49. 49. Development Phase in Waterfall Analysis Design Code Test
  50. 50. Development Phase in TDD Analysis Test Code Design Test Code Design Analysis Test Code Design Test Code Design
  51. 51. Legacy Code Refactoring
  52. 52. Legacy Code What is the Legacy Code? Old The code that I didn’t write!! Hard to Understand Hard to Change Hard to Maintain
  53. 53. Legacy Code “Code Without Test” ( Michael Feathers ) People are writing legacy code right now, maybe on your project. ( http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf )
  54. 54. Adding a new feature Legacy Code New FeaturePreserve Existing Feature You should prove that you don’t break the existing features.
  55. 55. Legacy Code Refactoring Algorithm 1. 생성자 테스트 작성 ( 테스트 픽스처 생성 비용 검사 ) 2. 테스트 커버리지 측정 3. 커버리지 데이터를 기반으로 테스트 되지 않은 코드를 커버할 새 테스트를 작성( Characterization Test ) 4. 기능을 100% 커버할 때까지 2,3 단계를 반복 5. 리팩토링 시작
  56. 56. Production Code Only (Legacy Code) Legacy Code Refactoring • Potential Bug Injection • Fear to change code • Insufficient Confidence Production Code Production Code Test Code Production Code + Test Code • Shelter to Production Code • Bugs found as soon as It is injected • No Fear To Change Code • Enough Confidence
  57. 57. Legacy Code Refactoring - One Big Step One Big Step
  58. 58. Legacy Code Refactoring Extract Method Test Move Method Test Extract Subclass + Push Down Test Extract Subclass + Push Down Test Sm all Baby Steps
  59. 59. Simple Design
  60. 60. Skills And Knowledge about Design Low Coupled High Cohesive SRP OCP LSP ISP DIP RREP CCP CRP SDP ADP SAP Coding Convention KISS Boy Scout Rule TDD Refactoring Software Craftsmanship ATDD Code Smell Don’t Repeat Yourself Simple Design You Are Not Gonna Need It! Design Pattern Unit Test Test Automation Separation of Concerns Role, Responsibilities, Collaborations Domain Driven Design POSA Analysis PatternUML Legacy Code Refactoring Law Of Demeter
  61. 61. Up Front Design How big is your up-front design? When do you design your code? How much will you pay for up-front design if you can change your design at no cost?
  62. 62. Design Spectrum Over EngineeringNo Design Simple Design
  63. 63. Simple Design 정의 - 현재까지의 문제를 해결하는 가장 단순한 설계 - 현재까지 발생한 변화의 방향을 쉽게 해결할 수 있는 설계
  64. 64. Simple Design Rules of Code Simplicity by Kent Beck ● the code is verified by automated tests, and all such tests pass ● the code contains no duplication ● the code expresses separately each distinct idea or responsibility ● the code is composed of the minimum number of components (classes, methods, lines) compatible with the first three criteria https://www.agilealliance.org/glossary/rules-of-simplicity/
  65. 65. Simple Design Principles for Simple Design ● design is an ongoing activity, which includes refactoring and heuristics such as YAGNI ● design quality is evaluated based on the rules of code simplicity ● all design elements such as design patterns, plugin-based architectures, etc. are seen as having costs as well as benefits, and design costs must be justified; ● design decisions should be deferred until the "last responsible moment", so as to collect as much information as possible on the benefits of the chosen option before incurring its costs. https://www.agilealliance.org/glossary/simple-design
  66. 66. Question #3. How? How do we practice Engineering Practices? ( A journey to be a software craftsman )
  67. 67. Start from Reading Books
  68. 68. Reading Books is not enough. Why?
  69. 69. Tacit Knowledge Once shared, it belongs to everyone. Can be seen “above the water” Tangible Visible Public Can be accessed on only a first-person basis Hidden “Underwater” Intangible Invisible Private
  70. 70. What is the most effective way to learn the tacit knowledge?
  71. 71. Work + Shop in the Medieval Period A medieval baker with his apprentice, The Bodleian Library, Oxford. Pair Baking!!
  72. 72. Pair Programming
  73. 73. Mob Programming Copy the Thinking Process
  74. 74. CSM Workshops ● Certificated Scrum Master, May 2014 ● What I learned? ○ What I read differs from what it really means
  75. 75. Michael Feathers Workshop ● October, 2014 ● First Programming Workshop ● Legacy Code Refactoring ○ How to break dependency ○ How to change legacy code in baby steps. ● What I learned? ○ How to refactor legacy code ○ How to transfer knowledge and experience!!!
  76. 76. CSD Workshop ● Odd-e At Singapore ● 1 Week Sprint ● What I Learned ○ How to make a potentially shippable product increment in a sprint ○ Specification Workshop ○ ATDD ○ TDD ○ ...
  77. 77. Steve Freeman Workshop • April, 2015 • Acceptance Test Driven Development
  78. 78. ● A Kind of Deliberate Practice ● Sites ○ http://codekata.com/ ○ http://rosettacode.org/wiki/Rosetta_Code ○ http://www.exercism.io/ ○ http://www.cyber-dojo.org ○ ... Coding Kata
  79. 79. ● Sites ○ https://www.industriallogic.com/elearning/ ○ http://www.cleancoders.com Online Training
  80. 80. Software Craftsmanship Manifesto Raising the Bar As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value: Not Only Working Software But Also Well-Crafted Software Not Only Responding To Change But Also Steadily Adding Value Not Only Individual And Interactions But Also A Community Of Professionals ( Practice ) Not Only Customer Collaboration, But Also Productive Partnerships That is, in pursuit of the items on left we have found the items on the right to be indispensable.
  81. 81. CoP - Closed Agile Talking Group ● First Meetup : 2014.5 ● Last Meetup : 2017.?.? ● Once a week ● Meet almost every week ● Product : Agile Workshop o Agile Introduction o Agile Requirement o Agile Mindset o Test Driven Development o Acceptance Test Driven Development
  82. 82. CoP - Xper Engineering Practice ● Once a Month ● Every First Monday of the Month ● Topics : TDD, Legacy Code Refactoring, Pair Programming, ...
  83. 83. Teaching Others - Learning Pyramid
  84. 84. Connected to the Global Agile Leaders
  85. 85. Great Programmer? “I'm not a great programmer; I'm just a good programmer with great habits.”
  86. 86. Great Habits Reflection leads to all the other habits. 1. How’d that last hour go? 2. What could I have done better? 3. What do I want to try next time? https://www.quora.com/Kent-Beck-You-have-been-quoted-saying-you-are-not-a-great-programmer-but-rather-a-good-programmer-with -great-habits-What-are-these-great-habits
  87. 87. Thank You!

×