path: root/translations/pt-BR.md

# 💻📖 hacker-laws

Leis, teorias, princípios e padrões que desenvolvedores acharão úteis.

[Traduções](#translations): [🇮🇩](./translations/pt-BR.md) [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translations/fr.md) [🇬🇷](./translations/el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr) [🇯🇵](./translations/jp.md)

Gostou deste projeto? Por favor, considere [me apoiar](https://github.com/sponsors/dwmkerr) e [apoiar os tradutores](#traduções).

---

<!-- vim-markdown-toc GFM -->

* [Introdução](#introdução)
* [Leis](#leis)
  * [Princípio 90-9-1 (Regra do 1%)](#princípio-90-9-1-regra-do-1)
  * [Lei de Amdahl](#lei-de-amdahl)
  * [Teoria das Janelas Quebradas](#teoria-das-janelas-quebradas)
  * [Lei de Brook](#lei-de-brook)
  * [Lei de Conway](#lei-de-conway)
  * [Lei de Cunningham](#lei-de-cunningham)
  * [Número de Dunbar](#número-de-dunbar)
  * [Lei de Gall](#lei-de-gall)
  * [Lei de Goodhart](#lei-de-goodhart)
  * [Navalha de Hanlon](#navalha-de-hanlon)
  * [Lei de Hofstadter](#lei-de-hofstadter)
  * [Lei de Hutber](#lei-de-hutber)
  * [O Ciclo Hype e Lei de Amara](#o-ciclo-hype-e-lei-de-amara)
  * [Lei de Hyrum (Lei das Interfaces Implícitas)](#lei-de-hyrum-lei-das-interfaces-implícitas)
  * [Lei de Kernighan](#lei-de-kernighan)
  * [Lei de Metcalfe](#lei-de-metcalfe)
  * [Lei de Moore](#lei-de-moore)
  * [Lei de Murphy / Lei de Sod](#lei-de-murphy--lei-de-sod)
  * [Navalha de Occam](#navalha-de-occam)
  * [Lei de Parkinson](#lei-de-parkinson)
  * [Efeito de Otimização Prematura](#efeito-de-otimização-prematura)
  * [Lei de Putt](#lei-de-putt)
  * [Lei de Reed](#lei-de-reed)
  * [A Lei da Conservação da Complexidade (Lei de Tesler)](#a-lei-da-conservação-da-complexidade-lei-de-tesler)
  * [A Lei das Abstrações Gotejantes](#a-lei-das-abstrações-gotejantes)
  * [A Lei da Trivialidade](#a-lei-da-trivialidade)
  * [A Filosofia Unix](#a-filosofia-unix)
  * [O Modelo Spotify](#o-modelo-spotify)
  * [Lei de Wadler](#lei-de-wadler)
  * [Lei de Wheaton](#lei-de-wheaton)
* [Princípios](#princípios)
  * [O Princípio Dilbert](#o-princípio-dilbert)
  * [O Princípio de Pareto (Regra do 80/20)](#o-princípio-de-pareto-regra-do-8020)
  * [O Princípio de Peter](#o-princípio-de-peter)
  * [O Princípio da Robustez (Lei de Postel)](#o-princípio-da-robustez-lei-de-postel)
  * [SOLID](#solid)
  * [O Princípio da Responsabilidade Única](#o-princípio-da-responsabilidade-única)
  * [O Princípio do Aberto/Fechado](#o-princípio-do-abertofechado)
  * [O Princípio da Substituição de Liskov](#o-princípio-da-substituição-de-liskov)
  * [O Princípio da Segregação de Interface](#o-princípio-da-segregação-de-interface)
  * [O Princípio da Inversão de Dependência](#o-princípio-da-inversão-de-dependência)
  * [O Princípio DRY](#o-princípio-dry)
  * [O Princípio KISS](#o-princípio-kiss)
  * [YAGNI](#yagni)
  * [As Falácias da Computação Distribuída](#as-falácias-da-computação-distribuída)
* [Lista de leitura](#lista-de-leitura)
* [Traduções](#traduções)
* [Projetos relacionados](#projetos-relacionados)
* [Contribuindo](#contribuindo)
* [Em construção](#em-construção)

<!-- vim-markdown-toc -->

## Introdução

Existem muitas leis sobre as quais as pessoas discutem quando falam sobre desenvolvimento. Este repositório é uma referência e uma visão global das mais comuns. Sinta-se a vontade para contribuir e compartilhar.

❗: Este repositório contém explicações sobre algumas leis, princípios e padrões, mas não _advoga_ nenhum. Se eles devem ser aplicados é uma questão de discussão, e depende diretamente no que você está trabalhando.

## Leis

E lá vamos nós!

### Princípio 90-9-1 (Regra do 1%)

[1% Rule on Wikipedia](https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture))

O Princípio 90-9-1 sugere que em uma comunidade da internet, como uma wiki, 90% dos participantes apenas consomem o conteúdo, 9% editam ou modificam o conteúdo e 1% dos participantes adicionam novos conteúdos.

Exemplos do mundo real:

- Um estudo de 2014 de quatro redes sociais de saúde digital concluíram que 1% dos usuários criaram 73% das publicações, os próximos 9% foram responsáveis por cerca de ~25% e os 90% restantes por uma média de 2% ([Referência](https://www.jmir.org/2014/2/e33/))

Veja também:

- [O Princípio de Pareto (Regra do 80/20)](#o-princípio-de-pareto-regra-do-8020)

### Lei de Amdahl

[Lei de Amdahl na Wikipédia](https://pt.wikipedia.org/wiki/Lei_de_Amdahl)

> A lei de Amdahl, também conhecida como argumento de Amdahl, é usada para encontrar a máxima melhora esperada para um sistema em geral quando apenas uma única parte do mesmo é melhorada. Isto é frequentemente usado em computação paralela para prever o máximo speedup teórico usando múltiplos processadores. A lei possui o nome do Arquiteto computacional Gene Amdahl, e foi apresentada a AFIPS na Conferência Conjunta de Informática na primavera de 1967.

Fica mais fácil de entender com um exemplo prático. Se um programa é feito de duas partes, parte A, que é executada por um processador único, e parte B, que pode ser feito paralelamente com N processadores. Se adicionarmos mais processadores ao sistema, só vai ter aumento nas tarefas relacionadas à parte B do programa. A velocidade de A se mantém a mesma.

O diagrama abaixo mostra alguns exemplos de melhoria na velocidade:

![Diagram: Lei de Amadhl](../images/amdahls_law.png)

*(Image Reference: By Daniels220 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*

Como pode-se perceber, mesmo um programa que teve metade da sua implementação de forma paralela, o benefício é menos de 10 _processing units_. Porém, um programa 95% paralelo, o ganho pode passar de 20 _processing units_.

### Teoria das Janelas Quebradas

[The Broken Windows Theory on Wikipedia](https://en.wikipedia.org/wiki/Broken_windows_theory)

A Teoria das Janelas Quebradas sugere que sinais visíveis de crimes (ou a falta de cuidado por um ambiente) leva a crimes mais sérios (ou mais deterioração do ambiente).

Essa teoria tem sido aplicada no desenvolvimento de software, sugerindo que a baixa qualidade do código (ou o [Débito Técnico](#TODO)) podem levar a percepção de que esforços para melhorar a qualidade talvez sejam ignorados ou desvalorizados, mantendo a baixa qualidade. Esse efeito de cascata leva a uma grande diminuição na qualidade através do tempo.

Veja também:

- [Débito Técnico](#TODO)

Exemplos:

- [The Pragmatic Programming: Software Entropy](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy)
- [Coding Horror: The Broken Window Theory](https://blog.codinghorror.com/the-broken-window-theory/)
- [OpenSource: Joy of Programming - The Broken Window Theory](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/)

### Lei de Brook

[Lei de Brooks na Wikipedia](https://en.wikipedia.org/wiki/Brooks%27s_law)

> Adicionar recursos humanos em um projeto, de desenvolvimento de software, atrasado, faz ficar ainda mais atrasado.

Essa lei sugere que em muitos casos, na tentativa de acelerar uma entrega, que já está atrasada, adicionando mais pessoas atrasa ainda mais essa entrega. Brooks assume que essa afirmação é uma generalização excessiva, entretanto, o principal motivo para isso acontecer é dado pelo simples fato de adicionar pessoas requer um gasto com comunicação e construção de novos recursos para a equipe suportar novos membros. Logo, a curto prazo esse investimento não tem um retorno. Também existem tarefas que não podem ser dividias, portanto adicionar mais pessoas não vai fazer ela ser concluída mais rápido.

"Nove mulheres não podem parir uma criança em um mês" e "Dois pilotos não fazem o carro ir mais rápido" são frases relacionadas a Lei de Brooks, principalmente porque algumas tarefas não podem ser divididas.

Esse é um tema central do livro '[The Mythical Man Month](#lista-de-livros)'.

Veja também:

- [Death March](#em-progresso)
- [Livro: The Mythical Man Month](#lista-de-livros)

### Lei de Conway

[Lei de Conway na wikipedia](https://en.wikipedia.org/wiki/Conway%27s_law)

Essa lei sugere que limites técnicos de um sistema refletirão na estrutura da organização. Se uma organização é estruturada em pequenos setores, desconexas unidades, o software que ela produz sera assim também. Se uma organização é construída de forma vertical, em torno de funcionalidades e serviços, terá reflexo disso dentro do sistema.

Veja também:

- [Modelo do Spotify](#modelo-spotify)

### Lei de Cunnigham

[Cunningham's Law on Wikipedia](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law)

> A melhor forma de obter a resposta correta na Internet não é fazer a pergunta, mas postar a resposta errada.

De acordo com Steven McGeady, Ward Cunningham o aconselhou no início dos anos 80: "A melhor forma de ter a resposta correta na Internet não é fazer a pergunta, mas postar a resposta errada." McGeady apelidou essa lei de "Lei de Cunningham", mesmo que Cunningham negue sua propriedade chamando-a de "citação". Mesmo originalmente se referindo a interações na Usenet, a lei tem sido utilizada para descrever como comunidades online funcionam (e.x.: Wikipedia, Reddit, Twitter, Facebook).

Veja também:

- [XKCD 386: "Duty Calls"](https://xkcd.com/386/)

### Número de Dunbar

[Número de Dunbar na Wikipedia](https://en.wikipedia.org/wiki/Dunbar%27s_number)

Dunbar propôs que humanos só conseguem manter de forma confortável, 150 relacionamentos estáveis. Esse número está mais em um contexto social, "o número de pessoas que você não se sentiria sem graça para se juntar em uma bebida se esbarrasse com ela em um bar". Esse número geralmente está entra 100 e 250.

Esse número é uma sugestão cognitiva limite para o número de pessoas para qual consegue-se manter uma relação social estável.

Como uma relação entre pessoas, manter uma relação entre desenvolvedor e código requer esforço. É necessário usar politicas, padrões e procedimentos para encarar projetos complicados ou qualquer adversidade possível nesse tipo de relação. Número de Dunbar é importante em vários aspectos, não somente quando a empresa está em crescimento, mas também ao definir o escopo para os esforços da equipe ou decidir quando um sistema deve investir em ferramentas para auxiliar na sobrecarga da logística. Colocando em contexto de engrenharia, é o número de projetos para os quais você se sentiria confiante para ingressar em uma rotação de plantão de suporte.

Veja também:

- [Lei de Conway](#lei-de-conway)

### Lei de Gall

[Gall's Law on Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law)

> Um sistema complexo que funciona é invariavelmente encontrado para ter evoluído a partir de um sistema simples que trabalhou. Um sistema complexo projetado a partir do zero nunca funciona e não pode ser remendado para fazê-lo funcionar.

A Lei de Gall afirma que tentativas de projetar sistemas altamente complexos provavelmente falharão. Sistemas altamente complexos raramente são construídos em uma vez só, mas evoluem a partir de sistemas mais simples.

Um exemplo clássico é a world-wide-web. Em seu estado atual, ela é um sistema altamente complexo. Contudo, ela foi definida inicialmente como uma forma simples de compartilhar conteúdo entre instituições acadêmicas. Ela foi tão bem-sucedida em atingir esses objetivos que evoluiu para se tornar algo mais complexo ao longo do tempo.

Veja também:

- [KISS (Keep It Simple, Stupid)](#o-princípio-kiss)

### Lei de Goodhart

[The Goodhart's Law on Wikipedia](https://en.wikipedia.org/wiki/Goodhart's_law)

> Qualquer regularidade estatística observada tende a entrar em colapso quando a pressão é aplicada para fins de controle.
>
> _Charles Goodhart_


Também referenciada como:

> Quando uma medida torna-se uma meta (ou alvo), ela deixa de ser uma boa medida.
>
> _Marilyn Strathern_

A lei diz que otimizações orientadas por medidas podem levar à uma desvalorização do próprio resultado da medição. O conjunto de medidas excessivamente seletivo ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) aplicado cegamente a um processo resulta em um efeito distorcido. As pessoas tentem a otimizar localmente "jogando com" o sistema para satisfazer métricas específicas ao invés de prestar atenção ao resultado holístico de suas ações.

Exemplos do mundo real:
- Testes sem `assertions` atendem à cobertura de código esperada, apesar do objetivo da métrica era criar software bem testado
- A pontuação do desempenho de desenvolvedores é indicada pelo número de linhas `commitadas` leva a uma base de código injustificadamente inchada.

Veja também:
- [Goodhart’s Law: How Measuring The Wrong Things Drive Immoral Behaviour](https://coffeeandjunk.com/goodharts-campbells-law/)
- [Dilbert on bug-free software](https://dilbert.com/strip/1995-11-13)

### Navalha de Hanlon

[Navalha de Hanlon na wikipedia](https://en.wikipedia.org/wiki/Hanlon%27s_razor)

> Nunca atribua à malícia aquilo que é adequadamente explicado por estupidez.
>
> Robert J. Hanlon

Esse principio sugere que ações negativas não são sempre resultado de má vontade. Em vez disso, é mais provável que o resultado negativo seja atribuído à ações que não foram totalmente entendidas.

### Lei de Hofstadter

[Lei de Hofstadter na Wikipedia](https://en.wikipedia.org/wiki/Hofstadter%27s_law)


> Sempre leva mais tempo do que esperado, mesmo quando se leva em conta a lei do Hofstadter.
>
> Douglas Hofstadter

Você já deve ter ouvido sobre essa lei quando se fala em estimar tempo para fazer algo. Quando se fala em desenvolvimento de software parece obvio que nós tendemos a não sermos muitos precisos em estimar quando tempo levará para entregar alguma coisa.

This is from the book '[Gödel, Escher, Bach: An Eternal Golden Braid](#lista-de-livros)'.

### Lei de Hutber

[Hutber's Law on Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law)

> Melhoria significa deterioração.
>
> _([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))_

Essa lei sugere que melhorias em um sistema irão levar à deterioração em outras partes, ou elas ocultarão outras deteriorações, levando a uma degradação do estado atual do sistema.

Por exemplo, a diminuição na latência da resposta para um `end-point` particular pode causar um aumento na taxa de transferência e na capacidade ao longo de um fluxo de solicitação, afetando um subsistema totalmente diferente.


### O Ciclo Hype e Lei de Amara

[The ciclo Hype on Wikipedia](https://en.wikipedia.org/wiki/Hype_cycle)

> Nós tendemos a superestimar os efeitos da tecnologia em curto prazo e subestimar os efeitos a longo prazo.
>
> Roy Amara

O Ciclo Hype é uma representação visual da empolgação e desenvolvimento da tecnologia ao longo do tempo, originalmente produzida por Gartner.
![The Hype Cycle](../images/gartner_hype_cycle.png)

*(Image Reference: By Jeremykemp at English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*

Em curto prazo, o ciclo sugere que acontece uma explosão de empolgação a cerca de uma nova tecnologia e seu impacto em potencial. Equipes geralmente entram juntas nessas tecnologias de forma rápida e em alguns casos ficam desapontadas com os resultados. Uma das possíveis causas para isso é o fato da tecnologia em questão não ser madura o suficiente, ou aplicações do mundo real que não estão totalmente prontas. Depois de um certo tempo, a capacidade da tecnologia aumenta e oportunidades práticas para uso dela aumentam, as equipes finalmente podem ser produtivas. A citação de Amara resume isso de forma sucinta - "Nós tendemos a superestimar os efeitos da tecnologia em curto prazo e subestimar os efeitos a longo prazo".


### Lei de Hyrum (Lei das Interfaces Implícitas)

[Lei de Hyrum site](http://www.hyrumslaw.com/)

> Com um número suficientes de clientes de uma API,
> não importa a sua pré-condição no contato:
> todos os comportamentos observáveis do seu sistema
> serão dependentes de alguém.
>
> Hyrum Wright

A lei de Hyrum sugere que quando você tem um número muito grande de consumidores de uma API, todos os comportamentos dessa API (mesmo aqueles que não estão definidos como parte de um contrato público) eventualmente irão depender de outra parte do sistema, ou outra API. Um exemplo trivial pode ser elementos não funcionais, como o tempo de resposta de uma API. Um exemplo mais sutil pode ser os consumidores que estão confiando em aplicar um regex a uma mensagem de erro para determinar o _tipo_ de erro de uma API. Mesmo que o contrato público da API não especifique nada sobre o conteúdo da mensagem, indicando que os usuários devem usar um código de erro associado, alguns usuários podem usar a mensagem e alterar a mensagem essencialmente interrompe a API para esses usuários.

Veja Também:

- [XKCD 1172](https://xkcd.com/1172/)


### Lei de Kernighan

> A depuração é duplamente mais difícil do que escrever o código em primeiro lugar. Portanto, se você escrever o código da