{"id":566,"date":"2010-01-12T15:41:48","date_gmt":"2010-01-12T17:41:48","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=566"},"modified":"2010-01-12T16:21:28","modified_gmt":"2010-01-12T18:21:28","slug":"how-everyone-is-inserting-technical-debt-in-app","status":"publish","type":"post","link":"https:\/\/blog.plataformatec.com.br\/2010\/01\/how-everyone-is-inserting-technical-debt-in-app\/","title":{"rendered":"How everyone is inserting technical debt in their applications"},"content":{"rendered":"

A couple days ago DHH twitted<\/a> that they were getting Basecamp<\/a> running on Ruby on Rails 3.0<\/a>.<\/p>\n

This means Basecamp<\/a> migrated from the first Rails release up to the edge one. So how come people say so frequently how hard is to update their applications from Rails 2.1 to Rails 2.2? And the answer is simple: plugins<\/strong>.<\/p>\n

Every time you are adding a plugin to your application, you are inserting some hundreds or even thousands of lines of code in your application, without knowing what it does exactly. And sometimes this becomes technical debt, mostly noticeable when you have to update to a new Rails version. And why is that? Because a lot of plugins are monkey patching Rails, so whenever Rails changes its internal API between releases, the plugin breaks.<\/p>\n

However, they are two simple actions you could do to improve your application maintainability, your ruby fu and also give a little back to the community.<\/p>\n

The first one is easy: check the source code of the plugin you are installing<\/strong>. Does it needs to monkey patch Rails code? Or even worse, Ruby classes? If so, how much? If too much, turn it down. Search for simpler solutions or even start one from scratch with just what you need, it will take more time, but you will learn a lot through the process.<\/p>\n

Another very compelling reason is that reading other people’s code is one of the best ways to learn<\/strong>. You will learn new things and probably see a few things which could be done better. And when it happens, write a patch!<\/p>\n

Besides, whenever something is going wrong in your application, you will know better where to start searching and you will eventually help plugins authors to track bugs down. And, in the worst scenario, if you have to update the plugin after a Rails release on your own because the plugin creator is no longer interested, you will be more capable to do so.<\/p>\n

Some people often choose plugin A because of features X, Y and Z. But whenever they have to add feature W, they are stuck, because the plugin code is a complete spaghetti. And all this time, they could have chosen plugin B, which just has feature X, but adding Y, Z and W would be quite easy. Reading the plugin’s source code is one way to ensure you are prioritizing code quality instead of features count<\/strong>.<\/p>\n

And the second step, guess what, is easy too: run the plugin test suite<\/strong>. Really, it will take just a couple minutes. You definitely don’t want to use a plugin where the test suite fails (or which does not have a test suite at all). Imagine that for some reason you need to add features to a plugin, how you will ensure you did not break other thing while doing so? Or even worse, imagine you have to update the plugin for a new Rails release. How can you ensure the plugin works on 3.0 if you cannot even ensure it works on 2.3?!<\/p>\n

Some already noted that I have patches applied in different plugins around GitHub. And this is the very reason: I check their code, send simple suggestions whenever it’s possible and most important of all, I choose well which plugins to use. So whenever I need to write a new feature because the application I’m working on needs it, I know it will be easy, since the plugin code is quite well written and test suite is green.<\/p>\n

It’s really two small efforts, which gives everyone, including you, a lot back.<\/p>\n","protected":false},"excerpt":{"rendered":"

A couple days ago DHH twitted that they were getting Basecamp running on Ruby on Rails 3.0. This means Basecamp migrated from the first Rails release up to the edge one. So how come people say so frequently how hard is to update their applications from Rails 2.1 to Rails 2.2? And the answer is … \u00bb<\/a><\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[1],"tags":[23,7,64],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/566"}],"collection":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=566"}],"version-history":[{"count":14,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/566\/revisions"}],"predecessor-version":[{"id":580,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/566\/revisions\/580"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=566"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=566"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=566"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}