Home Blog CV Projects Patterns Notes Book Colophon Search

Naive Style

14 Jan, 2017

A style of coding I'm liking involves being incredibly naive in a subset of ES6 and putting in no architecture or optimisation whatsoever. Some characteristics:

Absolutely no use of class, new, this, throw, null, for or while anywhere. Use Crockford's latest constructor pattern, array.forEach(), Object.keys().forEach() or promises instead.
Everything that a function should need to interact with its environment should be passed in explicitly as an argument by the calling function. For example, a function shouldn't call console.log() itself, but should have a log argument to allow the caller to pass whatever log() function it likes. This avoids implicit coupling and makes testing a doddle.
All concurrency is handled with promises. Promises can be used multiple times by different functions that depend on their results. The order you create, share and consume promises can tell you a lot about the problem you are trying to solve.
Don't look to apply DRY (don't repeat yourself) until you've done exactly the same thing at least 5 times and are confident the 6th time will follow exactly the same pattern
Test only the behaviour of the outer-most functions you care about (the ones that actually deliver the value you want to make sure you've delivered), mocking/faking as little as possible. Don't test any lower-level functions - if they aren't working well enough, the tests for the outer-most functions will tell you. Checking the log output is what you expect during test runs is a very lightweight way of ensuring those intermediate functions really are doing what you expect though and has the added benefit of making it easier to debug any production problems later.
Any time you don't think you could use the existing tests to re-write the entire codebase in a day (copying and pasting from the old codebase where that is helpful) then you should see if there is any design problem you could fix now that would make such a re-write possible.

The beauty of being hopelessly naive and not fixing any "problems" with the code is that your code emerges to fit exactly your problem space, rather than your preconceived solution ideas. The functions that emerge tell you about your APIs. Code that becomes coupled together by promises tells you about the implicit protocol of what you are doing (the order in which things have to be called). The code reflects the business requirements and looking at the code can give insight about the business.

You never do more work than you need to (either in writing code or in testing) and that means you are never worried about throwing out some of what you've done and doing it better. Besides, refactoring absurdly naive code that is devoid of patterns and architecture is really easy because there is nothing to understand, so you won't be overly attached to your investment.

Hint: any time you need to reach for a cache you are probably calling things in the wrong order due to premature architecture. A promise passed to one or more functions might be better.