Robert.C.Martin

Author's career is differ from that of mine. Also he is even younger than me. Different working locations, culture, and even nationality. Only one Common between author and me is we are programmers. That's enough.

This book is whole about repeating the professionalism. not only as an programmer, but as organizational sight. yeah, this book is about software craftsman. it handles large amount and areas like:

• design pattern
• pair programming
• TDD to process
• dealing with tight date planning
• Job interviews for developers and hiring document writting
• coworking methods with coworker and manager

This book is for some developers, team-leaders, managers who return from his working and whisper himself "Today was hard and awesome. nice works i did."

Junehan

As a developer, I sometimes get mazed by myself. And i can't tell myself i'm doing that good, and keep my head towards to something great because of me or little out world happenings around me which usually happends and useless. But i know i did something towards to be better many days, while passed some deep lazy days on this journey, me doing this works for about 2 year and few months, this is something handle me tight. This book was just like someone who Could tell me you're ideals, hopes and little steps towards Great masters was not useless but means. so keep my faith hard and be hard for me much more. As Robert.C.martin said in recommodation, this book does cover real bunch of areas in software development. (so i skipped really a few chapters...)

What a Software craftsman is?

Long Journey being a mater.

It means to responsible for his every choices in career, learn continuous for new tools and technics.

software craftsman is stands for:

• responsibility
• profassionality
• pragmatic
• self proud as a software programmer

What we do?

"We are not compatiting. In long life of software, there is compatiting with someone pursuing only for money with no any honer or just to finish their work with only a fast."

Manifesto

We as admiring the software craftsman,

• we keep our technics sharp,
• we help other people to learn the technics

to level up the software development.

By doing this, we Pursue the valuables as below

1. Not only working software, but also elaborate and skillfully created.
2. Not only reacts to changes, but also more valuable.
3. Not only cooperate each, but also Keep the community of professionals.
4. Not only cooperate with customer, but also effective co-working relations.

while pursue in the first(normal thickness) elements, next elements(Bold thickness) are irreplacable.

This Menifesto contains experienced difficulties, pursuing valuables, and admire by experienced and talented developers.

The project should not be failed because of leak of management, designed order in wrong way and stupid code.

does working-software recognized as well made application?

Real good one,

• Must be easily understandable at any time by developer.
• Side effects should be recognized and managable.
• Should have high coverage of code and testable.
• The Code must have simple design and well documented in business terms.
• Adding or modifying the feature should be done like as developing just started.
• Code base should as small as possible.
• Source code should be expectable and keep in fixable state.
• Modification should not be fearing situation.
• If change in spec occured, only partial modules should be affected and has no ripple effect.
• Automation in testing should be done in few minutes or secs, and able to sense the wrongs.

How application to be evaluate,

• Developerss should not have any fear to modify the code base.
• The code with, TDD, Simple design, descripted in business terms are the best ways to keep code healthy and in well-made state.*

Treated as Professional in work?

Hire the software craftsman

Craftsman is gardener.

Craftsman continuously cares the code base and refactor fast without any fear.

Craftsman have automated test which can be done in a few minute, and knows how to handle them.

Craftsman cannot have excuses for Constraints for time lefts or spec changes.

Execution convention and value

Values in Business of Test suite?

Refactoring in pragmatic conception

Refactoring without pragmatic conception is highly dangerous. Behave as a professional means understanding the tradeoffs. Entire system can be improved at sametime, but that can be useless. Refactoring the legacy Base code which is changed for few years is meaningless. After all, if Codebase need not be modified? then no need to refactor them. Refactoring should start from more frequently modified codebase. BoyScout rule should applied to not everything but actual specified part, which is understood to needs modifing.

Three Elements Motivates intellectual worker?

In Daniel Pink's book Drive: The Surprising Truth about what Motivates, Money is basic condition to be satisfied, Motivates the Intellectual base worker is,

1. Autononmy The State that We do control what, how and when. A fine Agile develop environment should guarantee them.
2. Mastery Improves and evalutation To be The better professional, better Person.
3. Sense of Purpose Sense and feel what I do now is important and making something better. Opposite concept of no any understands of things, and doing what someone orders only.

Does Good software takes long?

Software craftsman usually mastered execution process sets like TDD, So Following those sets never means to delay in working process. No other software or project will be bottlenecked by typing to them.

When to refactor and how refactoring has to be?

1. When to refactoring?

   If Legacy code base affects to new feature, then, before adding the new one, Should refactor those legacy.

   2-Questions before new feature:

   • Does legacy code base is prepared for applying new feature?
   • How many code base are need to be modified?

   If previous 2 question's answer is "no" and "A lot", We should refactor the old one.

2. How refactoring has to be?

   We have to make legacy to be easily appliable.

   Easily to appliable

   Means not change or modify in whole base, But Make minimize the affect from new feature. That is, OCP principle, (Open to Expansion close to modification) Refactoring.

The Pragmatic way of application Improvement

Refactoring order will better to,

1. Make it work,
2. then improve gradually.

Pragmatic way to improve application is,

System Change happens by actual Need, and little refactoring continuously upon them.

Extraordinaries and Well made

Extraordinary developers pursue even more than the simple and short one. They try to find the way not to write even 1 line of code. The Great code is the code that needs not to be written.

Well written code is,

• simple
• small
• able to test
• easy to understand
• And Code do what they have to do

Four Principles by kent beck

1. Should pass entire test.
2. Should be clear, enough expressed, consistent.
3. Should have no duplicates in behavior or configuration.
4. Count of Method, Class, Module to be as less as possible.

Skilled in XP execution convention

Basically TDD, If we skilled in Agile and XP execution convention, Writing the Future-expected-General-Code(if it exist) will be replaced to Writing the concrete code which are Actual in need.

Future preparing abstraction: YAGNI

Without any reasonables from currect need, Abstractions with concerns like "Have to prepare the future." will make application Trash. Why? We don't know what exact part will need to be modified, so abstraction by more complexity with more appliable code will be generated. Preparing Application to be evolve, change in someday's Possibilities could be considered as Smart actions, But Truth is, at contrast, that much stupid work.

Before applying design pattern

Before applying the pattern, Refactoring which is proper to problem should be tried to make code Simple design and follow the SOLID principle. After that, if our refactored solution is simmiar to specific design pattern, We can refactor them to be oriented by that pattern.

General Code

General code can have more expandabilities then non general ones, But They are complex than specific ones. Must pursuing the General code, that is a thing should never happened. but rather to be find specific code to find solution, and if needed to be generalized, It can be.

A Code with Craftsmanship and Pragmatism

Code written in Fast doesn't mean dirty code. Large Project doesn't mean BDUF(big design up-front), or over-engineering. Clean and fine written code is always important. Clean and fine code will be the base of safe-changing by the need of business. It is best way to help business that to change code in fast speed depends on spec changes.

Craftsman's role

As a craftsman, our role is to low the price of product while not making issue. To do so, we need to master the Good Execution conventions and stand in Pragmatic. In many different Contexts, We have to understand what each conventions values are.