When working on large projects there are a couple of items that will really help you stay on top of things and stay on time.

Don’t use frameworks unless you need to

A lot of times projects don’t need frameworks.  Sometimes you will make your project and your life a whole lot simpler if you don’t use these.  That’s not to say that you should not ever use them.  There is a time and a place.  It’s called over-architecting (it is now) and you can be the criminal or the victim.  It’s really bad when a programmer hands you some code and you know it didn’t need to be this way.

Don’t use a framework unless your confident with it

That’s not to say that you shouldn’t practice with other frameworks… Just do it with projects that don’t involve tons of money and resources.  If you write crappy code that no one can understand, or worse, you chose the wrong framework for the job, or WORST you are using the framework completely wrong, what is anyone supposed to do?  They will probably wind up complaining about you.  Probably behind your back.  You’ll look like a damn fool.

Set up a repository (even if your the only programmer on the project)

SVN or CVS are awesome for merging your code and keeping yourself and other programmers sane.  You can set up your SVN server all by yourself if you have a crappy computer laying around.  It’s supposed to take 30 minutes.. but the first time I set one up it took me 3 hours.

It’s a really good idea even if you are working hans solo.  1. you can always revert your code to a previous working version if you really screw something up.  2. You can work on a major huge scary sections separately and merge it with your main code later (see branch). 3.It’s always good to have a backup. 4. you can pause and make a version available while continuing to work. having 2 versions or many more. And then when an interviewer says “do you know about repositories?” you won’t have to say “did you say suppository?”

Make use of bug tracking systems

You can’t write perfect code the first time… Because no one does. Well, cept for me.

I personally enjoy bugzilla for bug tracking.  Github takes care of a lot of bug tracking.  Which brings me to my next point.

Make sure it’s tested (over and over and over)

Obviously.  If this is a major project with major resources, sometimes a mr. big company won’t think you need people to test the app.  He thinks he can test it himself (which is a great idea…. gag reflex()) so don’t let the big cheese be the tester. Later when it’s done… then he can test it. People get paid to find your bugs.  Then you can spend more time writing brilliant code.

Use some form of modularization

If your whole project loads all at one time theres a good chance that um well, you know… So besides modules, you can also use viewstack . The viewstack will load only what is currently in view.  Which is good because if the user never gets to the 100th page of your ginormous picture gallery then only page 1-49 (or whatever page they made it to) will  load which means it will never use precious resources for pages 50-100. PS. I am not suggesting you make a picture gallery with the viewstack…

Remove Event Listeners when your done with them

No nevermind leave them all in…  Never remove any event listeners and see what happens.

It’s a common interview question: “how do you prevent memory leaks?” The next point is (one of) the million dollar answer(s).

Use weak references in event listeners

This is ok:

myFastOOPCar.addEventListener(MouseEvent.CLICK,carGo);

This is better:

myFastOOPCar.addEventListener(MouseEvent.CLICK,carGo,false,0,true);

It’s that last true that we are looking at.  It means that if myFastOOPCar's reference is sudden gone.. if the car is gone then the event listener will be in better shape to be picked up by the GC.  And contrary to popular belief it does not cause random problems everywhere.  If this is a big project with a lot of event listeners you need to clean up after yourself.

Any more suggestions welcome.

Here are 2 good principles to follow all the time:

Program to an interface, not an implementation

Favor object composition over class inheritance.

I need to explain that more but it is certainly googlable.

42