diff options
Diffstat (limited to 'technical/reviews/talks.md')
| -rw-r--r-- | technical/reviews/talks.md | 81 |
1 files changed, 0 insertions, 81 deletions
diff --git a/technical/reviews/talks.md b/technical/reviews/talks.md deleted file mode 100644 index ed272c8..0000000 --- a/technical/reviews/talks.md +++ /dev/null @@ -1,81 +0,0 @@ -# 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. |
