Comments by "MrAbrazildo" (@MrAbrazildo) on "Clean Code is SLOW But REQUIRED? | Prime Reacts" video.

  1. 3:18, you (23:54) and Casey said something that I already knew: wait the need before abstracting. This is the right way to design: focused on the practical needs. And that means building abstractions for defensive proposes too - before somebody starts to advocate FP. 3:35, 1 of the basic optimizations made by the machine is to inline f()s. The only concern is about reaching a limit, after which it won't inline or starts extra calculations about it - but 1 can set it. The actual problem about helper f()s is the options for calling them by mistake, or to feel the need to memorize them, as options, when thinking about the whole thing. To avoid this extra stress, a class to hide them can help. But this starts to require more boilerplate. The best solution is writing lambdas (within the f(), of course), if those blocks are called more than once. Otherwise, I keep them inside the f(), as explicit code, if they only make sense there. 5:03, if 2 apps have a difference of ms for each action, people will feel better with the faster 1. So, it's not just for speed-critical projects: even the common ones can benefit. Meta said that "people feel more engaged when the app is faster" (probably about ms and above).
    5
  2. 6:00, yeah, choosing (what's likely to be) a correct data structure should be the starting point. And this is 1 of contiguous memory, like std::vector in C++. Because a mistake here will take too much refactoring later. On the other hand, algorithm is something that, even if is entirely wrong, 1 will has to change mostly inside 1 f(), not scattered parts throughout the project. 9:05, OO is so flexible, that 1 can inherit that class, and implement his version of some functionalities, not changing it. 10:29, I guess "Dave's Garage" (ex-MS) channel revealed who the guy was, in his series about this algorithm. 11:11, precisely. I made a small game that fit entirely in L1 cache (64 KB for the logic, not resources), after compressed in bits several variables. I spend less than 10% of developing time optimizing it, which led it to 30x faster. And even so, I wrote classes and abstractions (not interfaces) all over the place. It's maintainable, easy to catch bugs, even after not seen it in a while. And it's readable, due to enough abstractions. 25:20, there's a quote which says "Who works with a hammer tends to see the world as a nail" . He wants to say "use the right tool for the right job" .
    1