Re: First Project Advice
- From: "Larry Maturo" <lmaturo@xxxxxxxxxx>
- Date: Thu, 30 Mar 2006 10:12:09 -0600
Hear, hear!
I couldn't agree more. Those are all good books.
-- Larry Maturo
"John Jacobson" <jake@j[nospam]snewsreader.com> wrote in message
news:442b5864$1@xxxxxxxxxxxxxxxxxxxxxxxxx
Robin <Robin@.com> wrote in message <442b095d$1@xxxxxxxxxxxxxxxxxxxxxx>
So my questions are: Where do I start? What should I do?
In my career (as opposed to my hobby programming at home) I have been
involved
in a good number of successful software development cycles, and full
commercial
product cycles, so perhaps my point of view might be relevant here.
Stranger
things have been known to happen.
I'd recommend picking up a few books:
"Design Patterns" by a group of four programmers often called the "Gang of
Four". Erich Gamma is one of them, in case you want to do a search on
Amazon.com. This book is great because it will get you thinking about high
level design and architecture, not just coding. It is the point of view in
this
book that is so great, not just the patterns themselves. Most experienced
programmers already find that they have been applying these patterns just
not
in a formal manner.
"Agile Modeling" by Scott Ambler. This book is a good inoculation against
the
myth that design must be done in a linear, top-down fashion with formal
processes and methodologies that are all spelled out and designed ahead of
time. The best software development process involves concurrent tight
iterations. The longer the gap between your initial design and your
deployment
of something to the user, the more awry the whole process will go.
"Code Complete" by Steve McConnell. The Bible of coding standards, best
practices, etc. Full of excellent advice.
Do I need a
VCS?
Yes, I would recommend using the open source Jedi VCS, which used to be
called
FreeVCS. I use that in my newsreader project, which is an at-home
spare-time
type of software project.
How much detail in documentation? What /kind/ of documentation?
When it comes to the manual, that totally depends on your users. When it
comes
to code, you ought to document every deviation from the norm or
complicated
process. Also, anything that takes more than a screenful of code ought to
be
explained. Personally, I'd recommend learning UML and using something like
UMLExplorer to diagram your important processes, but you may find paper
and
pen to be better for you, at least at first.
Finally, it is important that you realize that until you've done it a few
times, your first major software projects will be done wrong. Later on
when you
look back on the design and the code you'll be wondering what the hell you
were
thinking when you wrote it. The key to becoming a great software developer
is
not to make as few mistakes as possible, but to make mistakes as fast as
you
can, admit them, and then correct them as fast as you can. After a while,
the
vast majority of this error commission, admission, and repair process will
occur all within the early stages of your software development. (In this
way,
software development is actually very much a learning process. Those who
think
they'll produce superb software simply through very careful planning are
almost
never successful.)
--
***Free Your Mind***
Posted with JSNewsreader Preview 0.9.4.2208
.
- References:
- First Project Advice
- From: Robin
- Re: First Project Advice
- From: John Jacobson
- First Project Advice
- Prev by Date: Re: What this mean for Borland?
- Next by Date: Re: What this mean for Borland?
- Previous by thread: Re: First Project Advice
- Next by thread: Re: First Project Advice
- Index(es):
Relevant Pages
|
