Notes 1 for Agile Software Development

Today I am reading chapter 7 of <Agile Software Development: Principles, models, and Practices>. I read the odor of software design in section 7.2-the smell of corrupt software.
When the software smells like any of the following, it indicates that the software is corrupt.
Rigidity: it is difficult to make changes to the system, because every change forces many other changes to the other part of the system.
Vulnerability: changes to the system may cause problems in many areas that are conceptually irrelevant to the system and the changes.
Strong: It is difficult to turn on the tangle of the system to make it a component that can be reused in other systems
Viscosity: Doing the right thing is more difficult than doing the wrong thing
Unnecessary complexity: The design contains an infrastructure that does not have any direct benefits
Unnecessary repetition: The design contains repeated structures which can be unified with a single abstraction.
Obscure: difficult to read and understand. Not showing intentions very well

These so-called "smells" are taken from agile software development: Principles, models, and practices. Here are some of my thoughts on these bad design habits.
As a designer or programmer, there will always be such bad habits that lead to a software always not appearing as a satisfactory prototype.
For rigidity, many developers did not fully consider it at the beginning of the design. Many functional implementations are only satisfied with achieving the final effect. For code optimization and structure design, they are all placed behind the scenes, which often results in unpredictable consequences. When he wants to modify a small part of the Code, he will find that, in fact, he still needs to modify more other part of the code at the same time... So tired, why...
For vulnerabilities, when changes occur in one place, there will be more irrelevant places that need to be changed. Developers often know that these areas need to be re-designed, but they are too lazy to redesign it. Such consequences can be imagined. During the development process, our team often encountered such problems. We knew that some areas were not perfect and we needed to design them again, but no one had such patience, I would rather constantly "patch" it than give up unreasonable design and try again... Sad...
For the robustness, the system often contains some useful parts for other systems, but it is really difficult to keep it independent. During the development process of our team, some useful system components are often designed. Although not too large, there are not too many functions, they are some very common components, few people want to separate these parts into a separate "component" to prepare for other systems in the future. The consequence is, of course, re-writing the code every time and re-considering integration ..
I don't have much experience on this point. I don't want to introduce my ideas first...
For unnecessary complexity, some unused parts are often introduced when implementing system functions. This may not be taken into account at the beginning of the design. when integrating functions, after careful inspection, we often find many such parts exist. Some structures that are never used. I think this should be a mistake made by many developers. Our teams often make such mistakes.
This is a literal explanation of unnecessary repetition. There is no need to introduce too many ideas here. For this, I think developers should have good development habits to make their code more concise.
For obscure, developers' code always produces millions of code formats due to their individual styles. Although this is understandable, it is often because of this that many codes become hard to read or even do not understand. I have had this experience since I started programming. In the beginner stage, we always focus only on results and do not care about the code format. It seems that the code is really unreadable. Later, some people and books have influenced my habits. Maybe, in the future, I will improve the Code style more...

These ideas are just some of my personal thoughts. For this book, I would like to say that it is a good book...