SlideShare uma empresa Scribd logo
1 de 33
Baixar para ler offline
“Writing Quality Code”
By Indika Maligaspe
““Give a man a fish and you feed him for a dayGive a man a fish and you feed him for a day
Teach him how to fish and you feed him for a lifetime”Teach him how to fish and you feed him for a lifetime”
Intro...Intro...
Indika Maligaspe

K. Indika Maligaspe

Developer, Designer, Architect , Trainer

Tech Geek specialized in JAVA and .Net

Over 14 years if experience in IT / Web Technologies

Lover of almost all sports...

http://www.linkedin.com/profile/view?id=201732082&trk=nav_responsive_tab_profile
ContributorsContributors
 David Bernstein
 Alan Shalloway
 Steve McConnell
 Martin Fowler
 Gamma, Helms, Johnson, Vlissides (GoF)
 James Coplien
Seminar AgendaSeminar Agenda
 What effects Software Quality?
 How to accommodate change?
 What are Code Qualities?
 Principles vs. Practices
 Principles of Coding (Rules of Thumb)
 Organizing Principles
 Clarity Principles (good practices)
 Summary
 Q&A
What effects Software Quality?What effects Software Quality?
Two questions…..Two questions…..
• How many of you have been involvedHow many of you have been involved
inin
 A totally successful project?
 A totally failed project?
 A "challenged" project?
What effects Software Quality?What effects Software Quality?
Two questions…..Two questions…..
• When Adding FunctionalityWhen Adding Functionality
Where was the Problem?Where was the Problem?
 Is it writing the new code?
 Is it integrating it into the system?
 Why?
How can we design toHow can we design to
accommodate change?accommodate change?
 We are not trying to anticipate change, per se, as much
as writing our code to accommodate change better.
Trying to anticipate change can lead to “paralysis by
analysis”
 To do this we need
 A way to avoid change when possible (outside of the scope of this
document)
 Componentized Architectures (CBA / SBC etc…)
 Use of Design Patterns
 Agile concepts
 A way to make change less risky when one cannot avoid it
 Code clarity and maintainability
 Refactoring
What are Code Qualities?What are Code Qualities?
• A computer has no concept of "well-
written“ source code. However, from a
human point of view source code can be
written in a way that has an effect on the
effort needed to comprehend its
behavior.
• Many source code programming style
guides, which often stress readability
and usually language-specific
conventions are aimed at reducing the
cost of source code maintenance by
having code predictability.
PredictabilityPredictability
 We can’t predict how our requirements are
going to change
 However we can predict how our code will
adapt to unpredictable requirement
changes
 How can we increase our predictive
abilities?
 Pay attention to code quality
Six Code QualitiesSix Code Qualities
 Cohesive
 Correct Coupling
 Non Redundant
 Encapsulated
 Testable
 Assertive
Principles vs. PracticesPrinciples vs. Practices
 Principle
 A standard
 Theory
 Practice
 How you put a principle to practice
i.e.
Principle - The need to be clean
Practice - Wash hands
CohesionCohesion
 Cohesion refers to how “closely the
operations in a routine [or class] are
related ” (Code complete – Steve McConnell)
 Strong cohesion is related to clarity and
understanding.
 No "schizophrenic classes”
 No “10000 - line classes”
 No “10 page methods"‐
Good StrongGood Strong cohesioncohesion
 Class Cohesion - A class has a single
responsibility, and everything in the class is about
fulfilling that responsibility.
 Using design patterns and OO concepts (strategy / encapsulation /
open – close etc…)
 Method Cohesion - Each method is about
fulfilling one functional aspect of the classes
responsibility.
 Programming by intention can help us to code with better method
cohesion from the beginning
Class Cohesion - exampleClass Cohesion - example
Class cohesion will be covered in detail in future sessions
Method cohesion – programmingMethod cohesion – programming
by intentionby intention
Method cohesion – programmingMethod cohesion – programming
by intentionby intention
What “programming by intention”What “programming by intention”
will bringwill bring
 Method cohesion
 Cohesion of perspective
 Sergeant is the controller (very little
implementation)
 Private’s do the work (implementation)
 Ease of refactoring
 Ease of applying/forming design patterns
 Easier to test
CouplingCoupling
 Coupling refers “to the strength of a connection between two
routines [or classes] Coupling is complement to cohesion. Cohesion
describes how strongly the internal contents of a routine [or class]
are related to each other. Coupling describes how strongly a routine
is related to other routines. The goal is to create routines [and
classes] with internal integrity (strong cohesion) and small, direct,
visible, and flexible relations to other routines [and classes] (loose
coupling).”*
 Tight coupling is related to highly interconnected code
* Code Complete Steve McConnell 1993 p 22 Copyright
Correct CouplingCorrect Coupling
 How interconnected Objects are
 Loosely coupled – Objects should be independent
and should mind their own business.
 One employee should not know about salary details
of other employees in the company
 Tight coupled – Objects are interconnected and
intertwined. Change one place and “All hell breaks
loose”
 Every employee knows the salaries of all the
employees in the company. Give increment to one –
MAJOR PROBLEM
Sample CouplingSample Coupling
 Tight Coupling
 Loose Coupling
Types of couplingTypes of coupling
 Identity
 One type to the fact that coupled another type exists.
 Representational
 One type coupled to the interface of another.
 Inheritance
 Subtypes are coupled to their superclass, in that any change in
the superclass will propagate downward.
 Subclass
 One type coupled to the fact that there are subclasses to a type,
and what specific subclasses exist.
Writing Quality code David Bernstein – 2008 p24 Copyright
No Redundancy –No Redundancy –
Avoiding duplicationAvoiding duplication
 "One Rule in One Place"
 Redundancy is not just:
 Redundant state
 Redundant functions
 It can also be redundant relationships, design, construction, etc…
 Anything that is redundant will cause maintenance problem
Avoid RedundancyAvoid Redundancy
 The “once and only once” rule
 If you are going to copy and paste, ask yourself
 What is the code I want to reuse?
 Can I make a new method that can be used by both my current
method and the place I need to use this similar functionality?
 If 2 entities need to do this, how likely will there be a third, fourth,
etc…
Writing Quality code David Bernstein – 2008 p27 Copyright
Encapsulation – Information hidingEncapsulation – Information hiding
 Two commonly used encapsulation methods
 Data : The data needed for a class to fulfill it's responsibilities is hidden from
other entities
 Implementation: How a class implements a particular function, or whether it
implements it itself or delegates to other objects, is hidden
 Not so commonly used
 Type: Abstract classes and interfaces can hide their implementing classes
 Design: Assembling, collaborating classes with an object factory keeps clients
decoupled from the way they are designed (abstract factory)
 Construction: Encapsulation of construction means wrapping "new" in, at
least, a separate method, giving you control over the return type (use of
getInstance)
TestabilityTestability
 Class responsibility should be individually testable (unit
testing)
 Considering how to test before developing or designing
leads to
 Correctness
 Good OO design
 OO design patterns
 And forces you to look at:
 the public method definitions
 what the responsibilities of the object are
 Easy testability is achieved by strong cohesion, loose
coupling, good encapsulation and non redundancy
Role of TestabilityRole of Testability
 You should always do unit testing. It helps
in code correctness
 Whether you agree or not ask two things
 You should always ask “ How will I test my
design / code?”
 If you see that your code/ unit or design is not
testable, then there is something wrong in it.
Ask your self “How can I make this more
testable”
Assertive or InquisitiveAssertive or Inquisitive
 In a relationship between two entities A and B
 Should A ask the state of B and then use it
(inquisitive)
 Should A tell B to do the task involving the
state (Assertive)
 It does not increase the code or design, just who
takes the code and responsibility
 Which is better?
Assertive vs. Inquisitive –Assertive vs. Inquisitive –
which is better?which is better?
 The more Assertive you code / design is the more
decoupled you code or design is
 Remember the “Gang of Four”: Design to interfaces. An
object's state is generally a part of its implementation.
We should not design to that, as it is highly likely to
change
 "He who holds the state should hold the function"
 Favor Assertiveness over Inquisitiveness (tell
but not Ask principle)
Organizing Principles
 Cohesion is an organizing principle in that it helps us
decide where new entities belong
 Coupling is an organizing principle in that it helps us
decide how different entities should talk to each other
(the interfaces)
 Eliminating redundancy is an organizing principle
because it tells us to bring together redundant
methods/rules into a single place
Clarity Principles
 How to document code
 Implementation details (documentation) should be in the code, not as comments
 If you have to write comments explaining “names”, your naming conventions
might be having issues
 There is BIG difference between comments about “what” you are doing and
comments “why” (business rules)
 Conceptual information can often be documented in abstract classes and
interfaces
 Naming is not always easy. It is often a good idea to pair on naming issues
 Always format code properly
(refer http://tutorials.rezg.net/Java/CodeConventions.pdf )
 Try not have more the
 100 characters per line
 30 lines in a method
 30 methods per class
SummarySummary
 Remember the Code QualitiesRemember the Code Qualities
T – TestabilityT – Testability
R – Non RedundancyR – Non Redundancy
E – EncapsulationE – Encapsulation
C – CohesionC – Cohesion
C – Correct CouplingC – Correct Coupling
A – AssertiveA – Assertive
T.R.E.C.C.A.T.R.E.C.C.A.
Writing Quality code David Bernstein – 2008 p54 Copyright
Summary – In a NutshellSummary – In a Nutshell
 In order of importance
 Be testable
 Contain no duplication (once and only once)
 Loose coupling, strong cohesion and clarity
 When writing, always program by intention
 Methods and classes should be implemented so they can be
understood totally from their names and their public interfaces. This
flows naturally from up front testing, and decreases coupling‐
 Classes should organize ideas in a readily understandable way
 Use intention revealing names so you don't have to explain‐
method, member or class names with additional comments
 Adhere to a coding standard
Thank YouThank You

Mais conteúdo relacionado

Mais procurados

Big Ball of Mud: Software Maintenance Nightmares
Big Ball of Mud: Software Maintenance NightmaresBig Ball of Mud: Software Maintenance Nightmares
Big Ball of Mud: Software Maintenance NightmaresGonzalo Rodríguez
 
A complexity approach to managing technology enabled business transformation ...
A complexity approach to managing technology enabled business transformation ...A complexity approach to managing technology enabled business transformation ...
A complexity approach to managing technology enabled business transformation ...Mikkel Brahm
 
Solid OO & Clean Coding is essential to successful Agile development
Solid OO & Clean Coding is essential to successful Agile developmentSolid OO & Clean Coding is essential to successful Agile development
Solid OO & Clean Coding is essential to successful Agile developmentSimon Gould
 
Pragmatic Not Dogmatic TDD Agile2012 by Joseph Yoder and Rebecca Wirfs-Brock
Pragmatic Not Dogmatic TDD Agile2012 by Joseph Yoder and Rebecca Wirfs-BrockPragmatic Not Dogmatic TDD Agile2012 by Joseph Yoder and Rebecca Wirfs-Brock
Pragmatic Not Dogmatic TDD Agile2012 by Joseph Yoder and Rebecca Wirfs-BrockJoseph Yoder
 
TDD vs. ATDD - What, Why, Which, When & Where
TDD vs. ATDD - What, Why, Which, When & WhereTDD vs. ATDD - What, Why, Which, When & Where
TDD vs. ATDD - What, Why, Which, When & WhereDaniel Davis
 
SOLID Principles and Design Patterns
SOLID Principles and Design PatternsSOLID Principles and Design Patterns
SOLID Principles and Design PatternsGanesh Samarthyam
 
Overview on TDD (Test Driven Development) & ATDD (Acceptance Test Driven Deve...
Overview on TDD (Test Driven Development) & ATDD (Acceptance Test Driven Deve...Overview on TDD (Test Driven Development) & ATDD (Acceptance Test Driven Deve...
Overview on TDD (Test Driven Development) & ATDD (Acceptance Test Driven Deve...Zohirul Alam Tiemoon
 
Is there a future for Model Transformation Languages?
Is there a future for Model Transformation Languages?Is there a future for Model Transformation Languages?
Is there a future for Model Transformation Languages?Jordi Cabot
 

Mais procurados (12)

Big Ball of Mud: Software Maintenance Nightmares
Big Ball of Mud: Software Maintenance NightmaresBig Ball of Mud: Software Maintenance Nightmares
Big Ball of Mud: Software Maintenance Nightmares
 
Clean code-v2.2
Clean code-v2.2Clean code-v2.2
Clean code-v2.2
 
(A)TDD The what, why and how
(A)TDD The what, why and how(A)TDD The what, why and how
(A)TDD The what, why and how
 
A complexity approach to managing technology enabled business transformation ...
A complexity approach to managing technology enabled business transformation ...A complexity approach to managing technology enabled business transformation ...
A complexity approach to managing technology enabled business transformation ...
 
Final grasp ASE
Final grasp ASEFinal grasp ASE
Final grasp ASE
 
Solid OO & Clean Coding is essential to successful Agile development
Solid OO & Clean Coding is essential to successful Agile developmentSolid OO & Clean Coding is essential to successful Agile development
Solid OO & Clean Coding is essential to successful Agile development
 
Pragmatic Not Dogmatic TDD Agile2012 by Joseph Yoder and Rebecca Wirfs-Brock
Pragmatic Not Dogmatic TDD Agile2012 by Joseph Yoder and Rebecca Wirfs-BrockPragmatic Not Dogmatic TDD Agile2012 by Joseph Yoder and Rebecca Wirfs-Brock
Pragmatic Not Dogmatic TDD Agile2012 by Joseph Yoder and Rebecca Wirfs-Brock
 
TDD vs. ATDD - What, Why, Which, When & Where
TDD vs. ATDD - What, Why, Which, When & WhereTDD vs. ATDD - What, Why, Which, When & Where
TDD vs. ATDD - What, Why, Which, When & Where
 
SOLID Principles and Design Patterns
SOLID Principles and Design PatternsSOLID Principles and Design Patterns
SOLID Principles and Design Patterns
 
Overview on TDD (Test Driven Development) & ATDD (Acceptance Test Driven Deve...
Overview on TDD (Test Driven Development) & ATDD (Acceptance Test Driven Deve...Overview on TDD (Test Driven Development) & ATDD (Acceptance Test Driven Deve...
Overview on TDD (Test Driven Development) & ATDD (Acceptance Test Driven Deve...
 
Is there a future for Model Transformation Languages?
Is there a future for Model Transformation Languages?Is there a future for Model Transformation Languages?
Is there a future for Model Transformation Languages?
 
Atdd half day_new_1_up
Atdd half day_new_1_upAtdd half day_new_1_up
Atdd half day_new_1_up
 

Semelhante a Writing Quality Code

PATTERNS01 - An Introduction to Design Patterns
PATTERNS01 - An Introduction to Design PatternsPATTERNS01 - An Introduction to Design Patterns
PATTERNS01 - An Introduction to Design PatternsMichael Heron
 
Software design principles - jinal desai
Software design principles - jinal desaiSoftware design principles - jinal desai
Software design principles - jinal desaijinaldesailive
 
Code Craftsmanship Checklist
Code Craftsmanship ChecklistCode Craftsmanship Checklist
Code Craftsmanship ChecklistRyan Polk
 
Are You a SOLID Coder?
Are You a SOLID Coder?Are You a SOLID Coder?
Are You a SOLID Coder?Steve Green
 
Refactoring page objects The Screenplay Pattern
Refactoring page objects   The Screenplay Pattern Refactoring page objects   The Screenplay Pattern
Refactoring page objects The Screenplay Pattern RiverGlide
 
Unit No 6 Design Patterns.pptx
Unit No 6 Design Patterns.pptxUnit No 6 Design Patterns.pptx
Unit No 6 Design Patterns.pptxDrYogeshDeshmukh1
 
Best practices for agile design
Best practices for agile designBest practices for agile design
Best practices for agile designIgor Moochnick
 
Clean Code .Net Cheetsheets
Clean Code .Net CheetsheetsClean Code .Net Cheetsheets
Clean Code .Net CheetsheetsNikitaGoncharuk1
 
Tdd and-design-draft
Tdd and-design-draftTdd and-design-draft
Tdd and-design-draftPrabudhGupta1
 
Object Oriented Design SOLID Principles
Object Oriented Design SOLID PrinciplesObject Oriented Design SOLID Principles
Object Oriented Design SOLID Principlesrainynovember12
 
Design Patterns Explained: From Analysis through Implementation
Design Patterns Explained: From Analysis through ImplementationDesign Patterns Explained: From Analysis through Implementation
Design Patterns Explained: From Analysis through ImplementationTechWell
 
Comfortable code
Comfortable codeComfortable code
Comfortable codeRemus Langu
 
Dependency Injection, Design Principles and Patterns
Dependency Injection, Design Principles and PatternsDependency Injection, Design Principles and Patterns
Dependency Injection, Design Principles and PatternsJuan Lopez
 
Practical Enterprise Application Development
Practical Enterprise Application DevelopmentPractical Enterprise Application Development
Practical Enterprise Application DevelopmentAdil Mughal
 
Module 2 design patterns-2
Module 2   design patterns-2Module 2   design patterns-2
Module 2 design patterns-2Ankit Dubey
 
Test-Driven Developments are Inefficient; Behavior-Driven Developments are a ...
Test-Driven Developments are Inefficient; Behavior-Driven Developments are a ...Test-Driven Developments are Inefficient; Behavior-Driven Developments are a ...
Test-Driven Developments are Inefficient; Behavior-Driven Developments are a ...Abdelkrim Boujraf
 
Introduction to design patterns
Introduction to design patternsIntroduction to design patterns
Introduction to design patternsAmit Kabra
 

Semelhante a Writing Quality Code (20)

PATTERNS01 - An Introduction to Design Patterns
PATTERNS01 - An Introduction to Design PatternsPATTERNS01 - An Introduction to Design Patterns
PATTERNS01 - An Introduction to Design Patterns
 
Software design principles - jinal desai
Software design principles - jinal desaiSoftware design principles - jinal desai
Software design principles - jinal desai
 
Code Craftsmanship Checklist
Code Craftsmanship ChecklistCode Craftsmanship Checklist
Code Craftsmanship Checklist
 
Are You a SOLID Coder?
Are You a SOLID Coder?Are You a SOLID Coder?
Are You a SOLID Coder?
 
Refactoring page objects The Screenplay Pattern
Refactoring page objects   The Screenplay Pattern Refactoring page objects   The Screenplay Pattern
Refactoring page objects The Screenplay Pattern
 
Unit No 6 Design Patterns.pptx
Unit No 6 Design Patterns.pptxUnit No 6 Design Patterns.pptx
Unit No 6 Design Patterns.pptx
 
Best practices for agile design
Best practices for agile designBest practices for agile design
Best practices for agile design
 
Clean Code .Net Cheetsheets
Clean Code .Net CheetsheetsClean Code .Net Cheetsheets
Clean Code .Net Cheetsheets
 
Tdd and-design-draft
Tdd and-design-draftTdd and-design-draft
Tdd and-design-draft
 
Object Oriented Design SOLID Principles
Object Oriented Design SOLID PrinciplesObject Oriented Design SOLID Principles
Object Oriented Design SOLID Principles
 
Design Patterns Explained: From Analysis through Implementation
Design Patterns Explained: From Analysis through ImplementationDesign Patterns Explained: From Analysis through Implementation
Design Patterns Explained: From Analysis through Implementation
 
Comfortable code
Comfortable codeComfortable code
Comfortable code
 
DDD In Agile
DDD In Agile   DDD In Agile
DDD In Agile
 
Dependency Injection, Design Principles and Patterns
Dependency Injection, Design Principles and PatternsDependency Injection, Design Principles and Patterns
Dependency Injection, Design Principles and Patterns
 
Practical Enterprise Application Development
Practical Enterprise Application DevelopmentPractical Enterprise Application Development
Practical Enterprise Application Development
 
Agile testing
Agile testingAgile testing
Agile testing
 
Module 2 design patterns-2
Module 2   design patterns-2Module 2   design patterns-2
Module 2 design patterns-2
 
Oops Concepts
Oops ConceptsOops Concepts
Oops Concepts
 
Test-Driven Developments are Inefficient; Behavior-Driven Developments are a ...
Test-Driven Developments are Inefficient; Behavior-Driven Developments are a ...Test-Driven Developments are Inefficient; Behavior-Driven Developments are a ...
Test-Driven Developments are Inefficient; Behavior-Driven Developments are a ...
 
Introduction to design patterns
Introduction to design patternsIntroduction to design patterns
Introduction to design patterns
 

Mais de indikaMaligaspe

Rez gateway (RezOS) innovate the future
Rez gateway  (RezOS) innovate the futureRez gateway  (RezOS) innovate the future
Rez gateway (RezOS) innovate the futureindikaMaligaspe
 
Rez gateway - RezOS - innovate the future
Rez gateway - RezOS -   innovate the futureRez gateway - RezOS -   innovate the future
Rez gateway - RezOS - innovate the futureindikaMaligaspe
 
Delivering Powerful Presentations
Delivering Powerful PresentationsDelivering Powerful Presentations
Delivering Powerful PresentationsindikaMaligaspe
 
How ICT is shaping Travel and Tourism landscapes
How ICT is shaping Travel and Tourism landscapesHow ICT is shaping Travel and Tourism landscapes
How ICT is shaping Travel and Tourism landscapesindikaMaligaspe
 
So you want to be a Software Engineer
So you want to be a Software EngineerSo you want to be a Software Engineer
So you want to be a Software EngineerindikaMaligaspe
 
Designing Rest Services - An Architects Guide
Designing Rest Services - An Architects GuideDesigning Rest Services - An Architects Guide
Designing Rest Services - An Architects GuideindikaMaligaspe
 
Memory efficient programming
Memory efficient programmingMemory efficient programming
Memory efficient programmingindikaMaligaspe
 
Object Oriented Software Design Principles
Object Oriented Software Design PrinciplesObject Oriented Software Design Principles
Object Oriented Software Design PrinciplesindikaMaligaspe
 

Mais de indikaMaligaspe (8)

Rez gateway (RezOS) innovate the future
Rez gateway  (RezOS) innovate the futureRez gateway  (RezOS) innovate the future
Rez gateway (RezOS) innovate the future
 
Rez gateway - RezOS - innovate the future
Rez gateway - RezOS -   innovate the futureRez gateway - RezOS -   innovate the future
Rez gateway - RezOS - innovate the future
 
Delivering Powerful Presentations
Delivering Powerful PresentationsDelivering Powerful Presentations
Delivering Powerful Presentations
 
How ICT is shaping Travel and Tourism landscapes
How ICT is shaping Travel and Tourism landscapesHow ICT is shaping Travel and Tourism landscapes
How ICT is shaping Travel and Tourism landscapes
 
So you want to be a Software Engineer
So you want to be a Software EngineerSo you want to be a Software Engineer
So you want to be a Software Engineer
 
Designing Rest Services - An Architects Guide
Designing Rest Services - An Architects GuideDesigning Rest Services - An Architects Guide
Designing Rest Services - An Architects Guide
 
Memory efficient programming
Memory efficient programmingMemory efficient programming
Memory efficient programming
 
Object Oriented Software Design Principles
Object Oriented Software Design PrinciplesObject Oriented Software Design Principles
Object Oriented Software Design Principles
 

Último

Top Software Development Trends in 2024
Top Software Development Trends in  2024Top Software Development Trends in  2024
Top Software Development Trends in 2024Mind IT Systems
 
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmony
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine HarmonyLeveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmony
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmonyelliciumsolutionspun
 
Kawika Technologies pvt ltd Software Development Company in Trivandrum
Kawika Technologies pvt ltd Software Development Company in TrivandrumKawika Technologies pvt ltd Software Development Company in Trivandrum
Kawika Technologies pvt ltd Software Development Company in TrivandrumKawika Technologies
 
OpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS CalculatorOpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS CalculatorShane Coughlan
 
20240330_고급진 코드를 위한 exception 다루기
20240330_고급진 코드를 위한 exception 다루기20240330_고급진 코드를 위한 exception 다루기
20240330_고급진 코드를 위한 exception 다루기Chiwon Song
 
ERP For Electrical and Electronics manufecturing.pptx
ERP For Electrical and Electronics manufecturing.pptxERP For Electrical and Electronics manufecturing.pptx
ERP For Electrical and Electronics manufecturing.pptxAutus Cyber Tech
 
Kubernetes go-live checklist for your microservices.pptx
Kubernetes go-live checklist for your microservices.pptxKubernetes go-live checklist for your microservices.pptx
Kubernetes go-live checklist for your microservices.pptxPrakarsh -
 
Transforming PMO Success with AI - Discover OnePlan Strategic Portfolio Work ...
Transforming PMO Success with AI - Discover OnePlan Strategic Portfolio Work ...Transforming PMO Success with AI - Discover OnePlan Strategic Portfolio Work ...
Transforming PMO Success with AI - Discover OnePlan Strategic Portfolio Work ...OnePlan Solutions
 
Watermarking in Source Code: Applications and Security Challenges
Watermarking in Source Code: Applications and Security ChallengesWatermarking in Source Code: Applications and Security Challenges
Watermarking in Source Code: Applications and Security ChallengesShyamsundar Das
 
online pdf editor software solutions.pdf
online pdf editor software solutions.pdfonline pdf editor software solutions.pdf
online pdf editor software solutions.pdfMeon Technology
 
Optimizing Business Potential: A Guide to Outsourcing Engineering Services in...
Optimizing Business Potential: A Guide to Outsourcing Engineering Services in...Optimizing Business Potential: A Guide to Outsourcing Engineering Services in...
Optimizing Business Potential: A Guide to Outsourcing Engineering Services in...Jaydeep Chhasatia
 
Generative AI for Cybersecurity - EC-Council
Generative AI for Cybersecurity - EC-CouncilGenerative AI for Cybersecurity - EC-Council
Generative AI for Cybersecurity - EC-CouncilVICTOR MAESTRE RAMIREZ
 
Why Choose Brain Inventory For Ecommerce Development.pdf
Why Choose Brain Inventory For Ecommerce Development.pdfWhy Choose Brain Inventory For Ecommerce Development.pdf
Why Choose Brain Inventory For Ecommerce Development.pdfBrain Inventory
 
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/ML
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/MLBig Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/ML
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/MLAlluxio, Inc.
 
Deep Learning for Images with PyTorch - Datacamp
Deep Learning for Images with PyTorch - DatacampDeep Learning for Images with PyTorch - Datacamp
Deep Learning for Images with PyTorch - DatacampVICTOR MAESTRE RAMIREZ
 
JS-Experts - Cybersecurity for Generative AI
JS-Experts - Cybersecurity for Generative AIJS-Experts - Cybersecurity for Generative AI
JS-Experts - Cybersecurity for Generative AIIvo Andreev
 
Mastering Kubernetes - Basics and Advanced Concepts using Example Project
Mastering Kubernetes - Basics and Advanced Concepts using Example ProjectMastering Kubernetes - Basics and Advanced Concepts using Example Project
Mastering Kubernetes - Basics and Advanced Concepts using Example Projectwajrcs
 
AI Embracing Every Shade of Human Beauty
AI Embracing Every Shade of Human BeautyAI Embracing Every Shade of Human Beauty
AI Embracing Every Shade of Human BeautyRaymond Okyere-Forson
 
Your Vision, Our Expertise: TECUNIQUE's Tailored Software Teams
Your Vision, Our Expertise: TECUNIQUE's Tailored Software TeamsYour Vision, Our Expertise: TECUNIQUE's Tailored Software Teams
Your Vision, Our Expertise: TECUNIQUE's Tailored Software TeamsJaydeep Chhasatia
 
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdfARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdfTobias Schneck
 

Último (20)

Top Software Development Trends in 2024
Top Software Development Trends in  2024Top Software Development Trends in  2024
Top Software Development Trends in 2024
 
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmony
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine HarmonyLeveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmony
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmony
 
Kawika Technologies pvt ltd Software Development Company in Trivandrum
Kawika Technologies pvt ltd Software Development Company in TrivandrumKawika Technologies pvt ltd Software Development Company in Trivandrum
Kawika Technologies pvt ltd Software Development Company in Trivandrum
 
OpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS CalculatorOpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS Calculator
 
20240330_고급진 코드를 위한 exception 다루기
20240330_고급진 코드를 위한 exception 다루기20240330_고급진 코드를 위한 exception 다루기
20240330_고급진 코드를 위한 exception 다루기
 
ERP For Electrical and Electronics manufecturing.pptx
ERP For Electrical and Electronics manufecturing.pptxERP For Electrical and Electronics manufecturing.pptx
ERP For Electrical and Electronics manufecturing.pptx
 
Kubernetes go-live checklist for your microservices.pptx
Kubernetes go-live checklist for your microservices.pptxKubernetes go-live checklist for your microservices.pptx
Kubernetes go-live checklist for your microservices.pptx
 
Transforming PMO Success with AI - Discover OnePlan Strategic Portfolio Work ...
Transforming PMO Success with AI - Discover OnePlan Strategic Portfolio Work ...Transforming PMO Success with AI - Discover OnePlan Strategic Portfolio Work ...
Transforming PMO Success with AI - Discover OnePlan Strategic Portfolio Work ...
 
Watermarking in Source Code: Applications and Security Challenges
Watermarking in Source Code: Applications and Security ChallengesWatermarking in Source Code: Applications and Security Challenges
Watermarking in Source Code: Applications and Security Challenges
 
online pdf editor software solutions.pdf
online pdf editor software solutions.pdfonline pdf editor software solutions.pdf
online pdf editor software solutions.pdf
 
Optimizing Business Potential: A Guide to Outsourcing Engineering Services in...
Optimizing Business Potential: A Guide to Outsourcing Engineering Services in...Optimizing Business Potential: A Guide to Outsourcing Engineering Services in...
Optimizing Business Potential: A Guide to Outsourcing Engineering Services in...
 
Generative AI for Cybersecurity - EC-Council
Generative AI for Cybersecurity - EC-CouncilGenerative AI for Cybersecurity - EC-Council
Generative AI for Cybersecurity - EC-Council
 
Why Choose Brain Inventory For Ecommerce Development.pdf
Why Choose Brain Inventory For Ecommerce Development.pdfWhy Choose Brain Inventory For Ecommerce Development.pdf
Why Choose Brain Inventory For Ecommerce Development.pdf
 
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/ML
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/MLBig Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/ML
Big Data Bellevue Meetup | Enhancing Python Data Loading in the Cloud for AI/ML
 
Deep Learning for Images with PyTorch - Datacamp
Deep Learning for Images with PyTorch - DatacampDeep Learning for Images with PyTorch - Datacamp
Deep Learning for Images with PyTorch - Datacamp
 
JS-Experts - Cybersecurity for Generative AI
JS-Experts - Cybersecurity for Generative AIJS-Experts - Cybersecurity for Generative AI
JS-Experts - Cybersecurity for Generative AI
 
Mastering Kubernetes - Basics and Advanced Concepts using Example Project
Mastering Kubernetes - Basics and Advanced Concepts using Example ProjectMastering Kubernetes - Basics and Advanced Concepts using Example Project
Mastering Kubernetes - Basics and Advanced Concepts using Example Project
 
AI Embracing Every Shade of Human Beauty
AI Embracing Every Shade of Human BeautyAI Embracing Every Shade of Human Beauty
AI Embracing Every Shade of Human Beauty
 
Your Vision, Our Expertise: TECUNIQUE's Tailored Software Teams
Your Vision, Our Expertise: TECUNIQUE's Tailored Software TeamsYour Vision, Our Expertise: TECUNIQUE's Tailored Software Teams
Your Vision, Our Expertise: TECUNIQUE's Tailored Software Teams
 
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdfARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
 

Writing Quality Code

  • 1. “Writing Quality Code” By Indika Maligaspe ““Give a man a fish and you feed him for a dayGive a man a fish and you feed him for a day Teach him how to fish and you feed him for a lifetime”Teach him how to fish and you feed him for a lifetime”
  • 2. Intro...Intro... Indika Maligaspe  K. Indika Maligaspe  Developer, Designer, Architect , Trainer  Tech Geek specialized in JAVA and .Net  Over 14 years if experience in IT / Web Technologies  Lover of almost all sports...  http://www.linkedin.com/profile/view?id=201732082&trk=nav_responsive_tab_profile
  • 3. ContributorsContributors  David Bernstein  Alan Shalloway  Steve McConnell  Martin Fowler  Gamma, Helms, Johnson, Vlissides (GoF)  James Coplien
  • 4. Seminar AgendaSeminar Agenda  What effects Software Quality?  How to accommodate change?  What are Code Qualities?  Principles vs. Practices  Principles of Coding (Rules of Thumb)  Organizing Principles  Clarity Principles (good practices)  Summary  Q&A
  • 5. What effects Software Quality?What effects Software Quality? Two questions…..Two questions….. • How many of you have been involvedHow many of you have been involved inin  A totally successful project?  A totally failed project?  A "challenged" project?
  • 6. What effects Software Quality?What effects Software Quality? Two questions…..Two questions….. • When Adding FunctionalityWhen Adding Functionality Where was the Problem?Where was the Problem?  Is it writing the new code?  Is it integrating it into the system?  Why?
  • 7. How can we design toHow can we design to accommodate change?accommodate change?  We are not trying to anticipate change, per se, as much as writing our code to accommodate change better. Trying to anticipate change can lead to “paralysis by analysis”  To do this we need  A way to avoid change when possible (outside of the scope of this document)  Componentized Architectures (CBA / SBC etc…)  Use of Design Patterns  Agile concepts  A way to make change less risky when one cannot avoid it  Code clarity and maintainability  Refactoring
  • 8. What are Code Qualities?What are Code Qualities? • A computer has no concept of "well- written“ source code. However, from a human point of view source code can be written in a way that has an effect on the effort needed to comprehend its behavior. • Many source code programming style guides, which often stress readability and usually language-specific conventions are aimed at reducing the cost of source code maintenance by having code predictability.
  • 9. PredictabilityPredictability  We can’t predict how our requirements are going to change  However we can predict how our code will adapt to unpredictable requirement changes  How can we increase our predictive abilities?  Pay attention to code quality
  • 10. Six Code QualitiesSix Code Qualities  Cohesive  Correct Coupling  Non Redundant  Encapsulated  Testable  Assertive
  • 11. Principles vs. PracticesPrinciples vs. Practices  Principle  A standard  Theory  Practice  How you put a principle to practice i.e. Principle - The need to be clean Practice - Wash hands
  • 12. CohesionCohesion  Cohesion refers to how “closely the operations in a routine [or class] are related ” (Code complete – Steve McConnell)  Strong cohesion is related to clarity and understanding.  No "schizophrenic classes”  No “10000 - line classes”  No “10 page methods"‐
  • 13. Good StrongGood Strong cohesioncohesion  Class Cohesion - A class has a single responsibility, and everything in the class is about fulfilling that responsibility.  Using design patterns and OO concepts (strategy / encapsulation / open – close etc…)  Method Cohesion - Each method is about fulfilling one functional aspect of the classes responsibility.  Programming by intention can help us to code with better method cohesion from the beginning
  • 14. Class Cohesion - exampleClass Cohesion - example Class cohesion will be covered in detail in future sessions
  • 15. Method cohesion – programmingMethod cohesion – programming by intentionby intention
  • 16. Method cohesion – programmingMethod cohesion – programming by intentionby intention
  • 17. What “programming by intention”What “programming by intention” will bringwill bring  Method cohesion  Cohesion of perspective  Sergeant is the controller (very little implementation)  Private’s do the work (implementation)  Ease of refactoring  Ease of applying/forming design patterns  Easier to test
  • 18. CouplingCoupling  Coupling refers “to the strength of a connection between two routines [or classes] Coupling is complement to cohesion. Cohesion describes how strongly the internal contents of a routine [or class] are related to each other. Coupling describes how strongly a routine is related to other routines. The goal is to create routines [and classes] with internal integrity (strong cohesion) and small, direct, visible, and flexible relations to other routines [and classes] (loose coupling).”*  Tight coupling is related to highly interconnected code * Code Complete Steve McConnell 1993 p 22 Copyright
  • 19. Correct CouplingCorrect Coupling  How interconnected Objects are  Loosely coupled – Objects should be independent and should mind their own business.  One employee should not know about salary details of other employees in the company  Tight coupled – Objects are interconnected and intertwined. Change one place and “All hell breaks loose”  Every employee knows the salaries of all the employees in the company. Give increment to one – MAJOR PROBLEM
  • 20. Sample CouplingSample Coupling  Tight Coupling  Loose Coupling
  • 21. Types of couplingTypes of coupling  Identity  One type to the fact that coupled another type exists.  Representational  One type coupled to the interface of another.  Inheritance  Subtypes are coupled to their superclass, in that any change in the superclass will propagate downward.  Subclass  One type coupled to the fact that there are subclasses to a type, and what specific subclasses exist. Writing Quality code David Bernstein – 2008 p24 Copyright
  • 22. No Redundancy –No Redundancy – Avoiding duplicationAvoiding duplication  "One Rule in One Place"  Redundancy is not just:  Redundant state  Redundant functions  It can also be redundant relationships, design, construction, etc…  Anything that is redundant will cause maintenance problem
  • 23. Avoid RedundancyAvoid Redundancy  The “once and only once” rule  If you are going to copy and paste, ask yourself  What is the code I want to reuse?  Can I make a new method that can be used by both my current method and the place I need to use this similar functionality?  If 2 entities need to do this, how likely will there be a third, fourth, etc… Writing Quality code David Bernstein – 2008 p27 Copyright
  • 24. Encapsulation – Information hidingEncapsulation – Information hiding  Two commonly used encapsulation methods  Data : The data needed for a class to fulfill it's responsibilities is hidden from other entities  Implementation: How a class implements a particular function, or whether it implements it itself or delegates to other objects, is hidden  Not so commonly used  Type: Abstract classes and interfaces can hide their implementing classes  Design: Assembling, collaborating classes with an object factory keeps clients decoupled from the way they are designed (abstract factory)  Construction: Encapsulation of construction means wrapping "new" in, at least, a separate method, giving you control over the return type (use of getInstance)
  • 25. TestabilityTestability  Class responsibility should be individually testable (unit testing)  Considering how to test before developing or designing leads to  Correctness  Good OO design  OO design patterns  And forces you to look at:  the public method definitions  what the responsibilities of the object are  Easy testability is achieved by strong cohesion, loose coupling, good encapsulation and non redundancy
  • 26. Role of TestabilityRole of Testability  You should always do unit testing. It helps in code correctness  Whether you agree or not ask two things  You should always ask “ How will I test my design / code?”  If you see that your code/ unit or design is not testable, then there is something wrong in it. Ask your self “How can I make this more testable”
  • 27. Assertive or InquisitiveAssertive or Inquisitive  In a relationship between two entities A and B  Should A ask the state of B and then use it (inquisitive)  Should A tell B to do the task involving the state (Assertive)  It does not increase the code or design, just who takes the code and responsibility  Which is better?
  • 28. Assertive vs. Inquisitive –Assertive vs. Inquisitive – which is better?which is better?  The more Assertive you code / design is the more decoupled you code or design is  Remember the “Gang of Four”: Design to interfaces. An object's state is generally a part of its implementation. We should not design to that, as it is highly likely to change  "He who holds the state should hold the function"  Favor Assertiveness over Inquisitiveness (tell but not Ask principle)
  • 29. Organizing Principles  Cohesion is an organizing principle in that it helps us decide where new entities belong  Coupling is an organizing principle in that it helps us decide how different entities should talk to each other (the interfaces)  Eliminating redundancy is an organizing principle because it tells us to bring together redundant methods/rules into a single place
  • 30. Clarity Principles  How to document code  Implementation details (documentation) should be in the code, not as comments  If you have to write comments explaining “names”, your naming conventions might be having issues  There is BIG difference between comments about “what” you are doing and comments “why” (business rules)  Conceptual information can often be documented in abstract classes and interfaces  Naming is not always easy. It is often a good idea to pair on naming issues  Always format code properly (refer http://tutorials.rezg.net/Java/CodeConventions.pdf )  Try not have more the  100 characters per line  30 lines in a method  30 methods per class
  • 31. SummarySummary  Remember the Code QualitiesRemember the Code Qualities T – TestabilityT – Testability R – Non RedundancyR – Non Redundancy E – EncapsulationE – Encapsulation C – CohesionC – Cohesion C – Correct CouplingC – Correct Coupling A – AssertiveA – Assertive T.R.E.C.C.A.T.R.E.C.C.A. Writing Quality code David Bernstein – 2008 p54 Copyright
  • 32. Summary – In a NutshellSummary – In a Nutshell  In order of importance  Be testable  Contain no duplication (once and only once)  Loose coupling, strong cohesion and clarity  When writing, always program by intention  Methods and classes should be implemented so they can be understood totally from their names and their public interfaces. This flows naturally from up front testing, and decreases coupling‐  Classes should organize ideas in a readily understandable way  Use intention revealing names so you don't have to explain‐ method, member or class names with additional comments  Adhere to a coding standard