On these long weekends I decided to look through the following book “Code Leader: Using People, Tools, and Processes to Build Successful Software”, that somebody recommended me recently, only for a single reason – a couple of years ago I planned to write the set of articles about the tools and approaches of the modern development process.
In this book author directs you through important aspects of modern software development process. He describes how process should be organized, which tools, libraries and patterns should be used almost for all projects. It’s not a guideline to follow, but a good sample of what to use and to support the process of development.
Book is written for those who are just stepping into Team Lead positions and want to understand the pillars of this role. Experienced guys won’t find a lot of useful stuff in this book. I’d say that book will be useful for those who have 3-5 years of development experience.
Book consists from 12 chapters and begins from the moment when project starts and guides you to debugging and error handling.
Chapter 1: Buy, Not Build
Chapter 2: Test-Driven Development
Chapter 3: Continuous Integration
Chapter 4: Done Is Done
Chapter 5: Testing
Chapter 6: Source Control
Chapter 7: Static Analysis
Chapter 8: Contract, Contract, Contract
Chapter 9: Limiting Dependencies
Chapter 10: The Model-View-Presenter (MVP) Model
Chapter 11: Tracing
Chapter 12: Error Handling
I would like to highlight the most interesting sentences in this book
- “Writing code is fun, but writing high-quality code on time and at the lowest possible cost is what makes a software project successful”
- “They don’t hire us to write code. They hire us to solve problems using software”
- “The key is evaluating the benefits versus cost at the level of individual software components”
- “Writing software that could have been purchased at less cost is a good way to get your project cancelled”
- “The important part is to focus on the key piece of your project, which provides the most business value to your customers. That is, after all, our real job. Writing code is fun, but what we really do is solve problems for business owners.”
- “The idea was that writing your tests first forced you into thinking about tests, which in turn encouraged you to write more”
- “The primary tenet of Continuous Integration (CI) is ‘‘integrate early and often.’’ The more often you integrate, the less work it is for everyone”
- “Nothing paralyses a team faster than trying to reach consensus on every design point”
- “It really requires the architect to be involved at code level across large swaths of the software”
