When it comes to software development, there are a number of well-known ways of building a product. For some reason, all of their names follow the pattern “X Driven Development”. There is Test DD, there is Domain DD and there is Behaviour DD, to name a few.
However, nobody ever talks about the best one of them, the one that is used every day, is battle-tested and known for producing the best-of-breed software: Fuck It Driven Development, also known as FDD.
Let’s illustrate this methodology by following the key steps of building a piece of
garbage software with it. We’re going to use Java but, rest assured, this model works flawlessly with any language or ecosystem.
Java is a world of specifications and interfaces, which means your project should run on any platform which is implementing the specs that you are using. But fuck it: right off the bat, you should start by adding proprietary configuration files. This way, your project will not even deploy (let alone run) on a different platform than the one your company is paying a licence for.
Moreover, said configuration files should be as cryptic as possible so nobody can mess with them and ruin your application. Ideally, you also have no clue what those files are doing, you just copied them from an older project.
Maven has no restrictions when it comes to the number or the compatibility of the declared dependencies. With that out of the way, fuck it: bring in everything that you can remember off the top of your head, you never know when it’s going to come in handy.
Your project still doesn’t have a single Java class of its own, yet it already has half of Apache’s Java libraries as dependencies. Out of all those dependencies, you’re only going to use
StringUtils.isBlank(...) but who cares? Fuck it.
First API Endpoint
Now that the project is set up and only working on your machine, it’s time to start writing that
elegant RESTful API. Your first endpoint is
POST User /createOrUpdate – there is no such thing in REST but fuck it, it’ll be easier for the clients.
Validating the Input proves to be a bit difficult since Java’s Bean Validation API is pretty limited. You could implement your own ConstraintValidators and add your custom annotations but why bother? Fuck it, just add a private boolean method with a few
switch cases – did you know
switch is an expression now? All the better.
You need to call a third-party HTTP endpoint to read some data about your
you should encapsulate this part in a mockable module and only expose the necessary interfaces to your own code. You decide to fuck it: just pull in Jersey Web Client and start making HTTP Requests right there, right away. Of course, you didn’t really need Jersey because there are already a few other HTTP Client libraries in your classpath (see “Dependencies”) – again, fuck it. Don’t forget to catch and silently swallow any annoying
As suggested just above, in the FDD methodology exception handling is as straight-forward as it can be. Instead of bothering everyone with checked exceptions, just fuck it, catch them and deal with them yourself. In this regard, the following construct is quite common:
Clean code, easily understandable, no headaches.
DI and Persistence
Finally, it’s time to persist your work somewhere. The persistence layer should be very well thought and implemented but, don’t worry, you can fuck it as well. Just inject the
javax.persistence.EntityManager wherever it is convenient and store your objects. Good news is, you can also work with
org.hibernate.Session. See which one your IDE recommends first.
To conclude, this was a short overview of the widely used FDD. One last important aspect of FDD is that it requires almost no tests. Since the code is straight forward and self-documenting, tests only become a burdain to maintain.