Upload
josephnaveen
View
790
Download
0
Tags:
Embed Size (px)
Citation preview
10:02 1
Avoiding Software Insanity
Joseph Naveen
Extended Enterprise Pte Ltd.,
Code Quality? Nice to have, but we can address that later…
Does that sound familiar?
Interactive poll:Do you have binding rules for code quality?
Is your architecture defined in a formal way?
Do you measure quality rule violations on a daily base?
Do you measure architecture violations on a daily base?
Does quality management happen at the end of development?
Do you think, that more needs to be done in that area and that this would be beneficial for the team and the company?
12.04.23 2
Part I: Well Known Symptoms of Complexity
10:02 3
What is Software Entropy?
10:02 4
“The tendency for software, over time, to become difficult and costly to maintain.”
A software system that undergoes continuous change, such as having new functionality added to its original design, will eventually become more complex and can become disorganized as it grows, losing its original design structure.
10:02 5
Erosion of Architecture – Symptoms (Robert C. Martin)
Rigidity – The system is hard to change because every change forces many other changes.
Fragility – Changes cause the system to break in conceptually unrelated places.
Immobility – It's hard to disentangle the system into reusable components.
Viscosity – Doing things right is harder than doing things wrong.
Opacity – It is hard to read and understand. It does not express its intent well.
Overall: “The software starts to rot like a bad piece of meat”
10:02 6
Erosion of Architecture – Reasons
System knowledge and skills are not evenly distributed
Complexity grows faster than system size
Unwanted dependencies are created without being noticed
Coupling and complexity are growing quickly. When you realize it, it is often too late
Most projects don’t measure quality on a regular base
Management considers software as a black box
Quality measurement is done at the end of development
Time pressure is always a good excuse to sacrifice structure
The Law of Entropy?
Part II: Technical Quality
12.04.23 7
What is Technical Quality“Technical quality of software can be defined as the level of conformance of a software system to a set of rules and guidelines derived from common sense and best practices. Those rules should cover software architecture, programming in general, testing and coding style.”
Technical quality affects:Testability, Expandability, Maintainability, Comprehensibility
It cannot be achieved by testing only
Technical quality has the following aspectsArchitecture and dependency structure of the code
Software metrics
Common sense coding rules
Test coverage
12.04.23 8
Cost of Structural Erosion / Technical Debt
10:02 9
12.04.23 10
Structure vs. Cost to Change
Structure vs. Defects
Structure vs. Time to Change
Courtesy: NIST
How to Measure Technical Quality
ArchitectureMeasure number of dependencies violating architecture rules
StructureMeasure size and coupling of package cycle groups in relation to the size of the system
MetricsDefine a reasonably (small) number of metric thresholds and measure the number of threshold violations
Coding rulesUse automated rule checkers and configure a reasonable set of guidelines and rules. Measure number of rule violations
Test CoverageRun your unit tests with a coverage tool to measure the test coverage. Focus efforts to improve coverage on complex code
12.04.23 11
10:02 12
Your System
User Interface
Business Logic
Data Access
How to model Architecture
• Step 1: Cut horizontally into Layers
• Step 2: Cut vertically into vertical slices by functional aspects
Co
ntr
act
s
Cu
sto
me
r
Use
r
Co
mm
on
• Step 3: Defines the rules of engagement
Natural subsystems
12.04.23 13
Cyclic dependencies are evil
"Guideline: No Cycles between Packages. If a group of packages have cyclic dependency then they may need to be treated as one larger package in terms of a release unit. This is undesirable because releasing larger packages (or package aggregates) increases the likelihood of affecting something." [AUP]
"The dependencies between packages must not form cycles." [ASD]
"Cyclic physical dependencies among components inhibit understanding, testing and reuse. Every directed a-cyclic graph can be assigned unique level numbers; a graph with cycles cannot. A physical dependency graph that can be assigned unique level numbers is said to be levelizable. In most real-world situations, large designs must be levelizable if they are to be tested effectively. Independent testing reduces part of the risk associated with software integration " [LSD]
10:02 15
How to measure coupling
ACD = Average Component Dependency
NCCD: normalized cumulated component dependency
Graph 2 (CCD=19) Graph 1 (CCD=23)ACD = 3.29 ACD = 2.71
Example : Cyclic Dependency
AlarmClock
AlarmHandler
Presentation Model
Main
AlarmToConsole
AlarmToFile
Breaking the Cycle
AlarmClock
<<abstract>>
AlarmHandler
Main
<<interface>>
IAlarmHandler
AlarmToConsole
AlarmToFile
Presentation<<bottom>>
Model
Example : Another Cyclic Dependency
Customer___________________
Order[] listOrders() { …}
Order Customer
Order__________________
Customer cust;
Example : Breaking the Cycle
Customer___________________
Order Customer
Order__________________
Customer cust;static Order[] listOrders(Customer c) { …}
Structural Debt Index
This metric measures structural erosion by analyzing cyclic package dependencies. Very good for tracking project health.
12.04.23 20
Part III: How to Create a Master Piece ?
12.04.23 21
Improvement requires Awareness Six Sigma for Software
12.04.23 22
Measurable Quality must be a Process Goal
You can’t reach high quality if you do not measure it (daily !)
It is also of no use if you do measure, but don’t use the measurements (why do I have to mention that ??)
Quality as a goal must be backed an enforced by the management (requiring more than just getting the job done)
Things will always get worse, before they get better (getting rid of old habits is always difficult)
Its all about people, processes and tools (in that order)
But it also does not work without tools – the process must be automated as much as possible
Potential gains are tremendous
Start simple – fewer rules are better
12.04.23 23
10:02 © 2005-2011, 24
Some Simple Rules for a Masterpiece
Rule 1:Define a cycle free logical architecture down to the level of subsystems and a strict and consistent package naming convention
Rule 2:Do not allow cyclic dependencies between different packages
Rule 3:Keep the relative ACD low (< 7% for 500 compilation units, NCCD < 6)
Rule 4:Limit the size of Java files (700 LOC is a reasonable value)
Rule 5: Limit the cyclomatic complexity of methods (e.g. 15)
Rule 6:Limit the size of a Java package (e.g. less than 50 types)
“Designing Quality Software” Refcard
12.04.23 © 2005-2011, 25
Download from www.ext-ent.com
Relevant White-Papers:
12.04.23 © 2005-2011, 26
Download from www.ext-ent.com