“Clean Code” is a term that refers to code that fulfills certain quality standards. It is used in conjunction with certain principles and practices. And it refers to a mindset of programmers who care about their code and who take pride in what they do. What can SOA developers learn from these principles and practices?
In SOA integration platforms, we try to avoid traditional 3GL code. We use BPEL or some Business Rules notation for business logic. We configure message flows in domain (and vendor!) specific languages (DSLs). We use WSDL and XSD to describe interfaces. This leads to separation of concerns: we use dedicated technologies and languages for the different aspects of a system. In a general purpose languages, we can use the same language for everything: business logic, data models, control flow, UI, data access etc. This is why they are called general purpose languages. Maintaining a good software design is hard in these languages. Programmers might (happily assisted by their IDE) import classes they are not supposed to import, creating undesired dependencies and messing up your initial design. This is one reason that code “rots” like the car above. Modifications have the tendency to make code less maintainable. By actively applying principles and practices, this tendency can be fought. The term “Clean Code” is used in conjunction with a set of such principles and practices. They are very valuable and every programmer, architect or software manager should be aware of them. Back to our SOA integration world. Do we need such such principles and practices, too? Do the same principles apply? Can we employ the same practices? What kind of tool support can we expect? In the next few articles, I will discuss these questions.
Picture: Abandoned Car in Rhyolite, NV. Taken October 2012.