Commercial Development, coping with changes, more thoughts, less complaints

Share less.

Recently, in the QQ group, groupmates (Technical Department) often complained about business department needs to be changed or customer needs to be changed. A brother has been angry in the group for a long time. His case is that the customer requested to change the report. The content was not required at the beginning. After the change, another version emerged. For example, four or five changes were made. This is often the case when I make reports. I have also met that a report has made six versions within five days. However, this is an extraordinary extreme example.

There is no way to do business. There are also some design errors to be changed later, and there are also demand changes. The customer is so stupid that they don't know what they want, and there are also changes that you can think of only when you have done well. It doesn't take a long time, or the customer hasn't paid yet, or the XYZ reason. In short, it should be changed. When talking about the demand, there is almost no need to change it. This is not necessarily a system issue, nor is it caused by poor management. It can be solved simply by saying "cannot be changed after confirmation, and there cannot be exceptions. All businesses are, and there is only one way to resist changes.

The change was always the same as that of commercial software. As a working employee, when things cannot be changed, why don't we try to accept them apart from resistance? Modularize and decouple I believe you have heard a lot of things. If you use them, though there are no changes, you don't have to change them. However, you can reduce the number of casualties, reduce the time required for changes, and reduce the chance of bugs. Just a few examples:

Today, we will talk about the report requirements and, tomorrow we will talk about adding the maximum and minimum values, and then we will say that if the number exceeds a certain number field, it will be marked red. If we use the gridview, of course we will be dizzy. Why should we try RDL/Rpt to change the data source, report format, and presentation independently?

The more changes,CodeIt will become strange at the beginning, and my mind is not steadfast. Why not try all unit tests at the beginning and all changes are tested once?

The format sent by a third party (for example, XML or even CSV) is not mature and often changed, but we are about to launch the service immediately. Therefore, write an interface and even perform dependency injection for independent processing, what about it?

In doing so, some aspects are not the best. For example, the first draft may be slow, for example, the design may be complicated, but it will be much more convenient to change as the changes continue to emerge. I have written this article in a week, dragging my team to modify the test and try to end it as soon as possible. The last acceptance is one or two months later. There are many such examples. The ratio of development time to post-maintenance time and change time is. After all, development is one-time and long-term.

If we talk about fast and slow runtime, most of the time is not the most important for me. commercial software, I think it is the biggest consideration to cope with changes in demand. It is very important to grasp the part that will change. Are you also facing this situation? Try to adapt to changes from another angle. If you resist it, it doesn't mean it won't happen.

The simpler the better, the shorter the code, the better. Brother's main business is bubble, not code.