These three points
Preface
"Technical Manager" is the role that a programmer in the development team assumes when he is responsible for the entire development team that created the system together. Usually he is not only responsible for the final delivered software system, but also develops and implements the system like a programmer.
60% to 70% of a technical manager's time may be spent on development task decomposition and allocation, development practices, technical architecture review, code review and risk identification, while the remaining 30% to
40% of time is spent on securing the system Deliver all the necessary plans, collaborations, communication, and management on time. Unlike team managers, most of the management work of technical managers is for specific R&D tasks and technical affairs.Next, based on my role in technology TL, some of my mental development in development specifications, development processes, technical management and planning, etc., I would like to encourage everyone.
Development specification
The business I was in charge of at the time was the acquisition of a subsidiary by the group, which was very different from the group’s technical standards in terms of overall technical standards. The development specification can be said to be the first thing I did when I came to this team. The problem I faced at the time was that the API interface format was confusing, there was no standard RPC service, the code did not have a unified standard development specification, and the technical framework components were not standardized. A series of questions. As a newcomer to the business, I immediately formulated a set of relatively standard and comprehensive technical development specifications, combing the development specifications while writing the code, leading the team
to a unified standardized development path.
In response to the above problems exposed by the team's R&D specifications, the following specifications have been formulated:
Naming conventions
I myself attach great importance to the initial process of building the project structure. I think it is very important to apply naming conventions, module division, and directory (package) naming. If I do well enough, it may take only 10 minutes for others to understand after importing the project. system structure.
Specific specifications include 包命名、类的命名、接口命名、方法命名、变量命名、常量命名.
Unified IDE code template
A unified IDEA/Eclipse IDE code template is agreed, and the code style must be unified to avoid differentiation and code merge costs caused by different developers using different templates. Students using IDEA can install the Eclipse Code Formatter plug-in and Eclipse unified code template.
Maven usage specification
The versions of all second-party libraries and third-party libraries are uniformly defined in the parent pom, so that all business application projects inherit the versions of the second-party library and the third-party library specified in the parent pom, and unified framework and tool versions (Spring, Apache commons) Tools, log components, JSON processing, database connection pools, etc.), while requiring the production environment to disable the SNAPSHOT version. In this way, to upgrade the version of the general framework and tools, you only need to upgrade the parent pom of the application project.
Code Commit Specification
A unified ChangeLog is generated based on the Angular Commit Message specification, so that it is very clear for each release tag. The corresponding plug-in needs to be installed under Mac. IDEA also has corresponding plug-ins. For details, please refer to the "Commit message and Change log of Teacher Ruan Yifeng" Preparation of the guide.
At this moment, I suddenly remembered Linus's bout when facing the show operation in the pull request:
Get rid of it. And I don’t ever want to see that shit again. ——Linus
The specification of code commit is very important to the team. The release tag generated by clear commit information is very important for the failure rollback industry in the production environment and can provide some valuable information.
Unified API specification
The return value ResultDTO of the unified Rpc service interface, the specific code is as follows:
Success represents the success or failure of the interface processing the response result, errorCode and errorMsg represent the return error code and error message, module represents the return result set, and ResultDTO is defined in the common-api top-level second-party library, so that each application does not need to convert the return result back and forth.
The Http Rest interface specification agreement is almost the same as ResultDTO. You need to pay extra attention to encryption and decryption specifications, signature specifications, and version management specifications.
Exception handling specification
Exception handling is not only how to deal with Exception in a narrow sense, but also how to deal with various business logic errors. The exceptions caught by the service service layer mainly include BusinessEx-ception (business exception), RetriableException (retryable exception) to common-api, and define a public exception interceptor to handle business exceptions and retry exceptions in a unified manner. The service interface of the exception call needs to ensure its idempotence.
In addition, some special exceptions in other business layers do not need to be handled uniformly by the interceptor, and can be self-digested and processed internally. The processing principles corresponding to the scene mainly include:
● Direct return
● Throw exception
● Retry processing
● Fuse processing
● Downgrade processing
This again involves the topic of elastic design. Our system often docks with various external services and APIs. Most of the services do not have SLAs. Even under large concurrency, we need to consider the impact of the unavailability of external services on ourselves. , Will you drag yourself to death. We always hope:
● Try to make the business complete at the lowest possible cost;
● If the external service is basically unavailable and we call the external service synchronously, we need to protect ourselves and directly fuse it, otherwise it will continue to be concurrent. Under the circumstances, it will collapse;
● If external services are particularly important, we will often consider introducing multiple services of the same type, routing based on prices and service standards, and automatically downgrading when problems occur.
It is recommended to use Netflix's open source hystrix disaster recovery framework, which mainly solves the problem of bringing down the business system and even causing an avalanche when external dependencies fail. At present, our team is also using it, which can solve the downgrade processing of abnormal fuse, timeout fuse, and current limit fuse based on concurrent number.
Branch development specification
In the early days, the source code version management was based on svn, and then gradually switched to git, how the branch management (based on Gitflow) will be slightly different for each company.
For branch development specifications, specify the following standards:
● Branch definition (master, develop, release, hotfix, feature)
● Branch naming specifications
● Checkout, merge request process
● Test
process
● Online process ● Hotfix process
Although this has nothing to do with code quality and architecture, implementing it in accordance with this set of standards can give the entire R&D team great convenience:
● Reduce or even eliminate online accidents caused by code management;
● Improve the efficiency of development and testing. Too much is messy;
● Reduce or even eliminate online accidents caused by code management;
● Facilitate operation and maintenance to handle release and rollback;
● Allow project development to flexibly adapt to changing needs, and multi-person collaborative development.
Unified log specification
Log is an indispensable function of the product. Its unique advantages are its traceability and the ability to capture problem site information, especially in terms of problem location on the production system. It has an irreplaceable role.
Here I emphasize the following 针对异常的日志规范:
● The choice of WARN and ERROR needs to be carefully considered. For WARN, I generally tend to record errors that are self-healing but worthy of attention. ERROR represents an error that cannot be recovered by itself. It is unreasonable to use ERROR for business processing problems, and it is not all ERROR for catch exceptions.
● What information to record, it is better to print a certain context (link TraceId, user Id, order Id, key data from the outside) rather than just print the thread stack.
● The upper and lower questions are recorded, should the log desensitization be considered? It can be implemented at the framework level, such as the ClassicConverter that implements logback.
The correct and reasonable use of logs can guide developers to quickly find errors and locate problems. Therefore, a set of standard specifications for the use of logs has been agreed. Now you can refer to the "Alibaba Economy Development Protocol-Log Protocol".
Unified MYSQL development specification
The design of the table is similar to the definition of Api. It belongs to the kind that is not opened properly at the beginning and will cost 10x to change later. I know that it is difficult to design a good one-step table structure when the business is not clear at the beginning. But at least what we can do is have a good standard.
Unified tools and framework
The common components used in the development process are unified abstracted and encapsulated, including the dao layer framework mybatis, cache component jetcache, httpclient component, common-tools (common tools), and extract the global unique ID, distributed lock, power Wait for the public components, integrate the above public components into each application, perform unified upgrades and maintenance, so that it is convenient for everyone to focus more on business development.
supplement
How to become a good technical manager? You have to do these three points (two) development process