added thing_06 in pt_br

pt_br/SUMMARY.md

@@ -6,7 +6,7 @@
 1. [Pergunte-se "O que o usuário faria?" (Você não é o usuário)](thing_03/README.md)
 1. [Automatize seu padrão de codigo](thing_04/README.md)
 1. [A beleza está na simplicidade](thing_05/README.md)
-1. [Before You Refactor](thing_06/README.md)
+1. [Antes que você refatore](thing_06/README.md)
 1. [Beware the Share](thing_07/README.md)
 1. [The Boy Scout Rule](thing_08/README.md)
 1. [Check Your Code First before Looking to Blame Others](thing_09/README.md)

pt_br/thing_06/README.md

@@ -0,0 +1,19 @@
+# Antes que você refatore
+
+Em algum momento da carreira todo programador precisará refatorar código existente. Mas, antes que você faça isso, por favor pense sobre os seguintes aspectos que podem te economizar um tempo significativo (e sofrimento):
+
+- *A melhor abordagem para reestruturação se inicia por entender a base de código existente e os testes escritos contra ela.* Isso irá te ajudar a entender as forças e fraquezas do código na sua forma atual, de forma que você mantenha os pontos fortes e evite os erros. Nós sempre pensamos que podemos melhorar o sistema existente... até que nós entregamos algo que não só não é melhor - ou até pior - que o código antigo porque falhamos em aprender com as falhas do sistema existente.
+
+- *Evite a tentação de reescrever tudo.* É melhor reusar a maior quantidade de código possível. Não importa quão feio o código é, ele já foi testado, revisado e etc. Jogar fora código velho - especialmente se está em produção - significa que você está jogando fora meses (ou anos) de código testado e estressado que pode ter tido certos ajustes e correções de bugs que você não está ciente deles. Se você não leva isso em conta, o novo código que você escreve pode acabar mostrando os mesmos bugs misteriosos que foram corrigidos no código velho. Isso irá desperdiçar muito tempo, esforço e conhecimento adquirido ao longo dos anos.
+
+- *Many incremental changes are better than one massive change.* Incremental changes allows you to gauge the impact on the system more easily through feedback, such as from tests. It is no fun to see a hundred test failures after you make a change. This can lead to frustration and pressure that can in turn result in bad decisions. A couple of test failures is easy to deal with and provides a more manageable approach.
+
+- *After each iteration, it is important to ensure that the existing tests pass.* Add new tests if the existing tests are not sufficient to cover the changes you made. Do not throw away the tests from the old code without due consideration. On the surface some of these tests may not appear to be applicable to your new design, but it would be well worth the effort to dig deep down into the reasons why this particular test was added.
+
+- *Personal preferences and ego shouldn't get in the way.* If something isn't broken, why fix it? That the style or the structure of the code does not meet your personal preference is not a valid reason for restructuring. Thinking you could do a better job than the previous programmer is not a valid reason either.
+
+- *New technology is insufficient reason to refactor.* One of the worst reasons to refactor is because the current code is way behind all the cool technology we have today, and we believe that a new language or framework can do things a lot more elegantly. Unless a cost–benefit analysis shows that a new language or framework will result in significant improvements in functionality, maintainability, or productivity, it is best to leave it as it is.
+
+- *Remember that humans make mistakes.* Restructuring will not always guarantee that the new code will be better — or even as good as — the previous attempt. I have seen and been a part of several failed restructuring attempts. It wasn't pretty, but it was human.
+
+by [Rajith Attapattu](http://programmer.97things.oreilly.com/wiki/index.php/Rajith_Attapattu)