Skip to main content

Posts

Showing posts from April, 2016

X% of Configuration is Never Used

Code configuration is essentially for the likes of URLs, credentials or other per deployable settings. Sadly configuration seems to fall into examples where there is simply too much configuration, or the system has so many configuration points the actual code becomes far too complex for its own good.Too Much ConfigI once worked on a system with in excess of six hundred different configuration points. In reality all but a handful of these would ever actually need changing. Most configuration is added to enable anyone to make the change. Ironically if these configuration points do need changing, developers need to do it. The business or non technical individuals will never change settings. In this scenario you would need to actually test all six hundred different combinations of configuration. 1 on, 599 off, 2 on, 598 off and so on - this is not ideal nor realistic.Configurable Systems are ComplexOne of the earliest project mistakes I can remember involved creating a system that could b…

Legacy Code is Just Code

Try and define legacy code. Working Effectively With Legacy Code states it is simply code with no tests. This is an almost perfect definition, however it is quite easy to have code that is covered by automated tests, yet is still considered to be legacy. Poor quality, or missing test cases can provide a false sense of security.Legacy in the Real WorldLegacy code is scary to change or work with. Typically it is stuck using an old language or framework which is too expensive to upgrade. Most notable legacy code is often considered old. Developers or teams that no longer exist wrote it and have long since moved on. Hence legacy code is often ignored or over looked by the wise. To be blunt, most developers consider legacy code to be crap.Just CodeIn the end legacy code is just code. It should be treated and given the same amount of respect as your new and shiny solution. In fact legacy code is more than that, it's proven. Unlike clean code you have stagnating in your repository, legac…

Dependency Injection for Common Global Dependencies

The use of singletons can often be replaced by simply adjusting scoping of objects. The vast majority of dependencies fit this pattern, with a few exceptions such as DateTime instances, or logging.Sometimes you just need these dependencies everywhere. You can find yourself passing these dependencies down into the deep depths of your code base. Such changes are often dangerous, time consuming and undesirable.DateTimeFor a while the use of some date/time abstraction was my default approach to handling dates and times. This fake clock or calendar instance when combined with DI at the lowest level does actually work. However if we stop and think about the abstraction it is clearly unnecessary in many cases. Unless your domain is dealing with date and times explicitly, you don't really need an abstraction. In other words, other than the system where the code is running when or why would you provide a different implementation?The approach taken as part of the example within the Dependen…

Project Setup Tax

With microservices gaining popularity, one consideration prior to adoption is new project setup. In fact this statement holds true for any new project that you decide to create.Each new project requires at a minimumSource control - somewhere to actually store the code.A project base - API, executable, library, application etc.Users, accounts and permissions.Build configuration - in order to compile, package and run tests.Deployment and installation - to a production like environment.Remember this is all before you write a single line of code.Automating as much of this away does help. Templates, conventions, containers or similar can assist. Still nothing is free. This all requires maintenance regardless of how you choose to optimize the creation of a new project.When weighing up decisions about a separate project, always factor in the project setup tax. In my experience this tends to take longer than expected. Often it is very easy to forget various project conventions, configuration …