# Competent

• Writing maintainable CSS
• Code review process
• Code review theory and toolset
• Software metric conception
• Source lines of code metric
• Code coverage metric

# Writing maintainable CSS

• use semantic class name

<!-- non semantic -->
<div class="red pull-left pb3">
<div class="grid row">
<div class="col-xs-4">

<!-- semantic -->
<div class="basket">
<div class="product">
<div class="searchResults">

• write reusable css (@extend)

• prefer class name over id except:

  • labels to form fields
  • in-page anchors to a hash fragment in the URL
  • ARIA attributes to help screen reader users

• use convention .<module>[-<component>][-<state>] {}

# Code review process

Benefits

• Defect-free, well-documented software.
• Software that complies with enterprise coding standards.
• Teaching and sharing knowledge between developers.

Requirements

• code reviews must be a priority for everyone
• the reviewer should be critical, but considerate, and the reviewed should remember that the purpose is to help them improve and graciously accept feedback.

# Code review theory and toolset

• Instant code review

happens during pair programming. While one developer is hitting the keyboard to produce the code the other developer is reviewing the code right on the spot, paying attention to potential issues and giving ideas for code improvement on the go.

• Synchronous code review

Here the coder produces the code herself and asks the reviewer for a review immediately when she is done with coding.

The reviewer joins the coder at her desk and they look at the same screen while reviewing, discussing and improving the code together

also know as over-the-shoulder code review

• Asynchronous code review also known as tool-assisted code review

This one is not done together at the same time on the same screen, but asynchronously. After the coder is finished with coding, she makes the code available for review and starts her next task.

When the reviewer has time, he will review the code by himself at his desk on his own schedule, without talking to the coder in person, but writing down comments using some tooling.

After the reviewer is done, the tooling will notify the coder about the comments and necessary rework. The coder is going to improve the code based on the comments, again on his own schedule.

• Code review once in a while also known as meeting-based code review

A long time ago I used to do code review sessions about once every month together with the whole team. We were sitting in a meeting room and one developer was showing and explaining a difficult piece of code he has recently been writing.

The other developers were trying to spot potential issues, commenting and giving suggestions on how to improve the code.

# Code Review Tools

• Collaborator
• Review Assistant
• Codebrag
• Gerrit
• Codestriker
• Rhodecode
• Phabricator
• Crucible
• Veracode
• Review Board

# Software metric conception

Software metrics are quantitative measurements of a software product or project, which can help management understand software performance, quality, or the productivity and efficiency of software teams.

Top 5 Software Metrics:

• Customer Satisfaction
• Team Velocity
• Release Burndown
• Escaped Defects
• True test coverage

# Types of Software Metrics

• Formal code metrics

  • Lines of Code (LOC)
  • code complexity
  • Instruction Path Length, etc

• Developer productivity metrics

  These metrics can help you understand how much time and work developers are investing in a software project.

  • active days
  • assignment scope
  • efficiency and code churn

• Agile process metrics

  They measure the progress of a dev team in producing working, shipping-quality software features.

  • lead time
  • cycle time
  • velocity

Operational metrics

This checks how software is running in production and how effective operations staff are at maintaining it.

• Mean Time Between Failures (MTBF)
• Mean Time to Recover (MTTR)

Test metrics

This measures how comprehensively a system is tested, which should be correlated with software quality.

• code coverage
• percent of automated tests
• defects in production

Customer satisfaction

The ultimate measurement of how customers experience the software and their interaction with the software vendor.

• Net Promoter Score (NPS)
• Customer Effort Score (CES)
• Customer Satisfaction Score (CSAT)

# Source lines of code metric

Source lines of code (SLOC), also known as lines of code (LOC), is a software metric used to measure the size of a computer program by counting the number of lines in the text of the program's source code. SLOC is typically used to predict the amount of effort that will be required to develop a program, as well as to estimate programming productivity or maintainability once the software is produced.

# Physical and Logical SLOC

There are two major types of SLOC measures: physical SLOC and logical SLOC. Specific definitions of these terms vary depending on particular circumstances. The most common definition of physical SLOC is a count of lines in the text of the program's source code including comment lines and, sometimes, blank lines. Logical SLOC attempts to measure the number of executable expressions (such as operators, functions, etc.), but their specific definitions are tied to specific computer languages.

# Advantages

• Scope for automation of counting: since line of code is a physical entity; manual counting effort can be easily eliminated by automating the counting process. Small utilities may be developed for counting the LOC in a program. However, a logical code counting utility developed for a specific language cannot be used for other languages due to the syntactical and structural differences among languages. Physical LOC counters, however, have been produced which count dozens of languages.
• An intuitive metric: line of code serves as an intuitive metric for measuring the size of software because it can be seen, and the effect of it can be visualized. Function points are said to be more of an objective metric which cannot be imagined as being a physical entity, it exists only in the logical space. This way, LOC comes in handy to express the size of software among programmers with low levels of experience.
• Ubiquitous measure: LOC measures have been around since the earliest days of software

# Disadvantages

• Lack of accountability: lines-of-code measure suffers from some fundamental problems. Some think that it isn't useful to measure the productivity of a project using only results from the coding phase
• Lack of cohesion with functionality: skilled developers may be able to develop the same functionality with far less code
• Adverse impact on estimation: estimates based on lines of code can adversely go wrong, in all possibility.
• Developer’s experience: implementation of a specific logic differs based on the level of experience of the developer.
• Difference in languages: consider two applications that provide the same functionality (screens, reports, databases). One of the applications is written in C++ and the other application written in a language like COBOL.
• Psychology: a programmer whose productivity is being measured in lines of code will have an incentive to write unnecessarily verbose code. The more management is focusing on lines of code, the more incentive the programmer has to expand his code with unneeded complexity.

# Code coverage metric

This measures the number of lines of source code executed during a given test suite for a program. Tools that measure code coverage normally express this metric as a percentage.

# Basic coverage criteria

• Function coverage – has each function in the program been called?
• Statement coverage – Has each statement in the program been executed?
• Edge coverage – has every edge in the Control flow graph been executed?
• Branch coverage – Has each branch (also called DD-path) of each control structure (such as in if and case statements) been executed?
• Condition coverage (or predicate coverage) – Has each Boolean sub-expression evaluated both to true and false?

# Jest example