51–60 of 60 posts
I find that strong typing often obviates the need for unit tests. Software breaks when data transforms in a way that typing can't solve. When data goes across a wire, or into a database, it leaves your space. Anything you do to your code risks breaking it. Integration tests solve that, but at a very high cost. I don't have a great solution for that. It just comes down to experience: how do things change over time? Yo…
> One of the worst pieces of advice that I ever received was that every function should be unit tested. Obviously not every function should be -- many are so obvious and straightforward that there's nothing to test -- but every function that does anything vaguely "algorithmic" should be. Unit testing is really important for catching logic errors. > Instead, write higher level tests close to the client/user facing beh…
> Yes, these are good. But they're a different kind of test. There are tests for correctness, and tests that the program runs. You need both. Why do you need both? Some software is so small and simple that it's possible to write a high level running/integration test that covers all the practical correctness tests that application might need too. You can say "yeah, but they'd be better if they had unit test" but that'…
Sure, you don't need unit tests if you don't need unit tests because a program really is that simple. But that's an exception for tiny programs/modules, not the rule.
> eventually you reach a place where more tests, even those recommended as best practice, don't actually deliver any more _real world_ value
I explicitly said unit tests are for algorithmic code that can have logic errors. Obviously, if you've written tests for all those, you don't need any more.
> and even make the code harder and slower to maintain.
But you can trust the code is correct. Obviously this is the tradeoff, and for anything serious it's the right tradeoff.
You seem to be arguing against tests generally except for the most superficial ones. That's a recipe for buggy and often hard-to-understand, underspecified code.
> One of the worst pieces of advice that I ever received was that every function should be unit tested. Obviously not every function should be -- many are so obvious and straightforward that there's nothing to test -- but every function that does anything vaguely "algorithmic" should be. Unit testing is really important for catching logic errors. > Instead, write higher level tests close to the client/user facing beh…
> Yes, these are good. But they're a different kind of test I've had this exact same discussion with people before. The same people that say "unit tests are worthless because the implementation could change, then the test gets thrown away". Honestly, it drives me bonkers because that entire argument makes no sense to me.
It's as banal as saying that when you change a function definition, you have to go change all the places that call it. What do you expect?
I am amazed by the number of articles like this, that essentially say "you should not write bad code, you should write good code", while somehow implying "listen to me, I know better " (otherwise I wouldn't write the article...). The truth is that writing good code takes experience. Those who live by the rule "thou shalt not over-engineer" risk writing bad code. Those who live by the rule "thou shalt know all the pat…
> . If you need to justify your lack of "something" ("It's not a hack because..." or "I don't use OOP because..." or "I duplicated this code because..."), then it feels like it says something about your opinion of your own code, IMHO. I feel this sort of opinion is simplistic. "Explaining" is a need that is sparked by both sides. Just because someone is having doubts or questioning your work that doesn't mean they ar…
I was more refering to the need to write an article explaining why you think it's (not) always a mistake to do X.
> Just because someone is having doubts or questioning your work that doesn't mean they are automatically right
Of course not. Some discussions are constructive. And ideally one learns to recognise them with experience.
Now if you find yourself in a debate about styling or whether object-oriented programming is fundamentally bad, my opinion is that this is not a debate worth having. If it blocks PRs, then there is a problem, and someone higher in the hierarchy needs to solve it (because if there is the problem in the first place, it means that the team cannot solve it themselves). This is what hierarchy is for.
> Avoid Object-Oriented Programming Yeah, no. Every time I saw code written by someone who attempted to avoid OOP it ended up with passing a huge 'context' parameter to most functions, effectively reinventing Python's OOP but worse. Use pure functions as the starting point, but when you find yourself start passing complex structure around (any abstract word in parameter names, like 'context', 'data', 'fields' is a si…
I think of context parameters being a replacement for dependency injection. What parts of OOP are replaced by context params? State?
I think it can be all of these things, which in my opinion partially undermines the GP's point.
Recommended related musings: https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent
Earlier quoted context omitted.
i've been beating the drum for a long time that we teach OO programming wrong. we always start with inheritance (Car is subtype of Vehicle; Cat is subtype of Animal). we need to teach encapsulation as the primary use for OO. ime, the most effective way of using "OO" in practice is that you define data classes for different entities and then affix a few fancy constructors that let you build entities out of other entit…
This is my experience as well. I use encapsulation so often that to me it seems that that's the "point" of OOP, whereas inheritance I use extremely rarely.
Earlier quoted context omitted.
> Yes, these are good. But they're a different kind of test. There are tests for correctness, and tests that the program runs. You need both. Why do you need both? Some software is so small and simple that it's possible to write a high level running/integration test that covers all the practical correctness tests that application might need too. You can say "yeah, but they'd be better if they had unit test" but that'…
> Why do you need both? Sure, you don't need unit tests if you don't need unit tests because a program really is that simple. But that's an exception for tiny programs/modules, not the rule. > eventually you reach a place where more tests, even those recommended as best practice, don't actually deliver any more _real world_ value I explicitly said unit tests are for algorithmic code that can have logic errors. Obviou…
I have an engineer on my team that's always asking "what if this or that happens in the future?" to which I've started to reply "what if it does NOT?" I know, I know... wow. Not much insightful. But for some reason with this particular engineer this is the starting point to talk about actual requirements. This question in particular triggers the conversation of going back to product to figure out what they truly know…
Architectural decisions sometimes close doors and making future changes very difficult.
The only thing we know for certain is that change will happen.
Earlier quoted context omitted.
In most companies your job is to solve tickets. And the only creative freedom a developer has is how that ticket is solved. Quick fix, properly done, rework etc. Maybe that’s why certain smart developers over engineer, because that’s the only place they can create ownership
As long as you think like this then you’ll always stay in that niche
But I worked for a long time as a freelancer in big name corporates in the Netherlands and other large software companies. And that’s just how it is everywhere. Also in house senior devs have little to say. Hope other companies/countries are different
This is a great article, and I largely agree but I feel like we're giving ourselves an excuse to be lazy. Because I've absolutely seen this principle swing in the opposite direction, where someone writes slop code, without ever having had a real conversation with the end user(s) and consequently the software goes out the door without having considered top 5 most common edge cases that would have been so obvious if a…
In fact, it’s crossing my mind that people might not want to be accused of being lazy, and that is a motivation to over-engineer solutions.