notes from weekend with Uncle Bob, day 2

from yesterday: a comment is a failure to express something in code

keeping comments formatted bright red:
if someone writes a comment, i want it to yell at me..
and if i wonder why it is yelling at me about that, i’m going to delete it.

law of trainwrecks (Demeter – principle of least knowledge)

writing software is hard. TDD is hard.
it’s not easy, but it’s worth it

the way you behave under pressure is your belief

Liskov, LSP – can you subsitute a subtype w/out program knowing/ detecting?
if you have to ask object about type, b/c what you want to do depends on type or subtype, LSP is broken

representations don’t necessarily have the relations of what they represent (rectangle, square ex.)

early smell of breaking LSP – inherit or implement with empty or exception only methods

do you need an ugly hack? (ref above) – put it in an adapter w/ deps only outward

oo protects us from new types, but exposes us to new methods
fp protects us from new methods, but exposes us to new types

dependency inversion, at key points/ where you want to uncouple:
“don’t ever call anything concrete by name”
(use interfaces, abstracts, factories)

direction of dependencies, ood, loosen coupling:
go in one direction, from concrete towards abstract

more inheritance makes the code more rigid

moore’s law is failing, multicore crisis
sw devs got a free lunch for 40 years, hw devs did all the work – no longer…

architecture of a thing should tell you what the thing does
use cases at the top level
frameworks are tools, infrastructure

the only effective architect is an architect who codes

notes from weekend with Uncle Bob, day 1

read SICP! also, check out old lectures online (MIT)

(agile) architecture is the art of delaying decisions as long as possible

Big Redesign is almost always doomed to fail. clean the mess instead

having good/ agile/ evolving architecture depends on a good safety net of tests

extract till you drop

big functions have a geography that matches our caveman brain. doesn’t work too well when new to the code.

big functions are where objects go to hide

SRP
single responsibility principle
single reason-for-change principle
single source-of-change principle
who will ask for feature mods?
responsibility – family of functions to serve an actor

gateway – access to DB primitives

OCP, open/ closed principle – extend without modify
moral center of sw architecture

best predictor of change is change that’s already happened.
making a case for small changes into production to get feedback ASAP and frequently

good architecture – respond well to change, minimize amount of code that needs changing

biz/ domain and testability are both good (but different) reasons for abstraction, and might lead to different abstractions

a test of knowledge

by Kevlin Henney

www.artima.com/weblogs/viewpost.jsp?thread=340839

(my emphasis)

Summary
What can you learn from testing? When you look beyond the red and the green, the fail and the pass, you can learn a lot more about the nature of the code and the nature of the problem domain. And there is a lot to learn — software development is called knowledge work for a reason.

….
deeper truth becomes visible: knowledge work is about knowledge. It’s about knowing stuff and, most often, also about how you deal with stuff you don’t know.

….
curiosity is key to how we address a lack of knowledge. Questions are the agents of curiosity. Even without answers, questions can help us to increase and refine our knowledge, to learn.

….
Software testing is a form of learning. …. A test allows us to move from belief to knowledge

….
the first part of any feedback-based process is generating the feedback; what you do with it becomes the next challenge

….
learning opportunities are available from … the formulation [of testing] rather than the execution of tests.

….
The reality is that some things just are harder to code and test no matter how you write the code or the tests. When complexity was being handed out, not all applications and domains of interest were created equal.

on accidental complexity:

in principle, avoidable. This is the realm of technical debt, baroque frameworks and rococo architectures. It’s where speculative generality has come home to roost, copy-and-paste code has blossomed and coupling has weighed anchor. This is where the observation “if your code is difficult to test, it means your code is messy” may often apply.