Portal Home > Knowledgebase > Articles Database > Any rules of thumb in development to prevent your code becoming a mess after a while?
Any rules of thumb in development to prevent your code becoming a mess after a while?
Posted by Krupux, 07-18-2009, 12:02 AM |
Hi guys,
This is what normally happened:
1. Code looks clean in the first month.
2. New Business Logic required/updated, we implemented it.
3. Several more of #2, and the code become more and more complex.
4. After several months of more #2, the whole thing seems to require a rewrite.
Any advice to prevent this? It's hard to foresee all the potential #2s when we start the project.
|
Posted by mwatkins, 07-18-2009, 12:59 AM |
1. modularize, modularize, modularize.
2. Work hard to keep logic / business objects separate from UI
3. Ruthlessly refactor things each time you come back to it.
4. In time you / your analysts will get better at the anticipation game. Its a challenge - you don't want to over-engineer things out of the gate but sometimes doing a little bit extra makes sense if you have the sense the client is likely to go further with their project / business need
Rewriting isn't always bad or to be avoided; surely you get to reuse big chunks often enough.
|
Posted by Jakoota, 07-18-2009, 02:07 AM |
Modularization is good, you may want to look into using factories (a type of design pattern) or some sort of plugin framework to make it easier for you to add more things in the future. Plugins are a great way to add more functionality without mucking with your original code. Though too much of anything can be bad in of itself. Like mwatkins said, as you get better at being able to analyze and predict things it'll become easier.
|
Posted by dexxtreme, 07-18-2009, 02:53 AM |
I am working on a large web project at work, and the most important thing that I did was to separate everything into separate modules. They may not be fully separated into different objects and classes (I'm a coder coming from a sysadmin background, so I never went through the "official" development process), but the code and functions are completely separate from each other. Whenever I use the same snippet of code more than once (such as a template that is called from more than one place or from more than one module) I put it into a separate function and make sure the function call is designed to be usable from multiple locations and expandable enough to support new features. (I say "more than once" because if you used it a second time, then you will often end up using it a third time, and a fourth time, and a fifth, etc., and it is easier to update it in one place instead of six.) If you keep the functions separate enough, you will have enough room to add new functionality without completely confusing yourself. You should expect "feature creep" to be a major part of any large project, and design the system as such.
Separating the logic code from the templating/presentation code is also important. Nothing is worse than trying to figure out exactly where a certain line of HTML is being generated from when you have hundreds of "print" statements all over the place. It also makes it easier to match the code in your program to the layout of the page (for those of you who have to be web developers in addition to back-end programmers).
|
Posted by randombit, 07-21-2009, 11:03 AM |
This is pretty much inevitable, so get used to it. Nobody knows everything from the get go, so over time, you learn new coding patterns and approaches to problems.
One recommendation I can make is that if there is a framework for the language you are programming in, use it. It definitely helps keep your code and logic more consistent.
|
Posted by Krupux, 07-25-2009, 12:38 AM |
Thanks for the advice guys.
I've actually started to use Zend Framework as my base development work, and started reading on design patterns.
|
Posted by enkapsulate, 07-25-2009, 04:27 AM |
include shared code within included, then if required just add the require/included easily, then if that small piece of code needs updating it can easily be done.
Also like above use a framework.
Add hidden comments in something like dreamweaver rather than adding comments to the code, this will aid the development team and not clutter up the code.
|
Posted by Adrian Andreias, 07-25-2009, 05:21 AM |
These are great development guidelines. It shows that mwatkins has "some" experience in development .
I would add:
5. Implement automatic testing:
5.1. Unit testing
5.2. Automated interface testing, if it's a web application have a look at windmill: http://www.getwindmill.com. There are a lot of UI testing tools for desktop apps as well.
This actually allows you to do refactoring all the time.
In time will have hundreds of automated tests that you can run in a single command/cron.
6. And a lot of human-testing .
7. This is obvious but: use a source version control system (like subversion) so that you have code changes history and manage collaborative development. And will also help you when you realize that the refactoring that you just done, isn't that smart you thought it was .
|
Posted by mwatkins, 07-26-2009, 12:59 AM |
Thanks for adding testing to the list. In my own case I was something of a latecomer to test driven development; I'm not particular I am a full disciple but I do write a significant amount of unit tests and subscribe to the notion that I shall not check code into the repository until it passes the tests. I've mapped some keys in vim to allow me to quickly switch between code / test, or ui-code/ui-tests as need be. Making it easy to get to the right file, in my case, makes a big difference in how complete my tests are.
To the OP: once you've got a big suite of tests in place you'll marvel at how relatively painless it is to do even seemingly large changes in various modules. Part of that confidence is knowing the tests are there; but also once you start writing logical tests you tend to write better code in the first place. Python has numerous test frameworks including the built in unittest:
http://docs.python.org/library/unittest.html
It doesn't matter much what you use, just that you use one.
On the web ui testing front, here's a swack of other tools; that they are written in Python means nothing - you can use many or all of these to test any web application:
http://pycheesecake.org/wiki/PythonT...ebTestingTools
|
Add to Favourites Print this Article
Also Read