DevUI is a team with both design and engineering perspectives, serving huawei DevCloud platform and huawei internal background systems, as well as designers and front-end engineers. Add devui Helper (Devui-Official) DevUIHelper plugin: Devuihelper-lsp (welcome Star)
The introduction
When you are competent and gain the trust of your manager, it is natural to take on bigger and more important responsibilities, such as becoming the Owner of a medium to large business.
A medium to large business is one that is large and complex enough to be unable to deliver the required version on its own and requires teamwork.
Let’s assume that there are 12 people in the business, with roles as follows (sorted by product development process) :
role | Duties and responsibilities | membership |
---|---|---|
The product manager | Connecting users is the source of demand | 1 |
The project manager | Manage project schedules and deliver releases on a regular basis | 1 |
design | Responsible for UI interaction and vision, is the user experience designer | 1 |
The front end | Front-end user interface and interaction development | 3 |
The background | Background data storage and interface development | 4 |
test | Responsible for version quality | 1 |
operations | Deploy the live network | 1 |
If you were assigned to the business as a front-end Owner, what might you need to do to achieve efficient, high-quality release delivery?
Define objectives and responsibilities
Start by understanding what your organization and leaders expect of you. Assume that your organization wants you to improve the quality of delivery for the business and gain customer recognition.
The goal is very clear: improve the quality of delivery. This goal will drive your direction and behavior for the next year, and it will be the premise for you to exceed your expectations.
Once we have a goal, we need to measure it so that we know if we are improving, and try to find something that can be quantified.
Refer to our previous article on How to Measure R&d Efficiency and Quality for Front-end Projects.
Composition of delivery quality
Quality means good, and the fewer problems the better.
From the product side, defect rate and JS error rate are very good indicators to measure.
There are also good metrics from the development side, such as:
Repeat rate
Cyclomatic complexity
ESLint issue number
Boulder file/method number
3. Calculate the defect rate
Defect rate = number of defects/code size
Defects are also bugs. After we develop product features, we need to deploy them to the test environment and propose tests. After testing, the testers will submit a list of bugs, and the number of bugs is the number of defects.
Code size can be expressed as the number of lines of code. Generally, the source code is stored in the SRC directory of the project root directory. You can use cloC tools to count the number of lines of code:
cloc src
Copy the code
To exclude certain directories, such as __tests__, add the –exclude-dir argument
cloc src --exclude-dir=__tests__
Copy the code
For example, the number of lines of code in html2Canvas library:
With the number of defects and code size, you can calculate the defect rate.
The defect rate of historical iterations can be counted first. The number of defects can be obtained by viewing the test report. The number of code lines increased by this version can be obtained by Git commit record.
For example, in the previous iteration 1.2.6, it was from 2020.12.14 to 2020.12.25.
We can count the number of new lines of code using the following command:
git log --after="2020-12-14 00:00:00" --before="2020-12-25 23:59:59" --pretty=tformat: --numstat | grep -v 'static' | awk '{ add += $1 ; subs += $2 ; Loc += $1 - $2} END {printf "add :%s\n",add,subs,loc}'Copy the code
Or to html2Canvas chestnuts 🌰
Suppose that there are 3 bugs in total during this period by checking the test report, then the defect rate is:
Defect rate = number of defects/code size =3/130=2.3%
That is, the defect rate in the last iteration was 2.3%. We can calculate a few more iterations and then take an average, so that we can know what the defect rate level of the previous business was roughly.
In this way, you, as the business Owner, take a series of actions and finally lower this indicator. Let’s say it is lowered to 1.8%, then the quality can be considered improved:
(2.3 1.8) / 2.3 = 21.7%
4 Monitor the JS error rate
The second is the JS error rate, which monitors whether there are JS errors when users access the page on the live network. If there are JS errors, some functions are likely to be available.
We can’t be at the site of users. We don’t know how users experience our products and whether they encounter difficulties in the process of using them, which we can’t directly know.
However, JS error provides us with some clues to understand these information. If at some point, JS error occurs on the live network, we may be able to reproduce this error, find the cause of the error, and fix this defect in time before users complain.
Can say,
To reduce the JS error rate of the current network is to eliminate landmines. The less landmines there are, the fewer users there will be, which is of great significance to the user reputation of the product
This index needs to be collected through the front-end monitoring platform, such as Furion platform in DevUI, and its calculation formula is as follows:
JS error rate = Number of JS errors /PV
Also look at the previous live network JS error rate level, assuming 6.2%, you through efforts to reduce this indicator to 0.1%, then the quality improvement is 98%.
5 Statistical repetition rate
In addition to product-level quality metrics, we can also set some development-side quality metrics.
The repetition rate is a good indicator if there is too much duplicate code in a project
- One is that our maintenance costs are going up, one change, a lot of changes;
- Secondly, it is easy to leak some places, which never leads to bugs.
Duplicate code is the root of all evil
We can use the JSCPD tool to measure the front-end code duplication rate:
jscpd src
Copy the code
For html2canvas 🌰
The JSCPD command lists the file and row/column in which each of the 14 code repeats is located, with a 1.71% (relatively low) repetition rate.
We have to do is according to the repetition rate report, a change can, of course, modify the repeated code also to consider the readability, not to eliminate the repetition, reduce the readability of the code.
Assuming that the repetition rate drops to 1.16%, the quality improves by 32%.
6 calculate cyclomatic complexity
Cyclomatic complexity can be referred to in our previous article: a brief introduction to cyclomatic complexity in the front-end.
7 Clears the number of ESLint problems
ESLint ensures code quality by disciplining our code with best practices.
The following figure clearly shows the value of ESLint:
- If you don’t use ESLint, your code will have to be checked manually and will be badly formatted and bug-prone to infuriating collaborators or users;
- If you use ESLint, your code will have a reliable machine to check, formatting rules, and run with fewer problems and everyone will be happy.
If the code in the project does not conform to ESLint rules, an ESLint error or prompt will be generated. Fixing these ESLint problems can improve the quality of the code to some extent.
Assuming the ESLint problem is cleared, the quality improvement is 100%.
8. Count the number of files/methods of boulder
Large and complex things tend to be harder for us to understand, while simple things tend to be easier to understand.
The same is true for code, simple code that we know what it does at a glance, so that we can modify it less error-prone.
If a file contains thousands of lines of code, or if a method contains hundreds of lines of code with many branches and deep nesting, then it is difficult to read, and modification is always a matter of trepidation, trepidation, and bugs.
Count the number of lines of code for all files and sort them from largest to smallest, using the cloC tool mentioned earlier:
cloc src --by-file
Copy the code
Html2canvas as 🌰 (only intercepts files with more than 100 lines of code)
Generally, a file should have no more than 300 lines of code, above which some module splitting may be required to improve the readability and maintainability of the code.
Also consider the nesting depth of the file, starting from the root path down, usually no more than 7 layers.
At present, I have no better way to count the boulder methods, so I can only look in the boulder file. Once I find more than 50 lines of methods, I will consider reconstruction.
Everyone has a better way to welcome recommendation.
summary
Let’s make a simple summary, from the product side, can pass
- Defect rate
- JS error rate
To measure quality.
From the development side, yes
- Repeat rate
- Cyclomatic complexity
- ESLint issue number
- Boulder files/methods
To measure quality.
These quality indicators can be weighted according to the characteristics and preferences of the team, and ultimately calculate an overall quality improvement rate.
Having quantified our goals, we can roll up our sleeves and get to work.
After a period of efforts, we exceeded expectations to complete the goals of the organization, and we can take these quantitative indicators of quality improvement to the organization to ask for year-end bonuses and salary increases!
Join us
We are DevUI team, welcome to come here and build elegant and efficient human-computer design/research and development system with us. Email: [email protected].
The text/DevUI Kagol
Previous articles are recommended
How to Measure R&d Efficiency and Quality of Front-end Projects
Start writing Tests for Your Angular App now, Part 2
Denver “🏆 DevUI x | of 2020”