It also focuses you on the task at hand, which is to directly solve the problem. By focusing on the shortest path between point A and point B, the result should be small, lean, and direct.
However, in several projects I've worked on there comes a point where certain aspects of a codebase not directly related to its functionality begin to demand attention. These issues can be ignored up until the point at which inaction damages the codebase as a whole. I find these things are common across projects, and so they could be classed as "You're Gonna Need It". The examples that immediately come to mind in Java projects are:
- A logging setup, i.e. configuration of log files for errors and debug info.
- Likewise, a sprinkling of informative logging statements, without which it becomes difficult to tell what went wrong outside of a debugger.
- An exception hierarchy. You can throw new RuntimeException for a while, but eventually it becomes unmanageable and you need to distinguish in catch() clauses between errors inside and outside of your own codebase
- Interfaces, for the classic reason of hiding the implementation, but also because it enables Proxy-based AOP which is useful for a bunch of stuff 'YAGN' but may one day be 'YGNI', such as benchmarking and security interceptors.
- A base test case / test harness that lets you pull in different parts of the application and test them individually.
This stuff is all boring but necessary. When living without them starts to affect efficiency and quality, that is the point at which to stop working on functionality, get this stuff right, and then go back to working on the important things.
Posts
3 comments:
I think that when you start a project, you need define a sane set of rules. These rules can include architectural style , level of documentation, commit policy, test-coverage, uses of pattern... We want the rules to be followed so we must be careful not to add to much.
Now, in this context, YAGNI can be followed without worries because even if the code do only achieve a minimal set of function, it does it right.
Most of the boring aspects you mentioned (logging, interface) should have been taken in account very early.
We could create CLA like a SLA but for code. What do you think?
It sounds like a good idea but can you make a CLA language-independent without making it too abstract to be useful?
I would say first that is CLA could be very specific for a project or a sub-project. We should be avle to agree on: the language and version; use of specific libraries; code coverage in a specific test framework; rules to avoid copy-pasted code; respect of Liskov principle if I m coding in OO; code can only use interface not directly a class; forbidding some patent; enforce statelessness when possible...
But it would quite good to propose some general CLA for most common case and a tool box to check the compliance. Checkstyle, sonar, pmd or squale could cover a part of it
Post a Comment