Summary and Thoughts on launching a large project

I recently experienced a project development and launch that is not small in size. After that, I felt a lot and felt a sense of accomplishment. However, I also had a lot of experience and lessons. I would like to summarize and write them down for future use.

Note: Due to confidentiality issues, some details are vague.

1. Compatibility with legacy systems

This project is mainly used to completely upgrade (rewrite) the old version of the system to the new version. However, because a lot of data is generated by the old version of the system, the new version of the system has a data compatibility problem after it is launched.

(1) In the test environment, there is no problem with Chinese characters in all menus. However, on the evening of the launch, after the files are packaged and sent to the server, all Chinese characters become garbled, dozens of templates had to be changed one by one. Fortunately, not a lot of templates were quickly completed. But afterwards, I was wondering what to do if more chinese menus were wrong at the time, in this scenario, making large file changes can easily lead to errors. Later, it was found that the encoding settings in the test environment and online environment were different, and this problem was not taken into account during development.

(2) The second problem (this module is developed by myself) is because the original system is a famous CMS and the new system is no longer used, however, the CMS embedded Rich Text Editor has some flaws in processing entity escaping of single double quotation marks (or because we use an earlier version ), after the text data edited by the editor is displayed in the new editor in the new system, the tag is not parsed and the object is output as is.

Conclusion: when developing new system upgrade types, we must fully consider the compatibility between the new and old systems.

2. Ambiguous business needs

I once saw a blog on a programmer's forum about whether programmers need to learn business knowledge in their fields. Now I have been working for nearly a year, combining my own experiences, the answer to this question is required and important. In China, software development enterprises are mainly engaged in application development, and application development must be combined with specific business scenarios. If you do not know the business processes of the self-developed modules, from this perspective, the business process is an "algorithm" in application layer software development ".

(1) When the old version of the system is migrated to the new system, some fields and functions of the background management module need to be reduced. However, due to unclear business, some functions that should not be removed during the reduction process are removed, the items that can be removed are not removed, resulting in feedback of rework and modification during the periodic meeting Review, which has an impact on the construction period and can only be completed through overtime.

(2) With the rise of the Internet recently, agile development has also been widely used in various enterprises. However, most of the cases here are: "It cannot be a reverse dog ", agile Development emphasizes "focusing on communication and document-less", but in practice it becomes "relying on communication and document-less ". The consequence is that new users are involved in the project. They need to spend a lot of time reading code and other inefficient methods to familiarize themselves with the business. At the same time, new users ask old members in the group (mainly in the business) it is annoying to think about it frequently (I believe that everyone has been interrupted when writing code, so I will not say much about it). Further, perfect and efficient communication may replace writing, but throughout the programmer's communication skills, haha .....

Conclusion: there can be more exchanges in the business, but this document should still be available, especially for business processes with relatively few changes.

3. Schedule

(1) There is a periodic review meeting interspersed throughout the development process. After the meeting, the module may be modified in a feedback manner based on the review, which will delay the construction period.

(2) In the same module of the entire project, the time required for skilled veterans and new users is different. Therefore, you need to consider the schedule and assignment of tasks.

Conclusion: The scheduled period should not be arranged by module. redundant time should be set aside in each stage to cope with the schedule change.

4. The launch environment is consistent with the test (Development) Environment

(1) A function module of the new system is the mobile phone sending and downloading function. When my colleagues develop this function, they cannot send text messages in the test environment. That is to say, the verification code sending and downloading process cannot be tested before going online, so you have to perform a process test in your mind, carefully review the process of all the codes, and finally think that there will be no problems before going online, as a result, the function was not available that night ........

(2) As mentioned above, due to the inconsistent online data and test environment data, many static Resources in the test environment do not exist, in the unit test, the image cannot be displayed or garbled, and the result is online.

(3) test. Some companies feel that they do not pay enough attention to the test. Many tests follow the process in a formal manner, not to mention boundary tests. When programmers Perform unit tests, always tends to use "clean" data, so that the problem cannot be exposed as much as possible.

Conclusion: The test environment should be the same as the online environment in terms of layout, data, and software version. unit testing should be as detailed as possible. If time conditions permit, cross-module testing can be performed between members.

I have learned a lot from this launch, both technically and non-Technically. After summing up, I will often review and think about it to avoid falling down in the same place next time. As my work experience grows, some ideas in this article may need to be revised and supplemented. You are welcome to give your valuable comments.

Summary and Thoughts on launching a large project