Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's not a hack to satisfy known requirements

charemza.name

Post reply on HN
Print view View original

31–40 of 60 posts

Re: It's not a hack to satisfy known requirements

#31

Post by MobiusHorizons »

crazygringo wrote: post #20
jfengel wrote: post #10

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…

> I find that strong typing often obviates the need for unit tests. Can you expand? Because my experience is they are totally orthogonal. For me, unit testing is to ensure the function's algorithm is correct. You verify add(2, 3) == 5 and add(1, 2, 3) == 6 and add(2, Null) == Null. But you don't generally write unit tests that tests how a function behaves when you pass an unexpected type. Nobody in my experience is t…

For certain classes of dynamically typed languages the unit test serves the function that a compiler or linter would perform just by running the code on any input to ensure it can run at all. Basically since these checks are runtime instead of compile time, you have to run the code to get even basic syntactical checking. I think ruby, python and JavaScript all used to use unit tests in this way. These days static analysis tooling is much more advanced and can provide much of the same benefit without running the code, but I think this is where the idea of 100% line coverage comes from.

Strong typing certainly doesn’t remove the need for testing, but it does change what type of issues you test for. And for certain classes of boring code that just transform or move data, a single integration test can give you all the assurance you need.

Re: It's not a hack to satisfy known requirements

#32

Post by chamomeal »

raincole wrote: post #28

> 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?

Re: It's not a hack to satisfy known requirements

#33

Post by RHSeeger »

Otek wrote: post #8
inerte wrote: post #6

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…

The question “what if it happens” is important but useless without “how likely is that to happen” and “if it will happen how much time we need to cover for it”

I tend to approach it a similar way...

- If we do it , will be impossible to implement (without a huge rewrite cost) later? If so then, if is a realistic possibility, consider is probably a poor choice

- If we do it , will be harder to implement, but not terribly so? If so, then weigh the cost/probability of doing it and it not being needed vs not doing it and it being needed

- If we do it , will not be any more cost to add then if we did it now? If so, then don't do it now. Because you're risking unneeded time for no benefit

Admittedly, all three of those are the same "equation", just the three ranges of where the numbers stand. But it's nice to specifically ask the first and third questions... because they can cut short the analysis.

Re: It's not a hack to satisfy known requirements

#34

Post by palata »

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 patterns and use them" risk writing bad code.

You should strive to write code that others can understand and maintain, period. 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.

Re: It's not a hack to satisfy known requirements

#35

Post by RHSeeger »

wredcoll wrote: post #11

It's all pretty solid except for the part about OO. Inheritance almost never works in "the real world" but I find being able to tie functions to the data they're expected to work on to be pretty helpful. It's sort of like typing, really, functionX can only take FooBar variables vs making methodX on class FooBar. Like everything else you can "do it wrong" and you shouldn't be a slave to any particular software ideolog…

> Inheritance almost never works in "the real world"

Inheritance works just fine in the real world. It's just not the only tool in the box, and many times other tools work better. But, especially when limited to shallow hierarchies, it's very useful.

Re: It's not a hack to satisfy known requirements

#36

Post by AndrewKemendo »

wouldbecouldbe wrote: post #7
AndrewKemendo wrote: post #5

> We're not here to write code, but to solve problems. In my opinion having had multiple technical job roles (car stereo/alarm installer, website builder, military officer, CEO, CTO etc…) this is always the job. The job is *always* to make the organization more effective and efficient full stop. Your role in that is what you choose and negotiate with your team throughout your life; boundaries change pre/during/post e…

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

Re: It's not a hack to satisfy known requirements

#37

Post by 1dom »

wredcoll wrote: post #11

It's all pretty solid except for the part about OO. Inheritance almost never works in "the real world" but I find being able to tie functions to the data they're expected to work on to be pretty helpful. It's sort of like typing, really, functionX can only take FooBar variables vs making methodX on class FooBar. Like everything else you can "do it wrong" and you shouldn't be a slave to any particular software ideolog…

I came to the comments to try find a similar sentiment. I agree wholeheartedly with the author on everything apart from the bit about OO, where I feel the same as you.

What's the deal with this? I'm not an OO evangelist at all, but I often find myself using objects like you describe: as a mechanism to group related functions and data.

I feel there are people who see OO like a philosophy on how to architect stuff, and from that perspective, the idea of a "purely OO system" is perhaps a little unwieldy.

But from the perspective of OO as a low level tool to help group stuff in programming, as part of some other non-pure-OO system - it works really well and makes a lot of sense for me. I've often done this in environments around people who are outspoken anti-OO who either haven't noticed or haven't complained.

Am I a bad person, are you like me, are we idiots somehow?

Re: It's not a hack to satisfy known requirements

#38

Post by prerok »

palata wrote: post #34

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…

Could not agree more.

It's perfectly ok to not use a software pattern if it's not useful. It's ok to duplicate code if you know it will likely diverge in the future. Small and simple is the way.

Re: It's not a hack to satisfy known requirements

#39

Post by daxfohl »

Its easy to mix up "what seems easier to work with" vs "what's actually easier to work with". Pulling things out to config, splitting into microservices, additional layer of abstraction, rules engines, etc., they seem like they'll be easier to work with at a high level because it gets logic out of the core, but then when you're actually working with them, or worse, when someone else is working with them and doesn't have your context, now there are five places to go look for logic and deciding which piece needs changed, instead of just one obvious place.

Re: It's not a hack to satisfy known requirements

#40

Post by RHSeeger »

crazygringo wrote: post #26

> 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.

Post reply on HN