If you are a programmer and want to improve yourself, then these books are recommended for you.
1. Good code, bad code
In order to write good code, we must have a sound judgment on the solution at hand and think through the consequences (good and bad) of a particular approach. To do this, we must get to the bottom of the question: what exactly are we writing code to achieve? What high-level factors need to be considered to achieve those goals? The first part of the book will cover the theoretical aspects so that readers can build a solid foundation for writing good code.
Each chapter in Part II addresses a pillar of code quality, and each section addresses a specific consideration or technique. The usual pattern is to first illustrate common code problems and then explain how to improve the situation using specific techniques. Each section is organized independently so that it provides a useful reference for each reader wishing to explain a particular concept or consideration to other engineers, such as during a code review.
Testing is an essential part of creating code and software that works (and keeps working). As discussed in Chapter 1, there are different levels of testing, but unit testing is usually the type of testing that engineers encounter the most in their daily lives. The section on unit testing is introduced at the end of the book, but please don't infer from this that unit testing is an additional consideration only after the code is written. As we have seen in previous chapters, testing and testability are things we should always think about when writing code. And, as we'll see in Chapter 10, some schools of thought go even further—advocating writing tests before writing code.
The practical tips shared in this book can help you write code that is robust, reliable, and easy for team members to understand and adapt to changing requirements. Covers how to think about code like an effective software engineer, how to write functions that read like a well-formed sentence, how to make sure your code is reliable and bug-free, how to conduct effective unit tests, how to identify code that might cause problems and correct it. How to make improvements, how to write code that is reusable and adaptable to new requirements, how to increase the reader's productivity in the medium and long term, and how to save valuable time for developers and teams, and more.
2. The way to clean code
You'll see good code and you'll see bad code. You'll see how bad code turns into good code. You'll see a list of inspirations, rules, and tips. You'll see example after example. But the end result is up to you. Learning to write clean code is hard. It goes beyond asking you to master principles and patterns. You have to work on it. You have to practice it yourself and experience your own failures. You have to observe the practices and failures of others. You have to watch other people toddler and then go back and study their steps. You have to see how other people rack their brains to make decisions, and how they pay the price for bad decisions.
It takes a lot of thought to read this book. This isn't one of those "feel good" airplane books you can read before landing. This book is going to make you work, and work very hard. How to study hard? Read the code - lots of code. And you have to figure out where a certain piece of code is good and where it is bad. As we break down and assemble modules, you'll have to keep pace. It takes some work, but it's worth the effort.
This book can roughly be divided into 3 parts. The first few chapters introduce principles, patterns, and practices for writing clean code. Part 2 requires the most work. This section includes several case studies of increasing complexity. Your labor will pay off in Part 3. There is only one chapter in this part, which lists the inspirations and inspirations from the above case studies. As we walked through and cleaned up the code in the examples, we recorded each rationale for action as a revelation or inspiration.
This book presents a point of view: code quality is directly proportional to its cleanliness. Clean code is not only more reliable in quality, but also lays a good foundation for later maintenance and upgrades. As a leader in the field of programming, the author of this book gives a series of effective clean code operation practices. These practices are embodied in this book as rules (or "revelation"), supplemented by positive and negative examples from actual projects. As long as you follow these rules, you can write clean code, which can effectively improve the code quality.
The reading object of this book is all programmers and technical managers who are interested in improving code quality. The rules introduced in the book come from the author's many years of practical experience, covering multiple programming aspects from naming to refactoring.
3. Refactoring to Improve the Design of Existing Code (2nd Edition Paperback Edition)
This book is a refactoring guide written for professional programmers. My purpose is to show you how to refactor in a controlled and efficient manner. You will learn how to methodically improve the program structure without introducing bugs, which is the correct way to refactor.
Chapter 1 shows a small program with some common design flaws, which I refactored to make it easier to understand and modify. In the meantime, you can see the refactoring process and several useful refactoring techniques. If you want to know what refactoring is all about, this chapter is a must read.
Chapter 2 discusses general principles, definitions, and reasons for refactoring, and I outline some of the challenges that refactoring faces. Chapter 3 introduces how to sniff out "bad smells" in the code by Kent Beck, and how to use refactoring to remove these "bad smells". Testing plays a very important role in refactoring, and Chapter 4 introduces how to build tests into your code.
The space from Chapter 5 onwards is the core part of this book - the refactoring list.