3 ms·

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 a

by gHosts 7y ago

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!

kortex 7y ago
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)
- mpfundstein 7y ago
  How can his code pass code review?
faizshah 7y ago
> 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?
- gHosts 7y ago
  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 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.

by gHosts 7y ago

kortex 7y ago

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)

mpfundstein 7y ago
How can his code pass code review?

faizshah 7y ago

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

gHosts 7y ago
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 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.