{"id":273,"date":"2019-09-23T09:13:09","date_gmt":"2019-09-23T09:13:09","guid":{"rendered":"https:\/\/kalkus.dev\/?p=273"},"modified":"2023-08-24T23:31:38","modified_gmt":"2023-08-24T23:31:38","slug":"dry-is-dead-2","status":"publish","type":"post","link":"https:\/\/kalkus.dev\/blog\/2019\/09\/23\/dry-is-dead-2\/","title":{"rendered":"DRY is dead"},"content":{"rendered":"\n

The DRY principle, together with YAGNI, SOLID or KISS, is one of the most popular acronyms which shaped our way of thinking about developing software. It is simple, intuitive and easy to learn even during the early stages of education. However, the principle has been born in completely different circumstances than what we are dealing with today. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Simple idea<\/em><\/p>\n\n\n\n

I\u2019m not a historian of the software development and I\u2019m not sure how the DRY principle has been born, but I guess it was created during procedural programming age. It stinks with a procedural way of thinking anyway.<\/p>\n\n\n\n

The idea is simple. We have some code. The code should be organized. As long as we have some part of the code which repeats here and there we should create a procedure \u2013 extract this block of code, give it a name and reuse it.<\/p>\n\n\n\n

Time flows<\/em><\/p>\n\n\n\n

Since procedural programming things have changed. First of all the object-oriented paradigm explosion has happened. The complexity of the software has been growing. The systems for accounting, summing long rows of numbers, generating reports have been already created. The new frontier was internet browsers, instant messaging apps, trading systems for companies and snake for Nokia 3310. Except for the last one \u2013 it was quite a challenge.<\/p>\n\n\n\n

The DRY principle doesn\u2019t fit OOP as much as the procedural paradigm. Actually, if you think about it \u2013 it doesn\u2019t fit at all.<\/p>\n\n\n\n

Let\u2019s think for a while \u2013 what happens when we try to avoid repetition in object-oriented code? First what comes to our mind is probably inheritance \u2013 the beautiful useless idea. The dog has a name, the cat has a name so let\u2019s create a class Animal with property Name. But wait a second. Wild animals don\u2019t have names. Let\u2019s create WildAnimal and DomesticAnimal. Damn! \u2013 almost nobody gives names to fish\u2026<\/p>\n\n\n\n

Second popular solution for repetition problem is utils or commons.<\/p>\n\n\n\n

There\u2019s a secret rule in the software industry \u2013 every complex enough project has utils directory or class. Some of them 8k, 16k LoC. <\/p>\n\n\n\n

It\u2019s avoidable, it\u2019s possible to properly design object-oriented software without these cancer cells of utils and disastrous inheritance. Please keep in mind anyway that both of them are the result of the DRY principle application. We tried, in the most easy, cheap way, to not repeat ourselves.<\/p>\n\n\n\n

Microservices \u2013 nail in the coffin<\/em><\/p>\n\n\n\n

Once upon a time I asked a colleague who worked at Amazon \u2013 the company which is a role model, a pioneer of microservice architecture \u2013 how do they organize common parts of the project, how they manage reusability, he answered:<\/p>\n\n\n\n

We don\u2019t. We do repeat. It\u2019s cheaper and quicker at that scale of the project.  <\/em><\/strong><\/p>\n\n\n\n

The enormous size of the systems we are developing nowadays entails a new approach and different rules. The most visible tendency recently is breaking down problems and systems into smaller ones. Actually it is one of the main techniques since the beginning of software development, but recently it becomes more important than ever before. We can spot this trend in front-end frameworks (Angular, React \u2013 componentization), as well as in back-end (microservices architecture).<\/p>\n\n\n\n

To some extent, we can think of it as a proper way of object orientation, more proper than inheritance. The organisms are similar but not the same. They do not, strictly speaking, share some features. The human eye is not the same as a dog\u2019s or hawk\u2019s eye. Only seemingly, on the level of naming these objects, they\u2019re the same. Implementation details differ greatly. I\u2019m not a genetic scientist but I bet that if we cut out from human DNA the parts which we don\u2019t share with monkeys it will not create a monkey. I guess there are many subtle differences, some small parts of genetic code, few \u201clines\u201d which make a difference even if most of the code is the same.<\/p>\n\n\n\n

What to do?<\/em><\/p>\n\n\n\n

It seems that the DRY principle became harmful. Should we stop using it? Maybe. For sure we should use it more carefully. In many scenarios, it may bring more harm than good. In some cases repeated code can be signature of failure, in some cases, it may be the best possible solution.<\/p>\n\n\n\n

Is it bad when we repeat the identical code twice? If we repeat within the same class \u2013 I guess it is; in the same module \u2013 maybe; if it\u2019s repeated in the same project, which consists of 100k LoC, and repetition happened in different modules \u2013 maybe not.<\/p>\n\n\n\n

Is partial code repetition bad? Well, maybe it\u2019s not bad by default, but it depends. Depends on the possibility to create a proper abstraction to avoid it. Quite often we use principles very strictly. Don’t. Don\u2019t follow these rules blindly because they\u2019re merely suggestions. <\/p>\n","protected":false},"excerpt":{"rendered":"

The DRY principle, together with YAGNI, SOLID or KISS, is one of the most popular acronyms which shaped our way of thinking about developing software. It is simple, intuitive and easy to learn even during the early stages of education. However, the principle has been born in completely different circumstances than what we are dealing […]<\/p>\n","protected":false},"author":1,"featured_media":318,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[202,1],"tags":[13],"_links":{"self":[{"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/posts\/273"}],"collection":[{"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/comments?post=273"}],"version-history":[{"count":4,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/posts\/273\/revisions"}],"predecessor-version":[{"id":322,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/posts\/273\/revisions\/322"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/media\/318"}],"wp:attachment":[{"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/media?parent=273"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/categories?post=273"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/tags?post=273"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}