We have discovered that it is more and more difficult for us to introduce new features in erlide without breaking anything and realized that one of the reasons is because assumptions about the project structure are spread throughout the code and some times are even implicit. New features that don't follow these assumptions get weird errors and when the apparent problem is fixed, other problems appear in other parts.
The way to improve the situation is by:
- getting a picture of what we'd like things to work like
- using unit tests as "live specifications" for the desired functionality. Note that this is slightly different than introducing unit tests for current functionality.
- changing the code in small steps until it conforms to the tests/spec
There should be only one source of information in the system - the model of the projects and of the source code. The basic model should be possible to extend by extra tools (for example, a test framework may specify additional source code directories). These tools might also specify their own processing of the sources (for example, a coverage tool might require special arguments for the compiler; or a code-generation tool might require a script to be executed before compilation). The basic model should not have to be changed to accommodate for these extensions.
More about this later.
Posts
