Project development process worth reference

• No clear understanding of the final form of the product to be developed, no clear purpose, resulting in multiple rework, redesign.
• There is no clear development sequence, and the developed modules are not smooth and coherent, resulting in high coupling between modules and scattered codes that are difficult to continue development and maintenance.
• There is no system design structure diagram, no distinction between data level, control level, business level, display level, interaction level and interface level, so we cannot know the current development position and progress at any time, and cannot predict the time of subsequent development and the next appropriate development position.
• The code is too redundant and not elegant, mainly because there is no pseudo-code to explain the logic of each part of a function and the relationship between them.
• The code is too hard coded and not abstract enough, and when it becomes abstract, the code needs to be rewritten.
• Without considering the structural design of the data interaction, the data structure design should be isolated and packaged as a separate function for subsequent extension
• Spending too much time on interface design, time wasted on too many style tweaks.
• The test content was not written in each coding, the development progress was delayed for many times, the correctness of the code could not be guaranteed, and there were too many basic bugs.

After carefully combing the process, the following steps are roughly sorted out.

3. Documentation

According to each area and subsystem of the system, prepare the corresponding document notes, explain the function, general logic, contains the interface of this subsystem.

In addition, the process should be planned and thought about at the database level – > logical control level – > data presentation level – > interactive experience level – > interface design level.

Also consider scalability issues, whether subsystems are pluggable, whether components are strongly dependent on each other, and if necessary, complete large architectural level abstractions.

The documentation needs to outline what the test results of the subsystem module are, calculate the test steps and results of the module in advance, and the subsequent refinement of the code must pass the test requirements.

4. Technology selection

Identify the tools, frameworks, third-party libraries that each subsystem and component needs to use, as well as important syntax or class design, or programming techniques, or design patterns, and so on.

5. Confirm the development sequence

Make clear the development sequence of each part of the system, independent subsystems should be developed first, systems with strong coupling dependence should be developed last, simple ones should be developed first, and difficult ones should be developed later. Plan the development schedule. First develop the code of database level, then develop the data control level, then develop the data interaction level, then develop the data display, interactive experience design, interface development should be put last, interface development takes the most time.

6. Pseudo-code writing

Use Chinese to express logic, plus the necessary programming syntax mixed expression.

Pseudocode is required, and pseudocode must be written to the extent that the results of the code can be directly computed, that is, it can be written to determine almost 100% whether the requirements of module testing are met.

Pseudocode must be structured for data interaction.

The pseudocode must have a clear definition and explanation of the function, which explains what the function does.

7, coding

The code must follow the logic of pseudo-code, and the code should be tested many times, slowly.

Note the versioning of the code.

The code should be as elegant as possible with logic and syntax.

Special care should be taken with encoding variable names.

Each encoding should be based on a minimum of one function unit, i.e. the minimum encoding unit is a function. Once the encoding is decided, at least one function unit should be completed, or the writing of the function should be cancelled.

The completion of each function must achieve pseudocode definition and interpretation of this function, pay attention to the problems of high cohesion and low coupling.

If you don’t have high cohesion, split the logic and code appropriately.

If low coupling is not available, abstract the code appropriately and merge other functions of the same class.

8. Review code and optimize code

For each step above, if there are major problems and difficulties, you should go back up to find a solution, because these sequences have strong dependencies, so go up to the source and redesign the plan.

Because of the strong order dependence between the steps, the next step is strongly dependent on the previous step, so the previous step must be laid down in order to reduce rework redesign and planning problems.

Not every step has to be perfect, and not every step needs to be used in every project. Just like PMP, it is a routine and needs to be used reasonably as needed, but the overall planning and implementation logic should be guaranteed.

More according to this routine to complete the purpose, most of the events are training thinking and planning and design ability, coding is just a piece of the final implementation.

Copyright statement

Fundebug



Blog.fundebug.com/2019/05/06/…

Are your users experiencing bugs?

Experience the Demo
Free to use