It has been nearly a year since I came to Sohu in a twinkling of an eye. 2020 is an extraordinary year for all of us. As a technical person, I don’t want to make more regrets about all kinds of big events in this year. I want to make a small summary of my own year with this article.
Think carefully, in this year has done the most successful thing should be reconstructed sohu’s content in front of the stage. From the first day just came to Sohu, and content platform firmly tied together, even in the middle of the organizational structure adjustment, still did not separate and content platform project for a moment. To be honest, I am very happy to have just taken over this project, because this system can be said to be a very important internal system, and it is the biggest project that I am independently responsible for. However, as I became familiar with the project, predecessors dug holes everywhere, making the project iteration really difficult. As a development engineer, high cohesion and low coupling are common, and I think many people know this, but in real projects, the real implementation is very different. The content I took over is a typical negative textbook, in line with all the characteristics of low cohesion, high coupling, want to make a small change to a function, it can be said that the whole body (of course, there are exaggerations, but it does need to change a lot of places). Finally, as the new requirements kept coming and the frustration accumulated (it was time to change the code again, and the joy of writing code was completely lost), a decision was made to refactor the front end of the content.
Is very popular in the programmer inside a word is “as long as the code can run, try not to move it”, this sentence really makes sense, because a lot of times we don’t follow the project from the beginning grow together, most of his peers is halfway over others project has developed for a period of time, this is normal, because liquidity is really great. Then, if the whole system is reconstructed, the problem will become very big. It is not the problem of the technology stack or the specific implementation of a business, but the understanding of the background of the whole business, including the real needs of each business point at that time, and the understanding of each interface for the communication between the front and back ends. At this point, you’ll find that it helps if a project has a formal documentation system, but many projects don’t. Another big problem with refactoring a project is that it’s not easy to see the benefits, so that means you don’t get a lot of resources, or even full cooperation from the people involved. These are all problems that you should encounter more or less during refactoring, and more during actual development.
There are many difficulties mentioned above, so why did I decide to reconstruct this project? The reason is simple, because I think the benefits of refactoring far outweigh the costs of refactoring (and they do turn out to be high). Of course, I do not suggest you to reconstruct their own projects, to decide according to the actual situation, but also according to their own actual situation according to their own accordingly, otherwise it will really make you very tired, not worth the loss. Now that you’ve decided to refactor, there’s only one word left: “do.” Before the formal reconfiguration, I first made two small preparations. One was to know the real background of the system with the product and get familiar with every interaction detail of the system, so as to make myself familiar with the system as much as possible. Another is to communicate with the back end of the system and ask colleagues to help with the interface documentation as much as possible (😂 if they are willing to cooperate with you).
All things are difficult before they are easy. For internal systems, they all look the same, but they need to build systems that are more in line with their own business according to the characteristics of their own systems, which requires developers to think about it. Therefore, it took some time to build the foundation, and THANKS to the help of some friends, after all, one person can not take care of everything. The actual project construction process, in fact, there is nothing to say, not much technology used, mainly webpack, VUE and so on. But one thing that I think is really worth mentioning in this whole process is the partitioning of the code. Usually we should often hear the words of componentization and modularization, but a careful chat, you will find that everyone understands different, a lot of people feel almost the same, not the same meaning, so understanding can not say wrong in fact. But I think the code level should be called modular development, clustering the different functional code (for example, we remove the toolkit, such as the API layer, etc.); At the view level, it should be more consistent with the concept of componentization. For example, I implemented a small popover component. Of course, these are my own understanding, we have different views is ok. When we in accordance with the principle of a single function, the whole project has been componentized, modular reconstruction, you will find that the project is not the same, when the subsequent requirements come again, it is really so easy.
I’m sure a lot of people are interested in the specific benefits of refactoring. In this project, the benefits of reconstruction are quite obvious. The first one is that the iteration efficiency of content Platform itself has been greatly improved. It is difficult to say in specific quantitative evaluation, but as a developer, I can really feel the improvement in efficiency. The second is about the benefits this refactoring brings to other projects. In this refactoring, the infrastructure that can be reused can be produced quickly when other projects are built, and the actual developers only need to care about the business logic.
Of course, there’s a lot to think about refactoring as well. Actually did a lot, did not do a lot. Due to the whole reconstruction, not a lot of resources were allocated, so the specifications of the whole project should be relatively general, including the code review at the beginning, but later due to the busy business, it did not continue. The encapsulation of many common components is not good, but can fulfill the requirements of the current project. Moreover, the component samples are not well added, so other users will have some doubts.
That’s one meaningful thing to do in 2020, but there are plenty of others. Anyhow, it is to have harvest happiness in sohu, also have frustrated, see the sunshine of TX shines, or very sour 😄.
I hope that 2021 will be better, and I also hope that my technology will further improve, and I hope that everyone can be healthy and happy!