Personal Software Engineering Reading Notes

Personal Software Engineering Reading Notes

Today, I learned an article about improving the personal software development process. I am very touched by it, so I recorded it for future reference and spur myself to execute it.

Many people complain that the development process of their company is not standardized, the project management is chaotic, the documents are incomplete, and there are no records at this stage, and no artifacts are generated. This may all come from the management of the company, but to a greater extent, it comes from the pressure on the project, making us unable to concentrate on the fine and strict process. Is there no development in such a company? In fact, I personally think that the idea of software engineering and the control of software development processes have nothing to do with the groups on which it depends. If we really understand software engineering, implement and apply the application in our own development process, and make an analysis and comparison after the application. If the results are significant, we can certainly share them with our colleagues to influence others.

An individual software project refers to the development of its own work as a project. Since it is regarded as a project, it must have multiple stages: plan, demand, design, coding, testing, and maintenance. Of course, we can also choose several key points to improve our capabilities. For example, I personally compare my plans, requirements, designs, and tests. Others are less concerned during development.

Next I will talk about self-management in the process of software development.

L Planning and Tracking

Both management and engineering emphasize the importance of planning, and it is also

Highlights. In formal project management, we need to break down the work in the planning phase, that is, WBS, then, the activities are subdivided, sorted, the time of the activity is identified, key paths are searched, the project time, cost, and manpower are estimated. However, in our simplified version of the individual software project, we focus on it (because after all, we have limited energy). I think there are several actions that must be done.

First, identify activities, that is, there is an identifier for each activity in your development work. You 'd better add your own description to record our work, this prevents us from forgetting or missing the work we should do.

Secondly, after identifying an activity, we need to evaluate the workload of the activity, that is, to predict the actual working hours required for the activity, you can estimate the number of classes, the number of database tables, and the number of interfaces (this may be an accumulation of experience, which will be of great help for real project management in the future ). It is necessary to make a detailed record at this stage, because the record here represents your current project planning capability.

Finally, after the work is completed, compare the actual working time with the expected estimation to improve your estimation capability. I believe that it will play a major role in the future. In fact, in the process of planning and tracking, you should not forget that you should manage your own time well. It is best to record the time you spent in project activities every day, however, you can get the effective project time for 40 jobs in a week after the end of a week (maybe our base is not 40 :)). This will also help us estimate the project time in the future.

L requirement confirmation

Our development needs may vary depending on our positions, and may come directly from customers or

Business analyst or system analyst. However, no matter where we come from, we should make a request confirmation action. I think there are several important checkpoints:

First, check whether the information we get is sufficient for our design and coding work.

Second, the priority of the requirement should be clearly given.

In addition, when the demand is not clear, you must clarify the need for development to avoid rework (although sometimes you have to rework even if it is clear, because the demand changes :().

L Design

If we are programmers and programmers of companies with special procedures, we may not be able to access design,

Our requirement document may be detailed and cannot be detailed (such as tongue twisters). In this case, we may not have much room to use, however, if the design documents you have taken over are generic, you should spend more time designing them. I personally think that for our developers, the design here may involve the refinement of use cases, detailed state diagrams, activity diagrams, and code-level structural designs, such as component design, refactoring, and abstraction. We are all experts in these estimates.

L test

I don't know if there are thousands of bug rate indicators in the company's performance appraisal during development. We have! So submit

If QA testing is performed, it is impossible not to perform tests. Maybe we are used to unit tests, but for me, unit tests are also flexible, there may be no test plan, no test records, and no test analysis. But now all this is necessary in individual software engineering :) There are four points I think there should be room for improvement:

1. Do a good job in test cases, especially regression test cases.

2. Static code Lookup (I also tried to find the static code analysis tool of C #, But I was frustrated if I did not find it !)

3. Code dynamic testing (check the dynamic problems of our program, such as memory leakage and array out-of-bounds, but I have never used tools and are learning)

In addition, in individual software engineering, the test also involves peer review. Although I think this is really useful,

However, it is difficult to implement it. You can try it.

 

 

In fact, I personally think that the learning of project planning and tracking and testing has made me the most rewarding.