What else can I do wrong?
There are so many ways to make wrong decisions in designing software that it seems like often there is never going to be an easy and clean way to implement things. Large scale mistakes can cause lots of the code to become unreusable, inflexible, and eventually legacy code that has to be rewritten. Here some of the antipatterns that we must avoid. (sources include wikipedia, c2.com wiki, and other sites). Note, these antipatterns are my interpertation, and thus may not match exactly with other ways of saying it. I recommend wikipedia or c2 for more information.
- copy and paste programming. errors and bad programming mechanicsms get propagated to the copied code. We should make the concept of copy and paste either impossible, or make a mechanism, where copied code is automatically segmented from the main program and turned into a more general function outside of the original function, in other words, languages where auto-refactor is of low complexity. This will be easy if the programming language is designed to work with "semi-anonymous" name references. Functional languages are good, and so is stuff like subtext which acutally requires first class copy and paste.
- Abstraction Inversion, where in short, the uses of the components are reduced at the cost of complicating the use of the components. A tradeoff is made between the complexity of the interface, and using the components. A more complex interface will allow fast and easy doing of intent but at the cost of a huge learning curve, while a simple interface is easy to learn and flexible, but forces the user to use the interface many times and at a cost to the speed. A solution is to make all interfaces simple, and make all complex interfaces just scripts - in other words, doing a complex action is through a script that allows complex things to be broken down into the simple steps.
- Gas factory, where the design is unnecessarily complex. One way to force away this trend is to force an architecture onto the operating system and all programs. While restrictive and possibly unefficient, the resulting harmony and clear design may offer human benefits - i.e. to users.
- Ball of mud, where the design may be ok in areas, but the way they are joined together is complicated and has no real unifying point.
- Interface bloat, where the interface is way too complicated to make. This can be solved if we separate the interface from the actual stuff that the interface does, allowing us to design any interface we want
2 Comments:
At Wednesday, July 19, 2006 , Anonymous said...
This comment has been removed by a blog administrator.
At Thursday, July 20, 2006 , Anonymous said...
This comment has been removed by a blog administrator.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home