Designing Code?
Author
When you have a project in which you know you need to design some of the code (like classes, interfaces, methods/parameters, members, etc...) before you actually jump into your code editor to write it, what do you use to design the code? Do you use a UML tool, and if so what tool? Do you just write it out on a piece of paper or whiteboard? Do you never design your code and always just jump into the actually coding process? Do you do something else?
White board and paper here. I haven't found a tool that really works better for me than making notes on large post-it notes and moving them around a white board.
I design on whiteboards for preference. If that's not available, flipchart pad and biros -- there's loads of space on a flipchart pad. A4 just runs out too fast.
Like Talroth, I've never really found a tool which helps more than gets in the way. When I'm done with the designing, I sometimes write up the microarchitectures neatly so they can be stored as part of the docs.
For that I use either something like Inkscape (which has a connector tool) or in my own notation which then gets turned into Graphviz input by a perl script, and that makes svg for storing in a wiki.
Like Talroth, I've never really found a tool which helps more than gets in the way. When I'm done with the designing, I sometimes write up the microarchitectures neatly so they can be stored as part of the docs.
For that I use either something like Inkscape (which has a connector tool) or in my own notation which then gets turned into Graphviz input by a perl script, and that makes svg for storing in a wiki.
We don't do that.
Remember the YAGNI principle.
Trying to "design" those items (classes/interfaces/methods/parameters) is a waste of time. Is it significant to your game if a function takes two parameters or three? Is it significant to your game if your class is named Foo rather than Bar? Doing this is a significant time sink. You spend time thinking about stuff that really isn't a problem. You spend time writing code you don't need. You spend time maintaining something you will never use. Spending your valuable time and effort on unnecessary items is wasteful.
If you were working on something like an operating system, or a programming language, or a broad externally-used library, then it would make sense to do quite a lot of interface design. In that case you would listen to your users and understand their preferred usage patterns. Only after you know how they will use it should you build your interface around it. But chances are good that you're not making one of those.
We have design documents that describe how the game is supposed to work from the user/designer perspective. We have documents for coding standards that cover coding style, naming conventions, hierarchy standards, and so on.
The designers and senior developers break those conecpts down to individual items that can be done in a week or two, although sometimes there are very large items that can't be broken down further. Again, this is logical implementation details, not the classes/interfaces/etc.
From there we use scrum planning to break up the big tasks into very small tasks that a single programmer can do in a few hours or days. Again, there are no formal code requirements, only tasks to meet the conditions of satisfaction that actually make our game.
However...
On a very rare occasion, we will have core engine components that need to be authored or redesigned. The functionality is researched and somebody is assigned to build a prototype framework. Once they build it up, the spend that much time again breaking it down and eliminating stuff. Then the senior people and anybody else who has an interest in it will work on it from within Visual Studio, on a projector. The implementer has already designed the abstract base classes, leaf classes, and interfaces. They will also have several examples of how the main features will be used by the other programmers.
The group then review it and make suggestions for necessary changes. The first thing we look for is items to cut, and prioritize the items we need. We know YAGNI, so we'd rather delay the work if we are not absolutely sure we will need it later. A full UI system can be broken down to a handful of essential functions and a very simple tree. The second thing we look for is examples of how we will actually use it. If it is hard to use then the design is bad.
Even in that review we aren't looking at the details of the members and parameters, only checking that the functionality we need is there and that the functions are intuitive and easy to use for the main functionality. Once their very first core features are in place people immediately begin using it. They give feedback as they use it and the code and development priorities are modified to reflect the actual need.
Remember the YAGNI principle.
Trying to "design" those items (classes/interfaces/methods/parameters) is a waste of time. Is it significant to your game if a function takes two parameters or three? Is it significant to your game if your class is named Foo rather than Bar? Doing this is a significant time sink. You spend time thinking about stuff that really isn't a problem. You spend time writing code you don't need. You spend time maintaining something you will never use. Spending your valuable time and effort on unnecessary items is wasteful.
If you were working on something like an operating system, or a programming language, or a broad externally-used library, then it would make sense to do quite a lot of interface design. In that case you would listen to your users and understand their preferred usage patterns. Only after you know how they will use it should you build your interface around it. But chances are good that you're not making one of those.
We have design documents that describe how the game is supposed to work from the user/designer perspective. We have documents for coding standards that cover coding style, naming conventions, hierarchy standards, and so on.
The designers and senior developers break those conecpts down to individual items that can be done in a week or two, although sometimes there are very large items that can't be broken down further. Again, this is logical implementation details, not the classes/interfaces/etc.
From there we use scrum planning to break up the big tasks into very small tasks that a single programmer can do in a few hours or days. Again, there are no formal code requirements, only tasks to meet the conditions of satisfaction that actually make our game.
However...
On a very rare occasion, we will have core engine components that need to be authored or redesigned. The functionality is researched and somebody is assigned to build a prototype framework. Once they build it up, the spend that much time again breaking it down and eliminating stuff. Then the senior people and anybody else who has an interest in it will work on it from within Visual Studio, on a projector. The implementer has already designed the abstract base classes, leaf classes, and interfaces. They will also have several examples of how the main features will be used by the other programmers.
The group then review it and make suggestions for necessary changes. The first thing we look for is items to cut, and prioritize the items we need. We know YAGNI, so we'd rather delay the work if we are not absolutely sure we will need it later. A full UI system can be broken down to a handful of essential functions and a very simple tree. The second thing we look for is examples of how we will actually use it. If it is hard to use then the design is bad.
Even in that review we aren't looking at the details of the members and parameters, only checking that the functionality we need is there and that the functions are intuitive and easy to use for the main functionality. Once their very first core features are in place people immediately begin using it. They give feedback as they use it and the code and development priorities are modified to reflect the actual need.
Quote:Original post by 3dmodelerguy
Do you use a UML tool, and if so what tool?
I use a combination of UML software (Visual Paradigm for UML) and whiteboards/paper. The latter in the sketching phases and the former to flesh things out.
I actually use my own tool, LucidChart (see sig). I actually decided to create it because it was so painful trying to work together with a team on a Visio flowchart to map out some complex processes.
I don't usually use UML or even attempt to draw out all the requirements of a project. I just whip up some flow charts to help visualize some of the more complex processes--like recently, the flow through a complex new billing system.
I don't usually use UML or even attempt to draw out all the requirements of a project. I just whip up some flow charts to help visualize some of the more complex processes--like recently, the flow through a complex new billing system.
For my own projects, I'll likely use either the VS Class Designer or some freeware like ArgoUML to lay down some designs for classes. Sometimes, I just create classes in VS and randomly throw bits of code in until I get a half-arsed inheritance setup going. For general points, I keep an A4 pad and a pen on my desk to scribble down rough thoughts on as I go along, and it also serves as a todo list for the following day as I can update it whenever I stop or whenever I go home from work, etc.
As for how it was done at the 16 week internship I worked in 2008... *shudder*. I would love to tell you, but can't because a) it'll chill you to the bone and b) it's so uniquely terrible that my former boss will spot it immediately as their practices, will likely join the dots and withdraw the glowing reference he's been giving me. Let's just stop at saying it was truly hideous and no design process at all would have been an improvement.
Me neither. I never quite understood Rational Rose which is horrendously expensive yet unbelievably clumsy and unintuitive.
As for how it was done at the 16 week internship I worked in 2008... *shudder*. I would love to tell you, but can't because a) it'll chill you to the bone and b) it's so uniquely terrible that my former boss will spot it immediately as their practices, will likely join the dots and withdraw the glowing reference he's been giving me. Let's just stop at saying it was truly hideous and no design process at all would have been an improvement.
Quote:Original post by Katie
I've never really found a tool which helps more than gets in the way
Me neither. I never quite understood Rational Rose which is horrendously expensive yet unbelievably clumsy and unintuitive.
Quote:Original post by ukdeveloperQuote:Original post by Katie
I've never really found a tool which helps more than gets in the way
Me neither. I never quite understood Rational Rose which is horrendously expensive yet unbelievably clumsy and unintuitive.
Henceforth we shall not mention Rational Rose, or for that matter, any of the Rational Toolset-- as even muttering the name "ClearCase" three times in succession may cause a random developer in the world to instantly suffer a fatal heart attack.
Quote:Original post by BeanDog
I actually use my own tool, LucidChart (see sig). I actually decided to create it because it was so painful trying to work together with a team on a Visio flowchart to map out some complex processes.
I don't usually use UML or even attempt to draw out all the requirements of a project. I just whip up some flow charts to help visualize some of the more complex processes--like recently, the flow through a complex new billing system.
Woah that's a nice tool. Why didn't I know about that a long time ago? It just needs straight lines with cornered bends and it would beat inkscape and dia with boatlengths
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
