Team Development using Run Rev
steve.taxcalc at hotmail.co.uk
Fri Feb 29 05:21:40 EST 2008
Glad this question came up because the company I work for has been mulling over Rev for development work. No decision has been made yet, but I've had to give this some serious thought as to how we'd go about things if we did.
We'd basically have three or four coders working on a project, and we would have to split out into many stacks so each coder could work on a bit each. Some stacks, therefore, would act as interface but would contain very little 'doing' code and other stacks would act as libraries that process bits of data, or provide support for interface elements such as a tree view. In this way, you could break a project down and give each developer specific tasks and ownership of areas to work on.
If there was one stack that contained more UI that any other, one developer would have to be given responsibility over it and merge the others' efforts. This might mean that the other developers produce a stack with just that one particular card in it, which would then reduce the potential for mixing up versions of the stacks. If they're working on just one card but have the main stacks 'in use' at the time, there should be little chance of scripts not working when merged.
You'd need to set a variable naming convention, to make sure that your guys don't go mad and create their own globals for the same thing. Locals should be named conventionally too, so it's easier to read code. The first stack that loads should set your 'world' variables, as I call them... ones that determine look and feel, location of files and folders etc.
Code should be well commented and explained so a second developer can follow what's been done. In my own projects, I use two commenting styles... one that explains what the handler does and ones that explain what I'm doing as I go along. It's usually easier to read Rev's code than other languages but sometimes it can get complicated, especially if abbreviations or more advanced structures are used.
Using groups of controls should make things easier to manage too. So if you've got a panel on your main stack and it gets updated, it should just be a matter of deleting the group and replacing it with another.
There are loads of reasons why Rev would work so well as a development platform but it would require careful management of the project to ensure it all comes together. That said, I'm sure any development team is used to some discipline and my gut feeling is that the speed with which an application could be put together outweighs any additional time spent controlling it.
What do others think? Wouldn't it be interesting if the list worked on a group project to find out how easy it is to produce something in this way?
Free games, great prizes - get gaming at Gamesbox.
More information about the Use-livecode