This is the fifth day of my participation in the August Wen Challenge.More challenges in August

In the process of developing software, we often encounter a scenario like this: In the requirement description only ask us to provide a according to the specific requirements of function, but as a programmer, intuition tells us that in other scenarios may have similar needs, but the “don’t” scenario hasn’t really appear, is possible, also may not be a position, that we should be how to deal with the situation? In this article, how to deal with such problems will be discussed. Before we begin, let’s define the following two terms for our discussion:

  • Generality: it refers to that the design considers multiple different usage scenarios and can provide services in multiple different scenarios
  • Specific: Consider only very specific scenarios that require relatively many constraints to provide services

contrast

Everyone knows that there is no silver bullet in software development, so there is no definitive decision on whether to use “generic design” or “specific design” in business development. Here we first compare the pros and cons of the two.

Particular scenario

Advantages: generally is targeted at a specific scenario, this design difficulty will be relatively low, users of specific scenarios in also very clear how to use, reduce the burden of its cognition, which can also ensure the business online as soon as possible faults: some changes have taken place once the usage scenario, may need to put into human for development

General scenario

Advantages: When use scenarios occur, there is no need to redesign if it is within the scope of common design considerations. Disadvantages: Design is relatively difficult and can get bogged down in over-design, and the assumptions made during design may not always happen due to business changes

summary

In the above comparison, we can see that both have their own advantages and disadvantages. In current software design, we often refer to the design principle of “simplicity, suitability and evolution”. Under the simple principle, we should adopt specific design, while the principle of suitability and evolution encourages us to adopt more general design. At the same time, this principle implies that specific design should be combined with universal design so that it can be truly “simple, appropriate and evolutionary”.

merge

In most development today, we take a modular approach, where modules can be packages, classes, services, etc. The module itself can be divided into interface and implementation of two parts. In the interface part, it mainly expresses what the module can do, while in the implementation part, it is how the module does it. The interface and implementation of modules provide a place for “general design” and “specific design”, respectively.

general

The interface part of a module is mainly to show what the module can provide, and what it can do. In software development, there are two major problems: one complex, the other variable, but in the end complex. And there are three specific manifestations of complexity:

  • Changes result in many module modifications

  • Increase the cognitive burden on developers

  • Cause unpredictable problems

    However, taking “universal design” into full consideration in the interface design of modules can precisely slow down these three performances, as follows:

  1. In the interface design of the module, the “universal design” should be taken into full consideration. External callers need to mask the internal implementation of their module, so that when the internal implementation changes, it will not cause the callers to modify
  2. “Universal design” should be fully considered in the interface design of the module, so that users can deal with it only by mastering the same method in many cases, thus reducing the cognitive burden
  3. Consider “universal design” in the interface design of modules, providing the capabilities of modules in a few ways without touching the internal negative complex implementation and improving clarity

In addition, the “universal design” is fully considered in the interface design of the module, which enables designers to fully consider the strategic value of the module and ensures the continuous evolution of the module

specific

The implementation part of a module is to show how to do it, and the fundamental reason why software is valuable is because it does a specific job, and “specific design” just meets such requirements; Change is inevitable throughout the software lifecycle, and if we give too much thought to the implementation of a module, we tend to fall into the trap of overdesigning and not following the principles of “simple” design we talked about

design

After adopting “general” and “specific” respectively in the interface and implementation part of the module, two kinds of problems are likely to occur in the “general design” part of the interface:

  • The interface design can not meet the needs of subsequent evolution
  • Too much of a good thing, too complex interface design, increase the user’s cognitive burden

To avoid such problems, HERE are three questions I can ask and answer based on my own experience for you to consider when designing:

Does the current interface design meet current needs?

The point of this issue is to ensure that the current module provides sufficient value to the business

What is the simplest interface that meets all of my current needs?

The significance of this problem is that the total number of interface methods can be controlled, and by providing fewer interfaces, the requirements can be improved, thus improving the universality of the interface

How many scenarios will interface methods be used?

The point of this question is to force us to consider whether the interface’s generality is sufficient