They had rushed the product to market and had made a huge mess in the code, As they added more and more features, the code got worse and worse until they simply could not manage it any longer, It was the bad code that brought the company down
80년대 어떤 회사에 대한 이야기이다. 급하게 기능을 추가하면서, 더러워진 코드에 계속 기능을 추가한다. 상황은 계속 나빠지고, 결국 bad code는 회사마저 무너뜨렸다.
As the mess builds, the productivity of the team continues to decrease, asymptotically approaching zero, As productivity decreases, management does the only thing they can; they add more staff to the project in hopes of increasing productivity. But that new staff is not versed in the design of the system. They don't know the difference between a change that matches the design intent and a change that thwarts the design intent. Furthurmore, they, and everyone else on the team, are under horrific pressure to increase productivity. So they all make more and more messes, driving the productivity ever further toward zero
더러운 코드가 생성됨에 따라, 팀원들의 생산성은 zero에 수렴한다. 이러한 것을 이겨내기 위해서 매니저는 직원을 채용하지만, 새로 들어온 직원들은 코드의 의도조차 알 수 없다. 결국 팀원들은 생산성을 올려야한다는 압박감에만 휩싸게 되고, 그럼에도 생산성을 zero로 향해간다.
You will not make deadline by making the mess. Indeed, the mess will slow you down instantly, and will force you to miss the deadline. The only way to make the deadline - the only way to go fast - is to keep the code as clean as possible at all times.
코드를 어지럽히면서는 기한을 맞출 수 없을 것이다. 더러운 코드는 결국 당신을 느리게 만들고, 기한을 지킬수 없게 만들 것이다. 기한을 지키지 위한 단 하나의 방법은 항상 clean code를 유지하는 것이다.
In short, a programmer who writes clean code is an artist who can take a blank screen through a series of transformations untils it is an elegantly coded system
clean code를 작성하는 프로그래머는 빈 화면의 시작부터, 코드 시스템이 elegant 해질 때까지 지속적인 변화를 주는 것이다.
Clean code is focused. Each function, each class, each module exposes a single-minded attitude that remains entirely undistracted, and unpolluted, by surrounding details.
clean code는 포커싱이다. 함수, 클래스, 모듈 각각은 단 하나의 목적을 가진것으로 많은 detail로 인해서 어지럽혀지지 않아야 한다.
There is, after all, a difference between code that is easy to read and code that is easy to change
코드는 읽기 쉽고, 수정이 쉬워야한다.
Code, without tests, is not clean. No matter how elegant it is, no matter how readable and accessible, If if hath not test, it be unclean
테스트 코드 없이는, clean code가 될 수없다. (TDD의 중요성에 대한 내용이다.)
It is not the language that makes programs appear simple, It is the programmer that make the language appear simple.
프로그램을 간단하게 만드는것은 언어가 아니다. 프로그래머가 해야한다.
Because this ratio is so high, we want the reading of code to be easy, even if it makes the writing harder. Of course there's no way to write code without reading it, so making it easy to read actually makes it easier to write
여기서 말하는 ratio는 실제로 read code : write code의 비중이 10 : 1 정도라는 것이다. 읽지 못하면, 코드를 쓸수도 없다. 비록 쉽게 읽을 수 있게 만들기 위해서, 잘 쓰는 것이 쉽지 않지만, 결론적으로 읽기 쉽게 만들어야만, 쓰기도 쉬워진다.
isn't continuous improvement an intrinsic part of professionalism
지속적인 개선은 유능한 전문가의 필수적인 요소가 아니겠는가?
