In the life cycle of a Web application, it has to go through setting up a development environment, creating a build system, writing code, performing data analysis, etc., and finally replacing the legacy system with a new system.


Web application life cycle


In the projects I’ve worked on and the Web applications I’ve seen, they all have the same interesting life cycle. We often see on the Internet that a well-known website uses a new technology or language to replace the old system, and an APP uses a new framework to replace the existing APP. All we’re seeing is companies refactoring existing systems, which is really the end of one cycle and the beginning of a new one. The process is shown in the figure below:




If you think about it, you’ll see that the projects we’re working on are all going through the same life cycle at different lengths of time.

Legacy systems and new architectures

When I started, the first project I worked on was a legacy system. During a break, we competed to find the oldest source code file and found one written 10 years ago. Even though we had unit tests in our code, tests for specific business functions, and more than 200,000 lines of code in the project, there was still quite a bit of code in the project that was beyond our understanding of the business. After all, quite a few features have disappeared over the years. Later, we reconfigured the system using microservices. This is good medicine for mid-sized legacy systems.

Let’s start with the redesign of xyz website with a new architecture. When we decide to redesign the system with a new architecture, the reasons can be many and varied, and if we eliminate irresistible factors such as politics, there are probably only two reasons left:

  1. The system has become difficult to maintain. There are many reasons for this: a lot of code no one knows its business logic and becomes difficult to modify; The coupling degree between codes is too high and the difficulty of system reconstruction is too complex. The technology stack used in the project is outdated and has been eliminated by the market; In the process of changing members, the technical stacks of most members of the team are no longer compatible with the current project.

  2. The technology stack of the system has become difficult to meet the needs of the business. In the vast majority of cases, when we first start creating projects, the technology stack we choose is one that meets the needs of the business at the time and can quickly prove its business value. As the business expands, the existing technology stack will soon be unable to meet the needs of the current business or performance optimization constraints.

In most cases, we refer to these systems as legacy systems. The mood on the team at this point was “don’t touch the code if you can”. It has become difficult for us to attribute the project’s problems to human factors. Most of the time, they are influenced by business expansion.

As professional programmers, our instinct is to write good programs. And we often don’t have that opportunity:

The business person said to the project manager, “Our competitor launched this feature this week.”

The project manager said to the developer, “This feature is coming next week!”

Yes, our feature will have to go live soon. At this point, we often have to make some compromises on code quality and delivery speed. Compromise too much, and the system breaks down.

Developer: “I don’t dare to modify this code. What if there is a big bug?” . Slowly, people began to talk about refactoring the system and designing a new architecture — one that would meet current business needs, business and technical needs over time.


Technology selection and validation


In the process of discussing the new architecture, different people may have different technical preferences, and there may be some political factors leading to different technical solutions. For example, some people on the team might use Java for stability reasons, some might use Scala for new technology needs, and the majority of the team might choose to use JavaScript because they all use JavaScript. As the figure below shows, our consideration should depend on more than just this set of technical factors:




Attention should be paid to: when doing technology selection, as much as possible to the team as the core. Before we make a final decision, we need to propose and validate technical models in different languages and frameworks. Then we need to quickly build a prototype, work on a hypothetical prototype, and verify that the prototype itself stands the test.

At this stage, I usually like to search GitHub for projects with Boilerplate in their name, or module files. When a framework is popular, I go to the corresponding awl-xx to find, such as awl-react, the project set related to React. Then, with a Clone project, we started creating simple demos based on existing systems. Then we can try to expand on that based on our business. Finally, decide whether to use the technology and whether to use the framework.

Generally speaking, choosing a new technology to design a system involves considerable risk, and if it works, it is likely to bring significant benefits. From this point of view, using the latest technology and gambling are not helpful. In mature companies, there are technical committees that review new technologies to determine if they can be used in a particular project. In addition to the convenience it brings to development, they consider maturity, security, technical risk, etc.


Set up the build system


With the architecture decided and the technology stack selected, it was time to create the build system for the project and design the deployment process for the project. The build system not only contains the build process related to the project, but also reflects the work process of the project in a sense.

After we create the Hello, World application, all we need to do is create a continuous integration environment. This environment consists of a series of tools, procedures and practices, from the tool, we need to select the version management tool, code hosting environment, continuous integration tools, packaging tools, automatic deployment scripts, and so on a series of processes, these processes will be in the fourth chapter construct flow and workflow are detailed discussed.

Here is the build process for a project I worked on before:




This is a build flow for a project that uses Java as the background language and JavaScript as the foreground language.


The iteration


In the Internet industry, the faster it can respond to market needs, the better it will develop. As long as you observe carefully, you can find that most Internet companies update their products regularly, maybe a week, two weeks, a month and so on. This process of constantly improving products based on feedback is called iteration. The following figure is a simplified iterative model:




When an iteration starts, we need to gather feedback from the previous iteration, or new requirements, and start developing code before releasing our product. The products we develop are constantly enhanced in the process. To do this, we also need to choose a good iteration period. A good iteration cycle is one that allows enough time to fix bugs in the previous iteration and deliver important features before the next iteration begins. Of course, if we were unlucky enough to deliver a package with a significant Bug, we could use the old package the first time and deliver it in the next iteration. Of course, at this pace of development, a week is too short, a month is too long, and two weeks is a good amount of time.

When a team doesn’t do this well, they may go live, find important bugs, and have to update their product that night or the next day. Even experienced teams often encounter these issues in the early stages of development and can rely on retrospectives during iterations to improve these process issues. Good iterative practices evolve based on the team’s own needs, which means that sometimes what works for team A doesn’t work for team B.


And then we’re going to keep adding features to this Hello World.


Excerpt from: Full Stack Application Development: Lean Practices





Amazon: “the whole stack application development: lean practices” feng to review of trying to read the book jingdong 】 : “the whole stack application development: lean practices” (feng da) – the review of trying to read 】 【 jingdong books Down-down: “the whole stack application development: lean practices” (feng da) 【 introduction 】 _ _ reviews online reading – dangdang books


Live address: Zhihu Live – new real-time Q&A