Importance of maintaining the Code Quality
Why Is Good Quality Code So Important? Good quality code is an essential property of a software because it could lead to financial losses or waste of time needed for further maintenance,modification or adjustments if code quality is not good enough.
Characteristics Of Good Quality Code
•Efficiency
Directly related to the performance and speed of running the software.
The quality of the software can be evaluated with the efficiency of the code used.
No one likes to use a software that takes too long to perform an action.
•Relaibility
Ability to perform consistent and failure-free operations every time it runs.
The software would be very less useful if the code function differently every time it runs even with the same input in same environment and if it breaks down often without throwing any errors.
•Robustness
Ability to cope with errors during program execution even under unusual condition.
Image how would you feel when you use a software that keep showing strange and unfamiliar message when you did something wrong.
Software is typically buggy and fragile but it should handle any errors encountered gracefully.
•Portability
Ability of the code to be run on as many different machines and operating systems as possible.
It would be a waste of time and energy for programmers to re-write the same code again when
it transferred from one environment to another.
•Maintainability
Code that is easy to add new features, modify existing features or fix bugs with a minimum of effort without the risk of affecting other related modules.
Software always needs new features or bug fixes. So the written code must be easy to understand,
easy to find what needs to be change, easy to make changes and easy to check that the changes have not introduced any bugs.
•Readable
The ability of allowing the code to be easily, quickly, and clearly understandable by someone new or
someone that hasn't seen it in a while.
Ensures that everyone can understand the code written by everyone else. o If the code is messy and badly written, it would be very hard to understand what the code does and where changes need to be made.
_________________________________________________________________________________
How to measure the Code Quality
• Weighted Micro Function Points
This metric is a modern software sizing algorithm that parses source code and breaks it down into micro functions.
The algorithm then produces several complexity metrics from these micro functions, before interpolating the results into a single score.
WMFP automatically measures the complexity of existing source code. The metrics used to determine the WMFP value include comments, code structure, arithmetic calculations, and flow control path.
• Halstead Complexity Measures
Measures of program vocabulary, program length, calculated program length, volume, difficulty, and effort.
The difficulty is especially useful as it is a representation of how complex the code is to understand.
There is also a calculation for the estimated number of bugs in an implementation.
• Cyclomatic Complexity
This measures the number of paths through a given block of code. The cyclomatic complexity for a block is the upper bound of tests to achieve complete branch coverage. If all paths through the code are actually possible, then this is also the upper bound on test cases needed for path coverage.
__________________________________________________________________________
Code Quality maintaining Tools
• sonarQube
SonarQube 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.
SonarQube can record metrics history and provides evolution graphs. SonarQube provides fully automated analysis and integration with Maven, Ant, Gradle, MSBuild and continuous integration tools
• Sidekick
Sidekick is a code analysis tool that’s currently in beta stages, supporting Ruby, CoffeeScript and JavaScript code for analysis.
Get your code analysed for the perfect style guides, push code updates and have only the new pieces of code analyzed,watch as your productivity and code quality increases as Sidekick continues to give you back the most comprehensive insights with perfect acuity.
• Klockwork
Unlike other static code analysis tools, Klocwork integrates seamlessly into desktop IDEs, build systems, continuous integration tools,and any team's natural workflow. Mirroring how code is developed at any stage, Klocwork prevents defects and finds vulnerabilities on-the-fly,as code is being written.
Klocwork also helps prioritize work with SmartRank, the revolutionary new recommendation engine that prioritizes issues and helps select which ones to work on first.
Take prioritized, corrective action immediately to deliver more secure and reliable code.
_________________________________________________________________________________
Needs of Package management tools in Software development
External artefacts may introduce many integration issues.
•Different folder/file structures and may use
different ways of integrating into the main
framework.
•Different external artifacts may use different ways
of integration.
•Different versions are available and difficult to
upgrade.
So we need package management tools to manage these external artefacts towards minimizing above issues.
_________________________________________________________________________________
Role of dependency/package management tools in Software development
•Dependency management tools move the responsibility of managing third-party libraries from the code repository to the automated build.
•Instead of manually managing multiple versions of libraries in either place, dependency management tools provide an explicit, repeatable, and reliable procedure for obtaining any given version.
•Typically dependency management tools use a single file to declare all library dependencies,
making it much easier to see all libraries and their versions at once.
•They prevent mixing incompatible files/libraries.
By letting the package manager control the entire folder, you can't get mixed versions; you ensure consistency.
They also make it much harder to use incompatible dependencies, by automatically updating everything together, installing different versions where needed.
_________________________________________________________________________________
Dependency/package management tools
•NuGet
NuGet is the package manager for the Microsoft development platform including .NET.
The NuGet client tools provide the ability to produce and consume packages.
The NuGet Gallery is the central package repository used by all package authors and consumers.
When you use NuGet to install a package, it copies the library files to your solution and automatically
updates your project.
If you remove a package, NuGet reverses whatever changes it made so that no clutter is left.
•Composer
This dependency manager for PHP lets you create a composer.json file in your project root, run a single command, and all your dependencies are downloaded ready to use.
It deals with “packages” or libraries, but it manages them on a per-project basis.
By default it does not install anything globally.It does however support a “global” project for convenience via the global command.
•Ender
Ender is the “no-library library” and is one of the lightest package managers you’ll find online.
It allows devs to search through JS packages and install/compile them right from the command line.
Ender is thought of as “NPM’s little sister” by the dev team.
•Mantri
Still in its early stages of growth, MantriJS is a dependency system for mid-to-high level web applications.
Dependencies are managed through namespaces and organized functionally to avoid collisions and reduce clutter.
It’s completely open source and built for more complex web applications that require large bundles of dependencies.
Mantri aims to follow modular programming practices and hopes to encourage developers onto the same path.
_________________________________________________________________________________
Build Tools
Build tools are programs that automate the creation of executable applications from source code.
Building incorporates compiling, linking and packaging the code into a usable or executable form.
As build processes become ever more complex, build automation tools usually support the management of the pre- and post-compile and link activities, as well as the compile and link activities.
Part of the function of the build tool is to cope with errors in the compilation process of complex software systems.
Modern build tools go further in enabling work flow processing by obtaining source code, deploying executables to be tests and even optimizing complex build processes using distributed build technologies which involves running the build process in a coherent, synchronized manner across several machines.
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 whatdependencies there are in the building process.
Using an automation tool allows the build process to be more consistent.
_________________________________________________________________________________
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.
Types of build automation
•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.
_________________________________________________________________________________
Shell Scripts
In general, shell scripts do an OK job at being a build tool, but not great. Their great advantage is their convenience: really easy to get started, really easy to start using other tools or to be used from other tools,and can even (surprisingly?) let you parallelize parts of your build acceptably, if manually.
On the other hand,they don't have a model of "what depends on what" inside your build, and so do a lousy job at ensuring things are run in the right order, or ensuring you aren't doing redundant work.
Ant
Ant scripts are basically isomorphic to shell scripts: they are effectively shell scripts with an XML syntax implemented in Java, but function more or less identically: you run targets with the XML (equivalent to bash functions) and it executes the commands within from top to bottom.
Ant has the following main differences from shell scripts
•It's all XML, and is several times more verbose than Bash commands.
•It's cross platform Java, which means it runs on Windows with Java installed.
•You can specify that a target depends on another target, similar to make.
It's almost like a make-file, converted into XML, running on the Java Virtual Machine rather than using Unix shell commands. The task-execution model is similar to Make, and the innards of each command is similar to Bash, just converted into a verbose XML syntax.
Maven
Maven is another build tool from the Java community. While it's XML-based like Ant, that's where the similarity ends.
Rather than describing a build as a sequence of commands to run in response to each named target, Maven describes your build as a set of modules.
Each module lists out metadata such as:
•It's coordinates: it's name, groupId (i.e. author's ID) and version.
•It's dependencies, whether local or external.
Grunt
Grunt is pretty similar to Maven in its overall structure: you pass in an almost-dumb-struct to the grunt.initConfig function, and that configures the entire build telling it where files are, what sources need to be compiled, where the output should go, what files it needs to watch, and so on.
It's not quite a dumb struct, as you end up having some simple logic. e.g. '<%= jshint.files %>'
The string above, which will get evaluated based on the value of the jshint.files configuration option.
Like Maven, and unlike Ant or Make or Shell Scripts, a Grunt build doesn't contain imperative code.
All the code that actually does the work of dealing with files or shelling out the jshint is pushed to plugins,
e.g. grunt-contrib-jshint and grunt-contrib-watch above, and the "main" build configuration only deals with configuring these plugins.
_________________________________________________________________________________
Build Lifecycle
A Build Lifecycle is a well-defined sequence of phases, which define the order in which the goals are to be executed. Here phase represents a stage in life cycle. As an example, a typical Maven Build Lifecycle consists of the following sequence of phases.
There are always pre and post phases to register goals, which must run prior to, or after a particular phase.
When Maven starts building a project, it steps through a defined sequence of phases and executes goals, which are registered with each phase.
Maven has the following three standard lifecycles :-
•clean
•default(or build)
•site
A goal represents a specific task which contributes to the building and managing of a project. It may be bound to zero or more build phases.
A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation.
The order of execution depends on the order in which the goal(s) and the build phase(s) are invoked.
_________________________________________________________________________________
Maven
Maven is a multi-purpose tool. It's not only a package management tool or build tool, it's something more.
Maven is aslo a build automation tool for Java projects. Think of Ant, or Make, but much more powerful and easier to use.
If you've ever had to deal with building a Java project with dependencies or special build requirements ,then you've probably gone through the frustrations that Maven aims to eliminate.
Maven’s primary goal is to allow a developer to comprehend the complete state of a development effort in the shortest period of time.
In order to attain this goal there are several areas of concern that Maven attempts to deal with:
•Making the build process easy
•Providing a uniform build system
•Providing quality project information
•Providing guidelines for best practices development
•Allowing transparent migration to new features
•Takes cares from validating to installing/deploying --> Lifecycle of Maven
•Helps to create sites, reporting and documentation
To summarize, Maven simplifies and standardizes the project build process. It handles compilation, distribution, documentation,
team collaboration and other tasks seamlessly. Maven increases reusability and takes care of most of the build related tasks.
_________________________________________________________________________________
How Maven uses conventions over configurations
Developers do not have to mention each and every configuration detail. Maven provides sensible default behavior for projects. When a Maven project is created, Maven creates default project structure. Developer is only required to place files accordingly and he/she need not to define any configuration in pom.xml.
In order to build the project, Maven provides developers with options to mention life-cycle goals and project dependencies (that rely on Maven plugin capabilities and on its default conventions). Much of the project management and build related tasks are maintained by Maven plugins.
Developers can build any given Maven project without the need to understand how the individual plugins work.
Build Goal
A goal represents a specific task which contributes to the building and managing of a project. It may be bound to zero or more build phases.
A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation.
The order of execution depends on the order in which the goal(s) and the build phase(s) are invoked. For example, consider the command below.
The clean and package arguments are build phases while the dependency:copy-dependencies is a goal.
Build Profile
A Build profile is a set of configuration values, which can be used to set or override default values of Maven build.
Using a build profile, you can customize build for different environments such as Production v/s Development environments.
Profiles are specified in pom.xml file using its activeProfiles/profiles elements and are triggered in variety of ways.
Profiles modify the POM at build time, and are used to give parameters different target environments
Types of Build Profile
Build profiles are majorly of three types.
some other contemporary tools
Docker
Docker provides a software containerization platform that enables you to package your application or software in a filesystem. This container could be moved and executed anywhere. You will find everything that you need to run: code, system libraries, etc. This means that the software will be running the same and will not depend on its environment.
Intellij
Intellij is an Integrated Development Environment. An IDE integrates all the tools that you need to develop a platform, so it has a code editor, a compiler, a debugger, etc. What we like about Intellij is that it has auto-completion and it’s really user-friendly and therefore easy to use. It also helps to quickly navigate through your code, provide error analysis, and offer handy quick fixes. It increases our productivity a lot.
Jira
Jira was developed for agile teams to plan, track, and release software. Obviously, as we breathe Agile, we also use Jira. It helps a lot when it comes to project management. We found it great because it’s very customizable and has powerful features and tools for every phase of development. In one place, you can manage the team backlog, visualize the work in progress, and generate reports.
No comments:
Post a Comment