added thing_14 in pt_br

pt_br/SUMMARY.md

@@ -14,7 +14,7 @@
 1. [Desenvolva usando a linguagem do domínio de negócios](thing_11/README.md)
 1. [Código é Design](thing_12/README.md)
 1. [O layout do código é importante](thing_13/README.md)
-1. [Code Reviews](thing_14/README.md)
+1. [Revisão de código](thing_14/README.md)
 1. [Coding with Reason](thing_15/README.md)
 1. [A Comment on Comments](thing_16/README.md)
 1. [Comment Only What the Code Cannot Say](thing_17/README.md)

pt_br/thing_14/README.md

@@ -0,0 +1,15 @@
+# Revisão de código
+
+Você deve fazer revisões de código. Porquê? Porque eles *aumentam a qualidade de código* e *reduzem a taxa de defeitos*. Mas não pelas razões que você está pensando.
+
+Devido às más experiências prévias que alguns desenvolvedores tiveram com revisões de código, muitos tendem a não gostar delas. Eu já vi organizações que exigem que todos os códigos passem por um processo de revisão formal antes de serem implementados em produção. Geralmente é o arquiteto ou desenvolvedor líder que está fazendo essa revisão, uma prática que pode ser chamada de *arquiteto revisa tudo*. Isto é estabelecido em seu manual de desenvolvimento de software, e assim os desenvolvedores devem seguir. Existem algumas organizações que precisam de tais processos rígidos e formais, mas não é a maioria. Na maior parte das organizações, tais abordagens são contraprodutivas. Desenvolvedores sendo avaliados podem se sentir julgados por um comitê de liberdade condicional. Revisores precisam tanto de tempo para ler o código como de tempo para se manterem atualizados com todos os detalhes do sistema, Os revisores podem rapidamente se tornar o gargalo nesse processo, e o processo rapidamente se degenera.
+
+Ao invés de simplesmente corrigir erros no código, o propósito de revisões de código deve ser *compartilhar conhecimento* e estabelecer diretrizes comuns de programação. Compartilhar seu código com outros programadores habilita propriedade coletiva de código. Deixe um membro aleatório *percorrer através do código* com o resto do time. Ao invés de olhar os erros, você deve revisar o código tentando aprender sobre ele e compreendê-lo.
+
+Seja gentil durante revisões de código. Garanta que os comentários são *construtivos e não tóxicos*. Introduza diferente *papéis de revisão* para a reunião de revisão, para evitar ter senioridade organizacional entre os membros afetando a revisão de código. Exemplos de papéis podem incluir um revisor com foco em documentação, outro em exceções, e um terceiro olhando a funcionalidade. Essa abordagem ajuda a espalhar a carga da revisão por todo o time.
+
+Tenha um dia de *revisão de código* a cada semana. Gaste algumas horas em uma reunião de revisão. Rotacione o desenvolvedor sujeito à revisão em cada reunião num padrão de rodízio simples. Lembre de trocar os papéis entre os membros do time a cada revisão também. *Envolva os novatos* em revisões de código. Eles podem ser inexperientes, mas sua formação universitária recente pode fornecer uma perspectiva diferente. *Envolva os especialistas* pela sua experi~encia e conhecimento. Eles irão identificar código propenso a erros mais rápido e com maior acurácia. Revisões de código fluirão melhor se o time tem *convenções de código* que são checadas por ferramentas. Desta forma, formatação de código nunca será discutida durante a reunião de revisão de código.
+
+*Tornar as revisões de código divertidas* é talvez o fator que mais contribui para o seu sucesso. Revisões de código são processos que pessoas estão revisando. Se a reunião de revisão é dolorosa ou não efetiva será difícil motivar qualquer um. Torne uma *revisão de código informal* cujo propósito principal seja compartilhar conhecimento entre os membros do time. Deixe comentários sarcásticos de fora e traga um bolo ou um almoço no lugar.
+
+Por [Mattias Karlsson](http://programmer.97things.oreilly.com/wiki/index.php/Mattias_Karlsson)