Nowadays it already seems an age-old adage that functional approach very often is a good tool for fighting complexity and it gets highlighted here as well. This is also discussed more in yet another talk by him (also extremely good) on refactoring your language portfolio.
Do not walk away from Complexity, Run:
https://www.youtube.com/watch?v=nZcLHkORdHE
Refactor your language knowledge portfolio - we are what we can code in:
https://www.youtube.com/watch?v=zajUPJI19ZQ
Some highlights combined from both of the talks:
- "Mutability needs company, it often hangs out with bugs"
- Using a library is like dating, using a framework is like marriage
- "Don't build what you can download (library / dependency). Don't download what you really do not need"
- "We looked at this problem and said we can solve it using a pool of threads. Now we have a pool of problems to deal with."
- A key design skill we need to develop is the ability to discern accidental complexity from inherent / essential complexity
- Imperative code is packed with accidental complexity (see examples in the talk)
- What causes complexity:
- Too many moving parts
- Invisible changes
- Uncontrolled mutability
- Lack of cohesion
- Excessive dependencies
- Technology infatuation
- Low level concurrency
- Imperative style
- Entwinement
- "Good code is the opposite of legacy code: it captures and communicates essence, while omitting ceremony (irrelevant detail). Capturing and communicating essence is hard; most of the code I have ever read fails to do this at even a basic level.
- "The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn" - Alvin Toffler
- "There are risks and costs to a program of action, but they are far less than the long-range risks and costs of comfortable inaction" - JFK
The essence of many or even most of the tools regarding handling complexity come down to enabling developer to only look at one piece of a software or enterprise architecture and understand it without having to hold a multitude of other blocks in the puzzle in their mind. In other words the ability to reason about the code or architecture. Understanding this driving force enables you to come up with various tools and techniques to strive towards less complex future yourself without only relying on externally provided tidbits.
No comments:
Post a Comment