Concept Definition#
Completeness:
- Refers to the coverage of services that can be provided for current needs.
Goals of Architecture#
Architecture is a relatively broad concept.
It is a business or a series of businesses implemented for a specific requirement.
Aims to solve problems efficiently.
Refactoring#
The essence of refactoring is: to remake due to insufficient completeness of the current architecture.
Refactoring software means you may rewrite a certain module / application, or even a system.
This behavior generally arises from:
- The original code has numerous issues, and the cost of fixing them is huge.
- The original system's performance is insufficient to handle the continuous growth of the business.
- New features cannot be quickly integrated into the system.
- There are flaws in the architecture itself.
Regardless of the reason, refactoring is definitely to solve the problems that have arisen in the previous generation of products.
Refactoring cannot be avoided, but the frequency of refactoring must be within ==controllable limits==.
Otherwise, making small changes every three days and major changes every week (the time cost and mental burden brought by this are enormous).
- The best way to solve a problem is to address the root cause of the issue.
Imagine a scenario:
You have implemented a wrapper for an API (let's assume it's a weather interface, with data on temperature/humidity/changes/region).
If you believe that the humidity parameter is currently unnecessary, you might directly discard this data.
When one day the functionality you implemented relies on the humidity parameter, you either have to retrieve the humidity from the original code (which undoubtedly increases the mental burden, especially when the code is in a system), or implement a new wrapper to obtain this parameter.
Both of the above methods will make the system more complex.
So if at the beginning, you had stored the parameter internally in the wrapper (while still not outputting humidity), when implementing new functionality, you would only need to call that API to get the humidity parameter!
- The above example illustrates a common situation: rather than discarding data, it's better to encapsulate it internally for future use.
- Of course, this may consume more computational resources and bandwidth (but for stability and development costs, this isn't too significant, is it?).
Real-life Example#
Take Bilibili as an example; its web API interface contains several seemingly "useless" parameters and duplicates (like bvid and bv_id).
This is a trade-off between compatibility and development traversal, using bvid and bv_id to reduce the implicit issues and communication costs caused by confusion.