preface

Learn to merge and constantly update code.

Trouble spots

The code that a colleague handed over before leaving, except for the code mentioned above, except that the class is too big and the business logic is written into a method. A few more questions:

  • There is too much redundant code, a lot of copy and paste content, the reusability is very low;
  • A lot of unused code and configuration, and a lot of old and new compatibility left over switches. It was no longer clear which switch was on and which system to call;
  • A large project is split too thin and the call chain is too long. There are too many projects involved in troubleshooting, multiple projects or even multiple people need to be investigated, and the cost of troubleshooting and communication is too high.

Learn to merge

The key lies in sorting out the upstream and downstream call relationship and extracting the key content.

How to solve

  • In the main business logic method, only the main process should be written, and the same business processing logic should be combined into one method: for example, the main business logic contains ABC three business processing logic, then ABC can be separated into three relatively independent methods. In the main business method, only three business methods ABC need to be called;

  • Extracting functions with the same content: extracting template methods for the same content, extracting shared entity classes for the same fields, and extracting a shared dependency package for common ones;

  • Multiple projects invoke the same interface, extracting one project for dependency use. Each project should not write the same copy of the same call method, or it will have to be adjusted for each involved project when the interface is later adjusted;

  • Interface and return value abstraction. The policy + factory pattern, for example, can be routed to concrete implementations because methods are abstract. For example, retrieving cached values can be expressed directly as generics, rather than being split into different calling methods.

  • Reduce the call chain. Do not have to split too fine, can directly call directly, do not go through several transformations;

  • When it comes to core updates, provide a separate interface to provide updates. For example, save and update core basic information, should be consolidated in one place for update. Update should not be scattered to each project team, otherwise it is difficult to find out where the wrong data is updated when there is a problem;

  • When multiple projects update the same SQL, they should be updated together. Deadlocks and sequentiality can occur when concurrency is high (and production does);

  • Process core business modules converging with modules into a project. For example, there are receipt items for sending wechat, SMS, voice and corresponding channels. The code that was originally split into projects was too scattered. In the specific business should be convergent to a project, the specific call entry is just a shell, only to provide input verification, the specific implementation can be achieved through MQ or call;

  • With the methods provided by the public JAR package, do not duplicate the wheel. Such as date classes, nullifying, encryption and so on;

  • If a method has too many parameters, it can be merged into a single entity class or Map, which makes the method more common and does not need to change the method even if fields are added or deleted.

  • Classes and methods with the same functionality are extracted into a single method, rather than writing separate classes. Such as encryption, validation, dates, HTTP and so on;

  • Checkability content, custom throw errors, in try/catch handling. When input parameters require a lot of validation, it is obviously not appropriate to write the same validation part one by one. Consider using custom throw types that pass throw information into your code.

  • Remove unnecessary temporary variables;

The ultimate goal:

  • High cohesion and low coupling. Improve code readability, reuse and maintenance costs;
  • Reduce unnecessary code logic. Reduce code coupling, make code clearer;

Continuously updated

It’s not enough to just merge the code, because there are always configuration adjustments and compatibility issues during development. There might be a lot of unused code. If left unchecked, may not understand the back of the previous written content. Such as

The key is to continually eliminate unnecessary code content.

  • Remove unused configurations. Maybe one day when the old configuration goes offline, restart will produce an error;
  • Code that is not needed should be deleted.
  • Pilot run code, when not needed should be deleted in time;
  • Remove the switch. At the beginning of the online in order to trial run compatibility and increased a lot of new and old code switching, such as the system stability after a section of the deletion;

The end result

  • Do danshari. Delete what you don’t use.
  • Keep updating. Maintain your own projects.

Whether it is disassembly, merger or continuous update, the ultimate purpose is to make the code clear and clear, to provide the reuse and robustness of the code, so as to facilitate future expansion and troubleshooting. Writing code is an art that requires constant discipline to write elegant code.