Hacker News Reader

Comment by dstick | Hacker News Reader

Thanks! It's a familiar read. These days I prefer the pragmatic approach.

- Test features, not units (the time spent vs time saved is meh). So when something breaks, you can take it from there. Start digging.

- Build features

- Fix bugs by first writing a test, and then getting green

- Never go over-fancy with inheritance and whatnot. Readable longer functions are preferred over smaller once that break up the logic. Keep the poor soul in mind that has to go through your code in 3 years time. That could be you yourself ;-)

- Comment the "why"

That's it really. For web applications. Seems to work perfectly well for a code base that's over 10 years old and has seen many a developer come and go. Yes there's a bunch of legacy, but not a single part of it that's hard to reverse engineer with some effort.

View on HN

Closely related to tests are monitoring the production environment. Every time there was an incident and it wasn't visible at the source (whether it was found due to customers complaining or conversion rates dropping), no matter how unlikely it seems for it to happen again (we made a unit test so we should be safe now, right?), always monitor for it.

This might be my ops side speaking, but often undesired behavior aren't outright bugs (a value not being set is expected, but that empty value led to an empty template which led to the frontend framework not reading an event might not be), the same class of issues can be monitored for. This is a combination of logging and monitoring, of both events (where the application checks for unexpected results) and of state (where something external to the application reacts to for example things like active users without login sessions).

> Keep the poor soul in mind that has to go through your code in 3 years time. That could be you yourself ;-)

Isn't that why people move company every few years :D

Complaining about crap legacy code is easier when it hasn't got your name at the top

> Test features, not units (the time spent vs time saved is meh).

Might I add that testing for security should be a priority. Some agile shops move so fast because they aren’t worried about small bugs. All security issues are bugs and often they are ones that aren’t along normal feature usage.

> Never go over-fancy with inheritance and whatnot.

So much this.

Personally, I've grown to prefer object composition for bucketing and sharing reusable functionality across classes over the years. Testing with mocks becomes far easier, and it really seems to simplify the mental model.

Nowadays, I only use inheritance when working with generics and generalizable interfaces.

Well said, I'm a big fan of the pragmatic approach as well. But, for some reason we (people generally, including myself often) need to overcomplicate.

Reply on news.ycombinator.com