TQ
dev.com

Features are an asset, code a liability

04 Aug 2016 - by 'Maurits van der Schee'

Lines of code shouldn't be used to measure productivity, but it is a very good metric that tells you a lot about the state of the project. Especially when separated into testing and non-testing code and combined with number of features. I think that if you manage to add a requested/desired (!) feature without adding too many lines of code you are doing a good job. A project should also have a decent amount of code dedicated to automatic testing. Next to that active monitoring and automatic bug reporting are required to run a smooth web application.

DRY-ing out

I think lines of code are a good metric, but on the other hand I am a strong dis-believer of Don't Repeat Yourself (DRY). The over-zealous implementation of that philosophy leads to wrong abstractions and wrong abstractions are way worse than duplicated code. NB: Note that abstraction is a weird, but common, term for refactoring duplicated code out into re-usable functions. Actually I believe that code duplication leads to learning you the right abstraction. You may quote me:

"A little code duplication is preferable over an early abstraction"

Refactoring on the first code duplication is hardly possible as you have not yet learned enough about what generic functionality is and what specific is to the occurrence. Refactoring again on the third and fourth use of a certain algorithm would indeed help, but does not make sense in the real world as it would be hard to justify the costs involved. In reality that does not happen and people end up with a poorly chosen abstraction.

Lines of (test) code

The number of lines of test code in relation to the source code shows whether or not there is a balance between the effort in testing and building features. I feel a healthy project has about 25% of the code base consisting of test code. This is just a rough feeling for a typical web application where only a few pages are of critical importance and thus the effort for most pages is limited.

For most web applications it makes more sense to write functional tests than to write unit tests. Reason is that functional tests require less maintenance as they simply test the entire functionality, allowing you to refactor certain components or even the relationship between components without having to do maintenance on the tests. You may quote me:

"High level functional tests are preferable in web applications over unit tests as they (generally) provide more certainty when refactoring."

When you want absolutely none of the behaviour of a component to change and the component is critical and complicated then unit tests make sense, but when you are talking about forms in your business application it often is enough to test the happy flow, which is not much work and provides great certainty about the functionality of your application. Especially when you combine 100% happy flow testing with active monitoring and automatic bug reporting when error pages are served.

PS: Liked this article? Please share it on Facebook, Twitter or LinkedIn.