INDUSTRY PRACTICES AND TOOL - Part02

CODE QUALITY

Code quality can have a major impact on software quality, on the productivity of software teams, and their ability to collaborate. Code quality can matters many ways. Long term usefulness and long term maintainability is   good thing of a code. It also minimize errors and easily debugged. If your code is quality code it can improve understandability. It can also decreases risks.

Qualitative Code Quality Metrics

From a business perspective, the most important aspects of code quality are those that most significantly impact on software ROI. A major challenge in software maintenance is understanding the existing code, and this is where code quality metrics can have a big impact.

Consequently, quality code should always be:

• Easy to understand (readability, formatting, clarity, well-documented)
• Easy to change (maintainability, extensibility)

Extensibility - Extensibility is the degree to which software is coded to incorporate future growth. The central theme of extensible applications is that developers should be able to add new features to code or change existing functionality without it affecting the entire system.

Maintainability - Code maintainability is a qualitative measurement of how easy it is to make changes, and the risks associated with such changes.

Developers can make judgments about maintainability when they make changes if the change should take an hour but it ends up taking three days, the code probably isn’t that maintainable.

Another way to gauge maintainability is to check the number of lines of code in a given software feature or in an entire application. Software with more lines can be harder to maintain.

Readability and Code Formatting - Readable code should use indentation and be formatted according to standards particular to the language it’s written in; this makes the application structure consistent and visible.

Clarity - Clarity is an indicator of quality that says good code should be unambiguous. If you look at a piece of code and wonder what on earth it does, then that code is ambiguous.

This, along with readability and documentation, means any other developer can easily use code written by someone else, without taking a long time to understand how it works.

Well-documented - If the program is not documented, it will be difficult for other developers to use it, or even for the same developer to understand the code years from now. One common definition of quality is that it may be “used long term, can be carried across to future releases and products” (without being considered “legacy code”). Documentation is essential to make this happen.

Documentation also provides a way to improve by formalizing the decisions you make when writing. When you document code and do it well, you need to think differently about each component and why it exists in the software. Writing out the reasons for certain programming decisions can improve application design.

Well-tested - Well tested programs are likely to be of higher quality, because much more attention is paid to the inner workings of the code and its impact on users. Testing means that the application is constantly under scrutiny.

Efficiency - Efficient code only uses the computing resources it needs to. Another efficiency measurement is that it runs in as little time as possible.

Many developers believe that inefficient code is not of good quality (even if it satisfies some of the criteria above). Some negative impacts of not building for efficiency is long build times, difficulty to detect and fix bugs, and performance issues for the user.

How Code quality is measured?

To be effective, metrics must measure properties that have the most positive impact. According to our poll, 70% of respondents believe that maintainability is the most important aspect of code to measure, even as compared to performance or security. SIG has found a number of ways to measure software maintainability.

01.   Weighted Micro Function Points

02.   Halstead Complexity Measures

03.   Cyclomatic Complexity

04.   Lines of code

05.   Lines of code per method

WEIGHTED MICRO FUNCTION POINTS

Weighted Micro Function Points (WMFP) is a modern software sizing algorithm invented by Logical Solutions in 2009 which is a successor to solid ancestor scientific methods as COCOMO, COSYSMO, maintainability index, cyclomatic complexity, function points, and Halstead complexity. It produces more accurate results than traditional software sizing methodologies, while requiring less configuration and knowledge from the end user, as most of the estimation is based on automatic measurements of an existing source code.

As many ancestor measurement methods use source lines of code (SLOC) to measure software size, WMFP uses a parser to understand the source code breaking it down into micro functions and derive several code complexity and volume metrics, which are then dynamically interpolated into a final effort score. In addition to compatibility with the waterfall software development life cycle methodology, WMFP is also compatible with newer methodologies, such as Six Sigma, Boehm spiral, and Agile (AUP/Lean/XP/DSDM) methodologies, due to its differential analysis capability made possible by its higher-precision measurement elements.

 HALSTEAD COMPLEXITY MEASURES

Halstead complexity measures are software metrics introduced by Maurice Howard Halstead in 1977 as part of his treatise on establishing an empirical science of software development. Halstead made the observation that metrics of the software should reflect the implementation or expression of algorithms in different languages, but be independent of their execution on a specific platform. These metrics are therefore computed statically from the code.

Halstead's goal was to identify measurable properties of software, and the relations between them. This is similar to the identification of measurable properties of matter (like the volume, mass, and pressure of a gas) and the relationships between them (analogous to the gas equation). Thus his metrics are actually not just complexity metrics.

CYCLOMATIC  COMPLEXITY

Cyclomatic complexity is a software metric used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program's source code. It was developed by Thomas j. Maccaber in 1976.

Cyclomatic complexity is computed using the control flow graph of the program: the nodes of the graph correspond to indivisible groups of commands of a program, and a directededge connects two nodes if the second command might be executed immediately after the first command. Cyclomatic complexity may also be applied to individual functions, modules, methods or classes within a program.

One testing strategy, called basis path testing by McCabe who first proposed it, is to test each linearly independent path through the program; in this case, the number of test cases will equal the cyclomatic complexity of the program.

LINES OF CODES

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.

Many useful comparisons involve only the order of magnitude of lines of code in a project. Using lines of code to compare a 10,000 line project to a 100,000 line project is far more useful than when comparing a 20,000 line project with a 21,000 line project. While it is debatable exactly how to measure lines of code, discrepancies of an order of magnitude can be clear indicators of software complexity or man hours.

There are two major types of SLOC measures: physical SLOC (LOC) and logical SLOC (LLOC). Specific definitions of these two measures vary, but the most common definition of physical SLOC is a count of lines in the text of the program's source code excluding comment lines.

Logical SLOC attempts to measure the number of executable "statements", but their specific definitions are tied to specific computer languages (one simple logical SLOC measure for C-like programming languages is the number of statement-terminating semicolons). It is much easier to create tools that measure physical SLOC, and physical SLOC definitions are easier to explain. However, physical SLOC measures are sensitive to logically irrelevant formatting and style conventions, while logical SLOC is less sensitive to formatting and style conventions. However, SLOC measures are often stated without giving their definition, and logical SLOC can often be significantly different from physical SLOC.

TOOLS FOR MAINTAIN CODE QUALITY

There are so many tools available to maintain code quality.

                 Ex: - sonarqube

                          CSS LINT

                          Sonarsource

                          Klockwork

Sonarqube - SonarQube (formerly Sonar is an open-source platform developed by SonarSource for continuous inspection of code quality to perform automatic reviews with static analysis of code to detect bugs, code smells, and security vulnerabilities on 20+ programming languages. SonarQube offers reports on duplicated code, coding standards, unit tests, code coverage, code complexity, comments, bugs, and security vulnerabilities.

Sonarsource - SonarSource is a company that develops open source software for continuous code quality. Founded by Freddy Mallet, Olivier Gaudin, and Simon Brandhof in 2008, SonarSource is headquartered in Geneva, Switzerland. The main product of the company named “SonarQube” is a free open source platform to do automatic code reviews, with different paid extensions. The Enterprise package from SonarSource attracted around 900 customers, including eBay, Bank of America, BMW.

CSS LINT - CSS Lint is a tool to help point out problems with your CSS code. It does basic syntax checking as well as applying a set of rules to the code that look for problematic patterns or signs of inefficiency. The rules are all pluggable, so you can easily write your own or omit ones you don't want.

DEPENDENCY/PACKAGE  MANAGEMENT

Software project may have a backbone framework and many external artefacts linked, like third party packages, external libraries, plug-in’s and etc. Even though these external artefacts have many benefits it can introduce many integration issues.

·         Different folder/files structures and may use different ways of integrating into the main framework.

·         Different external artefacts may use different ways of integration.

·         Different versions are available and difficult to upgrade.

A package manager or package management system is a collection of software tools that automates the process of installing, upgrading, configuring, and removing computer programs for a computer's operating system in a consistent manner.

A package manager deals with packages, distributions of software and data in archive files. Packages contain metadata, such as the software's name, description of its purpose, version number, vendor, checksum, and a list of dependencies necessary for the software to run properly. Upon installation, metadata is stored in a local package database. Package managers typically maintain a database of software dependencies and version information to prevent software mismatches and missing prerequisites. They work closely with software repositories, binary repository managers, and app stores.

Some tools can minimizing these issues.

·                  Composer [PHP]

·                   Maven [Java]

·                   NuGet [.net]

·                   NPM [JS]

·                  Bower [JS]

MAVEN

Maven is a multi-process tool. It can making the build process easier providing a uniform build system, providing guidelines for best practices development. But providing quality project information is very important benefit of this tool.

           • Change log document created directly from source control

           • Cross referenced sources

           • List of mailing lists managed by the project

           • Dependency list

           • Unit test reports including coverage

Maven use two types of repositories. Local and remote. Local type is inside the computer. Remote type also divide two parts.

                      Internal - within the company

                      External – Via internet from the original repository

INTRODUCTION TO REPOSITORY

Artifact Repositories

A repository in Maven holds build artifacts and dependencies of varying types.

There are exactly two types of repositories: local and remote. The local repository is a directory on the computer where Maven runs. It caches remote downloads and contains temporary build artifacts that you have not yet released.

Remote repositories refer to any other type of repository, accessed by a variety of protocols such as file:// and http://. These repositories might be a truly remote repository set up by a third party to provide their artifacts for downloading (for example, repo.maven.apache.org and uk.maven.org house Maven's central repository). Other "remote" repositories may be internal repositories set up on a file or HTTP server within your company, used to share private artifacts between development teams and for releases.

Local and remote repositories are structured the same way so that scripts can run on either side, or they can be synced for offline use. The layout of the repositories is completely transparent to the Maven user, however.

Using Repositories

In general, you should not need to do anything with the local repository on a regular basis, except clean it out if you are short on disk space (or erase it completely if you are willing to download everything again).

For the remote repositories, they are used for both downloading and uploading (if you have the permission to do so).

Downloading from a Remote Repository

Downloading in Maven is triggered by a project declaring a dependency that is not present in the local repository (or for a SNAPSHOT, when the remote repository contains one that is newer). By default, Maven will download from the central repository.

To override this, you need to specify a mirror as shown in Using Mirrors for Repositories

You can set this in your settings.xml file to globally use a certain mirror. However, it is common for a project to customise the repository in its pom.xml and that your setting will take precedence. If dependencies are not being found, check that you have not overridden the remote repository.

For more information on dependencies, see Dependency Mechanism.

BEST PRACTICE – USING REPOSITORY MANAGER

A repository manager is a dedicated server application designed to manage repositories of binary components. The usage of a repository manager is considered an essential best practice for any significant usage of Maven.

PURPOSE –

     A repository manager serves these essential purposes:

§  act as dedicated proxy server for public Maven repositories

§  provide repositories as a deployment destination for your Maven project outputs

BENEFITS AND FEATURES

  Using a repository manager provides the following benefits and features:

§  significantly reduced number of downloads off remote repositories, saving time and bandwidth resulting in increased build performance

§  improved build stability due to reduced reliance on external repositories

§  increased performance for interaction with remote SNAPSHOT repositories

§  potential for control of consumed and provided artifacts

§  creates a central storage and access to artifacts and meta data about them exposing build outputs to consumer such as other projects and developers, but also QA or operations teams or even customers

§  provides an effective platform for exchanging binary artifacts within your organization and beyond without the need for building artifact from source

AVAILABLE REPOSITORY MANAGERS

The following list (alphabetical order) of open source and commercial repository managers are known to support the repository format used by Maven. Please refer to the respective linked web sites for further information about repository management in general and the features provided by these products.

§  Apache Archiva (open source)

§  CloudRepo (commercial)

§  Cloudsmith Package (commercial)

§  JFrog Artifactory Open Source (open source)

§  JFrog Artifactory Pro (commercial)

§  Sonatype Nexus OSS (open source)

§  Sonatype Nexus Pro (commercial)

§  packagecloud.io (commercial)

PROJECT OBJECT MODEL [POM]

A Project Object Model or POM is the fundamental unit of work in Maven. It is an XML file that contains information about the project and configuration details used by Maven to build the project. It contains default values for most projects. Examples for this is the build directory, which is target; the source directory, which is src/main/java; the test source directory, which is src/test/java; and so on. When executing a task or goal, Maven looks for the POM in the current directory. It reads the POM, gets the needed configuration information, then executes the goal.

Some of the configuration that can be specified in the POM are the project dependencies, the plugins or goals that can be executed, the build profiles, and so on. Other information such as the project version, description, developers, mailing lists and such can also be specified.

BUILD TOOLS

What are build tools?

Build tools are programs that automate the creation of executable applications from source code (e.g. .apk for android app). Building incorporates compiling, linking and packaging the code into a usable or executable form.

Basically build automation is the act of scripting or automating a wide variety of tasks that software developers do in their day-to-day activities like:

1.       Downloading dependencies.

2.       Compiling source code into binary code.

3.       Packaging that binary code.

4.       Running tests.

5.       Deployment to production systems.

Why do we use build tools or build automation?

In small projects, developers will often manually invoke the build process. This is not practical for larger projects, where it is very hard to keep track of what needs to be built, in what sequence and what dependencies there are in the building process. Using an automation tool allows the build process to be more consistent.

Various build tools available (Naming only few):

1.       For java - Ant, Maven, Gradle.

2.       For .NET framework - NAnt

3.       C# - MsBuild.

BUILD AUTOMATION

Build automation is the process of automating the creation of a software build and the associated processes including: compiling computer source code into binary code, packaging binary code, and running automated tests.

Build-automation utility (like Make, Rake, Cake, MS build, Ant, Gradle etc.)

Whose primary purpose is to generate build artifacts through activities like compiling and linking source code.

Build-automation servers

These are general web based tools that execute build-automation utilities on a scheduled or triggered basis; a continuous integration server is a type of build-automation server.

Depending on the level of automation the following classification is possible:

·         Makefile - level

·      Make-based tools

·      Non-Make-based tools

·         Build script (or Makefile) generation tools

·         Continuous-integration tools

·         Configuration-management tools

·         Meta-build tools or package managers

·         Other

A software list for each can be found in list of build automation software.

Build-automation utilities

Build-automation utilities allow the automation of simple, repeatable tasks. When using the tool, it will calculate how to reach the goal by executing tasks in the correct, specific order and running each task. The two ways build tools differ are task-oriented vs. product-oriented. Task-oriented tools describe the dependency of networks in terms of a specific set task and product-oriented tools describe things in terms of the products they generate.

Build-automation servers.

Although build servers existed long before continuous-integration servers, they are generally synonymous with continuous-integration servers, however a build server may also be incorporated into an ARA tool or ALM tool.

Server types

·         On-demand automation such as a user running a script at the command line

·         Scheduled automation such as a continuous integration server running a nightly build

·         Triggered automation such as a continuous integration server running a build on every commit to a version-control system.

Distributed build automation.

Automation is achieved through the use of a compile farm for either distributed compilation or the execution of the utility step. The distributed build process must have machine intelligence to understand the source-code dependencies to execute the distributed build.

CONVENTION OVER CONFIGURATION

Convention over configuration (also known as coding by convention) is a software design paradigm used by software frameworks that attempts to decrease the number of decisions that a developer using the framework is required to make without necessarily losing flexibility. The concept was introduced by David Heinemeier Hansson to describe the philosophy of the Ruby on Rails web framework, but is related to earlier ideas like the concept of "sensible defaults" and the principle of least astonishment in user interface design.

The phrase essentially means a developer only needs to specify unconventional aspects of the application. For example, if there is a class Sales in the model, the corresponding table in the database is called "sales" by default. It is only if one deviates from this convention, such as the table "product sales", that one needs to write code regarding these names.

When the convention implemented by the tool matches the desired behaviour, it behaves as expected without having to write configuration files. Only when the desired behaviour deviates from the implemented convention is explicit configuration required.

Ruby on Rails' use of the phrase is particularly focused on its default project file and directory structure, which prevent developers from having to write XML configuration files to specify which modules the framework should load, which was common in many earlier frameworks.

Disadvantages of the convention over configuration approach can occur due to conflicts with other software design principles, like the Zen of Python's "explicit is better than implicit." A software framework based on convention over configuration often involves a domain-specific language with a limited set of constructs or an inversion of control in which the developer can only affect behavior using a limited set of hooks, both of which can make implementing behaviours not easily expressed by the provided conventions more difficult than when using a software library that does not try to decrease the number of decisions developers have to make or require inversion of control.

BUILD LIFE CYCLE

Maven is based around the central concept of a build lifecycle. What this means is that the process for building and distributing a particular artifact (project) is clearly defined.

For the person building a project, this means that it is only necessary to learn a small set of commands to build any Maven project, and the POM will ensure they get the results they desired.

There are three built-in build lifecycles: default, clean and site. The default lifecycle handles your project deployment, the clean lifecycle handles project cleaning, while the site lifecycle handles the creation of your project's site documentation.

A BUILD LIFE CYCLE IS MADE UP OF PHASES

Each of these build lifecycles is defined by a different list of build phases, wherein a build phase represents a stage in the lifecycle.

For example, the default lifecycle comprises of the following phases (for a complete list of the lifecycle phases, refer to the Lifecycle Reference):

§  validate - validate the project is correct and all necessary information is available

§  compile - compile the source code of the project

§  test - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed

§  package - take the compiled code and package it in its distributable format, such as a JAR.

§  verify - run any checks on results of integration tests to ensure quality criteria are met

§  install - install the package into the local repository, for use as a dependency in other projects locally

§  deploy - done in the build environment, copies the final package to the remote repository for sharing with other developers and projects.

These lifecycle phases (plus the other lifecycle phases not shown here) are executed sequentially to complete the default lifecycle. Given the lifecycle phases above, this means that when the default lifecycle is used, Maven will first validate the project, then will try to compile the sources, run those against the tests, package the binaries (e.g. jar), run integration tests against that package, verify the integration tests, install the verified package to the local repository, then deploy the installed package to a remote repository.

ADDITIONAL TOOLS AND PRACTICES

·         Continuous Integration

·         Configuration Management

·         Test Automation

·         Issue/bug Tracking Tools

·         Agile Methodologies

CONTINUOUS INTEGRATION

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. 

By integrating regularly, you can detect errors quickly, and locate them more easily.

SOLVE PROBLEMS QUICKLY

Because you’re integrating so frequently, there is significantly less back-tracking to discover where things went wrong, so you can spend more time building features.

Continuous Integration is cheap. Not integrating continuously is expensive. If you don’t follow a continuous approach, you’ll have longer periods between integrations. This makes it exponentially more difficult to find and fix problems. Such integration problems can easily knock a project off-schedule, or cause it to fail altogether.

Continuous Integration brings multiple benefits to your organization:

·         Say goodbye to long and tense integrations

·         Increase visibility enabling greater communication

·         Catch issues early and nip them in the bud

·         Spend less time debugging and more time adding features

·         Build a solid foundation

·         Stop waiting to find out if your code’s going to work

·         Reduce integration problems allowing you to deliver software more rapidly

CONFIGURATION MANAGEMENT

In software engineering, software configuration management (SCM or S/W CM) is the task of tracking and controlling changes in the software, part of the larger cross-disciplinary field of configuration management. SCM practices include revision control and the establishment of baselines. If something goes wrong, SCM can determine what was changed and who changed it. If a configuration is working well, SCM can determine how to replicate it across many hosts.

The acronym "SCM" is also expanded as source configuration management process and software change and configuration management However, "configuration" is generally understood to cover changes typically made by a system administrator.

TEST AUTOMATION

Automation testing is a technique uses an application to implement entire life cycle of the software in less time and provides efficiency and effectiveness to the testing software.

Automation testing is an Automatic technique where the tester writes scripts by own and uses suitable software to test the software. It is basically an automation process of a manual process. Like regression testing, Automation testing also used to test the application from load, performance and stress point of view.

In other word, Automation testing uses automation tools to write and execute test cases, no manual involvement is required while executing an automated test suite. Usually, testers write test scripts and test cases using the automation tool and then group into test suites.

The main goal of Automation testing is to increase the test efficiency and develop software value.

AGILE METHODOLOGIES

Agile Methodology is a people-focused, results-focused approach to software development that respects our rapidly changing world. It’s centered around adaptive planning, self-organization, and short delivery times. It’s flexible, fast, and aims for continuous improvements in quality, using tools like Scrum and extreme Programming.

HOW IT WORKS

It works by first admitting that the old “waterfall” method of software development leaves a lot to be desired. The process of “plan, design, build, test, deliver,” works okay for making cars or buildings but not as well for creating software systems. In a business environment where hardware, demand, and competition are all swiftly-changing variables, agile works by walking the fine line between too much process and not enough.

AGILE METHODOLOGY OVERVIEW

It abandons the risk of spending months or years on a process that ultimately fails because of some small mistake in an early phase. It relies instead on trusting employees and teams to work directly with customers to understand the goals and provide solutions in a fast and incremental way.

·  Faster, smaller. Traditional software development relied on phases like outlining the requirements, planning, design, building, testing, and delivery. Agile methodology, by contrast, looks to deploy the first increment in a couple weeks and the entire piece of software in a couple months.

· Communication. Agile teams within the business work together daily at every stage of the project through face-to-face meetings. This collaboration and communication ensure the process stays on track even as conditions change.

· Feedback. Rather than waiting until the delivery phase to gauge success, teams leveraging Agile methodology track the success and speed of the development process regularly. Velocity is measured after the delivery of each increment.

·Trust. Agile teams and employees are self-organizing. Rather than following a manifesto of rules from management intended to produce the desired result, they understand the goals and create their own path to reach them.

·Adjust. Participants tune and adjust the process continually, following the

       KIS or keep it simple principle.