So with this article, I wanted to give you the information that helped me understand what Code quality is,what it can do,Dependency/package management, Build tools and Additional tools.
Let’s begin!
Code quality is rather a group of different attributes and requirements, determined and prioritized by your business.
Here are the main attributes that can be used to determine code quality:
- Clarity: Easy to read and oversee for anyone who isn’t the creator of the code. If it’s easy to understand, it’s much easier to maintain and extend the code. Not just computers, but also humans need to understand it.
- Maintainable: A high-quality code isn’t over complicated. Anyone working with the code has to understand the whole context of the code if they want to make any changes.
- Documented: he best thing is when the code is self-explaining, but it’s always recommended to add comments to the code to explain its role and functions. It makes it much easier for anyone who didn’t take part in writing the code to understand and maintain it.
- Refactored: Code formatting needs to be consistent and follow the language’s coding conventions.
- Well-tested: The less bug the code has the higher its quality is. Thorough testing filters out critical bugs ensuring that the software works the way it’s intended.
- Extensible: The code you receive has to be extendible. It’s not really great when you have to throw it away after a few weeks.
- Efficiency: High-quality code doesn’t use unnecessary resources to perform a desired action.
The quality of the code can be measured by different aspects •Weighted Micro Function Points
•Hal-stead Complexity Measures
•Lines of code
•Lines of code per method
Maintain the code quality:
•Using Code Review tools
How to maintain the code quality:
•Documenting the code.
Comments improves the readability and the understand-ability of the code.
•Regular Code Reviews.
According to a recent survey, software professionals rank-code reviews as the number one way to improve programming. These reviews enable developers to collaborate and share knowledge with each other, which improves their work. Furthermore, reviews ensure that code adheres to established standards.
•Functional Testing.
Functional testing is important because it encourages developers to focus on software functionality from the outset, reducing extraneous code. The aim of software development is to write an application that delivers exactly what users need.
•Clear Requirements.
Most software development projects begin with a requirements document, or story cards in agile development. A project with clear, feasible requirements is much more likely to achieve high quality than ambiguous, poorly specified requirements
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.
Package managers are designed to eliminate the need for manual installs and updates. This can be particularly useful for large enterprises whose operating systems are based on Linux and other Unix-like systems, typically consisting of hundreds or even tens of thousands of distinct software packages
Build tools are programs that automate the creation of executable applications from source code
(eg: 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.
Due to the increasing growth in complexity and size of software being developed, and the nature of large-scale software development, performing code coverage analysis is not an easy task despite the benefits to quality improvement. Empirical verification of several software metrics in large-scale software development were investigated to reduce efforts required for coverage analysis and to identify error-prone modules. The metrics examined were:
• coarse coverage analysis versus detailed coverage analysis
• block versus decision coverage
• Pareto-like defect distribution by releases, and components
• cyclomatic complexity
versus defect and module size The results suggested that detailed coverage analysis of all modules is not desirable and it is not cost effective. By present a systematic approach of coverage analysis, It will minimize the amount of effort needed for coverage analysis while maximizing the possibility of catching bugs.
In the context of software development, build refers to the process that converts files and other assets under the developers' responsibility into a software product in its final or consumable form. The build may include:
compiling source files
packaging compiled files into compressed formats (such as jar, zip)
producing installers
creating or updating of database schema or data
The build is automated when these steps are repeatable, require no direct human intervention, and can be performed at any time with no information other than what is stored in the source code control repository.
Build automation is a prerequisite to effective use of continuous integration. However, it brings benefits of its own:
eliminating a source of variation, and thus of defects; a manual build process containing a large number of necessary steps offers as many opportunities to make mistakes.
requiring thorough documentation of assumptions about the target environment, and of dependencies on third party products.
The majority of the dev world still chooses between just two build tools, Maven and Jenkins, the latter of the two having been created nearly a generation ago. At best, programmers would prefer their build tool remain invisible and stable; at worst, we hear complaints of downloading enormous libraries, scripts failing for no reason due to some invisible rule running in the background, and general annoyances.
With Maven we can run a single archetype command and create the skeleton of a fully compliant Jakarta EE, Spring Boot, Java EE Micro Profile or Android application. Writing a Maven plug-in is easy, as doing so only requires a basic knowledge of Java programming. Because of this low barrier for entry, a rich set of Maven add-ons exist, ranging from code quality quantifiers like PMD to McCabe cyclomatic complexity reporting tools like Jacoco. Maven is Java-based. Maven's installation couldn't be simpler. And Maven doesn't need to be hosted in a servlet engine. These are just a few of the reasons why Maven wins in any Maven vs. Jenkins comparison.
And as impressive as these aforementioned virtues are, they don't even touch upon Maven's greatest contribution to the Java development community, which is the fact that Maven solved the contemptuous problem of resolving dependent JAR files at run time.
The client-facing programming model Maven provides leaves plenty to be desired. Creating plug-ins is relatively easy, as their Maven plain Old Java Object (MOJO)-based twist on Plain Old Java Object (POJO) development is both clever and easy to learn. But, externally, Maven is configured primarily through XML-based Project Object Model (POM) files. Personally, I'd rather spend an afternoon filing expense reports than fiddling around with Maven POM files. I think most Java developers would agree with me on that point.
A Build Life-cycle 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.... There are always pre and post phases to register goals, which must run prior to, or after a particular phase.
There are three built-in build life-cycles:
default life-cycles
clean life-cycles
site life-cycles
Each of these build life-cycles is defined by a different list of build phases,This command executes each default life cycle phase in order (validate, compile, package, etc.)
the default life cycle comprises of the following phases :
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 distributed 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.
Maven, a Yiddish word meaning accumulator of knowledge, was originally started as an attempt to simplify the build processes in the Jakarta Turbine project. There were several projects each with their own Ant build files that were all slightly different and JARs were checked into CVS. We wanted a standard way to build the projects, a clear definition of what the project consisted of, an easy way to publish project information and a way to share JARs across several projects.
The result is a tool that can now be used for building and managing any Java-based project. We hope that we have created something that will make the day-to-day work of Java developers easier and generally help with the comprehension of any Java-based project.
Maven’s Objectives
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
Convention over configuration 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 behavior, it behaves as expected without having to write configuration files. Only when the desired behavior 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.
Build Life-cycle:
A Build Life-cycle 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.
There are three built-in build life-cycles: default, clean and site. The default life-cycle handles your project deployment, the clean life-cycle handles project cleaning, while the site life-cycle handles the creation of your project's site documentation.
build phases:
Each of these build life-cycles is defined by a different list of build phases, wherein a build phase represents a stage in the life-cycle.
For example, the default life-cycle comprises of the following phases :
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
However, even though a build phase is responsible for a specific step in the build life-cycle, the manner in which it carries out those responsibilities may vary. And this is done by declaring the plugin goals bound to those build phases.
A plugin 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 life cycle by direct invocation. The order of execution depends on the order in which the goals and the build phases are invoked.
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 and Development environments.
When we execute "mvnpost-clean" command, Maven invokes the clean life-cycle consisting of the following phases.
•pre-clean
•clean
•post-clean
•Maven clean goal (clean:clean) is bound to the clean phase in the clean life-cycle
•Its clean: clean goal deletes the output of a build by deleting the build directory
ADDITIONAL TOOLS
•Continuous Integration
•Configuration Management
•Test automation
•Issue/bug tracking tools
•Agile methodologies.
0 comments:
Post a Comment