클린코드 독서노트 1.

clean code란?
우아한 코드에 대한 신의 정의:

    I like my code to be elegant and efficient. The
logic should be  straightforward to make it hard
for bugs to hide, the dependencies minimal to
ease maintenance, error handling complete
according to an articulated strategy, and per-
formance close to optimal so as not to tempt
people to make the code messy with unprinci-
pled optimizations. Clean code does one thing
well.
                     ——  Bjarne Stroustrup, inventor of C++
                         and author of The C++ Programming
                         Language

    Clean code is simple and direct. Clean code
reads like well-written prose. Clean code never
obscures the designer’s intent but rather is full
of crisp abstractions and straightforward lines
of control.

                 ——  Grady Booch, author of Object
                     Oriented Analysis and Design with
                     Applications

Clean code can be read, and enhanced by a
developer other than its original author. It has
unit and acceptance tests. It has meaningful
names. It provides one way rather than many
ways for doing one thing. It has minimal depen-
dencies, which are explicitly defined, and pro-
vides a clear and minimal API. Code should be
literate since depending on the language, not all
necessary information can be expressed clearly
in code alone.
                             —— “Big” Dave Thomas, founder
                                 of OTI, godfather of the
                                 Eclipse strategy

In recent years I begin, and nearly end, with Beck’s rules of simple code. In priority order, simple code: • Runs all the tests; • Contains no duplication; • Expresses all the design ideas that are in the system; • Minimizes the number of entities such as classes, methods, functions, and the like.
Of these, I focus mostly on duplication. When the same thing is done over and over,it’s a sign that there is an idea in our mind that is not well represented in the code. I try to figure out what it is. Then I try to express that idea more clearly. Expressiveness to me includes meaningful names, and I am likely to change the names of things several times before I settle in.
With modern coding tools such as Eclipse,renaming is quite inexpensive, so it doesn’t trouble me to change. Expressiveness goesbeyond names, however. I also look at whether an object or method is doing more than one thing. If it’s an object, it probably needs to be broken into two or more objects. If it’s a method, I will always use the Extract Method refactoring on it, resulting in one method that says more clearly what it does, and some submethods saying how it is done.
In addition, the collection abstraction often calls my attention to what’s “really” going on, and keeps me from running down the path of implementing arbitrary collection behavior when all I really need is a few fairly simple ways of finding what I want.
Reduced duplication, high expressiveness, and early building of simple abstractions. That’s what makes clean code for me. —— Ron Jeffries, author of Extreme Programming Installed and Extreme Programming Adventures in C#
할 수 있다

직설적이고 읽기 쉽다

의도가 명확하고 실사구시, 독자의 추측을 거부

분단원,TestCase 검수 테스트가 있어야 한다

하나의 명칭 등

중복, 높은 추상도를 거부하는 대상, 방법, 유형은 한 가지 일만 한다. 그렇지 않으면 추상적으로 나와서 단독으로 실현한다.하나의 방법은 주요 논리적 목적을 추상화한 다음에 실현하고 그 중에서 서브논리로 나누어 실현한다

장점은 버그 누출, 결합 해체 등이다