Language:
switch to room list switch to menu My folders
Go to page: First ... 33 34 35 36 [37] 38 39 40 41 ... Last
[#] Thu Sep 10 2009 22:27:19 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Now if people would only stop doing that. :-)

Which? The former, or the latter? ;)

[#] Thu Sep 10 2009 22:28:33 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

... Like Objective C. <snicker> :-)

Starting to sound like a broken record. huh? ;)

[#] Sun Sep 13 2009 07:39:17 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

But when you write testable code, you are writing exquisitely modular

code that makes very few assumptions about what it's interfacing with.


I must say that I've always been a fan of loosely coupled code. It's great to be able to say "let's generalize this and move it out to a library of utility code" and then use it over and over again.

And of course, like everything else, that can be overdone too ... like when you've got something that ended up with utility code that has a hideous API because you had to take into account anything that someone might want to do with it. (I still think it's worth it most of the time though.)

[#] Sun Sep 13 2009 08:23:45 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Now if people would only stop doing that. :-)

Which? The former, or the latter? ;)

The latter.
generalized uncoupled code sounds great but all it does it make layers of crap where no one thing does exactly what you wanted, but it sure does do a whole bunch of things you'll never need it to.

Pete wrote a beautifully perfect pop server in C++. It was as near to perfect as you're going to get. he implemented the protocol in an abstract base class and subclassed an implementation for our data store.
The only thing imperfect about it came from me: I had to butcher the separateness between parent and child to handle some really goofy failure-recovery mode.
And while this now made impossible to ever again use this class to implement another pop3 server, the fact is IT NEVER HAPPENED.
Which is my point about all this. On paper and in class this all sounds and looks beautiful, but I;ve been doing this long enough to notice the pattern:
systems go away/get replaced/new operating environments arrive before you ever have a second use for any of that beautifully generic code you wrote.
So suck it up, write just what you need, becuase that's all it's ever going to be used for. And in trade, you'll get free speed.

[#] Sun Sep 13 2009 08:24:12 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Starting to sound like a broken record. huh? ;)

My record isn't hte only thing that's broken.

[#] Sun Sep 13 2009 08:29:10 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

and more speed will put off buying more/faster hardware which is real money which really matters.

[#] Sun Sep 13 2009 11:10:43 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I'm not a fan of making up requirements out of thin air and saying "ok, some day in the year 2100, the code might have to do something else, so we need to decouple this from that." I am a fan of taking the quick and dirty procedural code that I'd be writing anyway, and simply packaging it up as an object, and making it possible to subclass, at minimum, the datastore dependencies. All those datastore calls HAVE to be indirected through a vtable (or function pointers if you are some sort of retro-grouch who can't get with the program and learn from everyone else's experience) or your unit test performance is going to suck so hard that the tests are prohibitively slow to run.

And that definitely buys you some modularity essentially for free, and forces you to commit to a design pattern where all your data queries are isolated, one-per-method, so that you have some prayer they can be reused.

[#] Sun Sep 13 2009 11:26:50 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

And while this now made impossible to ever again use this class to
implement another pop3 server, the fact is IT NEVER HAPPENED.

Ok, but you are still missing the point: it's 2009, not 1965. You must abstract your data store.

pete did the right thing, and you might not have butchered it as bad as you think. Basically, it needs to remain possible to substitute that concrete datastore implementation with a mock implementation. It's really totally necessary because otherwise your tests take 24 hours to run because of cyclomatic complexity. And although Pete may have missed some detail that caused you to have to butcher it, or maybe a parent/subclass relationship wasn't the best design pattern for your particular problem, the fundamentals are sound. And it sounds like even though your base class is no longer general, you still have the ability to mock your subclass and that's what really matters in 2009 when any day now your upper management might decree: "developers, you must start practicing test-driven development immediately!" If you didn't design your code so it could accomodate that eventuality, you'll be hurting when it comes to pass and you have to rewrite everything.

[#] Sun Sep 13 2009 19:15:51 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

So suck it up, write just what you need, becuase that's all it's ever

going to be used for. And in trade, you'll get free speed.

In my (very limited compared to you professional devs) experience, it has instead been "hey, we use this same code in three different programs; let's modularize it and put it in a library so we don't have to maintain multiple copies."

[#] Mon Sep 14 2009 07:27:20 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

yes wholeheartedly agree there. If you ever find yourself copying code you're doin something wrong. There wa a guy who used to work at my job....

but to ls's point: makes sense, good plan. I modularize mt data store accessin functions but just to make things neat and tidy.
If I lived in a world of test programs there's no question your way is THE way.
I guess what happens is that I've never had to write a test harness, not once in my life.
It always seemed a waste of time to me. (again becuase there's almost never any future use)
So you ask, how do you test your applications? I'm sure weve been over this before. I use a debugger and trace through every line and every condition both ways.
This may seem miserable, but I'm a control freak and I HAVE to see it working anyway, and it's not as slow as it sounds.
I'll admin the horrid downside: I have no way of regression testing. And that's where my scheme falls apart badly. And I have gotten burned a few times. But the trade off seems to have been worth it because although I sometimes have to go back and fix bugs that the customer found that my non exsistant test harness did not, I haven't spent years writing test harnesses that would have ended up being a wast eof time.

So I suppose with that perspective, I'm better off time-use wise because i never write anything Idon't have to, but more bugs get out that way.
Although it's not like test harnessess catch everythin either...

[#] Mon Sep 14 2009 07:49:54 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

oh, there IS use for tests in future.

Imagine a lower layer has to be altered due to findings of profiling...

You probably will find much more acceptance in management for your changes if a big and thorough unit testing suite can prove the new code still does the same as the old.

I'm in the situation over here where you have to fight these obstacles first.



[#] Mon Sep 14 2009 09:53:12 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

It also comes down to your job.
Me and the 2-3 other senior developers is turns out are the most technical people in the company. Nobody questions our judgement. If we cared enough to band together to force an issue, I'm pretty sure we could make just about anything happen.

[#] Mon Sep 14 2009 10:41:03 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Then you should band together and tell them that you need Aeron chairs! And a pony!

[#] Mon Sep 14 2009 12:26:23 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

If I lived in a world of test programs there's no question your way

is THE way.

How long before some "self-important auditor" makes you do it? Apparently some people here are under the belief that JSOX (Japan's version of Sarbanes-Oxley, to which we are bound as a public Japanese firm) enforces automated testing as an I.T. requirement.

[#] Mon Sep 14 2009 12:33:18 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

So you ask, how do you test your applications? I'm sure weve been
over this before. I use a debugger and trace through every line and
every condition both ways.

So you have to find a way to trigger every branch both ways. Right, that's basically what unit testing coupled with test coverage analysis is enforcing. The test coverage analysis gives you that pretty little HTML page that tells you whether all the branches on each line have been exercised, or not. (Note, there is a difference between line coverage and branch coverage...)

And I might add that if you are doing what you say you're doing, your development practice is 10x more rigorous than 90% of the developers I've ever met, (a lot of them work for us, and could not be bothered to do that level of testing.)

So all this is about, is writing a harness to test all of those branches that you're already testing manually - it'll probably take about the same amount of time as what you're doing now to do the initial implementation, ***and then you can re-run the whole suite every time you modify the smallest, most trivial little thing***, which is rather liberating, but only if the initial effort was made to achieve good coverage at least for most of the "M" and "C" layers of MVC. (Actually you can almost ignore unit-testing the "M"odel layer if it mostly just deals with persistence. With today's development tools, persistence is something that sould mostly Just Work(tm).)

[#] Mon Sep 14 2009 12:34:34 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Me and the 2-3 other senior developers is turns out are the most
technical people in the company. Nobody questions our judgement. If we

cared enough to band together to force an issue, I'm pretty sure we
could make just about anything happen.

Wait, you don't work for the phone company anymore, now do you. ;)

[#] Mon Sep 14 2009 12:36:09 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

So I suppose with that perspective, I'm better off time-use wise
because i never write anything Idon't have to, but more bugs get out
that way.

This is a classic bandwidth/latency tradeoff. You're optimizing your own bandwidth, full stop.

[#] Mon Sep 14 2009 13:33:29 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


and don't get the wrong idea either. it's hard to implement test driven development without management buy-in. developers know that the extra testing means extra work which means longer estimates against deadline pressure. management has to be convinced that those longer initial estimates will be made up for with fewer revision cycles. they need to drink the kool-aid. as soon as you start getting ETA pushback, I can see developers just abandoning TDD. tricky.

[#] Mon Sep 14 2009 13:45:05 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Wait, you don't work for the phone company anymore, now do you. ;)

No. Not at all. Quite the opposite. I was rather surprised how far the other way you can go, when I got here.
People were just copying shit in and out of production willy nilly, without a second thought.
There's one guy still resistant to the idea of telling the sysadmins that he's changing things in production.

[#] Mon Sep 14 2009 13:46:35 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

How long before some "self-important auditor" makes you do it?

Well we got so screwed last year by our pci auditor, that the guy got pushed aside. I don't think he got fired but he's not auditing anymore.
We spent a ton of money and time becomeing a whole lot more 'compliant' that I think they dare not ask us for anything any time soon.

That's just pci. We don't have any other auditors that I know of. And after that episode I think we're going to design our product line around avoiding auditors.

Go to page: First ... 33 34 35 36 [37] 38 39 40 41 ... Last