21–30 of 78 posts
It's very tempting to make it "extensible" by overgeneralizing. What you get then is overly complex code, most of which is never used.
Cut out everything that isn't currently used, and you have a small system where every line pays for its keep.
I usually keep a Google Docs page open where, as I write the code, I update the documentation. It keeps things consistent and flexible, and much easier to go back and refactor.
I'd say write the least amount of code you can. While you're adding a feature it's always tempting to go down the "what if" route and make some kind of crazy interface that is extensible and able to accept plugins and all that. The problem is you're likely making it extensible in ways that turn out to be useless down the road. Just code the least amount you have to in order to achieve the current goal. That way down…
Sometimes its easy to predict how your code may need to be extended if you give it a bit of thought. In those cases, it might make sense to allow for easy extensibility. This is pretty rare though. Most times, you can't really predict what will be required of the code in the future. In those cases I prefer to bake as few assumptions into the code as possible, so when someone else is extending it in the future, they spend as little time understanding your code.
Keep a document of your design decisions. It's very tempting to hack away to get things done, but human memory is short and feeble: you will forget why stuff was coded the way it was faster then you think. I usually keep a Google Docs page open where, as I write the code, I update the documentation. It keeps things consistent and flexible, and much easier to go back and refactor.
On code you touch every day one can easily make changes since everything is fresh in one's mind.
When you are working with a code base that you touch once a week or even for a few hours/minutes every day having notes about what you did, why and perceived next steps at the time is crucial and VERY useful.
Another strategy I found useful is to try and be consistent with your choices even if they are not fantastic.
For example: all your tables are named like tbl_entityNam. Even if prefixing every table with 'tbl' is a bad idea, the consistency in keeping it will be useful later when you need to work with that code.
Only write code that's absolutely needed for what you're building. It's very tempting to make it "extensible" by overgeneralizing. What you get then is overly complex code, most of which is never used. Cut out everything that isn't currently used, and you have a small system where every line pays for its keep.
Example: if a computation requires some intermediate value, create a new variable with a proper name and assign the intermediate value to it, instead of just inlining it in a bigger statement or assigning it to "res". The compiler knows how to deal with temporary variables like these in an optimal way.