My understanding of hierarchy (3)

When I came to work overtime on Sunday, there was a bit of resistance in my mind against the boss. because there will be another project tomorrow. busy again. so I decided to write down my understanding of hierarchy today ..OK... let's talk about it in a few minutes ..

As mentioned in the previous two articles, if you plan for the early stage in the project development process, you can say that if you do a good job in the early stage of development, it will certainly drive development efficiency and reduce the workload during maintenance .. summary of the hierarchical relationship in project development today ..

First, in the project development process, use interfaces to manage and constrain your projects (for the concepts and advantages of using interfaces, refer to my other summary of interfaces and classes ).. avoid inconsistent development and naming of functional modules ..

Second: rationally allocate documents .. for example, in May August 1, the project was launched and the Project Manager issued documents .. in March August 5, there was a new demand change for the project .. the Project Manager modifies the decentralization document .. on July 6, August 7, the project was changed again .. OK .. continue to modify the decentralization document .. however, the customer suddenly canceled the change and requested to change according to the demand in August 5 .. the problem arises at this time, because Program Developers are developed based on the decentralized documents. Every time you change, Code It may need to be modified .. for this cancellation, you may need to re-develop the document requirements in April August 5 .. for such a situation .. if frequent occurrence occurs .. it will cause great trouble for project progress and management ..
My solution: 1. Change project requirements, do not modify the decentralization document, and issueRequirement change document.. And keep the decentralized document .. and save the code before this change .. one advantage is that the project progress is transparent. for a project with frequent changes, it is difficult to complete the development according to the expected time (the only solution is to work overtime ^_^ ).. delegate each requirement change in the form of a task ticket .. it is easy for boss to understand the project strength (this is the key to promotion and salary increase ).. second: solved the problem of repeated code development .. if the customer requests to restore to the previous requirement .. OK .. recall the function requirement of the deposit order to be replaced .. third, this change is useless even if you archive the function code. but will it not be used by other customers in the future ??

For threeArticle, I made the following summary:
1. Optimize functions and make reasonable plans for the function structure.
2. Compile the code reasonably, add comments... make your code easy to maintain... each class should have detailed comments. If necessary, add an example of class operations.
3. Use interfaces reasonably and efficiently to standardize programs. Add Rules to classes. Make projects easy to manage ..
4. Establish a project document management system to make the project transparent.
5. Increase code reusability as much as possible and archive the code... accelerate future project development ..

write here .. I looked at the previous two articles and found that I had a problem. haha .. I wanted to talk about the experience of layering .. who knows how to write it into the project management experience .. but it's not so bad... the above content is my personal experience and feelings in the company's project development .. hope to help you in development .. if you have good project development experience, you can make progress together ..