Write code for your colleagues

Write your colleagues behind you. Legend has it that this sentence came out of HP and was once famous. After agile development, it was accused of being too heavyweight and contrary to agile ideas. Many people criticized it. Agile advocates implementation when needed. Write for your colleaguesCodeYou need to think about your colleagues when writing code again, that is, for the users who use the code, how to make it easy to use. Although I am an agile supporter and practitioner, I still think it is useful to write code for my colleagues behind me. Even the idea of this sentence is not in conflict with agile development.

What kind of code is the best software code?

Easy to expand. When users propose new functions, they can quickly add new functions to the system while ensuring system quality.

Easy to modify. If it is easy to modify, it is necessary to reduce repeated code, make the code easy to read, the Code style of the entire system is consistent, the architecture is consistent, the name is consistent, and the annotations are proper.

There is also a well-defined system architecture with different levels of responsibilities, no use of unnecessary and overly complex technologies, and no use of unstable third-party libraries.

How can we make the system code meet the above standards? Good code, no matter what the guiding ideology is when writing the code.

During software development, the problem is that user requirements are unclear, requirements are constantly changing, and business logic is complex. Almost every software project has these problems. It not only enables the software to run quickly and stably, but also ensures the high scalability and maintainability of the system. It does pose a great challenge for System Design and code writing.

The most common development mode in software development is that each person is responsible for a module from start to end, from the top to the bottom. There are very few horizontal separation. Of course, this mode also has great advantages, and it is also suitable in many cases. However, one problem with the pattern code in this process is that there is little intersection with the code written by others. Generally, the upper-level code you write calls the lower-level code you write. At this time, everyone will write code for themselves. Now is what code is needed by the upper layer. We need to implement it below. This situation is common, and we often use this method. However, this has a disadvantage. Sometimes we are relatively lazy, and it is troublesome to call lower-level code at the upper layer. You can call your own code at any point. This leads to code confusion, unclear layers, complicated calls, and even the most basic encapsulation of object-oriented objects.

What if we write code for our colleagues behind us? Then we will notice that we must seal the encapsulation, and you cannot let upper-level developers write code for your laziness, which will be despised. You shouldn't write code on your own. You certainly won't write it on your own. At that time, it hurts people. Another point is that you want to make your own code very easy to use, simple, clear, and fulfilling. By the way, we have now talked about the nature of object-oriented and encapsulation. You don't need to know how to implement it. You just need to know how to use it.

So is there a conflict between agile development and this sentence? I don't think there is any conflict.