Is your code complete? (1) -- availability and ease of use

A few days ago, infoq published a piece of news called the declaration of completion, which explores what kindCodeCan be regarded as "completed" code. Some standards are listed in this article. You can view the relevant content here.

In this case, I began to reflect on the code I had done. Have I actually completed all the code? Does your code meet certain standards and can be submitted to users for use? In fact, looking back at these questions is a bit difficult to fix. Everyone should ask themselves before submitting their own code. Is this Code actually completed?

This article mainly defines the criteria for Code Completion based on various code features:

1. Code availability and ease of use

2. maintainability and standardization

3. testability and robustness

4. overall impact on the system.

Next, I want to analyze some of my experiences and reflect on myself.

 

I. Code availability and ease of use

First, for the code (orProgram) Availability

And ease of use, this should be the most basic requirement. What is our code developed? It is not used for self-appreciation, but to be used by business personnel in the business environment. It can be said that it is tested. In this case, there may be some requirements:

A) it fully meets business requirements and accurately completes related tasks.

B) The performance is good. It should save the user's time, rather than wasting their time. They will feel good about improving work efficiency.

C) There are no complicated operations. Even if there is no relevant training, the business staff will look at it at a glance and have a basic understanding of the functions and will be able to get started quickly.

These problems seem simple, but it takes a lot of detail to implement them. Do not believe in the following scenarios:

Scenario 1:Business personnel started to complain: What you developed was not what I wanted at all. I have been doing this all the time. Why should I change the way I work?

There may be two possibilities. One is that we use advanced management theories in the developed system. The changed working method is more conducive to business personnel to complete their tasks with high quality and efficiency, we need to patiently communicate with them and persuade them to test and feel whether they can actually improve their work. Once they get used to it, it will be fine.

Another possibility is that, without meeting the business needs, the business system cannot work at all. This situation is also very likely to occur, especially in the domestic project development process, the demand analysis and outline design are not well done, it is a rush to start coding. Or, before you see the actual program, the business staff simply don't know what they want. They don't tell you what they don't want until you do it.

In this case, or for such projects, it is quite troublesome. But if you want to improve it, I have some suggestions. First, we need to strengthen communication with our customers. In this case, one principle in XP programming is "on-site customer. If we can communicate with them frequently, listen to their opinions, and follow the "targeting-shooting-adjustment" method during the development process, we can avoid a lot of detours, it is easy for users to recognize. (But in this process, you must pay attention to the communication skills with the customer. I suggest you read my translated "flirting with the customer"). The second is to put down the shelf of programmers, put themselves in the same or even lower positions as business personnel, learn from them modestly, and understand the business process from the customer's perspective, try to make their work simpler and more efficient, instead of forcing them to follow our mindset. After all, the final thing is not what we use.

Here, the problem that will be involved is change management, which is also a frequent "fight" between the development team and the customer. In fact, sometimes it is easier to solve the problem of mutual understanding and not blindly entangled in money. Think about it. If every small change is closely related, the relationship will become rigid in many cases, therefore, the customer is unwilling to tell the development team the relevant business knowledge, which is absolutely irreparable loss for us and cannot be measured by money.

Scenario 2:You are too slow. It would have taken me one hour to do this. It would have taken me two hours to use your system and I had to work overtime!

If this is not said, it must be adjusted. Many people are tempted by an idea in the school. after implementing the function, we can use hardware to make up for the performance and adjust it later. In fact, the performance should be considered not only before the development of the program, but also before the entire system, including the design of database servers and application servers, the data storage methods and space allocation in the database should all be fully done before the system starts. Otherwise, when the wall is about to fall, it will be too late!

To what extent should performance be optimized? I think the most basic principle is that it is a little better than the customer's standard. In this way, they will feel that you attach great importance to their feedback, and they will be satisfied if they have exceeded their expectations.

Scenario 3:There are too many things on your interface, so I don't know how to do it. And the operation is too troublesome. It takes many steps to complete a job.

Before there was a complete information system, a lot of business work was done using Excel and other things, which was a very convenient tool. However, after using the developed software, you must change the original work habits, such as using carriage return and tab, or adding new records; in this case, the operation control should be exposed to the user as little as possible, and the system should do the work in the background as much as possible. If you see all the strange controls on the screen, you will surely faint.

Therefore, the program to be developed is really usable and easy to use for users, and requires a lot of work. In addition, with the passage of time, a lot of adjustment work is required in the future.

 

To be continued ......