It is better to change the code directly than to write bypass schemes

Original text: catern.com/change_code…

The body of the

I can’t count the number of times I’ve heard programmers talk about writing new code to accommodate and bypass other code behaviors they don’t want to change. Understand that you are a programmer with permission to modify code! This is actually your job description! Just change the code to what you want! Whether fixing bugs, changing code behavior, or adding new features!

  • Is the printed log information intrusive and useless? Delete the corresponding logging code!
  • Is the API not exposing what you need? Add a new parameter to support it!
  • Does your project software depend on inventory in some dangerous and terrible behavior? Stop the dangerous and scary behavior and wean the project software off it.
  • Is open source software doing something bad? Make the patch locally and push the patch synchronously.

Here’s what I’m saying: You know how to solve your problem, but you choose to bypass it and implement the solution at the level of some additional code rather than directly modifying the original problem code. As has often been said before, code is a responsibility; The more code a project has, the more complex and bad it gets (have you ever seen shit from a whale?). So, just change the original problem code!

There are some technical arguments you can use to say you can’t change code directly. Such as:

  • I don’t have access to this code
  • I don’t know how to modify this code
  • I don’t know where the source code is
  • I’m not going to build the project software
  • I don’t run tests
  • I have no way to use a modified version of this software

Some people may find it hard to believe that these statements are effective in their work, but there are many work environments in which they are not. Try switching from the former to the latter: don’t use legacy software, make it open source instead of closed, and quit your job to work with good development tools.

There are also social/institutional aspects to this. Such as:

  • Changing code directly means we have to talk to the person in charge of maintaining it, so what? They’ll probably be happy that you’re looking at their code and are intent on improving it! If they don’t like you doing it, then what you’re trying to do is evil anyway, and you should thank them for stopping you. If what you’re doing is good and they still don’t like it, thenforkLater,upstream.
  • Changing the code directly will affect other users! If you want to do something that will help them, they will be happy, and you should accept the costs and benefits of communicating with them. If you want to do something that will hurt them, then you shouldn’t do it. If you still choose to do this, you can surely figure out a way to keep them from using your modified version.
  • We haven’t evaluated the time to do it the right way! Then you’ll never have the budget time to do the right thing. Do it the right way now or you will always suffer.
  • This should support a rapid validation environment. You can make a quick experiment by just changing the original code; It would have been quicker to do it this way.

Don’t be afraid! Just change the code!

Beyond the original text, something to say

I have a front-end project of about 50W lines of code in hand. The project has been running for more than four or five years. It was all written with jquery before, but now it is mixed with JQ + VUe2. Have you ever seen shit from a whale? This is the project I have in my hand. The historical debt is too heavy, and it is too hot to handle. No one is willing to take it over. Maintaining old projects is very thankless:

  1. The maintenance of the historical code has changed several waves, no one can comb out the business logic of the old code, to the extent of refactoring does not move, can only rewrite
  2. Change the risk is very big, change leakage, change caused frequently, often be complained by people
  3. Project members (including newcomers) like to copy/reference old code into new code, and review code often sees rotten and outdated code
  4. Old code maintenance for a long time, people feel numb, lose momentum

In my opinion, the old project introduces new technology, the old module remains unchanged, and the new module adopts the new writing method. In some respects, this scheme is also a bypass scheme:

  • A lot of older modules arejqueryI wrote it. Part of it was usedvue2 + options apiIt was reintroduced early last yearvue-property-decorator, using TS to write new code, all kinds of writing methods mixed, maintenance cost ++, is not the futurecomposition-apiWhat about bringing in?
  • New and old technologies are mixed, the complexity is ++, and the cost for newcomers is very high, which makes it easy to dissuade newcomers
  • The mixing of different writing methods tests the thinking switching ability of members, you can never stop someone intsWrite theanyscriptHe said it was copied from the old code, which was written in JS
  • Old and new technologies coexist, and we expect in the future to remove the old and keep the new. But there are always people who like to reference the old module in the new module, copy the old code to the new code, and the maintenance of the old code is still using the old technology old architecture, the maintenance cost of the old code only increases, will not reduce, in the long run, will only form the coexistence of new and old technology, there is no way to remove the old technology.

I think that for any project that makes money, it’s important to have a continuous refactoring plan in place: refactoring a portion of the code every once in a while, and there’s always a window in the project where you can refactor, and if you want the project to last, the refactoring plan needs to stick with it. Instead of tolerating old code, encourage direct code changes and opt for compatible bypasses. Compatibility bypass will only make the project worse, the historical burden is heavier and heavier, and finally uncomfortable. Finally finally, I wish everyone a happy year of the Tiger, wish the world no shit mountain code!