Westling with Android development itself is hard enough. Often we find ourself fighting with Business requirement domain as well. In rapid change business environment, there is only one logical solution — to seperate both domain from one another. Meaning that the Android development domain should be solid with confident so that the main focus can be zeroing in on making awesome disturaption in business domain ☺

Unit Test/Testing

• Coverage
• Repeatable
• Independence — Test only one thing: A good unit test should only have one assert
• Professional — Readable, Maintainable, fast

SafetyNet — This allows the developers to have confident in the code — to do something risky. Unit test is written with TDD it should be small with tight safety net. But there are other tests such as intregration test, performance test as well as unit test. The more test type exists the safer the developer felt.

Legacy Code — code in production that lifetime is longer than our lifetime in the company. Sometime known as Zombie code.

Complexity

• Duplication
• Long Method
• Hard to read
• Code without Refactoring (Complexity increase overtime)

Design Principle — [SOLID] Opposite to code smell, What is a good pattern? Appying SOLID will result in more classes and longer class. But the goal is we get to model our problem in abstaction. To make the code more readable. An example maybe when we are looking JSON lib to convert to Model object, we should try to write a wrapper over the class instead of directly using lib right away.

• Single responsibility principle — One Class should do one thing. — Utility Class is a tell — tell sign of a bad smell. Rather try to write a class with single responsibility. Another example is known as ice-berg class. A class with one public method with many many private classes which we cannot write unit test on.
• Open/closed principle — Plugin method such as hook, registering. Example for this is Firefox or Wordpress.
• Liskov substitution principle — If The mother object can do it then the child object must also be able to handle that object.
• Interface segregation principle — Tight closely with Liskov and Dependency, states that no client should be forced to depend on methods it does not use. ISP splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them
• Dependency inversion principle — Try to work with Abstraction not the concrete class.

Code Smell — Set of tools to help detect abnormality, that something is wrong. An interesting thing is that smell is something you can get used to if you are in an environment for a long time. Your body set a new norm. In a way, we may accept a bad code as a norm — if we allow ourself to be emerge in an environment for too long.

Design Pattern — In TDD, We should only look for design pattern after we find an issue, even if we may solved similar issue by applying this pattern before. The key is to feel the pain first.