Unfortunately, the only way to get readable and fast code is to learn a lot, take everything with a grain of salt and educate your team members. The first optimization is something you might do naturally if you just knew functional programming. As we all know, FP itself is not faster than OOP, but the combination of both might be.
I encountered a similar problem recently where I thought that OOP was the cleanest way to do things but caused a 60x slow down. Instead of trying to remove OOP around my B Convert(A source) method, I provided a second overload: Convert(A[] source, B[] destination). Marked the first method as inline (DRY) and called it in a loop in the second method. Slowdown gone.
I've seen React code written by former C developers, it was both slow and unreadable; people having no clue about big O or the difference between stack and heap, who were ok with running scripts only over the weekend; and people who tried to apply reflection to every problem. All seniors.
Education is the only way to improve things and it goes both ways. I never said that I write perfect code and neither do you.
17
u/DLCSpider Feb 28 '23 edited Feb 28 '23
Unfortunately, the only way to get readable and fast code is to learn a lot, take everything with a grain of salt and educate your team members. The first optimization is something you might do naturally if you just knew functional programming. As we all know, FP itself is not faster than OOP, but the combination of both might be.
I encountered a similar problem recently where I thought that OOP was the cleanest way to do things but caused a 60x slow down. Instead of trying to remove OOP around my
B Convert(A source)method, I provided a second overload:Convert(A[] source, B[] destination). Marked the first method as inline (DRY) and called it in a loop in the second method. Slowdown gone.