An overview of the

Two points were shared in the previous post, “A person is promoted, Not just by ability, but by Trust” :

  1. What kind of engineer is likely to be promoted?
  2. When you were promoted to front-line management, what was your intention?

This article shares the first line of technology managers in charge of what?

Let’s start with a complete project release. A complete project release probably needs to go through these big nodes:

Project approval -> Requirements review -> Visual draft review -> Technical review -> project launch -> Development -> joint adjustment -> Test -> Release

There is a saying that by controlling the quality of the process, to ensure the quality of the results.

So, what front-line managers need to do is to ensure the quality of each node to ensure the quality of the whole project.

How? To look down.

To regulate

Technical review specification

Before the technical review, we should be familiar with the product documents, business flow charts and interaction prototype drawings provided by the product students, confirm with the product students repeatedly, and design the technical scheme when both sides reach an agreement.

Design technical scheme from the overall to the local, so that all aspects.

Overall:

  • General structure drawing
  • Business flow chart
  • Sequence diagram
  • The core class diagram

Local:

  • Functional changes
  • Database field changes
  • Changes in business processes
  • The upstream and downstream interface conventions are changed

When the technical solution is determined, we are determined:

  • Technology selection (front-end/back-end framework, logging middleware, messaging middleware, database…)
  • Technical architecture (how components work together, how they are deployed)
  • Technical difficulties prediction (identify existing technical difficulties and determine solutions)
  • Performance bottleneck prediction (Identify potential performance bottlenecks and determine what to do)
  • Upstream and downstream system interaction (specify which position in the process, and agree on the time of interface document provision and interface joint adjustment)
  • Functional module division (task splitting and assignment)

When the technical solution is determined, the output document is required:

  • Estimated development duration. XLSX, including system, module, function, function description, r&d personnel, time (h), estimated completion time, etc.

    In addition to the normal development work, it also includes the provision of interface documents, interface joint debugging, research and development self-testing, document update and so on.

    For normal function development, the granularity of working hours can be up to 2h. Such granularity can reduce the complexity of work and enable r&d that is not familiar with relevant businesses to get started quickly. For example, for 2H, one method is written.

  • Update project documentation, including project introduction, product documentation, business process, system structure, interface documentation, data fields, external dependencies, etc.

    This classification is customizable, mainly to solve the problem of omission when the system is handed over due to the movement of people.

Code style specification

While a code style doesn’t affect how a program works, nor does it pose a potential danger to the program, a good code style can be enjoyable to read, especially when reading someone else’s code as if it were your own.

Develop code style specifications based on the language you are using. Refer to the language standards, such as PSR for PHP.

Once the code style specification is agreed upon, it must be implemented in the document!! It is convenient for other colleagues to use when conducting CodeReview.

Code development specification

  • Access the unified visual log platform.
  • Access the unified configuration center platform.
  • Connect to the unified exception monitoring platform.
  • Access the unified messaging middleware platform.
  • Exception processing specification: direct return, throw exception, retry processing, fuse processing, degrade processing.
  • Unified API specification: HTTP interface, RPC interface, Code, Msg, Data, etc.
  • Branch development specification: branch name specification, hot repair specification, on-line specification, etc.
  • Other specifications, you can add your own…

Code management specification

Common code management tools: Git and SVN.

The use of tools, as we all know, without going into detail, is to agree on some basic specifications.

  • Do not submit your own user configuration, such as IDE configuration.
  • Don’t commit code that doesn’t compile.
  • Commit early, commit often, and update before committing.
  • The submission information must be filled in carefully and refer to the following specifications.


(scope) :

, for example: fix(home page module) : fix popup JS Bug.

Type Indicates the action type, which can be:

  1. Fix: fixes the XXX Bug
  2. Feat: Added the XXX function
  3. Test: debugging the XXX function
  4. Style: Change the XXX code format or comment
  5. Docs: Change the XXX file
  6. Refactor: Refactor XXX functions or methods

Scope indicates the scope of influence, which can be divided into modules, class libraries, and methods.

Subject indicates a short description, preferably no more than 60 words. If there are related Bug Jira numbers, it is recommended to add them to the description.

CodeReview specification

To tell the truth, due to a variety of reasons, their implementation is not good.

What problems does CodeReview check for?

  • Normative examination

    • Whether code development style specifications, code development specifications are followed.
    • Are all variables correctly defined and used, and are annotations accurate?

  • Robustness check

    • Whether inadvertently caught in a loop.
    • Check whether exceptions are not handled or resources are not released.
    • Whether there is a runtime error (array boundary overflow, divide by zero).

  • Reusability check

    • Whether the same method is written twice, whether it can be written as a generic class, method, component, etc.

  • Safety check

    • Whether SQL injection, XSS, SSRF, CSRF, unauthorized, and file upload vulnerabilities exist.

  • Performance check

    • Whether the synchronous execution is too slow and needs to be changed to asynchronous execution.
    • Whether there is no cache, frequent link DB situation.
    • Whether connection pooling is required.

How is CodeReview executed?

  • preparation

    • Develop CodeReview specifications and standards, so that in the review process can be based on evidence, rational to follow.
    • Identify CodeReview reviewers and participants.

  • Effective date

    • Prior to CodeReview, the reviewer will inform all participants and code authors of the content to be reviewed and the specifications and standards to be reviewed.
    • In CodeReview, the reviewer should carry out item by item review, not because of lack of time and other factors.
    • After CodeReview, the reviewer should provide solutions to the problems found and record the problems for subsequent tracking.
    • Reviewers can not only ask questions when they find problems, but also ask the code author to explain them so that they can get familiar with the whole business and code design.
    • During this period, we should create an atmosphere for discussing and solving problems. It should not be a critical meeting, which will affect everyone’s enthusiasm.

  • After the event tracking

    • Determine the difficulty of repair and the scope of the impact of the found problems.
    • Identify a time frame for the completion of the repair of the identified problems.
    • Verification shall be carried out after repair of the found problems.

summary

These are just a few of the things that front-line technical managers do.

I suppose some readers may ask the question: Where is the time? Business code every day overtime can not finish, which time to do these?

The question… The first thing to acknowledge is that in most companies, business code is just a necessity, because that’s where the money is and you need to get up and running quickly.

As the company grows and the technical staff expands, the specification must be established slowly, otherwise there will be problems of one kind or another.

If the company only has a few technical people, you can forget about this and focus on growing the business quickly.

When you find something wrong or imperfect, you are welcome to criticize and correct it.

Recommended reading

  • It’s not just ability that gets a person promoted, it’s trust