Tutorial 03 – Industry practices and tools 2
1.Discuss the importance of maintaining the quality of the code,
explaining the different aspects of the code quality?
code quality is
crucial to a company's succes. It goes without saying that the software
that we deliver to customers should be of high quality. Our products
need to look great and help customers run their business. The fact that they
do, is because of the thousands and thousands of lines of code under the
hood.
•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 overcomplicated. Anyone working with the code has to
understand the whole context of the code if they want to make any changes.
•Documented: The best
thing is when the code is selfexplaining, 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 thelanguage’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.
2.Explain different approaches and measurements used to measure the quality of code?
•Weighted Micro Function Points
•Halstead Complexity Measures
•CyclomaticComplexity
•Lines of code
•Lines
of code per method
- The quantitative performance requirements of user requirements and system performance requirements are measured in the operational and development test programs. Suggestions on key performance parameters can be found in Enclosure B of the Chairman of the Joint Chiefs of Staff Manual on the Operation of the Joint Capabilities Integration and Development System
- Technical Performance Measurement (TPM) monitors the developer's progress in meeting critical performance requirements over the life of the program where there is a development risk. The concept is further explained on the Office of the Secretary of Defense (OSD) TPM web site
- Earned Value Management (EVM) monitors a developer's cost and schedule performance in cost reimbursement development contracts. Additional information can be found in the Earned Value Management article in this Systems Engineering Guide and in EIA-748A and the OSD EVM web site
- Process Metrics are associated with development processes like software development. A good approach to identifying the type of measurement needed and the proven metrics that support that measurement can be found on the Practical Software and System Measurement web site
3. Identify and compare some
available tools to maintain the code quality?
Sidekick
CSS LINT
sonarQube
4. Discuss the need for
dependency/package management tools in software development?
Dependency is a broad software
engineering term used to refer when a piece of software relies on another one.
In software engineering, coupling or dependency is the degree to which each
program module relies on each one of the other modules. X depends
on Y. Y is X's dependency
Regardless of your experience in Java you have certainly heard about
building applications. Even if your single Java code consists of just one class
declaration with System.out.println (“Hello World!”) in main method it has to
be built. You are going to compile the class and make an executable jar to show
your friend the magic of HelloWorldApp, aren’t you? After a few days of
practicing Java you will want to add some dependencies and unit tests and
you’ll meet a build process again and again. Most likely you will notice that
in many cases you have to do the same magic with your source code every time
you want to run it: add dependencies, compile, test, package, deploy… and the
cycle is growing. And here the build automation tools come to do the trick.In this article we’ll set up a local deployment of a small web application in Eclipse Mars IDE without build automation and then improve dependency management by integrating several tools. The article will be interesting for Java developers with any level of expertise.
5. Explain the role of dependency/package
management tools in software development?
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. ... Upon
installation, metadata is stored in a local package database.
in short, dependency management tools
move the responsibility of managing third-party libraries from the code
repository to the automated build. 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.
6. Compare and contrast different
dependency/package management tools used in industry?
Gradle does not use XML. Instead,
it had its own DSL based on Groovy (one of JVM languages). As a result, Gradle
build scripts tend to be much shorter and clearer than those written for Ant
or Maven. ... Initially, Gradle used Apache Ivy for its
dependency management.
7. What is a build tool? Indicate
the significance of using a build tool in large scale software development,
distinguishing it from small scale software development?
A build tool is a programming
utility that is used when building a new version of a program
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.
8. Explain
the role of build automation in build tools indicating the need for build
automation?
To save time and money and to reduce
human mistakes that are possible during manual building, software developers
usually try to automate this process. Automated builds are very important
during software development and the use of automated tests during the build
process is also important.
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
9. Compare
and contrast different build tools used in industry?
Ant was the first among “modern” build tools. In many
aspects it is similar to Make. It was released in 2000 and in a short period of
time became the most popular build tool for Java projects. It has very low
learning curve thus allowing anyone to start using it without any special
preparation. It is based on procedural programming idea.
After its initial release, it was
improved with the ability to accept plug-ins.
Major drawback was XML as the format
to write build scripts. XML, being hierarchical in nature, is not a good fit
for procedural programming approach Ant uses. Another problem with Ant is that
its XML tends to become unmanageably big when used with all but very small
projects.
Later on, as dependency management
over the network became a must, Ant adopted Apache
Ivy.
Main benefit of Ant is its control
of the build process.
Maven was released in 2004. Its goal was to improve upon
some of the problems developers were facing when using Ant.
Maven continues using XML as the
format to write build specification. However, structure is diametrically
different. While Ant requires developers to write all the commands that lead to
the successful execution of some task, Maven relies on conventions and provides
the available targets (goals) that can be invoked. As the additional, and
probably most important addition, Maven introduced the ability to download
dependencies over the network (later on adopted by Ant through Ivy). That in
itself revolutionized the way we deliver software.
However, Maven has its own problems.
Dependencies management does not handle conflicts well between different
versions of the same library (something Ivy is much better at). XML as the
build configuration format is strictly structured and highly standardized.
Customization of targets (goals) is hard. Since Maven is focused mostly on
dependency management, complex, customized build scripts are actually harder to
write in Maven than in Ant.
Maven configuration written in XML
continuous being big and cumbersome. On bigger projects it can have hundreds of
lines of code without actually doing anything “extraordinary”.
Main benefit from Maven is its
life-cycle. As long as the project is based on certain standards, with Maven
one can pass through the whole life cycle with relative ease. This comes at a
cost of flexibility.
In the mean time the interest for
DSLs (Domain Specific Languages) continued increasing. The idea is to have
languages designed to solve problems belonging to a specific domain. In case of
builds, one of the results of applying DSL is Gradle.
Gradle combines good parts of both tools and builds on top
of them with DSL and other improvements. It has Ant’s power and flexibility
with Maven’s life-cycle and ease of use. The end result is a tool that was
released in 2012 and gained a lot of attention in a short period of time. For
example, Google adopted Gradle as the default build tool for the Android OS.
Gradle does not use XML. Instead, it
had its own DSL based on Groovy (one
of JVM languages). As a result, Gradle build scripts tend to be much shorter
and clearer than those written for Ant or Maven. The amount of boilerplate code
is much smaller with Gradle since its DSL is designed to solve a specific
problem: move software through its life cycle, from compilation through static
analysis and testing until packaging and deployment.
Initially, Gradle used Apache Ivy for its dependency management.
Later own it moved to its own native dependency resolution engine.
Gradle effort can be summed as
“convention is good and so is flexibility”.
10. Explain
the build life cycle, using an example (java, .net, etc…)?
When an ASP.NET page runs, the page goes through a life cycle in which
it performs a series of processing steps. These include initialization,
instantiating controls, restoring and maintaining state, running event
handler code, and rendering. The following are the various stages or
events of ASP.Net page life cycle.
11. What is
Maven, a dependency/package management tool or a build tool or something more?
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 is a build automation
tool
12. Discuss
how Maven uses conventions over configurations, explaining Maven’s approach to
manage the configurations?
Maven uses Convention over
Configuration, which means developers are not required to create build
process themselves. ... 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.
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
13. Discuss
the terms build phases, build life cycle, build profile, and build goal in
Maven?
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
However, even though a build phase
is responsible for a specific step in the build lifecycle, 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 (finer than a build phase) 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 (of a plugin).
Maven Phase
A Maven phase represents a stage in the Maven build lifecycle. Each phase is responsible for a specific task.Here are some of the most important phases in the default build lifecycle:
- validate: check if all information necessary for the build is available
- compile: compile the source code
- test-compile: compile the test source code
- test: run unit tests
- package: package compiled source code into the distributable format (jar, war, …)
- integration-test: process and deploy the package if needed to run integration tests
- install: install the package to a local repository
- deploy: copy the package to the remote repository
Phases are executed in a specific order. This means that if we run a specific phase using the command:
|
1
|
mvn
<PHASE> |
For example, if we run the deploy phase – which is the last phase in the default build lifecycle – that will execute all phases before the deploy phase as well, which is the entire default lifecycle:
|
1
|
mvn
deploy |
Maven Goal
Each phase is a sequence of goals, and each goal is responsible for a specific task.When we run a phase – all goals bound to this phase are executed in order.
Here are some of the phases and default goals bound to them:
- compiler:compile – the compile goal from the compiler plugin is bound to the compile phase
- compiler:testCompile is bound to the test-compile phase
- surefire:test is bound to test phase
- install:install is bound to install phase
- jar:jar and war:war is bound to package phase
|
1
|
mvn
help:describe -Dcmd=PHASENAME |
|
1
|
mvn
help:describe -Dcmd=compile |
|
1
2
|
compile'
is a phase corresponding to this plugin:org.apache.maven.plugins:maven-compiler-plugin:3.1:compile |
Maven Plugin
A Maven plugin is a group of goals. However, these goals aren’t necessarily all bound to the same phase.For example, here’s a simple configuration of the Maven Failsafe plugin which is responsible for running integration tests:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
<build> <plugins> <plugin> <artifactId>maven-failsafe-plugin</artifactId> <version>${maven.failsafe.version}</version> <executions> <execution> <goals> <goal>integration-test</goal> <goal>verify</goal> </goals> </execution> </executions> </plugin> </plugins></build> |
- integration-test: run integration tests
- verify: verify all integration tests passed
|
1
|
mvn
<PLUGIN>:help |
|
1
|
mvn
failsafe:help |
|
1
2
3
4
5
6
7
8
9
10
11
12
|
This
plugin has 3 goals:failsafe:help Display
help information on maven-failsafe-plugin. Call
mvn failsafe:help -Ddetail=true -Dgoal=<goal-name> to display parameter details.failsafe:integration-test Run
integration tests using Surefire.failsafe:verify Verify
integration tests ran using Surefire. |
|
1
|
mvn
<PLUGIN>:<GOAL> |
|
1
|
mvn
failsafe:integration-test |
14. Discuss
with examples, how Maven manages dependency/packages and build life cycle?
Transitive Dependencies Discovery
It is pretty often a case, when a library, say A, depends upon other library, say B. In case another project C wants to use A, then that project requires to use library B too.Maven helps to avoid such requirements to discover all the libraries required. Maven does so by reading project files (pom.xml) of dependencies, figure out their dependencies and so on.
We only need to define direct dependency in each project pom. Maven handles the rest automatically.
With transitive dependencies, the graph of included libraries can quickly grow to a large extent. Cases can arise when there are duplicate libraries. Maven provides few features to control extent of transitive dependencies.
|
|
Feature &
Description
|
|
1
|
Dependency mediation Determines what version of a dependency is to be used when multiple versions of an artifact are encountered. If two dependency versions are at the same depth in the dependency tree, the first declared dependency will be used. |
|
2
|
Dependency management Directly specify the versions of artifacts to be used when they are encountered in transitive dependencies. For an example project C can include B as a dependency in its dependency Management section and directly control which version of B is to be used when it is ever referenced. |
|
3
|
Dependency scope Includes dependencies as per the current stage of the build. |
|
4
|
Excluded dependencies Any transitive dependency can be excluded using "exclusion" element. As example, A depends upon B and B depends upon C, then A can mark C as excluded. |
|
5
|
Optional dependencies Any transitive dependency can be marked as optional using "optional" element. As example, A depends upon B and B depends upon C. Now B marked C as optional. Then A will not use C. |
15. Identify
and discuss some other contemporary tools and practices widely used in the
software industry?
•Continuous
Integration
•Configuration
Management
•Test automation
•Issue/bug tracking tools
•Agile methodologies, DevOps
Comments
Post a Comment