Stop Trying to Reinvent the Wheel is probably the first rule every programmer in his or her career has been told. In the company, I inculcate this idea into every new member of my team. But it’s not easy to actually do that.



Looking for the wheel

The so-called “wheel” can be understood as the technical solution in the industry. Especially in today’s open source community, open source software and open source technology solutions are emerging one after another, which provides a rich way to find the wheel.


Avoid reinventing the wheel

A wheel can be reused, reflecting the reuse of software.


Using wheels itself is “standing on the shoulders of giants”, maximizing the convenience brought by today’s technology, avoiding the tedious and complex development from scratch, and effectively reducing costs.


Take ORM framework for example, in the Field of Java, only Hibernate is really powerful. On the one hand, it is difficult to develop how to implement ORM on their own. On the other hand, developing their own ORM requires a lot of manpower and technical input, and ordinary small companies are not able to do research and development in this aspect.


Take the GNU/Linux operating system as an example. If Linux had not been the kernel of the operating system provided to the GNU project, GNU might not know how many years it would have delayed the launch of its own operating system. The GNU Project, on the other hand, provides many ecosystem software for the GNU/Linux operating system, making the GNU/Linux operating system more acceptable to ordinary users.


The wheels are hard to find

It’s hard to choose because there are so many choices. At present, the software industry has unprecedented development, with distributed message service framework, there are many open source products, including Apache ActiveMQ, RabbitMQ, Apache Kafka, Apache RocketMQ and so on. This has the very high request to the individual information retrieval ability. At the same time, because there are a lot of choices, it is also necessary to have a certain understanding of the user’s various technologies, the advantages and disadvantages of various technologies to be well informed, in order to make a reasonable choice. This requires a high level of skill from the user. Lao Wei’s book “Distributed System common Technology and Case Analysis” provides a very good basis for developers to choose.

Second, it will take time to tell if the wheel works. You can’t judge the quality and ease of use of a project at a glance, it actually requires a lot of project experience. Even if a choice is made, it takes time to validate it. After all, projects have many problems that can only be reflected in operation.


And finally, a good wheel needs polishing. To successfully integrate an open source project into your own project, you need to have a deep understanding of the project. Most open source projects have uneven documentation quality, and when using wheels, it’s often not enough to just look at the documentation. You also need to read the source code and even make deep customizations. Even if it is integrated into your own project, it may need to be continuously tuned to fit your project’s reality.


Master IT skills in “copy, paste and change”

Reuse existing good wheels properly to minimize the cost of development projects. If wheels represent reusable projects at the framework level, copy-past-change is reuse at a more granular level of code.


Many developers despise “copy-past-fix”, believing that all code must be typed from zero in order to be truly awesome. This is not to be refuted.

For example, developer C jun wrote A method in project A, experienced the pressure of online, and now it can run stably online. What if project B needs a method with the same functionality, and C needs to type the code again from scratch? Why not just copy and paste? Unless there is a specific need or a better improvement to the method, just copy and paste and change. Or would it not be A good idea to refactor the method into A common project shared by projects A and B? You don’t know what good it is to type an existing code from scratch, except to increase your chances of making a typo. Of course, you may have improved your typing speed.


The hardest part of mastering copy-past-edit is to copy, because if you don’t do it right, you copy. In the past, Tencent always said that most of the software imitate yunyun, but it is the people “change” the function of the extraordinary, time proved that those have been Tencent simulation of the company, project, or dead or half alive, and Tencent is firmly in the position of the leader, we can see the importance of “change” work.


Many configuration files, in fact, can be less dozen do not dozen. For example, Maven’s POM file coordinates, you can go to the central repository to find any library you want and “copy, paste and change” it. There is no need to type it by hand.


Now that we understand the theoretical importance of reusing wheels, let’s look at a real case.

Google has software engineers who write 100-150 lines of code a day on average, and they are already highly efficient in the industry. This reflects that writing code is not the focus of the day, and effective engineers spend more time thinking about code.


Of course, this approach is not always acceptable to all developers. As mentioned in the introduction, there are still plenty of people who love to repeat the wheel.


The author of this article is Lao Wei, a mooC instructor, who has been authorized by the author. Click to read the original article.


Writing layout is not easy, give a thumbs up at the end of the article ~