sábado, 23 de noviembre de 2019

Devil´s advocate technique

This is, in a nutshell, the Devil's Advocate technique. The intent isn't to break the software by sneaking in defects, but to explore how effectively the test suite detects bugs. In the current (simplified) example, the effectiveness of the test suite isn't impressive.
                                   source: https://blog.ploeh.dk/2019/10/07/devils-advocate/

viernes, 8 de noviembre de 2019

Some notes about Pluralsigth course: Encapsulation and SOLID by Mark Seemann

 - CQS for getting code simpler
 - More reading then writing code
 - Hide information (not public setters)
 - Not invalid states
 - Fail Fats
 - Never return null
 - SOLID, for making code more maintainable
rigidity: design difficult to change, easy to break
viscosity: no needed complexity, overkill design (simplicity)
 - Developers have  a tendency  to attempt  to solve specific problems with general solutions by Greg Young
 - Instead of being general code should be specific. by Greg Young
 - Following the SRP, each concrete class is very specific
 - Abstraction is the elimination of the irrelevant and the amplification of the essential by Robert C. Martin
 - Start with concrete behavior and discover abstractions as commonality emerges by rules of three
 - Favor composition over inheritance for example by strategy, decorator, ... patterns.
 - Don´t override inherited base class methods (Liskov Substitution Principle)
 - Implements all methods of inherited interface, don´t remove features from inherited class throwing NotSupportedException (Liskov Substitution Principle)
 - Prefer a tons of small, concrete, trial, simple and granular classes with a low level of abstraction, than a few classes with a lots of code.
 - Client should not depend on method that they do not use (Interface segregation principal)
 - Small interface with one operation.