4 ms·
> In my experience, code with too many functions is more difficult to grok than spaghetti code. In a way, it kind of _is_ spaghetti code. Even if there's no ba
by nx7487 6y ago
> In my experience, code with too many functions is more difficult to grok than spaghetti code.
In a way, it kind of _is_ spaghetti code. Even if there's no back references, it turns a single train of thought into a string of entrances and exits.
- agallant 6y agoThe best label I've heard for the excessive layers anti-pattern is "lasagna code."
- UK-Al05 6y agoLasagna code isn't meant to be derogatory, just a description.
- agallant 6y agohttps://wiki.c2.com/?LasagnaCode https://wiki.c2.com/?LasagnaCode https://en.wikipedia.org/wiki/Spaghetti_code#Lasagna_code https://en.wikipedia.org/wiki/Spaghetti_code#Lasagna_code https://matthiasnoback.nl/2018/02/lasagna-code-too-many-layers/ https://matthiasnoback.nl/2018/02/lasagna-code-too-many-laye... https://dev.to/mortoray/what-is-your-tale-of-lasagne-code-code-with-too-many-layers-3lp2 https://dev.to/mortoray/what-is-your-tale-of-lasagne-code-co... Generally used with a negative connotation. C2 also discusses how the layers can become entangled/stuck with one another and difficult to replace, which seems to fit the metaphor. For describing layered code in a non-negative fashion, just saying "layered (or "modular") seems most typical.
- u801e 6y ago"Lasagna code" might be a better term.
- pineconewarrior 6y agoIt's easy to say ugh, but we juniors are more than willing to learn "the right way". This is the hardest part for me. I get anxiety about it and it slows me down. How do I apply this to taking over someone else's 4 year old Magento project? We're out here doing our best, and sometimes our learning environments are in that context.
- hutzlibu 6y ago"the right way" I would say, don't stress about it too much. There is no perfect way. Everyone makes misstakes. And about when to make abstractions and when not, is mostly about experience. There are modules worth optimizing and abstracting. And others are not. You definitely will make wrong decisions about it and later found out, this optimisation was a waste of time, or that quick and dirty approach really cost you much later on, we all did that and still do. Much worse than making a wrong (design) decision is making no decision at all - because mostly you have to decide for something and then just go with it. Overthinking things seldom helps. What helps me sometimes is, putting a special hard problem to the side if I am stuck and solve something easier first. Then after some time, when I get back to it, things are much more clear. But I also wasted too much time thinking about the right approach in a neverending, neverprogressing loop to achieve perfection. Now my question is not, is it perfect or shiny, but: Is it good enough? What matters is, that shit gets done in a way that works.
- laudable-logic 6y ago> wasted too much time thinking about the right approach in a neverending, neverprogressing loop to achieve perfection A CEO from my past often muttered that "perfect software comes at infinite cost". It's key, imo, to identify which components of what you are building _must_ be perfect. The rest can have warts.
- hutzlibu 6y ago"to identify which components of what you are building _must_ be perfect" Well, but by the words of your former CEO (and my opinion) those parts would then have infinite costs, too... if they really need to be perfect. I mean, it is awesome, when you do a big feature change and it all just runs smooth without problems, because your design was well thought out, but you cannot think of every future change to come - and when you still try, chances are you get stuck and waste your time and risk the flow of the whole project. I rather tend to think about the current needs first and the immediate future second, but everything after that, I spend not much thought anymore.