One of the reading notes of Agile software development

One of the reading notes of Agile software development

To become a good software developer, you need to be proficient in the application of programming languages and development tools, and more importantly, to understand the principles behind the Code and the experience of previous generations--this is the subject of this book. This book is a world-class software development master Robertcmartin Decades of software development and training experience, not only a simple, vivid and understandable object-oriented principles and patterns of work, but also a popular Agile Method guide book and fast Practical UML tutorial. Divided into agile development, agile design, payroll case studies, packaged pay system, weather station case studies and ETS case studies six sections, including 30 chapters. Here are my thoughts and insights on the first two parts:

The following six chapters are the first part of the understanding and insight into agile development:

The "Agile Practice" chapter tells you that every software developer, every development team's career goals, is the most likely value for their employers and clients to interact, but our projects fail at a frustrating rate or fail to interact with any value. Although it is well-intentioned to adopt a process approach in a project, the method of expansion is at least a liability for our failure. The principles and values of Agile software development form a way to help teams break the process expansion cycle, and this approach focuses on techniques that can achieve team goals.

Extreme Programming Overview Describes extreme programming as a set of simple, concrete practices that combine to form an agile development process. This process has been used by many teams, and has achieved good results, extreme programming is an excellent, universal software development method. The project team can take it directly, add some practice, or modify some of these practices before using it.

The plan reveals that when a project enters a predictable and comfortable development rhythm, the only person who can actually see the actual progress of the project is the stakeholder, and using the Agile development approach does not mean that it can achieve the desired results for the stakeholders, simply means that they will be able to control the team to get the maximum business value at the lowest cost.

The most important benefit of "testing" is its impact on architecture and design in order for a module or application to be testable, it must be decoupled, the more testable it is, the weaker the coupling relationship. Thorough consideration of the behavior of acceptance tests and unit tests has far-reaching positive effects on the structure of the software.

"Refactoring" after the program is much better read than normal, the program is better, its purpose is to clean your code every day, only the code is clean, we can expand and modify our system.

"One-time programming practice" tells us that diagrams are sometimes unnecessary, such as when the code that creates them is going to loop them, the diagram is useless. It is not wrong to draw a picture to explore an idea, however, after drawing a picture, it should not be assumed that the diagram is the best design of the relevant task, the best design is one small step to form.

Here's what I learned from the second part of "Agile Design":

The chapter on "What Is agile design" illustrates that agile design is a continuous application of principles, patterns and practices to improve the structure and readability of software, and it is committed to keeping system design as simple, clean and expressive as possible at any time. and agile developers don't apply those principles and patterns to a large, pre-engineered design, which is applied over and over again, trying to keep the code and the design that the code is expressing clean.

The "single Responsibility Principle" describes the SRP as one of the simplest of all principles and one of the hardest to apply, and the real thing about software design is to discover responsibilities and separate those accusations from each other.

The "open-closure principle" can bring about the great benefits claimed by object-oriented technology, not to say that as long as you follow this principle with an object-oriented language, it is also not a good idea to abstract every part of the application in an arbitrary way. The right approach is for developers to abstract only those parts of the program that exhibit frequent changes, rejecting immature abstractions as important as abstractions themselves.

If the "Liskov substitution principle" is applied effectively, the application will have more maintainability, importance, and robustness. It is the substitution of subtypes that allows modules that use the base class type to scale without modification. If you do not have a display to enforce the accumulation of types of contracts, then the code must be good and obvious to express this.

The "dependency inversion principle" strategy is a matter of detail, and object-oriented programming inverts the dependency structure, making the details and strategy dependent on abstraction, and often the customer has a service interface, which implements the basic underlying mechanism of the benefits claimed by many object-oriented technologies, Its correct application is necessary to create an important framework. At the same time it is very important for building flexible code in the face of change, because the abstraction and detail are isolated from each other, so the code is also better maintenance.

The "interface Isolation principle" exposes the unhealthy and harmful coupling between fat classes and their customer levels, and client programs should rely solely on the methods they actually invoke, which can be achieved by decomposing the fat-like interface into multiple client-specific interfaces. Each client-specific interface declares only those functions that are called by its specific client or client group. The Fat class can then inherit all the client-specific interfaces and implement them. This relieves the dependencies between the client program and the methods that they do not call, and makes the client program independent of each other.

One of the reading notes of Agile software development