Work comments-1-build a complete solution

Preface:

Recent financial crisis-the economic crisis has led to a significant reduction in projects. Thanks for giving me a chance to think.

I want to organize my work experiences in recent years and prepare for future work.

 

 

Preface:

Today I wrote: Build a complete solution. The reason is that in the past few years, there have been frequent "demand changes. We have worked hard to find a solution for many years. If we want to solve the problem, we may still find ourselves, because our original foundation is incorrect. The customer does not really know their own needs. Do we really understand the meaning of this sentence and how should we be right?

 

1. What is "complete solution "?

As the name implies, the "complete solution" includes all the real needs of the customer and can be implemented reasonably. The definition is very simple. Just like go has only black and white, the only problem is that there may be more changes and the uncertainty is higher.

Compared with go, software requirements and solutions are much simpler.

The main problem is that our "requirements" ignore the invisible requirements of many customers.

What are the invisible requirements? This generally includes:

1.1 maintenance requirements

1.2 upgrade requirements

1.3 ease of use requirements

1.4 Performance Requirements

Basically, the customer is still maturing, and the above requirements will be mentioned more or less. However, please note that it may not be comprehensive enough. Therefore, we need to seriously consider what these requirements should contain.

 

• Maintenance requirements

The customer's maintenance requirements generally include at least the following:

1. Log requirements. This is complicated and will be considered separately later.

2. Ability to locate faults. That is to say, when a system encounters a problem, the customer wants the system to quickly identify the cause of the fault and find a solution or solution to the problem.

3. routine maintenance. This usually includes "health checks" for software and hardware ".

4. fault alert. When a serious fault occurs, the system can provide sufficient information and trigger the fault handling process.

• Upgrade requirements

Generally, the customer's requirements for upgrade are as follows:

1. Controllable upgrades. That is, it can be controlled to check whether the upgrade is possible, whether the upgrade is performed, the selection of multiple upgrade targets, and the planned upgrade tasks. For example, it can be set to automatically check whether the upgrade is performed; set the automatic upgrade to the maximum version. Set the upgrade to manual. Set the manual upgrade to upgrade immediately or specify the scheduled task time.

2. Business upgrades are not affected. Basically, customers want to upgrade their services without affecting them. However, some systems are too old. The redevelopment projects based on these old systems must be limited by the original system upgrade solution. In this case, consider: 1. Can the system be upgraded without affecting the business? 2. If not, how to minimize the impact of the upgrade on the business.

3. Upgrade simplicity. The upgrade should be simple and quick, with no too many parameters to be configured and too many steps requiring manual intervention.

4. Integrity of the upgrade. Especially for Distributed Systems, version consistency between components must be considered during upgrade. An upgrade solution must be complete, and the system cannot work after the upgrade due to incompatibility between versions. For example:
How to design a simple CS system that uses encrypted channels for communication and now upgrades the encryption algorithm?
Suppose it's an Internet application with tens of thousands of clients. How should we design it?
From this example, we can see that these "implicit" requirements must be taken into account in the system design from the very beginning, otherwise the system architecture may have to be overturned.

• Usability requirements

It is usually mentioned that usability is nothing more than interface and help. Yes, but not all.

Let's take a look at several examples to understand the concept of usability.

• In the competition for desktop systems, the professional and powerful Unix system has failed to the Windows series that are frequently criticized. Because windows is easy to install, easy to upgrade, and easy to install new games or software, this is especially true for operations. Although the intuitive graphic interface is not very rich and powerful in design and functions, it is necessary to learn the concept of "File System" before learning the command line, the concept of "Tree" allows users to communicate with each other without any knowledge, and even drag and drop operations are comparable to command lines;
• Similarly, Microsoft uses the C ++ language as Microsoft's name. The advantage of the operating system is that the language and development environment are not powerful, but what is the result? In IDE, most people still use Si. In terms of language, Microsoft has to launch C # To compete with Java. This is because it is easier for Si to look up the context when reading code; Java is easier to develop than C ++;
• In the competition for Chinese input methods, the powerful and efficient pen-and-video input methods were defeated by Pinyin input methods. Currently, Pinyin input methods are widely used, and stroke input is rarely mentioned.

Most importantly, the business model must be consistent with the customer's. This should be the foundation. The business model represents the thinking model (such as the input method). That is to say, we need to design the system from the customer's perspective, rather than mechanically piling up data and processes.

In general, the usability requirements include:

1. Common functions should be directly accessible. For example, in a financial system, different roles have different common functions. The system should be designed to open different initial pages based on roles. For example, in a common game, the Save/load menu is usually on the home page. No one is designed to read the progress only after watching the titles (which cannot be skipped), create a new game, and kill the Access Point all the way.
Strict academic classification is not recommended here. This may seem very professional, but it is not easy to use.

2. the operation should take care of the customer's habits and minimize the learning cost of the customer. Of course, the premise is to correctly locate your customer base.

3. elegance. For example, log.
When writing logs, do not write a 7 or 8 GB log file in one breath, as far as possible according to certain standards to classify and split. For example, by time, by log level.
We also use vs studio in MS as an example. For compilation errors, you can directly jump to the source code by double-clicking. Unlike makefile, it is just a blunt output file and line number.
Open a huge file and give a measurable progress bar. Is it better to show only one hourglass?
Now, what is "Elegance? My understanding is professional and considerate.

• Performance Requirements

It seems that the performance requirements have been paid more and more attention, so I will not talk much about it. In a simple sense, it includes:

1. First, identify the performance requirements of each part. User-involved operations generally require higher performance than other operations.

2. Know your upper limit. When the upper limit is reached, the system should be prompted in a reasonable way, instead of being paralyzed directly. Of course, this is idealistic. It can only be infinitely close and cannot be reached;

3. Performance requirements must include reliability requirements.

Performance needs to be designed rather than implemented by hardware alone. Therefore, when the customer does not mention performance requirements, you need to identify the performance requirements of the system through various channels. The result of "try it first" is often to repeat it. Zi Yue "targeted" is also.

• Log Requirements

Finally, let's talk about the log Requirements.

The log requirement is a requirement that is closely related to the customer's implicit requirements and involves almost all of them. For example, to record maintenance information and upgrade information in a log, the log must be simple and clear. You can see what the log means at a Glance. In addition, the logging function cannot have a major impact on the system performance.

In fact, the full name of "log Requirements" should be "what customers and we want to do with logs ".

(Dizzy, just finished writing, click "Post", the result is only the above, and it has to be rewritten)

Based on my experience, I think the log Requirements should include the following:

1. Logs must record key events and data (maintainability), such as operators, operation names, and results;

2. Log content should be easy to analyze and filter (easy to use), such as configuration data and user operations;

3. The log level should be dynamically adjustable. Java log4j is a good start, but the method of "modifying the configuration file and restarting the system" cannot be dynamically adjustable. In the actual system, most customers do not restart their systems because they view logs.

4. The log level adjustment granularity should have sufficient levels and sizes. The log level of the entire system, a module, or even a class can be adjusted. Both Java and C # Have ready-made modules available for implementation (that is, "Dynamic Adjustment" is not enough ). I am not very familiar with other languages. I don't think it is very difficult to develop a self-developed module.

5. log output formats and devices should be controllable. For example, when a specified log is output to a tape drive, if the tape is changed, the system operation and log records should not be interrupted. In addition, logs are often used to locate faults. If the output is controllable, it is possible to write a dedicated tool to receive and filter log information, so as to locate problems that are difficult to reproduce.

6. Log performance. Where to write logs and what to write are usually written in the code, you can only control whether to output logs. If a large number of operations (such as String concatenation and serialization) are performed before the log output is called, the system performance will be greatly affected. It is best to put it in the code, this ensures that these operations are performed only after they are determined to be output. The specific implementation is benevolent and wise. There must be a balance between log interfaces and conciseness and efficiency.

 

Now, let's write it here today. Plan the next article to write about how to embody the customer's invisible needs in the project.