Keeping Code Clean
Agile tools and practices for better code
Topics
● Pair Programming
● Automated Unit Testing
● Refactoring
● Test-Driven Development
● Agile Architecture
Pair Programming
Pair Programming
● Continuous Code Review
● Better Design w/ Less Code
● Faster Problem Solving
● More People Familiar w/ System
● Team Gro...
Pair Programming - Evidence
Pair Programming - Evidence
Williams 2000
● Efforts +15%, Schedule -43%
Baheti 2002
● Effort +2%, Schedule -49%
Ciokowlski...
Automated Unit Testing
What is Automated Unit Testing?
Use of special software to control the
execution of unit tests and the comparison of
actua...
Automated Unit Test Suite Benefits
● Unit tests find problems early in the development cycle
● Developers will be less afr...
What is a Unit Test Case?
● A test for a single unit of functionality
● Each method tests a specific bit of
functionality
...
AAA Test Structure
● Structure:
○ Arrange
○ Act
○ Assert
● Benefits:
○ Readable
○ Consistent
public class SalesTaxTest
{
p...
Unit Testing Best Practices
● Test simple stuff first
● Get it working - then test boundaries/exceptions
● Use assert
● Ke...
Test Doubles
● Stand in for a collaborating object e.g. database,
webservice
● Create test independence
● Make tests run f...
Refactoring
Refactoring
● What is refactoring?
● Why refactor?
● When to refactor?
What is Refactoring?
“A change to the system that leaves its behavior
unchanged, but enhances some non-functional quality ...
Why Refactor the Code?
● Prevent “design decay”
● Clean up messes
● Simplify
● Increase readability / understandability
● ...
When to Refactor
● Code reviews / TDD cycle
● Rule of three
○ cut & paste. Third time copying? Now is the time to
generali...
What is a Code Smell?
● any symptom in the code that possibly
indicates a deeper problem.
● not bugs - but indicate weakne...
Code Smells (1/2)
● Duplicated code: near-identical code in multiple places
● Long method: a too large method/function/pro...
Code Smells (2/2)
● Comments - refactor so these are no longer needed!
● Feature envy: excessive use of another class’ met...
Why Developers Resist Refactoring
● Lack of understanding
● Short-term focus
● Not paid for overhead tasks like refactorin...
Test-Driven Development
TDD as a Design Approach
● Tests define up front what “works” means
● Programing by intention - write tests for what
code ...
Red-Green-Refactor Cycle
How to Get to Green? Implement it!
Obvious
Implementation
code the real implementation, if
it's obvious and can quickly ma...
How to Get to Green? Fake it
Fake it
hardcode constants to make test
pass, gradually generalize code
using variables
publi...
How to Get to Green? Triangulate
Triangulate
figure out the behavior of an
algorithm by examining a couple
of test cases i...
Use TDD to Earn a Gift Card!
TDD is a great tool to use in solving the code challenges. E.g. Function takes a
Roman Numera...
A Great TDD Example!
● Bowling Kata - how to score a bowling
game.
● Eclipse and junit step-by-step presentation
on red - ...
Agile Architecture
● Collaborative Design
● Good coding Standards and Principles
Agile Architecture
Collaborative Design
● Emergent Design
○ Light Design Up Front (LDUF)
● Every team member contributes
● No command and con...
Collaborative Design - payoff
http://martinfowler.com/bliki/DesignStaminaHypothesis.html
Standards and Principles
● Agree as a team
○ coding and naming conventions
○ toolset
■ Static Code Analysis, Test mocks, e...
Object Oriented Design Principles
S ingle Responsibilty
O pen/Closed
L iskov Substitution
I nterface Segregation
D ependen...
The Single Responsibility Principle
● Every class should have a single responsibility, and that responsibility
should be e...
class Book {
function getTitle() {
return "A Great Book";
}
function getAuthor() {
return "John Doe";
}
function turnPage(...
The Open/Closed Principle
● You should be able to extend a classes
behavior without modifying it
● Open for extension, but...
public double Area(object[] shapes)
{
double area = 0;
foreach (var shape in shapes) {
if (shape is Rectangle) {
Rectangle...
The Liskov Substitution Principle
● Derived classes must be substitutable for
their base classes
public class Rectangle {
private int width;
private int height;
// setters and getters
}
public class Square extends Recta...
The Interface Segregation Principle
● No client should be forced to depend on
methods it does not use
interface Worker {
void work();
void eat();
}
class HumanWorker implements Worker {
Public void work { /* do work stuff */...
The Dependency Inversion Principle
● High-level modules should not depend on
low-level modules. Both should depend on
abst...
class Worker {
private FileWriter fileWriter;
public Worker() {
fileWriter = new FileWriter();
}
}
class Worker {
private ...
Object Orient Patterns
● Common Design Patterns
○ Strategy, Command, Decorator, Adapter, etc
● Enterprise Integration Patt...
Acknowledgements
Pair Programming:
● http://www.cs.pomona.edu/classes/cs121/supp/williams_prpgm.pdf
● http://collaboration...
Keeping code clean
Keeping code clean
Keeping code clean
Keeping code clean
Keeping code clean
Upcoming SlideShare
Loading in...5
×

Keeping code clean

575

Published on

One of the main hindrances to teams being able to respond rapidly to new features are technical problems resulting from bad coding practices, also known as technical debt. Melissa and Brett will cover Agile tools and practices that help development teams write better code and increase maintainability. Topics that will be covered include:

Pair programming
Automated Unit Testing
Refactoring
Test-Driven Development
Agile Architecture

Published in: Software, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
575
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Keeping code clean

  1. 1. Keeping Code Clean Agile tools and practices for better code
  2. 2. Topics ● Pair Programming ● Automated Unit Testing ● Refactoring ● Test-Driven Development ● Agile Architecture
  3. 3. Pair Programming
  4. 4. Pair Programming
  5. 5. ● Continuous Code Review ● Better Design w/ Less Code ● Faster Problem Solving ● More People Familiar w/ System ● Team Grows Closer Pair Programming - Benefits
  6. 6. Pair Programming - Evidence
  7. 7. Pair Programming - Evidence Williams 2000 ● Efforts +15%, Schedule -43% Baheti 2002 ● Effort +2%, Schedule -49% Ciokowlski 2002 ● Effort +9%, Schedule -46%
  8. 8. Automated Unit Testing
  9. 9. What is Automated Unit Testing? Use of special software to control the execution of unit tests and the comparison of actual outcomes with predicted outcomes. To get full benefit run as part of the build process and schedule to run automatically once or twice a day.
  10. 10. Automated Unit Test Suite Benefits ● Unit tests find problems early in the development cycle ● Developers will be less afraid to change code ● Development process becomes more flexible ● Easier for a developer to take over code they are unfamiliar with (improves “Truck Factor”) ● Reduces need for manual testing ● Software development becomes more testable and repeatable
  11. 11. What is a Unit Test Case? ● A test for a single unit of functionality ● Each method tests a specific bit of functionality ● Automated by the test-runner framework
  12. 12. AAA Test Structure ● Structure: ○ Arrange ○ Act ○ Assert ● Benefits: ○ Readable ○ Consistent public class SalesTaxTest { private SalesTax unit; @Test public void TestCalculate() { unit = new SalesTax(); // ARRANGE double tax = unit.Calculate(10); // ACT Assert.assertEquals(tax, 0.9); // ASSERT } }
  13. 13. Unit Testing Best Practices ● Test simple stuff first ● Get it working - then test boundaries/exceptions ● Use assert ● Keep tests small & understandable ● Make test method names descriptive ● Keep tests independent of each other ● Avoid System.out messages ● Don’t repeat tests! Test once and trust it.
  14. 14. Test Doubles ● Stand in for a collaborating object e.g. database, webservice ● Create test independence ● Make tests run faster ● Types of Doubles ○ Fakes: working implementation e.g.fake web service ○ Mocks: preprogrammed with expectations ○ Stubs: provide canned answers to the test’s calls
  15. 15. Refactoring
  16. 16. Refactoring ● What is refactoring? ● Why refactor? ● When to refactor?
  17. 17. What is Refactoring? “A change to the system that leaves its behavior unchanged, but enhances some non-functional quality - simplicity, flexibility, understandability, performance” -- Kent Beck, Extreme Programing Explained (p. 179) “A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.” -- Martin Fowler, Refactoring (p. 53)
  18. 18. Why Refactor the Code? ● Prevent “design decay” ● Clean up messes ● Simplify ● Increase readability / understandability ● Find bugs ● Reduce debugging time ● Build in what we learn about the application ● It’s part of the creative process
  19. 19. When to Refactor ● Code reviews / TDD cycle ● Rule of three ○ cut & paste. Third time copying? Now is the time to generalize and move this to a new procedure. ● When you: ○ add functionality ○ learn something about the code ○ identify a code smell
  20. 20. What is a Code Smell? ● any symptom in the code that possibly indicates a deeper problem. ● not bugs - but indicate weaknesses in design that may be slowing down development or increasing the risk of bugs or failures in the future.
  21. 21. Code Smells (1/2) ● Duplicated code: near-identical code in multiple places ● Long method: a too large method/function/procedure ● Large class: a class that has grown too large. ● Too many parameters: decreases readability/quality. ● Identifier names are too short or excessively long ● Complex conditionals: branches that check lots of unrelated conditions and edge cases that don't seem to capture the meaning of a block of code.
  22. 22. Code Smells (2/2) ● Comments - refactor so these are no longer needed! ● Feature envy: excessive use of another class’ methods ● Inappropriate intimacy: a class that has dependencies on implementation details of another class. ● Lazy class / Freeloader: a class that does too little. ● Contrived complexity: simpler design would suffice. ● Excessive use of literals (use named constants)
  23. 23. Why Developers Resist Refactoring ● Lack of understanding ● Short-term focus ● Not paid for overhead tasks like refactoring ● Fear of breaking current program Use TDD to overcome this fear!
  24. 24. Test-Driven Development
  25. 25. TDD as a Design Approach ● Tests define up front what “works” means ● Programing by intention - write tests for what code intends to do not what the code you just wrote does. ● Focus on minimum set of required features ● Regular integration of small changes ● Evolutionary Design: Tests provide a safety net for refactoring.
  26. 26. Red-Green-Refactor Cycle
  27. 27. How to Get to Green? Implement it! Obvious Implementation code the real implementation, if it's obvious and can quickly make test pass, otherwise... public int Sum(int x, int y) { return x + y; }
  28. 28. How to Get to Green? Fake it Fake it hardcode constants to make test pass, gradually generalize code using variables public int Fibonacci(int n) { if (n >= 1) return 1; return 0; }
  29. 29. How to Get to Green? Triangulate Triangulate figure out the behavior of an algorithm by examining a couple of test cases instead of just one. public void TestSum() { Assert.AreEqual(4, Plus(3, 1)); Assert.AreEqual(7, Plus(4, 3)); }
  30. 30. Use TDD to Earn a Gift Card! TDD is a great tool to use in solving the code challenges. E.g. Function takes a Roman Numeral String and returns the Decimal value. ● Start with simple valid numbers I, III... up to more complex tests ● Incorporate tests for boundary conditions and invalid numbers ● With a set of tests you can easily refactor your solution. VALID NUMBERS INVALID NUMBERS I Boundary: Empty, 0, MMMM III iii IV IVIV, IIII, IIX, MXXXX VI, XLIX, MMMDCCCLXXXVIII ABCDEF
  31. 31. A Great TDD Example! ● Bowling Kata - how to score a bowling game. ● Eclipse and junit step-by-step presentation on red - green - refactor to solve (butunclebob. com/files/downloads/Bowling%20Game%20Kata.ppt)
  32. 32. Agile Architecture
  33. 33. ● Collaborative Design ● Good coding Standards and Principles Agile Architecture
  34. 34. Collaborative Design ● Emergent Design ○ Light Design Up Front (LDUF) ● Every team member contributes ● No command and control
  35. 35. Collaborative Design - payoff http://martinfowler.com/bliki/DesignStaminaHypothesis.html
  36. 36. Standards and Principles ● Agree as a team ○ coding and naming conventions ○ toolset ■ Static Code Analysis, Test mocks, etc ○ best practices ● Avoid Technical Debt ● Follow well established principles and patterns
  37. 37. Object Oriented Design Principles S ingle Responsibilty O pen/Closed L iskov Substitution I nterface Segregation D ependency Inversion
  38. 38. The Single Responsibility Principle ● Every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. ● Single Reason to Change
  39. 39. class Book { function getTitle() { return "A Great Book"; } function getAuthor() { return "John Doe"; } function turnPage() { // pointer to next page } function printCurrentPage() { echo "current page content"; } }
  40. 40. The Open/Closed Principle ● You should be able to extend a classes behavior without modifying it ● Open for extension, but closed for modification
  41. 41. public double Area(object[] shapes) { double area = 0; foreach (var shape in shapes) { if (shape is Rectangle) { Rectangle rectangle = (Rectangle) shape; area += rectangle.Width*rectangle.Height; } else { Circle circle = (Circle)shape; area += circle.Radius * circle.Radius * Math.PI; } } return area; }
  42. 42. The Liskov Substitution Principle ● Derived classes must be substitutable for their base classes
  43. 43. public class Rectangle { private int width; private int height; // setters and getters } public class Square extends Rectangle { public Square(int height, int width) { setWidth(width); setHeight(height); } }
  44. 44. The Interface Segregation Principle ● No client should be forced to depend on methods it does not use
  45. 45. interface Worker { void work(); void eat(); } class HumanWorker implements Worker { Public void work { /* do work stuff */ } Public void eat { /* eat stuff */ } } class RobotWorker implements Worker { Public void work { /* do work stuff */ } Public void eat { /* ACK! I don't eat! */ } } interface Worker { void work(); } interface Eater { void eat(); } class HumanWorker implements Worker, Eater { Public void work { /* do work stuff */ } Public void eat { /* eat stuff */ } } class RobotWorker implements Worker { Public void work { /* do work stuff */ } }
  46. 46. The Dependency Inversion Principle ● High-level modules should not depend on low-level modules. Both should depend on abstractions. ● Abstractions should not depend on details. Details should depend on abstractions.
  47. 47. class Worker { private FileWriter fileWriter; public Worker() { fileWriter = new FileWriter(); } } class Worker { private FileWriter fileWriter; public Worker(FIleWriter writer) { fileWriter = writer; } } interface FileWriter { // writer files or something }
  48. 48. Object Orient Patterns ● Common Design Patterns ○ Strategy, Command, Decorator, Adapter, etc ● Enterprise Integration Patterns
  49. 49. Acknowledgements Pair Programming: ● http://www.cs.pomona.edu/classes/cs121/supp/williams_prpgm.pdf ● http://collaboration.csc.ncsu.edu/laurie/Papers/ieeeSoftware.PDF SOLID ● http://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational- pictures/ Content based on: ● SolutionsIQ CSD training slides ● http://en.wikipedia.org/wiki/Code_smell ● http://www.codeproject.com/Articles/5404/The-benefits-of-automated-unit-testing
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×