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. Someone who is very skilled at software
development.
Software Craftsman
7. How does a craftsman prove that he is
a skilled person?
QUALITY
8. How does a Software Craftsman
show that he is a skilled person?
QUALITY
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. 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. 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. 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?
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.
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.
32. Refactoring
is a discplined technique for restructuring an existing body
of code,
altering its internal structure without changing its external
behavior.
35. 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?
44. 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
47. 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
53. Legacy Code
What is the Legacy Code?
Old
The code that I didn’t write!!
Hard to Understand
Hard to Change
Hard to Maintain
54. 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 )
55. Adding a new feature
Legacy Code New FeaturePreserve Existing Feature
You should prove that you don’t break the existing features.
56. Legacy Code Refactoring Algorithm
1. 생성자 테스트 작성 ( 테스트 픽스처 생성 비용 검사 )
2. 테스트 커버리지 측정
3. 커버리지 데이터를 기반으로 테스트 되지 않은 코드를
커버할 새 테스트를 작성( Characterization Test )
4. 기능을 100% 커버할 때까지 2,3 단계를 반복
5. 리팩토링 시작
57. 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
61. 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
62. 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?
65. 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/
66. 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
67. Question #3. How?
How do we practice
Engineering Practices?
( A journey to be a software craftsman )
70. 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
71. What is the most effective way
to learn
the tacit knowledge?
72. Work + Shop in the Medieval Period
A medieval baker with his apprentice, The Bodleian Library, Oxford.
Pair Baking!!
75. CSM Workshops
● Certificated Scrum Master, May 2014
● What I learned?
○ What I read differs from what it really means
76. 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!!!
77. 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
○ ...
81. 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.
82. 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
83. CoP - Xper Engineering Practice
● Once a Month
● Every First Monday of the Month
● Topics : TDD, Legacy Code Refactoring, Pair Programming, ...
88. 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