Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
IntrusionCM326442dThat's the spirit.
Root6705442dI agree to all but your optimizations point. I’m tired of halfassed approaches and bloatware. Build things right, even if it’s more involved. Just build it cleanly so another dev can understand and maintain it.
I come to a similar conclusion by a different route.
I'm more of the opinion that if your code is highly provable, it will naturally be readable, testable and performant. Provable code eats its own dogfood all the way down.
I disagree on perf though. I sat in a room once with a director who looked me in the eye and said, "well, it's only 20ms." To which I could only reply, "it's 20ms on every request, between one and 3 times. At our load, we will be dedicating 3 clock days to this computation every month."
@SortOfTested Yes, I get your point “per request”. But I was talking more generally. The most used requests should be optimized the most. Or have some kind of “bulk” api.
We won 10% of execution time just by caching login infos (The token, not the password hien). In this case the challenge was to not forget to reset the cache when necessary.
fzammetti59042dJust be careful that the one-line solution isn't overly clever and terse. There's a real push for terseness in code these days and as long as I've done this I know that's counterproductive in the long-term. Use more than one line of code if that makes the code more readable - and it frequently does! The trick is that each line should be RIDICULOUSLY simple on its own. I'll take 10 painfully simple lines instead of one super-duper, ultra-cool line (but, granted, there's a nebulous line you shouldn't cross, and certainly 500 versus 1 line sounds about like where that line is).