In recent times I've come to think that I must have learned a thing or two about architecting and developing software. Much of this wisdom can be presented as short mantras that are, of course, universally and unequivocally true :-). Interestingly these mantras often translate to life in general. I hope I can remember to collect them here when they pop up during work.
Problems are not god-given. You define the problem. If you have a problem, try to make the problem simpler before looking for a solution.
Foolish consistency. Don't be afraid to add code that doesn't fit in cleanly. That's better than hiding the problems. The right way to restructure the surrounding code might soon become apparent, improving overall architecture.
If you know how to solve a "problem", that doesn't mean you should. Don't solve it unless it is a problem in actual practice. (premature abstraction / problem solving, KISS)
In a solid architecture decisions are pushed out as far as possible. Delegation is the key. Decisions that are not strongly associated with the name of a procedure must not be made in that place.
Generalizations are always wrong.
Object-orientation generally sucks. Its antithesis is aspect-orientation and it works. Helper classes / modules are a code smell. They probably exist because the implementation of an aspect is scattered across the program source (across multiple datatypes).
If you can get away without materializing a concept in code, that's probably a good idea. Abstractions and taxonomies break easily. Large programs have many of these. Example: Metadata/Data, Objects/data-and-procedures, Complicated type systems/primitive machine types. Be aware of the cost of unwrapping concepts for other parts of the program where they don't fit. Example suggestions for minimizing that cost: Build OOP classes only as proxies to procedural code. Don't physically separate Data/Metadata (consider the great success of Unix filesystem files. They have (almost) no separate metadata. Instead such questions are delegated to individual file formats and implementations).
Reusable code is often not the best code. There is probably a lot of redundancy (cross-cutting concerns). Or alternatively, increased interface complexity, to the point where it's easier to just write a custom-tailored version of the code.
todo: "naming is a matter of perspective"
todo: "know your primitives and you can work with less abstraction"
Created: 2017-04-05Last updated: 2018-07-10