Web application development cycle

Introduction: This part of the content first comes from the article "RePractise: Seven Days of Web Development" written by the author. The original text briefly describes the life cycle of Web applications. Later, it was found that this road is the only way for almost all Web applications. In its life cycle, a web application must go through building a development environment, creating a build system, writing code, performing data analysis, etc., until the legacy system is finally replaced with a new system. If you are an experienced developer, I believe you must have a deep understanding of this life cycle.
This article is a brief overview of the book Full Stack Application Development: Lean Practices.
The Web Application Lifecycle
　　In the projects I've worked on and the web applications I've seen, they all have the same very interesting life cycle. We often see on the Internet that a well-known website uses a new technology and language to replace the old system, and an App uses a new framework to replace the existing App. All we're seeing is that these companies are refactoring existing systems, which is actually the end of a cycle and the beginning of a new cycle. The process is shown in Figure 0-1.
　　　　　　　　　　　　　　　　　　Picture description
　　　　　　　　　　　　　　　　　　　　　　　Figure 0-1 The life cycle of

　　a web application If you think about it carefully, you will find that the projects we go through are all going through the same life cycle for different lengths of time.

Legacy Systems and New Architectures
When I started work, the first project I worked on was a legacy system. During a break, we were looking for the oldest source code file in the competition, and finally found a file written 10 years ago. Although there are unit tests and tests for specific business functions in our code, the code of the project has exceeded 200,000 lines, and there is still a considerable amount of code in the project that is beyond the business scope we understand. After all, there are quite a few features that no longer exist over the years. Later, we refactored the system using microservices. For mid-sized legacy systems, this is a good medicine.
Let's start with the redesign of the so-and-so website using the new architecture. When we decide to redesign a system with a new architecture, the reasons can be various, and if we exclude some irresistible factors (such as politics), then there may be only two reasons left.

The system has become difficult to maintain. There are still many reasons for this: a large amount of code has no business logic and is difficult to modify; the coupling between codes is too high, and the difficulty of refactoring the system is too complicated; the technology stack used by the project is outdated and has been used by the market. Eliminated; the technology stack of the team is in the process of member change, and the technology stack of most of the team members has not matched the current project.
The technology stack of the system has been difficult to meet the needs of the business. In most cases, when we first start creating a project, the technology stack we choose is a technology stack that meets the business needs at the time and can quickly verify its business value. With the expansion of the business, the existing technology stack will soon be difficult to meet the needs of the current business, or there will be limitations in performance optimization.
In most cases, we will refer to such a system as a legacy system. At this time, the atmosphere in the team is "if you can't move the code, try not to touch it". It is difficult for us to attribute the problems of the project to the human factor. Most of the time, it is affected by the expansion of the business. As a professional programmer, our instinct is to write programs well, and we often do not have such opportunities.

Read the full text http://click.aliyun.com/m/22669/