TIL (Today I Learned)

2022.02.19

오늘 읽은 범위

Foreword / Introduction / On the Cover / 1. Clean Code

책에서 기억하고 싶은 내용을 써보세요.

• There will be Code (p.2)

• Nonsense! We will never be rid of code, because code represents the details of the requirements. And specifying requirements in such detail that a machine can execute them is programming. Such a specification is code. (p.2)

• Bad Code (p.3)

• It was the bad code that brought the company down. (p.3)

• We call it wading. We made through bad code. We slog through a morass of tangled brambles and hidden pitfalls. We struggle to find our way, hoping for some hint, some clue, of what is going on; but all we see is more and more senseless code. (p.3)

• We've all said we'd go back and clean it up later. Of course, in those days we didn't know LeBlanc's law: Later equals never. (p.4)

• The Total Cos of Owning a Mess (p.4)

• As the mess builds, the productivity of the team continues to decrease, asymptotically approaching zero. (p.4)

• The Grand Redesign in the Sky (p.5)

• Eventually the team rebels. They demand a redesign. Eventually they bend to the demands of the developers and authorize the grand redesign in the sky. (p.5)

• Spending time keeping your code clean is not just cost effective; it's a matter of professional survival. (p.5)

• Attitude (p.6)

• It is unprofessional for programmers to bend to the will of managers who don't understand the risks of making messes. (p.6)

• The Primal Conundrum (p.6)

• 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. (p.6)

• The Art of Clean Code? (p.6)

• A programmer who writes clean code is an artist who can take a blank screen through a series of transformations until it is an elegantly coded system. (p.7)

• What is Clean Code? (p.7)

• Bjarne Stroustrup, inventor of C++ and author of The C++ Programming Language: 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 performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well. (p.7)

  
  'Elegant': Clean code is a pleasing to read.
  'Efficiency': Wasted cycles are inelegant, they are not pleasing.

  
  'Tempt': Bad code temps the mess to grow!
  The error handling should be complete.
  Clean code does one thing well. Clean code is focused.

• Grady Booch, author of Object Oriented Analysis and Design with Application: Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designers's intent but rather is full of crisp abstractions and straightforward lines of control. (p.8)
  'Readability'
  'Crisp abstractions': Our code should be matter-of-fact as opposed to speculative.

• "Big" Dave Thomas, found of OTI, godfather of the Eclipse strategy: 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 things. It has minimal dependencies, which are explicitly defined. and provides 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. (p.9)
  Clean code makes it easy for other people to enhance it.
  Smaller is better.

• Michael Feathers, author of Working Effectively with Legacy Code (p.10)
  'Care': Clean code is code that has been taken care of.

• Ron Jeffries, author of Extreme Programming Installed and Extreme Programming Adventures in C# (p.10)
  Simple code: runs all the tests; contains no duplication; expresses all the design ideas that are in the system; and minimizes the number of entities such as classes, methods, functions, and the like.
  No duplication, one thing, expressiveness, tiny abstractions.

• Ward Cunningham, inventor of Wiki, inventor of Fit, coinventor of eXtreme Programming. Motive force behind Design Patterns. Smalltalk and OO thought leader. The godfather of all those who care about code (p.11)
  You read it, nod your head, and then go on to the next topic.
  Beautiful code makes the language look like it was made for the problem!

• Schools of Thought (p.12)

• We Are Authors (p.13)

• Authors are responsible for communicating well with their readers.

• If you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.

• The Boy Scout Rule (p.14)

• Leave the campground cleaner than you found it.

• Indeed, isn't continuous improvement an intrinsic part of professionalism?

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• It was awesome opportunity to see how godfathers in this field think about what clean code is and how important it is. I can't wait to read this book more.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• What is LeBlanc's Law? - "Later equals never" is used in the context of software development, but may be applied more broadly to other areas. The law is attributed to Dave LeBlanc.