Code Complete: Um guia prático para a construção de software

One of the most worthless and dull books I've ever read. Some right ideas and proper approaches are described there indeed but, first, they are obvious and, second, the amount of text one should absorb is 5-10 times greater that needed, in my opinion.

Further, a lot of people recommend this book to beginners which is not worthless but, I would dare to say, dangerous. Many ideas are very controversial, and to yet unformed minds they may be really wrecking.

The idea which I believe can replace the whole book is here: write the code for people to understand. Nothing is beyond that simple truth.

Эта книга должна быть одной из первых у тех кто начинает программировать. Она сразу правильно формирует отношение к разработке и указывает как надо делать и как не стоит.
Я бы выделил эту книгу в TOP10 книг которые стоит прочитать чтобы вырасти до Lead Developer.

Code Complete 2... A Review

One-liner: Read it. 3.5 stars

I came into this with super high expectations. Things I'd heard people say: "I make everyone on my team read this." or "Every developer should start with this book". So, I thought, "sweet, a great 'back to basics' book... I can't wait!". I read through this book with a host of colleagues all with quite different experience levels and in different areas of expertise.

It was the best of times. It was the worst of times.

Well... maybe not the worst, but not my favorite ;)

Needless to say the book didn't live up to my expectations... however, the book is still a gem. I think the book is best approached (especially for more experienced devs) with a 'back to basics' mindset or an 'I'm starting fresh here... forgetting everything I know' type of attitude. It can be incredibly easy to completely discount large portions of this book without that type of attitude.

The Best

The absolute best part of the experience was having a group of peers to bounce ideas off of. Many pieces of information in the book invoked questions in my head that needed some consideration. Having a discussion forum like a book club was an excellent way to solidify my understanding of things I thought I already knew, and to break down some misunderstandings with opinions and feedback from the group.

Some specifics...

Simplicity is a common theme throughout the entire book... and I think rightly so. Software has such a knack at becoming complex, and without always striving for simplicity, the complexity will overwhelm anyone.

In particular, I appreciated the performance chapters where he talks about how to improve performance (loaded term...) in your system. The gist of the story is that you have to measure. If you don't measure how do you know you got better? Developers almost always assume the bottleneck is in the wrong place (odd isn't it?). And this gem of a quote "if it isn't worth profiling [/measuring:] it isn't worth improving". PLEASE keep that in mind the next time you're performance hacking! Oh yeah... just in case that bit didn't do it for you... MEASURE BEFORE AND AFTER you enhance performance! It's so simple, really.

He talks about standardizing in many areas of the book. Standardizing on naming, style, layout, design concepts, standards themselves, etc., etc. Standardizing is great, and keeps things simple... until someone puts out an eye. It's easy after reading this thing to want to go CRAZY on standards. "Spaces here, not there; Braces here, not there; Capital letter here, and there, and there, but not over there!". "A good style applies to most cases" (emphasis mine). I think this holds true for most standards. When a standard is defined in absolutes, I think, it becomes less about simplicity and more about rigidity (BTW, simplicity != rigidity).

Steve gives some amazing stats that are often quite surprising and inspiring, and are usually well backed (although, I'm guessing he could've found stats to back any statement he wanted to make). The wealth of information and completeness of the book in the areas that it touches are impeccable and spot on.

The Worst

I don't want to hate on the book too much (or at all really), but I do have some nits to pick.

This thing is freakin' huge! I had to use a hand-truck to haul this thing around! I needed a social contract to get myself through this book. I had been trying to read it for years. A group of us set out to read this together, meeting once a week as a book club, so that gave me the social commitment I needed to get through this monster.

I felt a general 'anti-Agile' undertone, though he never really stated it explicitly. I'm no Agile Zealot, but I do like to be lean and nimble.

Many of the things I felt like I already knew, or already had opinions on. Some of his suggestions (PPP in particular) just seemed weird, and not generally (or even specifically) applicable to how I work. Maybe I was just looking to be shocked and awed by the experience and wasn't. I think had I approached some of the book with a more open mindset I might've been able to glean more out of those 'basics'.

_The_ book about the craft of programming. Not only should every programmer read it, they should reread it every several years. In the detailed view this book is an examination of all aspects of software construction, down as far as the minutia of loops and conditionals. But in the broad view there is a golden thread running through this book that ingrains in your mind: "Code doesn't just happen. You _choose_ how you write code. Strive to choose wisely."

Очень крутая книга, которая поможет заложить основы качественного кода. Поднимаются полезные темы про конструирование, проектирование. Читать лучше одновременно с изучением языка программирования, чтобы раньше выработать привычку писать правильно. Много времени посвящается принципам как писать хороший и понятный код, как правильно выбирать имена переменных, методов и классов, чтобы код был самодокументирующимся. Однозначно "must read" для тех, кто хочет посвятить свою жизнь написанию кода. P.S. Эта книга никак и никогда не сможет устареть. Эта книга о том, как писать хороший код. Практически везде автор воздерживается от упоминания конкретных технологий. Да и как правила написания понятного кода, которым преимущественно и посвящена эта книга, могут устареть?

This is one of those books that every programmer must read.

If there's one problem with this book, it's that it is too long, at 900+ pages. But, I wouldn't hold that against it. This book has tons of good information. I should have read this years ago. A lot of what I learnt over the years could have been done so earlier. Also, there were a few points that I didn't completely agree with, but I guess that's ok. Like it is said here, creating software is a craft.

The top 3 biggest takeaways from this book are
* Design is a heuristic process
* Software's primary technical imperative is managing complexity
* Code for humans first, and computers second

Required reading for those that approach software developer as a craftsman would, as an artisan would.

So it’s a #1 must read programming book according to this poll on StackOverflow. That raises quite some expectations, and if you ask me, the book doesn’t really meet them.

I mean, it doesn’t even feel like a proper programming book - it’s written in some “Easy way to quit smoking for dummies” style. Every idea is explained verbosely, then illustrated with some numeric stats, then with a 3D chart, then with some real-life anecdote, then with a reference to a 1973 paper, and finally reiterated in a checklist in the end of the chapter.

But still, this book makes a lot of good points, it’s easy to read, there’s not much prerequisites (“If you’re rusty on polynomials, they’re the the things that look like Ax² + Bx + C”) – maybe it makes sense to read it in high school.