View Full Version : Code Development - What's the best way?

17 Feb 2007, 7:59 PM
I've spent most of my time programming unintentionally avoiding Object Oriented-based programming. More recently (over the past year) I've picked up the concepts and began to create my most efficient code. However a big weakness in my development is my lack of code planning. What I mean is, I'll sit down, put together a detailed feature list of what items I or my customer want in the software, and i'll program it. However I tend to run into issues about 1/3-2/3 way through the project where I just get lost in what I was doing. I lose track of specifically what needs to be programmed and when.

I've played with the idea of diagraming the actual classes/code segments to assist in what steps need to be taken in what order, but I wanted to hear what you guys do.

Is Diagraming your classes/code segments the best way to keep yourself organized during the programming stage? Or is there some more efficient and easier way to do it?

17 Feb 2007, 9:55 PM
Yeah, diagramming will help, as well as making a list of the order things need to be done in and when.

17 Feb 2007, 11:55 PM
I tend to break up all of the OO applications I write into the object tree that makes sense to me from the start. I try to take the approach of thinking about what the hierarchy will look like first. If I know I'll be subclassing due to having overlapping functionality, I'll try to fit that in up front.

For design, I pull apart my objects and lay them out into the properties and methods for the classes. I maintain 2 tables for each class. When I find the overlaps between base and subclasses, I'll roll the methods or events up into the parent class. If I find overlaps between classes with similar functionality at the same level, I'll base/sub class them with a new class.

When I finally get down to coding, I start with frameworks for everything. This goes back to my old Smalltalk days and then into my C++ days when it was important to maintain some sane level of definition/implementation. Then I just start filling in the blanks.

The challenge for OO Javascript, for me, is the scoping of objects. It's easy to forget to declare a globally scoped object in a function scope. Fortunately I don't really write a lot of object javascript. I'm more of a library consumer than anything. But that doesn't mean I don't have to know how it works. If you don't know how it works, it's really hard to understand what's wrong with your code when something goes wrong.

One thing that helps is to use a development environment that helps you keep track of where you are. I've been using Aptana lately for the stuff I've been writing and it's been useful. In the past I've wavered through Emacs, vi, Visual Slick Edit, Borland's environment, Microsoft's environment, the KDE environments, the Gnome environments, etc. They all have their strengths and weaknesses. The older I get the more prone I am to forgetting where I was the previous day. That's why one of my development criteria now is the ability to manage todo lists within the code. It allows me to setup where I was, what I was doing, and where I wanted to go. I also find 3rd party notetaking applications to be extremely useful, and I also go through trees worth of notebooks. I have a full 8 foot by 4 foot shelf filled with just engineering notebooks with ideas, designs, etc.

18 Feb 2007, 4:53 AM
Wow, thanks for the great feedback.

Dfen, that's exactly what I was searching for! I'm going to take a peek at some of those applications and see what they offer and such. I'm also going to implement some of the ideas you posted..... I'm open to anymore feedback anyone has to offer as well.

18 Feb 2007, 5:36 AM
I have found in my experience (10+ years OO Java/C++/C#) that laying out complex object diagrams up front leads to refactoring later. In general, there will always be things you miss no matter how well you plan. With JS and the web, it even worse because there are other things to consider.

The approach I have found to be most effective is "incremental refactoring". This means starting out with a basic idea of how your object model should look. It will probably be raw and imperfect, but you know that and knowing that is the key to what makes it work.

Start out small and make pieces of it work. While it's small (and not a big object model with all kinds of pieces to develop before you have anything working) you should be able to find various imperfections with you initial design (like browser problems!) and you can refactor while it's still cheap. As soon as you have something working, it's time to refactor to look for ways to make things more generic, cut code duplication, improve interfaces and efficiency. Then start on the next piece in the same way.

The most important thing is you have to think OO, think efficiency and know your patterns. Once this is in place, the rest is kind of automatic.

Hopefully this is semi-coherent. ;)

18 Feb 2007, 7:33 AM
The diagrams seem to be where I get hung up. When I diagram code, its normally diagramming the funtionality of the application, however it seems as though (from what you guys are saying) that I need to be diagramming the acctual objects. I will deffenitly have to try that, as I am also having much the same problem that webnet is having.

Thanks a lot! This topic is a great thing for us not-so-OO-programmers.

18 Feb 2007, 9:38 AM
I agree with what Jack said. Given my 20+ years of doing development, the design-code-test approach doesn't work. Use diagrams if it helps you visualize things, but don't get married to the idea that once you've diagrammed it, it's not going change.

Application development works best when you can take small incremental steps. Develop, test, refactor, as you go. Add stubs for objects/methods as you think of them. Put comments into the code when you do this to remind you of your thought process when you go back later to work on it some more.

Continually look for places to improve the code, not necessarily trying to improve performance (although that's important), but rather looking to extract reusable components, reduce dependancy between objects, simplify the API.

18 Feb 2007, 9:56 AM
The diagrams seem to be where I get hung up. When I diagram code, its normally diagramming the funtionality of the application, however it seems as though (from what you guys are saying) that I need to be diagramming the acctual objects. I will deffenitly have to try that, as I am also having much the same problem that webnet is having.

Thanks a lot! This topic is a great thing for us not-so-OO-programmers.
After you diagram the functionality, think of anything that can be grouped together under one name (object). The most common of course are everyday objects, but you'll of course find things such as helper classes that don't fit under the every day object being needed as well.

7 Mar 2007, 10:50 AM
For what it is worth - you might wish to invest about 30 bucks into a sheet of whiteboard and a sheet of backing board (like luan) at your local home center. Don't pay the massive bucks for a 'whiteboard' at Staples or their ilk.

I am totally uncomfortable when I don't have a whiteboard or blackboard handy and I am programming.

Use one area for a rough sketch of your current area of focus - never terribly detailed. Use this to quickly annotate points where you can 'hook' into for additional features should they jump to mind. Glance at this when you think you are starting to stray.

Use another area to quickly rough sketch code concepts, ordering of events - whatever you are having a rough time visualising at a more macro level. Use another for things like cementing naming conventions you are establishing. Finally - use another area for data constructs and scheming of current interest. NEVER underestimate the value of solid, intelligent data structuring!!!

Because you can fearlessly refresh your board quickly once older notes are part of your brain and well docced in your code, you don't spend a lot of time trying to page through notebooks and you have the 'at a glance' reminder.

This is what helps me the most. Maybe it will appeal to you or others as well.

7 Mar 2007, 12:38 PM
Diagrams should generally be used for 2 things:

- Visually planning or working through specific concepts that are complex
- Communicating such things to other developers easily

Generally diagrams should not be used as permanent fixtures or as deliverables that must stand the test of time. That never works as things will change as soon as you write any code. You should also never try to diagram out your entire app or object model just for the sake of doing it or because you think that's the "proper" approach. Diagrams are simply tools, just like UML in general -- they are extremely helpful when you need them to accomplish a task, but overusing them is almost worse than not using them at all.

8 Mar 2007, 5:53 AM
An XP approach is to: for each iteration, do the 'simplest possible thing that will work' and then refactor as required.

You must waste some time hyperlinking madly through here http://c2.com/cgi/wiki?ExtremeProgramming .... this site was where Wiki was invented :D