I was remotely reviewing a new team member’s code:
It wasn’t that bad, but I wrote him a document suggesting some general design principles. I’m repeating some of them here, because they seemed to be the sort of thing that I would like to refer to often.
- For the typical application, start with the 3 basic layers: Front-end (GUI), Back-end (Database) and Business Logic. Give them their own classes within separate projects in the solution.
- Ensure there are no cyclic dependencies
- Establish well-defined interfaces between the layers.
- Internal implementation within a layer should be modifiable, with minimal (ideally zero) impact on other layers
- Control should flow cleanly between layers, not back & forth
Don’t duplicate code (or data structures) amongst layers (DRY Principle)
At the highest level, each class should map to a real-world object that you intend to manipulate.
- Then start breaking down the functionalities and add more classes at the lower levels
- Try as much as possible to adhere to Object Oriented Principles, and at the very least to the one-class-one-responsibility principle (SOLID) (Annotation: I know it sounds obvious, but you’d be surprised what passes for “object oriented programming” these days)
Don’t try to cover all the possible use cases up-front, instead aim for a design that has a solid foundation, on top which features can be added iteratively (YAGNI Principle)
The earlier you put in place a flexible logging mechanism (whether your own or reused), the happier you’ll be. No application is too small to benefit from logs. Besides debug info, they can also serve a source of useful information that the user need not be burdened with under normal circumstances.
Prioritization: Normally I would proceed in the order:
- Functionality, Reliability
- Robustness, Security
- Maintainability, Portability
- Mindmaps for capturing Requirements & Design (Reference)
- Dia for flowcharts (Annotation: Yeah, I’m old skool)
- StarUML for UML Diagrams