Maintainability and Clean Code

• use language default
  • detailed guidelines available
  • style switches necessary when working on multiple projects within the same team or project with multiple languages
• decide in your team on a standard
  • keep consistent
  • one style over all languages
  • maybe switching styles between teams

• indications of poor coding and design choices that may lead to bad maintainability
• technically not incorrect
• indicate weaknesses and could be slowing down development or increase risk of bugs
• code vs architectural level

• Lack of Modularity: low cohesion, high coupling
• God Class: uses many attributes of other classes, many big methods with high complexity, does everything
• Refused Bequest: Subclasses dont need inherited methods and data from parents, subclass and superclass too different
• Feature Envy: Method is more interested in data/functions of another class, envies scope of other class
• Shotgun Surgery: single responsibility has been split up among large number of classes

• Simulated Polymorphism: conditionals are used instead of inheritance and polymorphism
• Dead Code: code blocks are never reached, no longer used
• Duplicated Code: same structure in more than one place, same expressions in two methods,...
• Data Clumps: Identical group of variables passed from function to function together instead of one single data structure
• Primitive Obsession: use of primitives to represent domain idea instead of self-defined, meaningful types (Currency, telephone number)

• changing a software system in such a way that it doesnt alter external behavior of code but improves internal structure

• improve software design
• make software easier to understand and modify
• helps finding bugs by improving general understandability of the code
• program faster

Extract Function

• turn it into own function
• replace extracted code with new method call

Move Function

• in other class create function with similar body
• turn old function into delegation or remove old function

State/Strategy:

• replace type code with state object
• create new state class for type code
• add subclass of state object for each type code

Parameterization

• use single function and parameterize it 
• use one of similar functions as baseline
• replace original calls with calls to parameterized function

Pull up method

• make methods identical and move them to superclass
• parameterize them
• delete sublcass methods

Collapse Hierarchy

• Merge subclass and superclass to one class
• adjust references and remove empty class

• Unit Testing
  • testing the smallest testable parts (public methods, APIs)
  • do units fulfill functionalities
• Integration Testing
  • testing groups of units across modules
  • do units perform correctly together
• System Testing
  • testing entire application as whole
  • does system meet specification
• Acceptance Testing
  • testing final system before release
  • are end users expectations met

• automated piece of code that invokes unit of work being tested
• checks assumptions about single end result of that unit
• consistent in results if production code doesnt change

• Self-Documenting and Readable: clear, precise and easy to understand, expressive with clear intent
• Concept-bounded: should test single concept only, asserts should be minimized
• Isolated: tested unit should be isolated from external dependencies (databases)

• properties of clean tests
• Fast: tests should run quickly, otherwise they are not run frequently
• Independent: tests should not depend on each other, could cause stream of failure
• Repeatable: tests should not rely on environment, always yield same result for same code base
• Self-Validating: boolean output
• Timely: write tests before production code

1. Write a for now failing test for a piece of functionality
2. Write production code that passes test
3. Refactor, run all tests to verify refactoring did not change external behaviour

• controllable replacement for an existing dependency in the system
• used to test code depending on external objects, without dealing with dependency directly
• find interface that object under test works against
• eventually add level of indirection hiding interface
• replace underlying implementation of interface with something you have control over (stub)

• fake object in system that decides whether unit test fails or passes
• verifies whether object under test called the fake object as expected
• class under test communicates with mock, mock records all communication
• test uses mock object to check if test passed based on verifying communication using expectations

• either mock (tested against) or stub (tested against object under test)
• main purposes:
  • test independence
  • interface discovery: stubbing/mocking not yet existent classes

• fixed state that exists at start of the test
• ensures that test is repeatable by ensuring all preconditions
• fixture might be setup/torn down after test

1. Set up Fixture
2. Exercise System under test: interact with SUT to exercise the behavior that should be verified
3. Result Verification: determine whether outcome fails the test or not
4. Fixture Teardown: put everything back into original state

• allows programmer to refactor code at later time and make sure that modules still work correctly
• by testing parts of program first and then sum of its parts integration testing becomes much easier