Technical debt management and debt evaluation of Firefox/chromium

Now the software development is everywhere agile, everyone speaks only fast not broken era, who has time to think about code quality, design quality? Which one doesn't kill crowd from a bunch of code to implement another feature? A product can not survive a few years, why consider what maintainability?

When we pursue progress, we always sacrifice something or destroy something and wait for it to be mended. This is technical debt! Poor management, debt, even if not bankrupt, but also to Rob Peter, pay Paul play balance. The reality is cruel, but it does not affect us to look up to the world.

Technical debt

The word technical debt (Technical debt), which I first learned from Infoq's an interview with Uber, is also thinking about continuing refactoring, and finding it to be an effective tool to drive continuous refactoring. So took a little time to do some study, here to do a share, mainly from the study of this article, there is time to read the original text is good:
Technical debt in Firefox and Chromium

As for technical debt, it is not a term, it is not textual research its history. In fact, many teams have similar tools, such as: Problem record, optimization point, TODO list and so on. But usually it is relatively loose, mixed-style, not systematic.

I have not managed to summarize before there are two points:

1. The range is too large
   An important point was also highlighted in an IEEE No. 20121 article (Technical debt:from metaphor to Theory and practice), Technical debt do not engage with demand and bugs, The design and implementation that should be focused on negative effects on the future are often not directly perceived. For example, performance optimization to how much, this is not technical debt. Think back to the points of optimization that were made, too focused on functionality, more like a reference for future development work arrangements.
2. Lack of management in place
   If one thing is just a quest for icing on the cake, it will naturally be ranked low in priority. Then, too naïve, actually did not then.

The countermeasure is not said, this is a management problem, a matter of opinion. If there is no awareness, or as the beginning, if you feel that there is no need, there is really nothing to do, because everyone is similar.

If you want to do it, how do we define and evaluate technical debt? Learn from the leader! Both Firefox and chromium are big open source projects, which are 2.8 million rows and 4.7 million rows in size. Look at their summary is very good study. The core is evaluating and managing code in a quantitative way, and tools are open source. (In fact, the way to find & record is also very good, here is just as a reference way.) )

Quantification of technical debt (i.e., evaluation of code quality)

Mainly from how maintainable is the Firefox codebase?. To optimize, you need to define the criteria for the problem and evaluation.
Dimensions of the following code quality evaluations:

1. LOC (number of lines of code)
   Represents the size of the code. You can use this: cloc
   The larger the code, the greater the complexity of the system, but the lower the relative bug rate. The object of the assessment was not stated, apparently for a well-designed system. If the architecture is well-designed and everyone adheres to it, the new functionality will be implemented in the form of components and will not change the interface, which is why the bug does not spread.
2. Cyclomatic complexity
   Not much to say, do not know to see here: cyclomatic complexity evaluation and tools. If a rigorous definition is to be defined, the definition in software engineering books shall prevail.
3. First order density (First-order Density)
   It is used to evaluate the degree of direct dependency between files, because it is directly dependent, so it is the first order, which has only a and B relationships. The corresponding tool is DSM, Design Structure Matrix. You can find a tool on GitHub that I haven't tried.
4. Change costs (propagation cost)
   Estimate how many files will be affected by the random change of a file. It can react to a direct dependency of a first order relationship, or it can rise with the indirect dependency level of the higher order relationship.
   This is also an important indicator for measuring architectural design. Welcome to recommend the relevant tools.
5. Core code size (core size)
   So the core code is defined from the dependency relationship. If the file has a ring-dependent form of high dependency is the so-called core code. Many studies have shown that the smaller the amount of code, the fewer bugs.

Tools

1. Code Static Analysis Tool
   LOC, cyclomatic complexity, and dependencies are all readily available through a static analysis tool.
   For example, the code volume changes for both:
   
   The cyclomatic complexity of both:
   

2. Networked processing (network multiplication)
   Through the network processing, can obtain the change cost, the first order density, the core code size data.
   Comparison of cost changes for Firefox&chromium:
   
   Is the comparison of the core size:
   

3. DSM Tools.
   DSM is actually very simple. is to describe the relationship of each element in the system. The horizontal and vertical axes are all elements of the system, and if I,J is associated, The matrix (I,J) is either true or marked.
   is a Firefox 16 DSM provided by the author:
   
   The left side is a direct dependency, and the right side is indirect.

For more detailed information, refer to: Technical debt in Firefox and Chromium
Complete Tools on GitHub: Tools
Its approximate processing flow is as follows:

Summarize

The definition of technical debt is only a reference, and more importantly, awareness and implementation. With the basic concepts and intentions, the tools of execution are flexible and completely a technical management act.

Reprint Please specify source: Http://blog.csdn.net/horkychen

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Technical debt management and debt evaluation of Firefox/chromium