7/10 are interactive advertising, which means that I have usually 2
weeks(at
best) to do something that doesn't relate and never had the time to make
me
own framework.
Has it occurred to you that if you built a class and got in the habit of
using it, it would take exactly the same amount of time and have 10x the
flexibility of your "faster" way? See, the whole idea of an "architecture"
is to not have to redesign it for every app; you resuse it every time so
that once it's there, you can use that codebase to build anything you want.
All this talk about "real" programmers and "theorycoders" is pretty
laughable. I especially like the part about using OOP techniques as "job
security" so that they can't bring anyone else in to read your code, when
that's actually pretty much the opposite of the reality of the situation:
any *competent* programmer could understand it, and your problems with these
methodologies speak more about you than your breadth of "experience".
I routinely have Java and C# programmers do code reviews on my AS2 code.
You know how that's possible? I use OOP techniques, so that it is apparent
what the code is doing even though the guy doing the review doesn't
understant the specific of the APIs I'm accessing. They don't need to know
specifically why these APIs work the way they do, all they need to do is
read my inline comments and look at the code changes, and it is immediately
apparent to them what was changed and why. Any of those guys could replace
me with a bit of time spent learning the APIs, the syntax is essentially the
same and my codebase is clean and well documented, so it would be easy for
anyone with any experience to take over it with a minimal learning curve.
It's true, designing interactive banner ads generally does not require
these lengths, but neither do banner ads usually require maintenance, so
what difference does it make? If you build one-off, deliver-it-and-forget-it
Flash work, good for you, your "coding style" is irrelevant, both to you and
to the rest of the world, because no one will ever have to look at it again.
For those of us who do actually have to revisit and maintain code, and who
sometimes inherit large codebases, these things are not only important, they
are essential.
I'll just close with a great quote from earlier in the thread:
'Not understanding why something is done in a particular way does not make
it "lame".'
ryanm
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
