Kurt, I completely agree. After reading the whole article, I find that
his argument that large codebases are /inherently/ bad is a weak one.
I'd like to comment on two of his major points: a) Large codebases are
*unmanageable*, even by IDEs and b) Large codebases are *hard to learn*,
remember, maintain, and extend. Steve is pushing a very good concept
here: Parsimony (extreme frugality). It is one of the 17 rules of Unix
Philosophy
(http://software-quality.blogspot.com/2005/12/basics-of-unix-philosophy.html).
However, it seems like he is missing some key design patterns as you
mention, Kurt.
a) Large codebases don't need to be unmanageable. They should be
composed of lots of small codebases--tool kits, frameworks,
sub-applications and what not. The trick is to make each part a simple
/part/. The whole may be complex, but enhancing a modular codebase will
require additions of and changes to a small number of simple parts.
Loading huge codebases into Eclipse is silly; load a small portion of
the codebase instead.
b) Large codebases don't need to be hard to learn. A good codebase will
have searchable documentation that is auto generated. It should require
learning a small subset of the modules and functions by eliminating the
need to manage low-level operations and following the principle of least
surprise. Consider a database connector. The main things developers
need to learn are functions like connect(), query(), beginTransaction(),
rollbackTransaction() and commitTransaction(). It is easy to remember
because the method names are intuitive. The database connector probably
has dozens or even hundreds of files to manage drivers, connections and
compatibility, but editing those files is unnecessary--the database
connector can be a separate module that never is loaded into Eclipse at all.
- Ken Snyder
Kurt Griffiths wrote:
If you are trying to reduce the size of your code base and switching
languages simply isn't an option (for one reason or another), there are
several other areas you can focus on that can really help:
1. DRY
2. Relying on operating system services/libraries
3. Using 3rd-party components
4. Using code generation and/or an embedded scripting language
5. Supporting plug-ins and templates
6. Choosing smart DAL and UI frameworks that don't require a lot of
boilerplate code
On Dec 19, 2007 10:44 AM, Nathan Blackham <[EMAIL PROTECTED]> wrote:
This article was mentioned in the IRC channel. Remember that he is
describing a problem that can exist in any language. He isn't bashing a
given language other than to get his point across. I am not a big
programmer, but I can understand his argument and is something I think
every
programmer should look at and examine if they fall into the big code base
trap.
Without futher ado:
http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html
Later,
Nathan
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
