Maintaining code can be a real pain in backside. Especially when you’re using shared code, almost always at a later date you will want to make the code more versatile to accommodate a scenario you hadn’t thought of before.
I’ve had experience this in an ASP / VbScript environment, and therefore I’m going to use the terminology of page and functions as opposed to files and classes:
- Rework the code and update all pages. This is obviously a bad idea.
- To extend inflexible code: Rename the function and create a wrapper in its place to access the function using default parameters that are compatible with your existing codebase.
- Create functions that are extendable.
To use optional parameters, pass them in an Array or dictionary object. This way you can add additional ones. The benefit that Arrays have over Dictionary objects is that they use less resources. This can be important if you are developing for a popular website.
Another advantage of using Arrays is that you’ll use less code calling the function. Using a dictionary object you’ll have to add each parameter separately, then pass the dictionary object as the parameter of the function.
On the other hand, code will be more legible using dictionary objects. Dictionary objects use key value pairs to tell you that key A has a value B. You’ll not have to bother about the order of parameters, but you’ll have to know the keys of each function. It results in verbose, legible, resource intensive code.
Acquiring feedback on web projects can be harder than you’d think, especially when you’re working on internal projects that don’t get discussed on outside your organization. By making feedback a fun, easy and rewarding thing to do more people might be encouraged to help us and put in the effort.
I’m sure some of you are in a similar situation: you launch a project and silence follows. Trivial problems might emerge but a there’s no general response to the long hours you put in. That makes it much harder to evaluate the project and set a schedule for future developments.
To help with this we’ve created a UserVoice page. Let’s describe it as a digg-like FAQ. People are encouraged to leave a message, can vote on feedback they find important, and always have the full picture of what the development is focused on. Developers act on the consensus and theoretically will work on solving the most urgent issues.
Of course this model will work best when both users and developers care enough to communicate. So Uservoice is engineered to make it trivial to leave a message. It can be easily integrated into an existing site. Some functionality requires a user account, which is a stumbling block. But you can leave feedback without it, which is a bonus. Oh and it doesn’t integrate with any bug trackers which is a shame.
Will it work and will there be enough participation? Ask me again in 6 months time. I’m not sure how to make it any easier though.
developing, feedback, uservoice
Brian Wood presents an excellent Dreamweaver tips video on Youtube. Many people just use DW as a text-editor but it’s capable of a lot more even in code view. The following video might open your eyes:
Very nice.
