Agile Software Design and Development:

Unit-IV
 Agile Design
• If agility is about building software in tiny
increments,
– How can you ever design the software?
– How can you take the time to ensure that the
software has a good structure that is flexible,
maintainable, and reusable?
– If you build in tiny increments, aren't you really
setting the stage for lots of scrap and rework in the
name of refactoring?
– Aren't you going to miss the big picture?
 Agile Design cont…
• In an agile team, the big picture evolves along with
the software. With each iteration, the team improves
the design of the system so that it is as good as it can
be for the system as it is now.
• The team does not spend very much time looking
ahead to future requirements and needs.
• Nor does it try to build in today the infrastructure to
support the features that may be needed tomorrow.
• Rather, the team focuses on the current structure of
the system, making it as good as it can be.
 What Is Agile Design?
• After reviewing the software development life
cycle as I understood it, I concluded that the
only software documentation that actually
seems to satisfy the criteria of an engineering
design is the source code listings.
Jack Reeves
 What Is Agile Design?
• How do we know how whether the design of a
software system is good?
• In this chapter we enumerates and describes
symptoms of poor design. Such symptoms, or
design smells often pervade the overall
structure of the software.
• The chapter demonstrates how those
symptoms accumulate in a software project
and explains how to avoid them.
 Design Smells
• If you are lucky, you start a project with a clear picture of what you
want the system to be. The design of the system is a vital image in your
mind. If you are luckier still, the clarity of that design makes it to the
first release.
• But then something goes wrong. The software starts to rot like a piece
of bad meat. As time goes by, the rotting continues.
• Ugly, festering sores and boils accumulate in the code, making it more
and more difficult to maintain. Eventually, the sheer effort required to
make even the simplest of changes becomes so onerous that the
developers and front-line managers cry for a redesign.
• Such redesigns rarely succeed. Although the designers start out with
good intentions, they find that they are shooting at a moving target.
The old system continues to evolve and change, and the new design
must keep up.
 Design Smells The Odors of Rotting
Software
• You know that the software is rotting when it starts to exhibit any
of the following odors.
• The symptoms are:
– Rigidity. The design is difficult to change.
– Fragility. The design is easy to break.
– Immobility. The design is difficult to reuse.
– Viscosity. It is difficult to do the right thing.
– Needless complexity. Overdesign.
– Needless repetition. Mouse abuse.
– Opacity. Disorganized expression.
• These symptoms are similar in nature to code smells, but are at a
higher level. They are smells that pervade the overall structure of
the software rather than a small section of code.
 Why Software Rots
• In non-agile environments, designs degrade
because requirements change in ways that the
initial design did not anticipate.
• Often, these changes need to be made quickly and
may be made by developers who are not familiar
with the original design philosophy.
• So, though the change to the design works, it
somehow violates the original design. Bit by bit, as
the changes continue, these violations accumulate
until malignancy sets in.
 Why Software Rots
• However, we cannot blame the drifting of the
requirements for the degradation of the design.
• We, as software developers, know full well that
requirements change. Indeed, most of us realize that the
requirements are the most volatile elements in the project.
• If our designs are failing owing to the constant rain of
changing requirements, it is our designs and practices that
are at fault.
• We must somehow find a way to make our designs
resilient to such changes and use practices that protect
them from rotting.
 Why Software Rots
• An agile team thrives on change. The team invests little
up front and so is not vested in an aging initial design.
• Rather, the team keeps the design of the system as
clean and simple as possible and backs it up with lots
of unit tests and acceptance tests.
• This keeps the design flexible and easy to change.
• The team takes advantage of that flexibility in order to
continuously improve the design; thus, each iteration
ends with a system whose design is as appropriate as it
can be for the requirements in that iteration.
 The Copy Program
• A Familiar Scenario:
– Watching a design rot may help illustrate the preceding points. Let's say
that your boss comes to you early Monday morning and asks you to write
a program that copies characters from the keyboard to the printer.
– Doing some quick mental exercises in your head, you conclude that this
will be less than ten lines of code. Design and coding time should be a lot
less than 1 hour.
– What with cross-functional group meetings, quality education meetings,
daily group progress meetings, and the three current crises in the field,
this program ought to take you about a week to complete if you stay after
hours.
– However, you always multiply your estimates by 3.
• "Three weeks," you tell your boss. He harrumphs and walks away,
leaving you to your task.
 The Copy Program
• The initial design
• You have a bit of time right now before that process review meeting begins, so you
decide to map out a design for the program. Using structured design, you come up
with the structure chart in Figure
 The Copy Program
• There are three modules, or subprograms, in the application.
– The Copy module calls the other two.
– The Copy program fetches characters from the Read Keyboard module and
– Routes them to the Write Printer module.

• You look at your design and see that it is good. You smile and then leave
your office to go to that review. At least you'll be able to get a little sleep
there.
 The Copy Program
• On Tuesday, you come in a bit early so that you can finish up the Copy program.
Unfortunately, one of the crises in the field has warmed up overnight, and you have to go
to the lab and help debug a problem. On your lunch break, which you finally take at 3 PM,
you manage to type in the code for the Copy program. The result is Listing 7-1.
• Listing 7-1. The Copy Program
public class Copier
{
public static void Copy()
{
int c;
while((c=Keyboard.Read()) !
= -1)
Printer.Write(c);
}
}

• You just manage to save the edit when you realize that you are already late for a quality
meeting. You know that this is an important one; they are going to be talking about the
magnitude of zero defects. So you wolf down your Twinkies and Coke and head off to the
 The Copy Program
• On Wednesday, you come in early again, and this time nothing seems to be amiss.
So you pull up the source code for the Copy program and begin to compile it. It
compiles first time with no errors! It's a good thing, too, because your boss calls
you into an unscheduled meeting about the need to conserve laser printer toner.
• On Thursday, after spending 4 hours on the phone walking a service
technician in Gyan , North Delhi, through the remote debugging and error-
logging commands in one of the more obscure components of the system,
you grab a Hoho and then test your Copy program. It works, first time!
Good thing, too. Because your new co-op student has just erased the
master source code directory from the server, and you have to go find the
latest backup tapes and restore it. Of course, the last full backup was
taken 3 months ago, and you have 94 incremental backups to restore on
top of it.
 The Copy Program
• Friday is completely unbooked. Good thing, too, because it takes all day to get the
Copy program successfully loaded into your source code control system. Of course,
the program is a raging success and gets deployed throughout your company. Your
reputation as an ace programmer is once again confirmed, and you bask in the
glory of your achievements. With luck, you might actually produce 30 lines of code
this year!
 The Copy Program
• The requirements they are a'changing'
• A few months later, your boss comes to you and says that the Copy
program should also be able to read from the paper tape reader. You
gnash your teeth and roll your eyes. You wonder why people are always
changing the requirements. Your program wasn't designed for a paper
tape reader! You warn your boss that changes like this are going to destroy
the elegance of your design. Nevertheless, your boss is adamant, saying
that the users really need to read characters from the paper tape reader
from time to time.
 The Copy Program
• So you sigh and plan your modifications. You'd like to add a Boolean argument to
the Copy function. If True, you'd read from the paper tape reader; if false, you'd
read from the keyboard as before. Unfortunately, so many other programs use the
Copy program now that you can't change the interface. Changing the interface
would cause weeks and weeks of recompiling and retesting. The system test
engineers alone would lynch you, not to mention the seven people in the
configuration control group. And the process police would have a field day, forcing
all kinds of code reviews for every module that called Copy!

• No, changing the interface is out. But then how can you let the Copy
program know that it must read from the paper tape reader? Of course!
You'll use a global! You'll also use the best and most useful feature of the C
family of languages, the ?: operator! Listing 7-2 shows the result.
 The Copy Program

Copy callers who want to read from the paper tape reader must first set the ptFlag
to true. Then they can call Copy, and it will happily read from the paper tape reader.
Once Copy returns, the caller must reset the ptFlag; otherwise, the next caller may
mistakenly read from the paper tape reader rather than from the keyboard. To
remind the programmers of their duty to reset this flag, you have added an
appropriate comment.
Once again, you release your software to critical acclaim. It is even more successful
than before, and hordes of eager programmers are waiting for an opportunity to
use it. Life is good.
 The Copy Program
Give 'em an inch:

Some weeks later, your boss who is still your boss despite three corporate wide
reorganizations in as many months tells you that the customers would sometimes
like the Copy program to output to the paper tape punch. Customers! They are
always ruining your designs. Writing software would be a lot easier if it weren't for
customers. You tell your boss that these incessant changes are having a profound
negative effect on the elegance of your design, warning that if changes continue at
this horrid pace, the software will be impossible to maintain before year's end. Your
boss nods knowingly and then tells you to make the change anyway.
 The Copy Program
This design change is similar to the one before it. All we need is another global and
another ?: operator! Listing 7-3 shows the result of your endeavors. You are
especially proud of the fact that you remembered to change the comment. Still, you
worry that the structure of your program is beginning to topple. Any more changes
to the input device will certainly force you to completely restructure the while loop
conditional. Perhaps it's time to dust off your resume.
 Agile Design of the Copy Program
• An agile development team might begin exactly the same way, with the code in Listing 7-1.[3]
When the boss asked to make the program read from the paper tape reader, the developers
would have responded by changing the design to be resilient to that kind of change. The
result might have been something like Listing 7-4.
 Agile Design of the Copy Program
• Instead of trying to patch the design to make the new requirement work, the team seizes the
opportunity to improve the design so that it will be resilient to that kind of change in the
future. From now on, whenever the boss asks for a new kind of input device, the team will be
able to respond in a way that does not cause degradation to the Copy program.
Following agile practices:
• The agile developers in our example built an abstract class to protect them from changes to
the input device. How did they know how to do that? The answer lies with one of the
fundamental tenets of object-oriented design.
The agile developers knew what to do because they followed these steps.:
1. They detected the problem by following agile practices.
2. They diagnosed the problem by applying design principles.
3. They solved the problem by applying an appropriate design pattern.
Keeping the design as good as it can be
The design must remain clean. And since the source code is the most important expression of
the design, it too must remain clean.
 Conclusion
• So, what is agile design? Agile design is a process, not an
event. It's the continuous application of principles, patterns,
and practices to improve the structure and readability of the
software.
• It is the dedication to keep the design of the system as simple,
clean, and expressive as possible at all times.
• In the chapters that follow, we'll be investigating the principles
and patterns of software design. As you read, remember that
an agile developer does not apply those principles and
patterns to a big, up-front design. Rather, they are applied
from iteration to iteration in an attempt to keep the code, and
the design it embodies, clean.
 Design
Practices How do we go about design and what do we produce?

Principles What are the characteristics of good design?

Patterns What are good solutions to common design problems?

 Agile Design Practices
• How Agile are you? It seems that nowadays most software
developers claim they are doing Agile.
• However, it is also a well-known fact that many teams are only
following part of the practices that characterize Agile software
development.
• In the case of Scrum, this is called “Scrum-but”: Doing Scrum
but adapting it to your own taste.
• There is a range of agile design practices, see Next Figure ,
from high-level architectural practices to low-level
programming practices. Each of these practices are important,
and each are needed if your team is to be effective at agile
design.
Agile Design Practices
 Agile Design Practices
Below is a list of 35 Agile Best Practices. You can go over it and check how
many of these practices your team is currently following:

• Priorities (product backlog) maintained by a dedicated role (

product owner)
• Development process and practices facilitated by a dedicated role (
Scrum master)
• Sprint planning meeting to create sprint backlog
• Planning poker to estimate tasks during sprint planning
• Time-boxed sprints producing potentially shippable output
• Mutual commitment to sprint backlog between product owner and
team
• Short daily meeting to resolve current issues
• Team members volunteer for tasks (self-organizing team)
• Burn down chart to monitor sprint progress
 Agile Design Practices
•Sprint review meeting to present completed work
• Sprint retrospective to learn from previous sprint
•Release planning to release product increments
•User stories are written
•Give the team a dedicated open work space
•Set a sustainable pace
•The project velocity is measured
•Move people around
•The customer is always available
•Code written to agreed standards
•Code the unit test first
•All production code is pair programmed
•Only one pair integrates code at a time
•Integrate often
•Set up a dedicated integration computer
•Use collective ownership
•Simplicity in design
 Agile Design Practices
•Choose a system metaphor
•Use class-responsibility-collaboration (CRC) cards for design sessions
•Create spike solutions to reduce risk
•No functionality is added early
•Refactor whenever and wherever possible
•All code must have unit tests
•All code must pass all unit tests before it can be released
•When a bug is found tests are created
•Acceptance tests are run often and the score is published
Design Principle: DRY
SIMPLE, INTUITIVE, FLEXIBLE

Don’t repeat yourself

data/code should occur once and only once
Examples: ??
 Design Principle:

INTUITIVE
Use real world objects

Domain Design
model model

Abstract: Real:
Game Game
console
 Design Principle: EV
related to SRP

Encapsulate Variation
every class should have only one reason to change

FLEXIBLE

Change should not cause a domino effect!

 Good Design Principles
• The Single Responsibility Principle
• The Open-Closed Principle
• The Liskov Substitution Principle
• The Dependency Inversion Principle
• The Interface Segregation Principle
 The single-responsibility principle
• “A class should have only one reason to
change.” -- Robert Martin
• A responsibility = a reason to change
• Separate coupled responsibilities into separate
classes
 Example
• As an example, consider a module that compiles and prints a
report. Imagine such a module can be changed for two reasons.
First, the content of the report could change. Second, the
format of the report could change. These two things change for
very different causes; one substantive, and one cosmetic. The
single responsibility principle says that these two aspects of the
problem are really two separate responsibilities, and should
therefore be in separate classes or modules. It would be a bad
design to couple two things that change for different reasons at
different times.
• The reason it is important to keep a class focused on a single
concern is that it makes the class more robust. Continuing with
the foregoing example, if there is a change to the report
compilation process, there is greater danger that the printing
code will break if it is part of the same class.
The single-responsibility principle
• Example:
– Often we need to sort students by their name, or ssn. So one
may make Class Student implement the Java Comparable
interface.
class Student implements Comparable {
…
int compareTo(Object o) { … }
…
};
– Student is a business entity, it does not know in what order it
should be sorted since the order of sorting is imposed by the
client of Student.
– Worse: every time students need to be ordered differently, we
have to recompile Student and all its client.
– Cause of the problems: we bundled two separate
responsibilities (i.e., student as a business entity with ordering)
into one class – a violation of SRP
The single-responsibility principle

Register Student
Add(Course d, Student s); SSN Comparable
Name int compareTo()
getSSN()
getName()
major
getMajor()
int compareTo()

When a new requirement needs to

sort students in a different order,
Student, Register, and AClient all AClient
need to be recompiled, even op() { ;}
Register has nothing to do with any
ordering of Students.
It invokes
Collections.sort(aListofStudents);
The single-responsibility principle
Register
Add(Course d, Student s); Comparator
int compare(Object o1, Object o2)

Student
SSN
Name
getSSN() StudentByName
getName() int compare(Object o1, Object o2) ClientA
major op() { ;}
getMajor()

StudentBySSN
int compare(Object o1, Object o2)

The solution is to separate the two ClientB

responsibilities into two separate op() { ;} It invokes
classes and use another version of Collections.sort(aListofStudents,
StudentBySSN);
Collections.sort().
The single-responsibility principle

Computational Rectangle Graphical

Geometry +draw():void
+area():integer Application
Application

GUI

Class Rectangle may be forced to make changes from two different

unrelated sources. One is from the Computational Geometry
Application (CGA). E.g., adding area function for length and width of
type double. The other is from Graphical Application (GA). E.g., add
draw() in Windows XP to the existing draw in X Windows. A change
from either of the two source would still cause the other application
to recompile.
The single-responsibility principle

Computational
Graphical
Geometry
Application
Application

Geometric Graphic
Rectangle Rectangle
+area():double +draw():void GUI

• Package CGA is no longer dependent on graphical side of Rectangle

and thus it becomes independent of package GUI. Any change caused
by graphical application no longer requires CGA to be recompiled.
• However, any changes from the CGA side may cause GA to be
recompiled.
The single-responsibility principle

Computational
Graphical
Geometry
Application
Application

Rectangle
Geometric -double length Graphic
-double width
Rectangle +getLength():dobule Rectangle
+area():double +getWidth():dobule +draw():void GUI

Class Rectangle contains the most primitive attributes and operations of

rectangles. Classes GeometricRectangle and GraphicRectangle are
independent of each other. A change from either side of CGA or GA, it
would not cause the other side to be recompiled.
NOTE: this does not violate LSP, since Rectangle does not have any client.
 The open-closed principle
• “Software entities (classes, modules, functions, etc,) should be open for
extension, but closed for modification.” – R. Martin
• To make a class open for extension, closed for modification, program the
class to interfaces (or abstract classes), not implementation (concrete
classes).
• A module will be said to be open if it is still available for extension. For
example, it should be possible to add fields to the data structures it
contains, or new elements to the set of functions it performs.
• A module will be said to be closed if [it] is available for use by other
modules. This assumes that the module has been given a well-defined,
stable description (the interface in the sense of information hiding)
The open-closed principle
Employee
+int EmpType

Faculty Staff Secretary Engineer

+getOffice() +getDept() +getTypeSpeed() +getEngTYpe()

void printEmpRoster(Employee[] emps) {

What if we
for (int i; i<emps.size(); i++) {
need to add
if (emps[i].empType == FACULTY) Engineer??
printfFaculty((Faculty)emps[i]);
else if (emps[i].empType ==STAFF)
printStaff((Staff)emps[i]);
else if (emps[i].empType == SECRETARY)
printSecretary((Secretary)emps[i]);
}
}
The open-closed principle
Employee
+printInfo()

Faculty Staff Secretary Engineer

+printInfo() +printInfo() +printInfo +printInfo()

void printEmpRoster(Employee[] emps) {

for (int i; i<emps.size(); i++) {
emps[i].printInfo();
}
}

When Engineer is added, printEmpRoster() does not even

need to recompile. PrintEmpRoster() is open to extension,
closed for modification.
 The open-closed principle
• Three versions of SORT
– sort(List list)
• Elements of list must implement Comparable interface
– sort(List list, StringComparator sc)
• Elements of list are not required to implement Comparable
• StringComparator orders objects of String only
– Sort(List list, Comparator comp)
• Elements of list are not required to implement Comparable
• Comparator may compare objects of any type.
• Open to extension since it can sort objects of any type at
any order specified in the second parameter.
 The Liskov substitution principle
• “Subtypes must be substitutable for their base types.” –
R. Martin
• Demand no more, promise no less
– Demand no more: the subclass would accept any arguments
that the superclass would accept.
– Promise no less: Any assumption that is valid when the
superclass is used must be valid when the subclass is used.
• Interface inheritance – The LSP should be conformed to.
• Implementation inheritance – use composition instead
of inheritance (in Java) or use private base classes (in C+
+).
The Liskov substitution principle
• Implementation inheritance
– When you use List to implement Queue (in Java), use composition, not
inheritance.
– The intention is that you use only List’s implementation

<foundation>
List List
+insert() List +insert()
+delete() +insert() +delete()
+find() +delete() +find()
+find()
MyList

Queue Queue Queue

+enqueue() +enqueue() +enqueue()
+dequeue() +dequeue() +dequeue()
+isEmpty() +isEmpty() +isEmpty()
 The Liskov substitution principle
class Square extends Rectangle {
public void setWidth(int width) { Rectangle
super.setWidth(width); -int width;
-int height
super.setHeight(width); +getWidth()
} +setWidth()
+getHeight()
public void setHeight(int height) { +setHeight()
super.setHeight(height); +area();

super.setWidth(height);
} IS-A
}
void clientOfRectangle(Rectangle r) { Square
+getWidth()
r.setWidth(10); +setWidth()
r.setHeight(20); +getHeight()
+setHeight()
print(r.area());
}
Rectangle r = new Square(…);
clientOfRectangle(r); // what would be printed?
The Liskov substitution principle

• Rectangle and Square

– Invariant of Rectangle: width and height are
independent of each other (which can be
expected from the setWidth and setHeight
operations)
– Square violates the width-height-
independence invariant of Rectangle
The Liskov substitution principle
• There are cases in which the substitutability may not be needed
• Generalization: we found that Faculty, Staff, Secretary and Engineer
all have the same set of attributes and operations, so we created
the Employee as a placeholder for those common properties.
• For the system, there is no client for Employee
• Thus, the four subclasses do not need to be substitutable
• Actually, there is no way we can tell whether they are or not.

Employee
+printInfo()

Faculty Staff Secretary Engineer generalization

+printInfo() +printInfo() +printInfo +printInfo()
 The dependency inversion principle
• “Abstraction should not depend on details.
Details should depend on abstraction.” – R.
Martin
• High-level concepts are more stable than low-
level implementation
The dependency inversion principle

Policy Layer High-level modules make calls to low-

level modules.

Mechanism
Layer

Utility Layer
The upper-level layer is dependent upon
lower-level layers.
The dependency inversion principle
Policy Dependency Inversion: Lower-level layers is
dependent upon upper-level layers.
Policy
Layer Mechanism

Mechanism
<<interface>> Layer
Policy
Service Utility

<<interface>>
Mechanism Utility
Service Layer

Ownership Inversion: The client (upper-level layer) owns

the interface, not the lower-level layers
The interface segregation principle

• “Clients should not be forced to depend

on methods that they do not use.” – R.
Martin
• When we bundle functions for different
clients into one interface/class, we create
unnecessary coupling among the clients.
– When one client causes the interface to
change, all other clients are forced to
recompile.
 Software design principles -
summary
 The single-responsibility principle
– There is only one source that may the class to change
 The open-closed principle
– Open to extension, closed for modification
 The Liskov substitution principle
– A subclass must substitutable for its base class
 The dependency inversion principle
– Low-level (implementation, utility) classes should be dependent
on high-level (conceptual, policy) classes
 The interface segregation principle
– A client should not be forced to depend on methods it does not
use.
 Refactoring
• Refactoring is:
– restructuring (rearranging) code in a series of small, semantics-
preserving transformations (i.e. the code keeps working) in order to
make the code easier to maintain and modify
• Refactoring is not just arbitrary restructuring
– Code must still work
– Small steps only so the semantics are preserved (i.e. not a major re-
write)
– Unit tests to prove the code still works
– Code is
• More loosely coupled
• More cohesive modules
• More comprehensible
• There are numerous well-known refactoring techniques
– You should be at least somewhat familiar with these before inventing
your own
– Refactoring “catalog”
 When to refactor
• You should refactor:
– Any time that you see a better way to do things
• “Better” means making the code easier to understand and to
modify in the future
– You can do so without breaking the code
• Unit tests are essential for this
• You should not refactor:
– Stable code that won’t need to change
– Someone else’s code
• Unless the other person agrees to it or it belongs to you
• Not an issue in Agile Programming since code is communal
Typical Refactoring
 Automated build tools
Software build definition:
 The term build may refer to the process by which source code is converted
into a stand-alone form that can be run on a computer or to the form itself.
 One of the most important steps of a software build is the compilation process, where
source code files are converted into executable code.
 The process of building software is usually managed by a build tool.
 Builds are created when a certain point in development has been reached
or the code has been deemed ready for implementation, either for testing
or outright release.
 Some of the automated build tools are:
1. Jenkins: One of the leading Continuous Delivery (CD) and Continuous Integration (CI)
tools on the market, Jenkins is an automation server with a high-level of extensibility and a
large community of users.
2. ElectricFlow: ElectricFlow is a release automation tool that offers a free community
edition you can run on VirtualBox. ElecticFlow supports a number of plugins and Groovy-
based DSL, CLI, APIs.
 Version control
• Version control systems are a category of software tools that help a software team manage
changes to source code over time.
• Version control software keeps track of every modification to the code in a special kind of
database.
• If a mistake is made, developers can turn back the clock and compare earlier versions of the
code to help fix the mistake while minimizing disruption to all team members.

Why Use Version Control?

• Version control is essential when working with a team of developers, if you are working in a
team of developers and don't have version control, make sure everyone stops what they
are doing right now and read this.

If you don't have version control, the only way you can work is by having your code in a
shared location possibly on a network drive and you all access these files to make changes
to the code. There are lots of things wrong with this way of working, first of all you can't
have two developers working on the same file at the same time. If two developers are
working on it, the last person to save will override all other code changes. Using version
control will allow multiple developers to work on the same file at the same time, when they
have completed their code changes they will commit them back into the repository. When
you commit a file back into the repository it will merge your changes into version control.
Conti..
• Second problem with this is that there is no code history so if you create a new feature and
demo it to the client and they decide that they don't want it anymore you would normally
have to go through your code and remove everything you did. If you were using version
control you could just revert your code back to before you started developing that feature.
• The third feature that you can't use without version control is the blame feature.
Version control will record who wrote a piece of code, which means if there is a
piece of code that your not sure why it's there, you can use version control to
check the code to tell you which developer wrote this so you can ask the developer
to explain the reasons why it's there.
• Version control is also a good way to keep your code shared on multiple
computers, if you are a single developer but use both a desktop and a laptop to
code when you switch between different computers you can just do an update on
the repository and get all the latest code.
• Tagging is an important feature you need to take advantage of when working with
version control. When you have completed a piece of work and ready to deploy
the code, you then tag this version of the code. This is essential creating a different
branch of code at this current time. Then you can deploy your code from this tag,
leaving you with the exact code that you have on the live server. The benefit to this
is that if there was a problem with the current live version you can easily revert
back to the previous tag.
 Version Control Options

• Now that you understand the benefits of using Version

Control which one should you be using?
• There are many different types of version control, here
we are just going to look at the two most popular
version control repositories, Git and SVN. Even though
they are quite similar, the way you will work with these
two repositories is going to be different. I'm not going
to say which one is better than the other and which
one you should be learning, this will have to come out
of your own workflow and what you want to achieve
with version control.
 SVN

• SVN or Subversion is very popular due to the

fact that it's very easy to understand and very
straight forward to work with. The WordPress
plugin repository uses SVN.
• It works by having a central server for your
repository, this repository is split into 3 key
areas...Trunk, Branches and Tags. Each one of
these areas have an important role to play.

(https://www.tutorialspoint.com/svn/svn_quick_guide.htm)
THANK YOU