Task granularity, software particle size

xiaoxiao2021-03-20  214

One project of the company has three subsystems, of which the A subsystem is developed first, and the development of each form class is developed by a developer, and the entire A subsystem has developed a lot of problems.

There are two main two, first, time it seems that there is no pre-plan (seemed that all software items in the company are in the company); due to the lack of communication between each other, each form class is different from the same functionality Implementation, resulting in a slightly different rendering of runtime, of course, there is obvious manpower waste to realize more complicated places.

Subsequently, the development of B subsystems is responsible for learning from the development experience and lessons of A subsystems and the idea of ​​agile software development, and I do a few important adjustments in the development of B subsystems.

The software project seems to have a concept of software granularity. In fact, I don't understand. However, I think of the granularity of the task. We can understand this, computers write a form class, if the development of the entire form class is a thicker task grain size, then the data to be processed in the form class is displayed, data Check, data export, etc. is a finer task granularity. I refine the task granularity of the form class to deal with the task of the form, and the fine task is intensively configured to study the implementation of the implementation, and then communicate to everyone, so that many people have the same or similar function point. Seeking solutions. It is a taste that is a little layered, but it is very different. The hierarchical development requires different layers to develop different layers, with each other's intersection only in the interface, parameters. I am like a person who requires a person to burn the bricks, but everyone is an architect, it is necessary to take a porcelain or a brick, just take it.

When testing, I got inspiration from "Confidential Programming", I have developed a strategy of "pairing tests". "Confidential Programming" is the concept of agile software development, defined as all product software is built with two programmers and sits on the same machine. Early non-development team efficiency, and will greatly reduce the defect rate. Similarly, I ask every two developers to sit together, talk while testing, find as many bugs as possible. The results prove that two people tests more easily, and more deeper, those comparing bugs have been exposed.

The development of the B system has used some development methods and ideas, which are the only system in which three subsystem development can be guaranteed and delivered on time. I am very grateful to my partner, they will adopt my suggestions and actively implement it.

I hope to help this article.

转载请注明原文地址:https://www.9cbs.com/read-130410.html

New Post(0)