Talks, articles, papers that I watch or read during lunch time
-
The insufficiency of good design by Sarah Mei
- Conway's Law
- Good communication produces good code
- Decoding smelly code
- Hidden silos
- Every piece of bad code is trying to say something
- Pair Programming
- Create opportunities for informal communication
-
SOLID Object Oriented Design by Sandi Metz
- SOLID
- Rigid - Every change causes a cascade of changes
- Fragile - Distant and unrelated changes with every other change
- Immobile - You can't reuse anything
- Design Stamina Hypothesis
- Only mock classes that you own
- Don't mock/stub the object under test
- The fact that there's a need to refactor doesn't mean you should
- Don't be attached to your first idea
- Embrace the code friction
- If testing seems hard there's a problem with the design
- TDD will punish you if you don't understand about design
- TDD Rules
- Refactor
- Is the code DRY?
- Does it have one responsibility?
- Does everything change at the same rate?
- Does it depends that change less often than the unit itself?
- Refactor
- Code Smells
- Describing something using "and" implies that it does two different things
- Describing something using "or" implies that it does two different and unrelated things
- As soon as you feel resistant with arguments order that's a data clump use a hash or value object
- When testing - if it's going to change on production inject if not stub
- Refactor not because you know which is the abstraction but because you want to find it.
- class_eval
- It is better to depend on things that doesn't change often
- TDD is not enough
- DRY is not enough
- Design because you expect your application to succeed
-
Less - The path to better design by Sandi Metz
- What is design?
- Not something establish by an architect but something you evolve through several iterations
- Code needs to - work today, be able to change forever
- Design purpose
- Reduce the cost of change
- Design description
- Easily composable
- Highly cohesive
- Loosely coupled
- Context independent
- TRUE
- Transparent - Consequence of change should be obvious
- Reasonable - Cost of adding a new feature is proportional to it's value
- Usable - If you write the code; you should be able to use it
- Exemplary - More code like this should be good for your application
- Knowledge is coupling
- Create dependencies
- Unstable dependencies increases risk
- Try to always loose coupling
- Uncertainty should be your guide
- What is design?
-
Therapeutic Refactoring by Katrina Owens
- Guilt driven development
- Characterization tests
- Add test cases to discover what the code do right now
- Replace method with method object
- To isolate the behavior
- Rename methods in terms of what the method does
- Follow longest lines to do extraction for clarification
- Helps you identify a piece of code that does something and give it a name
- Code smells
- Code junks
- Comments
- Do not echo the implementation
- Do not be wrong or mispell
- White spaces
- Remove dead code
- Needles parenthesis
- Explicit default parameters
- Unneeded dependencies
- Too much hard work - simplify the code at every change
- Duplicated tests
- Combine all of the above
- Comments
-
Get a whiff of this by Sandi Metz
- Code smells
- Bloaters
- Tool abusers
- Change preventers
- Dispensables
- Couplers
- Every code smell has a refactoring recipe
- Code smells
-
Rampant Emergence: Lessons Learned from 4 Years of Aggressive Change by Neal Ford
- Emergent design
- Finding abstractions and patterns
- Last responsible moment - It is safe to defer decisions?
- Longer delay; more real data for decision
- Who needs an architect
- Architecture
- Dynamic - Hard to change later
- Static - web frameworks, tools. Allow few changes as possible
- Product - features
- Technical - Static/Dynamic
- Traditional architect role
- Define long term architecture up front
- Agile architecture role
- Few architecture elements and make them as flexible as possible
- Don't do stupid things
- Staff projects inadequately
- Ramp up staffing too quickly
- Assume good initial velocity on brand new X
- Indulge in RDD (Resume Driven Development) - Put every single technology on your codebase
- Anything on Anti Patterns Catalog
- Be careful of architectural smearing
- Produce afferent/efferent coupling between components
- Stay in sync with upgrades
- Tools, OS, frameworks
- Future ported features are hard to refactor
- Lingering upgrades == technical debt * 2
- Age of codebase by number of components ongoing effort required for stasis
- Especially true for "smeary" frameworks - Rails does this
- Budget early as technical stories/tasks
- Keep domain logic DRY
- Business rules
- Validations
- Data rules
- Workflow
- Functionality must exist across tiers
- Green to brown - when a project has some time in development
- Every project hits an inflection point
- Engineering practices should reflect the change
- Add semi-permanent technical debts cards (Why not do refactoring every time someone touches the code?)
- Harvesting model for reuse
- Switch to emergent design styles
- No design
- No matter how much you try, requirements evolve chaotically
- Bed-rock assumptions become malleable
- Prefer dynamic over static
- Don't think of the application as an equation
- Make rules and policies dynamic
- Loose coupling at integrations points
- Early integration efforts focused on RPC-style interaction
- Great for an equation bu lousy for a process
- Resources over remote procedure calls
- Choreography over orchestration
- Coarse-grained components/services
- Continuous delivery
- Semantic monitoring
- Consumer driven contracts
- For brown field projects
- Refactoring and restructuring exercises require increasing effort for the same result
- Plan escalating effort towards remedial architecture and design
- Trade off for reduced up-front effort
- Emergent design