After a project's exercise, I feel that I have made great progress!
Summary now:
1, demand report. Before the project is officially launched, as much as possible, try to describe the needs as much as possible, but the demand must not be too dead in detail, it is best to abstract. Particularly reflecting the logical changes of business strategies, especially flexible, this avoids writing this part of the code too much when designing. In fact, if you can determine all the needs is the best, this I also want, but it is impossible in reality, and there is a constant demand change in the process of coding. This has enough programming levels to ensure that your code can cope with changing demand.
2, system design. I used to imagine a project. It is inevitably by one or more system architects, first doing a face design, and then coded by programmers, which we know that our project requires everyone to participate in design. I think this is very good, so that everyone can have a deep understanding of this system, most likely to produce higher quality procedures, and can also reduce the burden of system architects, and you can exercise everyone! However, this requires everyone to have a certain level of design and understand the business. If each person is designed a subsystem, you need to consider the docking problem between each subsystem, otherwise it may seriously affect the progress of the project.
3, coding specification. Coding specifications should be required for each project, such as named, case, code style, etc. I think this is not required, but it is also beneficial!
4, documentation. Possible people don't like to write documents, I don't like writing documents, especially with code-related documents, each code has a little change, then documentation will make corresponding changes, often make a document code Synchronize, this will eventually lead to unusuristic documents. I have a deep understanding! I think it is best to have a special document writing personnel in the project, and don't be too intended in the development process. There are also developed documents to do with some third-party tools.
5, resource management. I want to use resources in the program you develop (such as resource files, data files, profiles) I think everyone should be very clear, then how this resource is stored, how to naming should be determined in the project. If the encoding is later determined, it may cause unnecessary trouble.
6, database. If there is a dedicated database administrator and the database designer, then say it. If everyone involves database design and implementation (in each person involved in design), then be careful not to repeat. For example, many log tables, some universal stored procedures are all shared.
7, staff division, project technology. In a project, project managers must know the strength and special length of each member of the project group, and each group should be assigned to his most suitable task, of course, many group members do not have outstanding specialty, or project Managers are not very clear from everyone's strength. Many group members are assigned to their tasks that are not suitable for their own, which is very dangerous to the entire project. There are also what technologies before the project begins to be clear, and the team members should be prepared, otherwise it is very dangerous if they want to temporarily learn a new technology, which is likely to not get high quality products.
The project is still in progress, and my experience is constantly accumulating. I found that after learning a lot of theoretical knowledge, I have been huge after a certain practice.