Hacker News Reader

Hacker News

Comment by gHosts | Hacker News Reader

Full thread

gHosts

Start at the bottom, make your bottom layers solid first.

You can't reliably deduced anything about what your current problem is, if the things it depends on are flaky.

Design by Contract. Understand it. Used it. Turn your asserts on always.

Turn on all warnings that don't give false positives that your compiler / tools provide.

Fix them don't mute them.

Run around your code base and find every damn place where some damn fool has discarded an error code and check and report all failures.

You'd be flabberghasted by how many "it's impossible" bugs I have found and fixed by that one simple action alone!

View on HN

My coworker is a fan of:

  try: 
    something() # that throws nonfatal errors frequently
  except:
    pass

"it saves time in development" they say. Good luck if something in that (non trivial) function call breaks.

Ugh.

Don't be like that.

If you don't know the precise error, heres the solution (in python):

  except Exception as exc:
    log("{}: {}".format(type(exc).__name__, exc))

Bingo, you now know what to catch. Catch that error, move your broad exception down (or remove if you can)

How can his code pass code review?

> You can't reliably deduced anything about what your current problem is, if the things it depends on are flaky.

Interesting, as a junior dev I always start thinking about the fun architecture stuff first and end up being slow to complete a project. I figure that deploying one place vs another is so different you want to deploy early and often for testing. Maybe I should just start getting the basic functionality and tests down before packing it up into docker containers and running it on kubernetes and all that?

You need to start from both ends...

TDD to get the chunks of functionality you add rock solid..

A Walking Skeleton to guide your vision of where you're going... https://wiki.c2.com/?WalkingSkeleton

Each part you add must be rock solid before you move on to the next that depends on it.

That doesn't mean you have to do everything... merely make it solid and reliable.

Say you plan to depend on a subsystem that is going to do something wonderful and flashy.... but you don't need it right now, you just need to build the place where it's going slot in....

Then don't put your sketch of the wonderful shiny thing into your dependency tree, put a mock that might do nothing, but does nothing utterly reliably.

If you have something flaky firing bullshit events and rubbish into your whole system while you're trying to get the rest going... you're just going to hurt yourself.

You can add a feature toggle or chicken bit to switch the new shiny/flaky stuff in when you want to contemplate it, and switch it out when you're working on the rest of the stuff.

Reply on news.ycombinator.com