Tag: code

The Purpose of Testing

• To exercise the Api and the design. A hard class to test, is a poorly designed interface.
• To prevent regressions.

The Cost of Regressions

Dimensions of the Risk

• The likelihood the event.
• The impact of the event.

To reduce risk, you either decrease the likelihood or the impact of the event.

What is the impact of the error if happens? If it’s a dev app, there is almost zero risk. If it’s a Voyager probes. It could doom the project.

F.I.R.S.T

• Fast
• Independent
• Repeatable
• Self-Validatable
• In-Time, written before production code

Types of Tests

• Unit Tests – verify the behavior of a unit under tests in isolation
• Integration Tests – verify the behavior of either a part of the system or a whole system. These tests are often brittle.
• Acceptance Tests – verify the software from the user’s point of view.

Frameworks & Tools

• SpecFlow – BDD
• xUnit – unit testing
• Moq – Mocking
• NCrunch
• Resharper

Notes

• Triangulation
  • We generalize the implementation when we have two or more test cases. We add test cases until the right way of implementation starts to emerge.
• Faking
  • Faking means returning constants and gradually replacing the value with variables and evolving the solution.
• Obvious Implementation
  • Sometimes the implementation appears obvious, but as you start to poke at it with tests, it begin to crumble.
• Grabbing the gold
  • You start from writing unit tests which cover the core functionality right away, and it fails with edge cases.
  • Suggestion: Write as many tests as possible before approaching the core functionality. Check for max values, empty strings, null values, min values… etc.
  • Uncle Bob’s Suggestions: Write tests exactly in the following order: exceptional, degenerate, and ancillary
    • Degenerative cases are those which cause the core functionality to do "nothing"
    • Ancillary behaviors are those which support the core functionality

Apply the design pattern when the design is ready to accept it.

• Don’t force a design pattern onto a problem. Let the code evolve until it’s obvious the design pattern is needed. It is better to be late than early.

• This idea comes back to my thoughts on keep things simple don’t over architect code. Don’t add it, until it’s a requirement.

Multiple Iterations

• The first attempt is to produce the tailored design
  • Design patterns do not fit into this phase
• Then refactor to reach a better design
  • this is where design patterns fit well.

Principle of Least Surprise

Design Patterns are generally more complex than they are in the examples and text books.

A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. – Martin Fowler

Technical debt is the sum of the following coding shortcuts:

• Duplication
• Excess Coupling
• Quick Fixes
• Hacks

Why Refactor?

• Improves Design
• Improves Readability
• Reveals Defects
• Helps You Program Faster

Other than when you are very close to a deadline, however, you should not put off refactoring because you haven’t got time. Experience with several projects has shown that a bout of refactoring results in increased productivity. Not having enough time usually is a sign that you need to do some refactoring. – Martin Fowler

Refactoring Principles

• Keep it Simple
• Keep it DRY
• Make It Expressive
• Reduce Overall Code
• Separate Concerns
• Appropriate Level of Abstraction

Refactor Tips

• Keep Refactoring’s Small
• One At a Time
• Make a Checklist
• Make a ‘later’ list
• Check in Frequently
• Add Test Cases
• Review the Results

Premature optimization is the root of all software evil. – Donald Knuth

Coding Philosophy

• Keep it simple.
• Deliver value.
• Avoid over-engineering.
• Avoid gold plating your code.

Principle of Least Surprise

• Do what users expect
• Be Simple
• Be Clear
• Be Consistent
• Design API to behave as programmers would expect.

Organizing Code Smells into 5 groups

• The Bloaters
  • Do it all god objects…
    • Small lean code bases and changed quickly
  • Long Methods
    • Keep methods smaller
      • 10 lines or fewer
      • Avoid regions
• The Object-Orientation Abusers
• The Change Preventers
• The Dispensables
• The Couplers
• The obfuscators
• Environment Smells
• Test Smells
• Architecture Smells

Refactoring Long Methods

• Extract Method
  • Introduce Parameter Object
  • Replace Temp with Query
  • Replace Method with Method Object
• Compose Method
  • Place bits of functionality into smaller methods.
  • The result is a method that has a number of method calls.
• Replace Nested Conditional with Guard Clause
• Replace Conditional Dispatcher(switch statement) with Command Pattern
• Move Accumulation to Visitor ()
• Replace Conditional Logic Strategy pattern

Refactor Large Class

Violating Single Responsibility Principle

Too many instance variables

Too many private methods (Iceberg class)

Lack of cohesion

Some methods work with some instance variables, others with others

Compartmentalized class

Refactoring Large Classes Strategy

Extract Method (and hopefully combine logic)

Extract class

Extract Subclass/Extract Interface

Replace Conditional Dispatch with Command

Replace State-Altering Conditionals with State Machine

Replace Implicit Language with Interpreter Pattern

Primitive Obsession

• Over-use of primitives, instead of better abstractions, results in excess code to shoehorn the type. The primitives themselves can contain invalid states and therefore must be checked when the value is set or used.

  • Often Guard clauses and validation is used to everytime the value changes for the type.
  • Les Intention – Revealing code

• Refactor away from Primitive Obsession

  • Replace Data value with Object
  • Replace Type Code with Class
  • Replace Type Code with Subclass
  • Extract Class
  • Introduce Parameter Object
  • Replace Array with Object
  • Replace State-Altering Conditionals with State
  • Replace Condition Logic with Strategy

• Examples of a Primitive Data Obsession

  • ZIP / Postal Codes
  • Phone Numbers
  • Social Security Numbers
  • Telephone Numbers
  • Money
  • Age
  • Temperature
  • Address
  • Credit Card Information

Long Parameter List

• May indicate procedural rather than OO programming style

• Related Smells

  • Message Chains
  • MiddleMan
  • Rules of Thumb
    • No more than three arguments
    • No output arguments
      • Not intuitive
    • No flag arguments
      • means the method is doing more than one things
    • Selector arguments
      • MEans the method is doing more than one thing.

• In general

  • Prefer more, smaller, well-named methods to fewer methods with behavior controlled by parameters