1 It’s not that I don’t write code
On the contrary, some core components and core codes will be involved. These codes will be used in various projects. They have very high requirements for robustness, performance and other aspects, and require people with a certain level of ability to write them well.
Ruan Yifeng's blog has a saying: "Be wary of people who haven't written any code for a long time but are designing systems."
2 Generally not deeply involved in business code writing
Because the business code online process is very complicated and requires various tests, etc., which takes a long time, I don’t have that much energy to participate. However, I will review the codes of each business group, and occasionally participate in some businesses. For example, this year I myself I participated in the core business development of a project. The reason is that I know this business best and have the highest input-output ratio, so I joined it myself.
3 Responsibilities are more reflected in design
and the company's overall technical system construction. For example, in a project's technical feasibility demonstration (theory guides practice), the architect needs to come up with a theoretical process, guide R&D personnel in production practice, and tell the team what path to take. The construction of the company's technical system is reflected in: For example, what kind of company network architecture can serve company personnel well and make everyone's network easy to use? The construction of the company's operation and maintenance system is consistent with the construction of a more efficient energy efficiency system, the technology selection of R&D personnel, and what technology architecture to use. Framework, whether additional packaging is needed, etc.
4 Based on my current experience
Architects should consider everything that is implemented by the software. Architects should be able to implement all functions entrusted to R&D implementation and ensure that they are reasonable.
Architects should ensure that [software] does not corrupt and information is not lost as personnel change over time. Architects should also consider the quality of the software, should prevent some problems from occurring in advance, and should also ensure that problems that occur will not recur.
Architects should also consider improving software features, testability, stickiness, observability, scalability, development efficiency, etc. Ensure that R&D has no other mental burdens other than realizing requirements.
5 Summary
In a nutshell, architects can cover the direction of a software. If they do not develop it themselves, or in the process of personal development, there will be serious loss of contextual information, [development environment] performance will be poor, and efficiency will be slow. Development environments are difficult to build and bugs are easily fixed due to loss of context. Then these are the architect's dereliction of duty.
We call on every R&D company to ask themselves as architects. Architect should not be a position, but a responsibility.