diff options
Diffstat (limited to 'reviews/talks.md')
| -rw-r--r-- | reviews/talks.md | 81 |
1 files changed, 81 insertions, 0 deletions
diff --git a/reviews/talks.md b/reviews/talks.md new file mode 100644 index 0000000..ed272c8 --- /dev/null +++ b/reviews/talks.md @@ -0,0 +1,81 @@ +# Sandi Metz - Nothing is Something + +:::: tags +- OOP +- Ruby +:::: + +Some insightful thoughts on OOP. + +Clever examples of message-passing to get rid of conditionals. + +Prefer composition with dependency injection to inheritance: +inheriting to override a method really means that the parent class had +a default "null" behaviour that can be injected explicitly. + +Name the role, make an interface for it, and make classes that +implement each behaviour (the null one and the specialiazed one). +This will make it easier to compose specializations (i.e. save you +from multiple inheritance). + + +# Sandi Metz - Rules + +:::: tags +- OOP +- Ruby +:::: + +Some theory-crafting on rule-following, then the actual rules, which +amount to + +- small classes, +- tiny methods, +- few parameters. + +At the 16-minute mark, an interesting interaction between Metz and a +programmer starting to apply these rules: the programmer wonders when +they will be able to understand the new application "the same way" +they understood the old one. I.e. will they ever reach a point where +they have a complete mental map of every interaction between every +object, the same way they used to have a complete mental map of the +old monolithic, sequential application? + +Metz's response is that nope, this will never happen; they will "cease +to care" instead. In exchange, they will be able to make localized +changes without worrying about breaking the whole application. + + +# Fred George - The Secret Assumption of Agile + +:::: tags +- Agile +- OOP +- programming methods +- project management +- training +:::: + +Advice on when to refactor: + +- *after* design, *before* writing unit tests for the new stuff: + prepare ground for the addition to fit right in; + +- *after* implementing the new behaviour, *before* integrating. + +Goes over the usual code smells taught during the training he gives +(conditionals, getters & setters, class names ala "Manager", too many +instance variables) + +Mentions a requirement for training "retention": skills must be +applied within a month after receiving the training, otherwise the +rationale will be lost. + +Questions: + +- Does he know of open-source projects that showcase this style of + programming? + - Smalltalk, some NodeJS libraries + +- Does he rely on naming conventions? + - Quite a lot. |
