{"id":41,"date":"2014-12-02T09:06:54","date_gmt":"2014-12-02T07:06:54","guid":{"rendered":"http:\/\/blog.adrianbolboaca.ro\/?p=41"},"modified":"2020-01-15T19:56:30","modified_gmt":"2020-01-15T17:56:30","slug":"basic-rules-of-refactoring","status":"publish","type":"post","link":"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/","title":{"rendered":"Legacy Coderetreat: Part 6 &#8211; Basic rules of refactoring"},"content":{"rendered":"<h2>Basic Rules of Refactoring<\/h2>\n<h3>Blog post series<\/h3>\n<p>This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see <a href=\"\/2014\/04\/legacy-coderetrea\/#sessions\">more sessions<\/a> about legacy code.<\/p>\n<h3>Purpose<\/h3>\n<p>This technique is useful to minimize the mistakes one does while changing existing code. When refactoring existing code, one can introduce defects because of rushing through the changes.<\/p>\n<p>During the next sections you will find some rules (guidelines) and some explanations about why these rules are useful.<\/p>\n<p>&nbsp;<\/p>\n<figure id=\"attachment_1155\" aria-describedby=\"caption-attachment-1155\" style=\"width: 300px\" class=\"wp-caption aligncenter\"><a href=\"http:\/\/blog.adrianbolboaca.ro\/wp-content\/uploads\/2014\/03\/Workplace_Safety_Signs.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"size-medium wp-image-1155\" src=\"http:\/\/blog.adrianbolboaca.ro\/wp-content\/uploads\/2014\/03\/Workplace_Safety_Signs-300x290.jpg\" alt=\"Basic Rules of Refactoring\" width=\"300\" height=\"290\" srcset=\"https:\/\/blog.adrianbolboaca.ro\/wp-content\/uploads\/2014\/03\/Workplace_Safety_Signs-300x290.jpg 300w, https:\/\/blog.adrianbolboaca.ro\/wp-content\/uploads\/2014\/03\/Workplace_Safety_Signs.jpg 426w\" sizes=\"(max-width: 300px) 100vw, 300px\" \/><\/a><figcaption id=\"caption-attachment-1155\" class=\"wp-caption-text\">Basic Rules of Refactoring<\/figcaption><\/figure>\n<p><!--more--><\/p>\n<h3>Concept<\/h3>\n<p>The following steps are very useful when moving code from one place to another. These steps are extremely useful if your code editor does not have automated refactoring tools. But even if your code editor has these refactoring tools, try to use these rules to check if the automated refactorings are safe enough.<\/p>\n<p>The <strong>basic rules of refactoring<\/strong> are very useful during any refactoring activity:<\/p>\n<ul>\n<li>when we have tests covering the code<\/li>\n<li>for changing just the structure of the code<\/li>\n<li>without changing the functionality<\/li>\n<\/ul>\n<p><b>Steps<\/b><\/p>\n<ol>\n<li>Write some system tests like in <a href=\"\/2014\/04\/from-nothing-to-system-tests\/\">here<\/a><\/li>\n<li>Duplicate implementation<\/li>\n<li>Cover duplicated implementation with tests<br \/>\nThese are characterization tests<br \/>\nRefactor the code if needed<br \/>\nMake sure you have enough coverage<\/li>\n<li>Reroute original code to new code<\/li>\n<li>Remove old implementation<\/li>\n<li>Check all tests pass<\/li>\n<li>Test manually<\/li>\n<\/ol>\n<p>Let&#8217;s take the steps one by one:<\/p>\n<p><strong>Step 1: System tests<\/strong><br \/>\nIn order to make sure the following changes will not introduce defects, we need to focus on writing some system tests first. If the system&#8217;s design permits we can also write some unit tests, integration tests, component tests or other types of tests if needed.<br \/>\nIt is important to have these tests to cover only the part of the system we will change, and not more.<br \/>\nWe need to check if the tests we wrote cover enough of the code base.<\/p>\n<p><strong>Step 2: Duplicate Implementation<\/strong><br \/>\nWhenever some part of the code needs to be refactored, we need to extract that part of the code. First of all we need to duplicate the code. We need to chose a part of the code that is independent, or that can be easily extracted to a different place.<br \/>\nMake sure the extracted code is small enough so you will be able to integrate fast with the big code base. The larger the duplicated code base, the more likely to have problems with integration at the end.<\/p>\n<p><strong>Step 3: Cover duplicated implementation with tests<\/strong><br \/>\nOnce the code has been copied to a different place, we need to cover the extracted code with tests. If we can we should start with unit tests. If there are static dependencies we need first of all to write some component tests. After writing component tests we can extract the static dependencies and write unit tests. At the end we might want to write some acceptance tests, if the duplicated code needs that.<\/p>\n<p>All these tests are characterization tests. The tests written on existing code help us characterize the system. We focus on understanding the system and documenting it with automated tests.<\/p>\n<p>After we have all these tests we can refactor the code to have less coupling, better abstractions and a clear intention of the code. We need to keep the same input and output interfaces (contracts) as this code will be called in the next step by the bigger system.<\/p>\n<p>We need to constantly check if we have enough tests for the code we have just extracted. For that we can use a static test coverage analysis, or if the code is small enough we could just make some complexity computations.<\/p>\n<p><strong>Step 4: Reroute code<\/strong><br \/>\nOnce we wrote enough tests for the code we duplicated we can call the duplicated and tested code from the initial big code base. We need to run the initial system tests to make sure the code now does the thing it was supposed to.<\/p>\n<p>If the tests are not green, we need to see what the problem is. The safest thing is to reset the changes in order to see where the mistakes came from. Even though reseting seems tough, it is the safest step to take. If you want to make sure that you will not introduce mistakes, just reset and learn from this.<br \/>\nIf you will not reset, you need to understand perfectly the risks you are taking.<\/p>\n<p>In the ideal case, nothing bad will happen and all the tests will be green. This means that we took small and safe steps, or we were just lucky.<\/p>\n<p><strong>Step 5:&nbsp; Remove old implementation<\/strong><br \/>\nThe tests pass, the code was extracted, so we do not need the initial code that was duplicated. This is the moment to remove the old code.<br \/>\nSome code editors will show us a warning that we have unused code. All of it must go away.<\/p>\n<p><strong>Step 6: Test the whole system<\/strong><br \/>\nWe have deleted all the unused code, and now it is the time to run all the test suites: unit tests first, component tests, integration tests, system tests, acceptance tests. If everything is green, it means that we have most likely made a safe refactoring.<\/p>\n<p><strong>Step 7: Test manually<\/strong><br \/>\nEven though we have a lot of automated tests, we still need to test manually. Follow a test plan with a couple of manual testing scenarios both for happy path and exceptions. If everything is fine, we can say we have done a great refactoring and the code is better.<\/p>\n<p>If we have some minor issues we can fix them on the spot. But remember to make sure they are small and easily fixable.<\/p>\n<p>If we have major issues, the reasonable thing is to reset and start all over. Then we can analyse what were the mistakes and learn from them. In order to make sure this step is not waste, but learning we need to retrospect on what were the good and bad decisions on the way.<\/p>\n<h3>Outcomes<\/h3>\n<p>These steps are for ensuring a high level of safety while refactoring.<\/p>\n<p>By following these guidelines we can minimize the waste of fixing bugs, but with the cost of a time investment in small and safe steps.<\/p>\n<h3>Remarks<\/h3>\n<p>Remember to commit after each step. Remember to commit during each step. Committing often with good messages helps you minimize the risks and lets you focus on one simple thing at a time.<\/p>\n<p>These steps are guidelines, so feel free to change them as you feel fit. But try them as they are again and again until you find a way to improve them. They are difficult to respect in the beginning, but they ensure safety and a constant pace.<\/p>\n<p>If you have a code editor that can do these things automatically, make sure you have tests covering the implementation. Do not believe that the code editor is bug-free. Or sometimes it can happen that the automated refactorings are thought for a different purpose than how you are using them.<\/p>\n<p>The basic rules of refactoring are very useful for legacy code. But they are useful as well when refactoring a code base covered already by tests. By doing small and safe steps we can have a steady pace, without needing to understand our last changes or fix strange bugs.<\/p>\n<p>Sometimes you may feel that you do not need to take small and safe steps. Be aware that we often minimize the complexity of things. It is better to be safe than sorry.<\/p>\n<h3>History<\/h3>\n<p>I found about the basic rules of refactoring from <a href=\"https:\/\/twitter.com\/jbrains\">JB Rainsberger<\/a> during the first Legacy Coderetreat I attended in Belgium. I have used them since then, and I am very happy they decreased dramatically the number of my programmer&#8217;s mistakes (or bugs) when working with legacy code.<\/p>\n<h3>Code Cast<\/h3>\n<p>Please find <a href=\"\/2015\/03\/episode-5-basic-rules-of-refactoring\/\">here<\/a> a code cast in Java about this session<\/p>\n<p>&nbsp;<\/p>\n<p>Image credit: http:\/\/upload.wikimedia.org\/wikipedia\/commons\/0\/02\/Workplace_Safety_Signs.jpg<\/p>\n<a target=\"_blank\" href=\"https:\/\/drpeterscode.com\/bad-bot-exterminator-protects-wordpress-sites-from-hackers-cyber-ddos-dos-attacks.php\"><img src=\"https:\/\/blog.adrianbolboaca.ro\/wp-content\/plugins\/dpabottomofpostpage\/apixel1x1.jpg\" ><\/a><table><\/table>","protected":false},"excerpt":{"rendered":"<p>Basic Rules of Refactoring Blog post series This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click&hellip; <\/p>\n","protected":false},"author":3,"featured_media":2473,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[61,347],"tags":[256,113,65,106,260,120],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v22.0 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>Basic Rules of Refactoring, Legacy Code - Adrian Bolboaca<\/title>\n<meta name=\"description\" content=\"These basic rules of refactoring help you take small steps and avoid mistakes. When you need to move or extract code these rules are very useful.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Basic Rules of Refactoring, Legacy Code - Adrian Bolboaca\" \/>\n<meta property=\"og:description\" content=\"These basic rules of refactoring help you take small steps and avoid mistakes. When you need to move or extract code these rules are very useful.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/\" \/>\n<meta property=\"og:site_name\" content=\"Adrian Bolboaca\" \/>\n<meta property=\"article:published_time\" content=\"2014-12-02T07:06:54+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2020-01-15T17:56:30+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/blog.adrianbolboaca.ro\/wp-content\/uploads\/2014\/12\/legacy-code-part-6-1024x576.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1024\" \/>\n\t<meta property=\"og:image:height\" content=\"576\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Adrian Bolboaca\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Adrian Bolboaca\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"7 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/\"},\"author\":{\"name\":\"Adrian Bolboaca\",\"@id\":\"https:\/\/blog.adrianbolboaca.ro\/#\/schema\/person\/9894e1b2a4241be86991388625407d76\"},\"headline\":\"Legacy Coderetreat: Part 6 &#8211; Basic rules of refactoring\",\"datePublished\":\"2014-12-02T07:06:54+00:00\",\"dateModified\":\"2020-01-15T17:56:30+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/\"},\"wordCount\":1326,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/blog.adrianbolboaca.ro\/#\/schema\/person\/9894e1b2a4241be86991388625407d76\"},\"keywords\":[\"Coderetreat\",\"Legacy\",\"legacy code\",\"Legacy Coderetreat\",\"Refactoring\",\"Rule\"],\"articleSection\":[\"Legacy code\",\"Legacy Code Post\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/\",\"url\":\"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/\",\"name\":\"Basic Rules of Refactoring, Legacy Code - Adrian Bolboaca\",\"isPartOf\":{\"@id\":\"https:\/\/blog.adrianbolboaca.ro\/#website\"},\"datePublished\":\"2014-12-02T07:06:54+00:00\",\"dateModified\":\"2020-01-15T17:56:30+00:00\",\"description\":\"These basic rules of refactoring help you take small steps and avoid mistakes. When you need to move or extract code these rules are very useful.\",\"breadcrumb\":{\"@id\":\"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/blog.adrianbolboaca.ro\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Legacy Coderetreat: Part 6 &#8211; Basic rules of refactoring\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/blog.adrianbolboaca.ro\/#website\",\"url\":\"https:\/\/blog.adrianbolboaca.ro\/\",\"name\":\"Adrian Bolboaca\",\"description\":\"Programmer, Trainer, Coach\",\"publisher\":{\"@id\":\"https:\/\/blog.adrianbolboaca.ro\/#\/schema\/person\/9894e1b2a4241be86991388625407d76\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/blog.adrianbolboaca.ro\/?s={search_term_string}\"},\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"en-US\"},{\"@type\":[\"Person\",\"Organization\"],\"@id\":\"https:\/\/blog.adrianbolboaca.ro\/#\/schema\/person\/9894e1b2a4241be86991388625407d76\",\"name\":\"Adrian Bolboaca\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/blog.adrianbolboaca.ro\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/blog.adrianbolboaca.ro\/wp-content\/uploads\/2019\/11\/Adi-300x400.jpg\",\"contentUrl\":\"https:\/\/blog.adrianbolboaca.ro\/wp-content\/uploads\/2019\/11\/Adi-300x400.jpg\",\"width\":300,\"height\":400,\"caption\":\"Adrian Bolboaca\"},\"logo\":{\"@id\":\"https:\/\/blog.adrianbolboaca.ro\/#\/schema\/person\/image\/\"},\"description\":\"Adrian was involved in developing software for domains like energy, ecommerce, banking, customs and ERP\/CRM. He has been working with companies from Netherlands, Romania, Italy, France and Germany, and he is knowledgeable in software technical domains like: clean code, unit testing, test driven development, simple design, emergent design, working effectively with legacy code. As a continuous learner and challenger of existing ideas and concepts, Adrian is a supporter of movements that give new ideas on how to continuously improve software and that embrace the values of software quality and efficiency. He facilitated many code retreats in Romania, Belgium, France, Germany, Netherlands, Finland, Bulgaria and has a keen interest in serious games and using gamestorming for continuous improvement. He is fluent in Romanian, English and French, but when it comes to programming languages he supports language agnosticism, since he strongly believes that a programming language is only a tool towards higher level software concepts. As a constant participant to conferences and workshops, he is recognized for challenging ideas and getting people out of their comfort zone, not out of disrespect or lack of reverence for his peers, but out of his desire to show people that there are always things to learn. \u201cI try to be a continuous learner and a continuous teacher, because I think good software comes from the skills of the people that are involved in the process, on each and every level. Whenever I write code I focus on reducing domain complexity to obtain maintainable software. I love to develop software that helps companies to improve their business, to implement solutions that improve their internal processes and to motivate teams to use their capabilities to yet another level.\u201d Adrian works as a technical and organizational trainer and coach at Mozaic Works.\",\"sameAs\":[\"http:\/\/blog.adrianbolboaca.ro\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Basic Rules of Refactoring, Legacy Code - Adrian Bolboaca","description":"These basic rules of refactoring help you take small steps and avoid mistakes. When you need to move or extract code these rules are very useful.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/","og_locale":"en_US","og_type":"article","og_title":"Basic Rules of Refactoring, Legacy Code - Adrian Bolboaca","og_description":"These basic rules of refactoring help you take small steps and avoid mistakes. When you need to move or extract code these rules are very useful.","og_url":"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/","og_site_name":"Adrian Bolboaca","article_published_time":"2014-12-02T07:06:54+00:00","article_modified_time":"2020-01-15T17:56:30+00:00","og_image":[{"width":1024,"height":576,"url":"https:\/\/blog.adrianbolboaca.ro\/wp-content\/uploads\/2014\/12\/legacy-code-part-6-1024x576.png","type":"image\/png"}],"author":"Adrian Bolboaca","twitter_misc":{"Written by":"Adrian Bolboaca","Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/#article","isPartOf":{"@id":"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/"},"author":{"name":"Adrian Bolboaca","@id":"https:\/\/blog.adrianbolboaca.ro\/#\/schema\/person\/9894e1b2a4241be86991388625407d76"},"headline":"Legacy Coderetreat: Part 6 &#8211; Basic rules of refactoring","datePublished":"2014-12-02T07:06:54+00:00","dateModified":"2020-01-15T17:56:30+00:00","mainEntityOfPage":{"@id":"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/"},"wordCount":1326,"commentCount":0,"publisher":{"@id":"https:\/\/blog.adrianbolboaca.ro\/#\/schema\/person\/9894e1b2a4241be86991388625407d76"},"keywords":["Coderetreat","Legacy","legacy code","Legacy Coderetreat","Refactoring","Rule"],"articleSection":["Legacy code","Legacy Code Post"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/","url":"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/","name":"Basic Rules of Refactoring, Legacy Code - Adrian Bolboaca","isPartOf":{"@id":"https:\/\/blog.adrianbolboaca.ro\/#website"},"datePublished":"2014-12-02T07:06:54+00:00","dateModified":"2020-01-15T17:56:30+00:00","description":"These basic rules of refactoring help you take small steps and avoid mistakes. When you need to move or extract code these rules are very useful.","breadcrumb":{"@id":"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/blog.adrianbolboaca.ro\/2014\/12\/basic-rules-of-refactoring\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/blog.adrianbolboaca.ro\/"},{"@type":"ListItem","position":2,"name":"Legacy Coderetreat: Part 6 &#8211; Basic rules of refactoring"}]},{"@type":"WebSite","@id":"https:\/\/blog.adrianbolboaca.ro\/#website","url":"https:\/\/blog.adrianbolboaca.ro\/","name":"Adrian Bolboaca","description":"Programmer, Trainer, Coach","publisher":{"@id":"https:\/\/blog.adrianbolboaca.ro\/#\/schema\/person\/9894e1b2a4241be86991388625407d76"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/blog.adrianbolboaca.ro\/?s={search_term_string}"},"query-input":"required name=search_term_string"}],"inLanguage":"en-US"},{"@type":["Person","Organization"],"@id":"https:\/\/blog.adrianbolboaca.ro\/#\/schema\/person\/9894e1b2a4241be86991388625407d76","name":"Adrian Bolboaca","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/blog.adrianbolboaca.ro\/#\/schema\/person\/image\/","url":"https:\/\/blog.adrianbolboaca.ro\/wp-content\/uploads\/2019\/11\/Adi-300x400.jpg","contentUrl":"https:\/\/blog.adrianbolboaca.ro\/wp-content\/uploads\/2019\/11\/Adi-300x400.jpg","width":300,"height":400,"caption":"Adrian Bolboaca"},"logo":{"@id":"https:\/\/blog.adrianbolboaca.ro\/#\/schema\/person\/image\/"},"description":"Adrian was involved in developing software for domains like energy, ecommerce, banking, customs and ERP\/CRM. He has been working with companies from Netherlands, Romania, Italy, France and Germany, and he is knowledgeable in software technical domains like: clean code, unit testing, test driven development, simple design, emergent design, working effectively with legacy code. As a continuous learner and challenger of existing ideas and concepts, Adrian is a supporter of movements that give new ideas on how to continuously improve software and that embrace the values of software quality and efficiency. He facilitated many code retreats in Romania, Belgium, France, Germany, Netherlands, Finland, Bulgaria and has a keen interest in serious games and using gamestorming for continuous improvement. He is fluent in Romanian, English and French, but when it comes to programming languages he supports language agnosticism, since he strongly believes that a programming language is only a tool towards higher level software concepts. As a constant participant to conferences and workshops, he is recognized for challenging ideas and getting people out of their comfort zone, not out of disrespect or lack of reverence for his peers, but out of his desire to show people that there are always things to learn. \u201cI try to be a continuous learner and a continuous teacher, because I think good software comes from the skills of the people that are involved in the process, on each and every level. Whenever I write code I focus on reducing domain complexity to obtain maintainable software. I love to develop software that helps companies to improve their business, to implement solutions that improve their internal processes and to motivate teams to use their capabilities to yet another level.\u201d Adrian works as a technical and organizational trainer and coach at Mozaic Works.","sameAs":["http:\/\/blog.adrianbolboaca.ro"]}]}},"_links":{"self":[{"href":"https:\/\/blog.adrianbolboaca.ro\/wp-json\/wp\/v2\/posts\/41"}],"collection":[{"href":"https:\/\/blog.adrianbolboaca.ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.adrianbolboaca.ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.adrianbolboaca.ro\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.adrianbolboaca.ro\/wp-json\/wp\/v2\/comments?post=41"}],"version-history":[{"count":0,"href":"https:\/\/blog.adrianbolboaca.ro\/wp-json\/wp\/v2\/posts\/41\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.adrianbolboaca.ro\/wp-json\/wp\/v2\/media\/2473"}],"wp:attachment":[{"href":"https:\/\/blog.adrianbolboaca.ro\/wp-json\/wp\/v2\/media?parent=41"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.adrianbolboaca.ro\/wp-json\/wp\/v2\/categories?post=41"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.adrianbolboaca.ro\/wp-json\/wp\/v2\/tags?post=41"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}