Leis, teorias, princípios e padrões que desenvolvedores acharão úteis.
Traduções: 🇮🇩 🇧🇷 🇨🇳 🇩🇪 🇫🇷 🇬🇷 🇮🇹 🇱🇻 🇰🇷 🇷🇺 🇪🇸 🇹🇷 🇯🇵
Gostou deste projeto? Por favor, considere me apoiar e apoiar os tradutores.
- Introdução
- Leis
- Princípio 90-9-1 (Regra do 1%)
- Lei de Amdahl
- Teoria das Janelas Quebradas
- Lei de Brook
- Lei de Conway
- Lei de Cunningham
- Número de Dunbar
- Lei de Gall
- Lei de Goodhart
- Navalha de Hanlon
- Lei de Hofstadter
- Lei de Hutber
- O Ciclo Hype e Lei de Amara
- Lei de Hyrum (Lei das Interfaces Implícitas)
- Lei de Kernighan
- Lei de Metcalfe
- Lei de Moore
- Lei de Murphy / Lei de Sod
- Navalha de Occam
- Lei de Parkinson
- Efeito de Otimização Prematura
- Lei de Putt
- Lei de Reed
- A Lei da Conservação da Complexidade (Lei de Tesler)
- A Lei das Abstrações Gotejantes
- A Lei da Trivialidade
- A Filosofia Unix
- O Modelo Spotify
- Lei de Wadler
- Lei de Wheaton
- Princípios
- O Princípio Dilbert
- O Princípio de Pareto (Regra do 80/20)
- O Princípio de Peter
- O Princípio da Robustez (Lei de Postel)
- SOLID
- O Princípio da Responsabilidade Única
- O Princípio do Aberto/Fechado
- O Princípio da Substituição de Liskov
- O Princípio da Segregação de Interface
- O Princípio da Inversão de Dependência
- O Princípio DRY
- O Princípio KISS
- YAGNI
- As Falácias da Computação Distribuída
- Lista de leitura
- Traduções
- Projetos relacionados
- Contribuindo
- Em construçã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.
E lá vamos nós!
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)
Veja também:
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 processaores 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:
(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.
The Broken Windows Theory on Wikipedia
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) 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:
Exemplos:
- The Pragmatic Programming: Software Entropy
- Coding Horror: The Broken Window Theory
- OpenSource: Joy of Programming - The Broken Window Theory
Adicionar recursos humanos em um projeto, de desenvolvimento de sotware, atrasado, faz ficar ainda mais atrasado.
Essa lei sugere que em muitos casos, na tentativa de acelerar uma entrega, que já está atrasada, adcionando mais pessoas atrasa ainda mais essa entrega. Brooke 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 concluida 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 Brooke, principalmente porque algumas tarefas nao podem ser divididas.
Esse é um tema central do livro 'The Mythical Man Month'.
Veja também:
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 sofware que ela produz sera assim também. Se uma organização é construida de forma vertical, em torno de funcionalidades e serviços, terá reflexo disso dentro do sistema.
Veja também:
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:
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 bebiba se esbarrase 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 pessoass para qual consegue-se manter uma relação social estável.
Como uma relação entre pessoas, manter uma relação entre desenvolvedor e codigo 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 u msistema deve investir em ferramentas para axuliar na sobrecarga da logística. Colocando em contexto de engrenharia, é o número de projetos para os quais você se sentiria confiante para ingresssar em uma rotação de plantão de suporte.
Veja também:
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:
The Goodhart's Law on Wikipedia
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) aplicado cegamenta 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
assertionsatendem à 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
commitadasleva a uma base de código injustificadamente inchada.
Veja também:
Navalha de Hanlon na wikipedia
Nunca atribua à malícia aquilo que é adequadamente explicado por estupidez.
Robert J. Hanlon
Esse principio sugeste que ações negativas não são sempre resultado de má vontade. Em vez disso, é mais provável que o resultado negativo seja atribuido à ações que não foram totalmente entendidas.
Lei de Hofstadter na Wikipedia
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'.
Melhoria significa deterioração.
Essa lei sugere que melhorias em um sistema irão levar à deterioração em outras partes, ou ela 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.
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.
(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 tecnlogias de forma rápida e em alguns casos ficam desapontados com os resutados. 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".
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 dependender 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:
A depuração é duplamente mais difícil do que escrever o código em primeiro lugar. Portanto, se você escrever o código da maneira mais inteligente possível, por definição, você não é inteligente o sufiencte para depurá-lo.
Brian Kernighan
A Lei de Kerningham é nomeada por Brian Kernighan e devivada de uma citação de Kerningham no livro The Elements of Programming Style:
Todo mundo sabe que depurar é duplamente mais difícil do que programar em primeiro lugar. Então, se você é o mais inteligente possível quando escreve, como você conseguirá depurar o código?
Enquanto hiperbólica, a Lei de Kerningham faz a argumentação de que código simples deve ser preferido ao invés de código complexo, porque depurar qualquer problema que poderá surgir em um código complexo pode ser custoso ou até mesmo inviável.
Veja também:
Na teoria das redes, o valor de um sistema cresce aproximadamente o quadrado do número de usuários daquele sistema.
Esta lei é baseada no número de possíveis conexões pareadas dentro de um sistema e é relacionada com a Lei de Reed. Odlyzko e outros argumentaram que tanto a Lei de Reed e a Lei de Metcalfe exageram o valor do sistema, não levando em consideração os limites da cognição humana sobre os efeitos da rede; veja Número de Dunbar.
Veja também:
O número de transistores dentro de um circuito integrado dobra a cada 2 anos, aproximadamente.
Até meados de 1965 não havia nenhuma previsão real sobre o futuro do hardware, quando Gordon E. Moore fez sua profecia, na qual o número de transistores dos chips teria um aumento de 100%, pelo mesmo custo, a cada período de 18 meses. Essa profecia tornou-se realidade e acabou ganhando o nome de Lei de Moore.
Esta lei serve de parâmetro para uma elevada gama de dispositivos digitais, além das CPUs. Na verdade, qualquer chip está ligado a lei de Gordon E. Moore, até mesmo o CCD de câmeras fotográficas digitais (sensor que capta a imagem nas câmeras nuclear; ou CNCL, sensores que captam imagens nas câmeras fotográficas profissionais).
Esse padrão continuou a se manter, e não se espera que pare até, no mínimo, 2021.
Tudo que poderá dar errado, irá dar errado.
Relacionada com Edward A. Murphy, Jr, a Lei de Murphy diz que se algo pode dar errado, isso dará errado.
Isso é um ditado comum entre desenvolvedores. Muitas vezes o inesperado ocorre durante o desenvolvimento, testes ou até mesmo em produção. Essa lei também pode ser relacionada a Lei de Sod (mais comum no inglês britânico):
Se algo pode dar errado, dará errado, no pior momento possível.
Essas 'leis' são geralmente utilizadas em um sentido cômico. Contudo, fenômenos como Confirmation Bias e Selection Bias podem pevar as pessoas a enfatizarem demais essas leis (na maioria das vezes quando as coisas funcionam, elas passam desapercebidas, as falhas são mais perceptíveis e atraem mais discussões).
Veja também:
Entidades não devem ser multiplicadas sem necessidade.
William of Ockham
A Navalha de Occam diz que em meio a várias possíveis soluções, a solução mais provável é aquela com menor número de conceitos e suposições. Essa solução é a mais simples e envolve apenas o problema em questão, sem introduzir complexidades acidentais e possíveis consequências negativas.
Veja também:
Exemplo:
O trabalho se expande de modo a preencher o tempo disponível para a sua realização.
A lei de Parkinson foi publicada por Cyril Northcote Parkinson num artigo na revista The Economist em 1955, sendo depois reimpresso com outros artigos no livro Parkinson's Law: The Pursuit of Progress [A lei de Parkinson: a busca do progresso].Em seu contexto original, essa Lei foi baseada em estudos de burocracia. E pode ser pessimisticamente aplicado a desenvolvimento de software, a teoria diz que equipes serão ineficientes até os prazos finais, quando irão dar o máximo até o prazo final.
Premature Optimization on WikiWikiWeb
Otimização prematura é a raiz de todo o mal.
No artigo de Donald Knuth, Structured Programming With Go To Statements, ele escreve: "Programadores perdem grandes quantidades de tempo pensando ou se preocupando com a velocidade de partes não críticas de seus programas, e essas tentativas de eficiência possuem um forte impacto negativo quando depuração e manutenção são consideradas. Nós devemos esquecer essas pequenas eficiências, cerca de 97% das vezes: otimização prematura é a raiz de todo o mal. No entando, não devemos perder a oportunidade nesses 3% críticos".
Contudo, Otimização Prematura pode ser definida (em termos menos carregados) como otimizar antes de saber o que precisamos.
Tecnologia é dominada por dois tipos de pessoa. Aqueles que entendem o que não gerenciam e aqueles que gerenciam o que não entendem.
A Lei de Putt é frequentemente seguida pelo Corolário de Putt:
Cada hierarquia técnica, no tempo, desenvolve uma inversão de competência.
Estas declarações sugerem que devido a vários critérios de seleção e tendências na forma como grupos se organizam, haverá um número de pessoas qualificadas nos níveis de trabalho de organizações técnicas, e um número de pessoas em funções gerenciais que não estão cientes das complexidades e desafios do trabalho que estão gerenciando. Isso pode ser devido a fenômenos como (#em-progresso)
Veja também:
A utilidade de grandes redes, particularmente redes sociais, escalam exponencialmente com o tamanho da própria rede.
Essa lei é baseada na teoria dos grafos, onde a utilidade é escalonada com o número de possíveis subgrupos, que é mais rápido que o número de participantes ou o número de possíveis conexões pareadas. Odlyzko e outros argumentam que a Lei de Reed exagera a utilidade de um sistema por não levar em conta os limites da cognição humana sobre os efeitos da rede; veja Número de Dunbar.
Veja também:
A lei da Conservação de Complexidade na wikipedia
Essa lei sugere que em todos sitemas sempre vai existir uma quantidade de complexidade que não pode ser reduzida.
Alguma complexidade em um sistema é "inadvertida". É uma consequência da estrutura deficiente, erros ou apenas má modelagem de um problema a ser resolvido. A complexidade inadvertida pode ser reduzida (ou eliminada). No entanto, alguma complexidade é "intrínseca" como consequência da complexidade inerente ao problema a ser resolvido. Essa complexidade pode ser movida, mas não eliminada.
Um elemento interessante para essa lei é a sugestão de que, mesmo simplificando todo o sistema, a complexidade intrínseca não é reduzida, ela é “movida para o usuário”, que deve se comportar de uma maneira mais complexa.
The Law of Leaky Abstractions on Joel on Software
Todas as abstrações não triviais, até certo ponto, são vazadas
Essa lei afirma que abstrações, as quais são geralmente utilizadas na computação para simplificar um trabalho com sistemas complexos, em certas situações irão 'vazar' elementos do sistema subjacente, fazendo com que a abstração se comporte de maneira inesperada.
Um exemplo disso pode ser carregar um arquivo e ler o seu conteúdo. As APIs do sistema de arquivo são abstrações do kernel de nível inferior, que são uma abstração dos processadores físicos relacionados à alteração de dados no disco rígido (ou na memória flash em SSD). Na maioria dos casos, a abstração de tratar um arquivo como um fluxo de dados binários funcionará. Contudo, para um disco rígido, a leitura sequencial dos dados será significamente mais rápida que o acesso aleatório (devido ao aumento da sobrecarga de falhas na página), mas para um disco SSD, essa sobrecarga não estará presente. Os detalhes subjacentes precisarão ser entendidos para lidar com esse caso (por exemplo, os arquivos índices de uma base de dados são estruturados para reduzir a sobrecarga do acesso aleatório), a abstração 'vaza' detalhes de implementação os quais o desenvolvedor precisa estar ciente.
O exemplo acima pode se tormar mais complexo quando mais abstrações são introduzidas. O sistema operacional Linux permite que os arquivos sejam acessados por rede mas representados localmente como arquivos 'normais'. Essa abstração será 'vazada' se houverem falhas de rede. Se um desenvolvedor tratar esses arquivos como 'normais', sem considerar o fato de que eles podem estar sujeitos à latência e falhas na rede, as soluções serão incorretas.
Veja também:
Exemplos do mundo real:
- Photoshop Slow Startup - um problema que eu encontrei no passado. O Photoshop demorava para abrir, às vezes levando alguns minutos. Parecia que o problema era que, ao iniciar, o programa lia algumas informações sobre a impressora padrão. No entando, se essa impressora fosse uma impressora de rede, isso demoraria tempo extremamente longo. A abstração de uma impressora de rede ser mostrada ao sistema como uma impressora local causou um problema para usuários em situação de baixa conectividade.
The Law of Triviality on Wikipedia
Essa lei sugere que grupos irão dar maior atenção para problemas triviais ou cosméticos, do que para os problemas sérios e substanciais.
O exemplo fictício comum utilizado é o de um comitê aprovando planos para uma usina nuclear, que passam maior tempo discutindo a estrutura do bicicletário ao invés do design da própria usina que é muito mais importante. Pode ser difícil fornecer informações valiosas em discussões sobre tópicos muito grandes e complexos sem um alto grau de conhecimento ou preparação no assunto. No entando, as pessoas querem ser vistas contribuindo com informações importantes. Daí uma tendência de concentrar muito tempo em pequenos detalhes, que podem ser facilmente explicados, mas necessariamente não são de importância particular.
O exemplo fictício acima levou ao uso do termo 'Bike Shedding' como uma expressão por gastar tempo em detalhes triviais.
The Unix Philosophy on Wikipedia
A Filosofia Unix prega que componentes de um software devem ser pequenos, e focados em fazer muito bem uma coisa específica. Isso torna mais fácil a construção de sistemas compondo unidades pequenas, simples e bem definidas, em vez de usar programas grandes, complexos e multiuso.
Práticas modernas como a 'Arquitetura de Microsserviços' podem ser pensadas como uma aplicação dessa lei, onde os serviços são pequenos, focados em uma tarefa específica, permitindo que um comportamento complexo seja composto de blocos de construção simples.
The Spotify Model on Spotify Labs
O Modelo Spotify é uma abordagem para a organização de equipes que foi popularizado pelo 'Spotify'. Neste modelo, times são organizados por funcionalidades, não por tecnologias.
O Modelo Spotify também popularizou o conteido de Tribos, Guildas, Capítulos, que são outros componentes de sua estrutura organizacional.
Wadler's Law on wiki.haskell.org
Em qualquer design de linguagem, o tempo total gasto discutindo a uma funcionalidade nessa lista é proporcional a dois elevados à potência de sua posição.
- Semântica
- Sintaxe
- Sintaxe léxica
- Sintaxe léxica de comentários
(Em resumo, para cada hora gasta em semântica, 8 horas serão gastas na sintaxe de comentários)
Semelhante à Lei da Trivialidade, a Lei de Wadler afirma que quando projetamos uma linguagem, o tempo gasto em estruturas é desproporcionalmente maior do que a imporância dessas funcionalidades.
Veja também:
Não seja um babaca
Wil Wheaton
Cunhada por Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), esta lei simples, concisa e poderosa visa aumentar a harmonia e o respeito dentro de uma organização profissional. Ela pode ser aplicada ao conversar com colegas de trabalho, ao efetuar code reviews, contrariar outros ponto de vista, criticar, e, em linhas gerais, na maioria das interações que os humanos mantém entre si.
Os princípios são como diretrizes relacionadas à design.
The Dilbert Principle on Wikipedia
Empresas tendem a promover sistematicamente funcionários incompetentes para a gerência para tirá-los do fluxo de trabalho.
Scott Adams
Um conceito de gerência desenvolvido por Scott Adams (criador da tirinha Dilbert), o Princípio de Dilbert é inspirado pelo Princípio de Peter. Sob o Princípio de Dilbert, funcionários que nunca foram competentes são promovidos para a gerência, para limitar o estrago que eles podem causar. Adams explicou esse princípio pela primeira vez um artigo no Wall Street Journal, em 1995, e o expandiu para seu livro de negócios em 1996, o The Dilbert Principle.
Veja também:
The Pareto Principle on Wikipedia
A maioria das coisas na vida não são distribuídas de maneira uniforme.
O Princípio de Pareto sugere que em alguns casos, a maioria dos resultados vem de uma minoria de insumos:
- 80% de um certo pedaço de software pode ser escrito em 20% do tempo total alocado (inversamente, os 20% mais difíceis do código levam 80% do tempo)
- 20% do esforço produz 80% do resultado
- 20% do trabalho cria 80% da receita
- 20% dos bugs causam 80% das quebras
- 20% das funcionalidades causam 80% da utilização
Nos anos 40 o engenheiro americano-romeno Dr. Joseph Juran, reconhecido como pai do controle de qualidade, começou a aplicar o Princípio de Pareto a questões de qualidade.
Este princípio é também conhecido como: A Regra do 80/20, A Lei dos Poucos Vitais e O Princípio de Escassez do Fator.
Exemplos do mundo real:
- Em 2002 a Microsoft reportou que corrigindo 20% dos erros mais reportados, 80% dos erros e quebras relacionadas no Windows e no Office foram eliminados (Referência).
The Peter Principle on Wikipedia
Pessoas em uma hierarquia tentem a subir ao seu "nível de incompetência".
Laurence J. Peter
Um conceito de gerenciamento desenvolvido por Laurence J. Peter, o Princípio de Peter observa que as pessoas que são boas em seu emprego são promovidas até um nível onde elas não são mais bem-sucedidas (o "nível de incompetência"). Neste ponto, à medida em que são mais seniores, é menos provável que elas sejam removidas da organização (a não ser que elas performem de maneira horrível) e irão continuar a permanecer em uma função na qual possuem poucas habilidades intrínsecas, pois as habilidades originais que as fizeram bem-sucedidas não são necessariamente as mesmas que o novo cargo exige.
Isso é de interesse particular para engenheiros - que inicialmente começam em funções técnicas mas tem uma carreira que leva ao gerenciamento de outros engenheiros - o que requer um conjunto de habilidades fundamentalmente diferente.
Veja também:
The Robustness Principle on Wikipedia
Seja conservador naquilo que você faz, seja liberal naquilo que você aceita dos outros.
Geralmente aplicado no desenvolvimento de aplicativos para servidor, esse princípio afirma que o que você envia para outras pessoas deve ser o mínimo compatível possível, mas que você deve ter como objetivo permitir entradas fora de conformidade, se puderem ser processadas.
O objetivo desse princípio é construir sistemas que são robustos, pois eles conseguem lidar com dados mal formatados se a intenção ainda puder ser entendida. No entanto, há potenciais implicações de segurança na aceitação de entradas mal formatadas, principalmente se o processamento dessas entradas não for bem testado.
É um acrônimo para:
- S: The Single Responsibility Principle
- O: The Open/Closed Principle
- L: The Liskov Substitution Principle
- I: The Interface Segregation Principle
- D: The Dependency Inversion Principle
Esses são os princípios-chave da Programação Orientada a Objetos. Os princípios de design como esses devem ajudar os desenvolvedores a criarem sistemas mais sustentáveis.
The Single Responsibility Principle on Wikipedia
Cada módulo ou classe deve possuir apenas uma única responsabilidade.
O primeiro dos princípios 'SOLID'. Esse princípio sugere que módulos ou classes devem fazer apenas uma única coisa. Em termos mais práticos, isso significa que uma mudança simples a uma funcionalidade de um programa deve exigir uma mudança em apenas um componente. Por exemplo, mudar como uma senha é validada por complexidade deve exigir uma mudança em apenas uma parte do programa.
Teoricamente, isso deve tornar o código mais robusto, e fácil de ser mudado. Sabendo que um componente que está sendo alterado possui apenas uma responsabilidade siginfica que o teste deverá ser mais fácil. Usando o exemplo anterior, trocar a complexidade do componente de senha deve afetar apenas as funcionalidades que são relacionadas com a complexidade de senha. Pode ser muito mais difícil argumentar sobre o impacto de uma alteração em um componente que tem muitas responsabilidades.
Veja também:
The Open/Closed Principle on Wikipedia
Entidades devem estar aberta para extensão e fechadas para modificação
O segundo princípio do 'SOLID'. Esse princípio afirma que entidades (que podem ser classes, módulos, funções e afins) poderão ter seu comportamento extendido, mas que o comportamento já existente não poderá ser alterado.
Em um exemplo hipotético, imagine um módulo que converte um documento Markdown para HTML. Se o módulo pode ser extendido para aceitar uma nova funcionalidade do markdown, sem modificar a parte interna desse módulo, quer dizer que ele está aberto para extensões. Se o módulo não pode ser modificado por um consumidor, de modo que as funcionalidades existentes do markdown sejam tratadas, então ele estará fechado para modificações.
Esse princípio tem uma relevância particular na orientação a objetos, onde nós projetamos objetos para serem facilmente extendidos, mas evitamos projetar objetos onde o comportamento existente pode ser alterado de maneiras inesperadas.
Veja também:
The Liskov Substitution Principle on Wikipedia
Deve ser possível trocar um tipo por um subtipo, sem o sistema apresentar quebras.
O terceiro princípio 'SOLID'. O princípio afirma que se um componente confia em um tipo, então ele deverá estar apto para utilizar subtipos daquele tipo, sem que o sistema falhe ou que ele conheça os detalhes daquele subtipo.
Como um exemplo, imagine que temos um método que lê um documento XML de uma estrutura que representa um arquivo. Se o método utiliza a base de um tipo 'arquivo', então qualquer coisa que seja derivada de 'arquivo' poderá ser utilizada na função. Se 'arquivo' suporta busca recursiva, e o interpretador de XML utiliza essa função, mas o tipo derivado 'arquivo de rede' falha quando tenta uma busca recursiva, então o tipo 'arquivo de rede' estaria violando o princípio.
Esse princípio tem uma relevância particular na orientação a objetos, onde as hierarquias de tipos precisam ser modeladas com cautela para envitar confusão entre usuaríos do sistema.
Veja também:
The Interface Segregation Principle on Wikipedia
Nenhum cliente deverá ser forçado a depender de métodos que ele não utilize.
O quarto princípio do 'SOLID'. Esse princípio afirma que os consumidores de um componente não devem depender de funções daquele componente, as quais eles atualmente não usem.
Como um exemplo, imagine que um método lê um documento XML de uma estutura que representa um arquivo. O método apenas precisa ler os bytes, ir para frente ou para trás no arquivo. Se esse método precisar ser atualizado porque um recurso não relacionado da estrutura do arquivo é alterado (como uma atualização no modelo de permissões utilizado para representar a segurança do arquivo), o princípio foi invalidado.
Esse princípio tem uma relevância particular na orientação a objetos, onde interfaces, hierarquias e tipos abstratos são utilizados para minimizar o acomplamento entre componentes diferentes. Duck typing é uma metodologia que enforça esse princípio, eliminando interfaces explícitas.
Veja também:
The Dependency Inversion Principle on Wikipedia
Módulos de alto nível não devem ser dependentes de implementações de baixo nível.
O quinto conceito do 'SOLID'. Esse princípio afirma que componentes
Como um exemplo, imagine que temos um programa que lê os metadados de um website. Nós devemos assumir que o componente principal precisa conhecer um componente que irá baixar a página, depois um outro componente que irá ler os metadados. Se fôssemos levar a inversão de dependências em conta, o componente principal deveria depender apenas de um componente abstrato que pode buscar pelos bytes, e depois outro componente abstrato que irá ler os metadados de um fluxo de bytes. O componente principal não sabe nada sobre TCP/IP, HTTP, HTML, etc.
Esse princípio é complexo, pois pode "inverter" as dependências esperadas de um sistema (daí o nome). Na prática, isso também significa que um componente de orquestração separado deve garantir que as implementações corretas dos tipos abstratos sejam usadas (por exemplo, no caso anterior, algo ainda deve fornecer ao componente de leitura dos de metadados um downloader de arquivos HTTP e um leitor de metatags HTML). Isso toca em padrões como Inversão de controle e Injeção de dependência.
Veja também:
The DRY Principle on Wikipedia
Cada pedaço de código deve possuir uma representação única, inequívoca e autoritária dentro de um sistema.
DRY é um acrônimo para Don't Repeat Yourself (Não repita você mesmo). Esse princípio ajuda os desenvolvedores a reduzir a repetição de código e manter a informação em um único lugar. Foi citado em 1999 por Andrew Hunt e Dave Thomas no livro The Pragmatic Developer.
O oposto de DRY seria WET (Write Everything Twice or We Enjoy Typing) - (Escreva tudo duas vezes ou Nós gostamos de digitar).
Na prática, se você tem o mesmo pedaço de informação em dois (ou mais) lugares diferentes, você pode utilizar o DRY para centralizá-los em um único lugar, e reutilizar a informação onde necessário.
Veja também:
Mantenha simples, idiota
KISS é um acrônimo para Keep it simple, stupid. O princípio afirma que a maioria dos sistemas trabalham melhor se eles são mantidos simples ao invés de complicados. Portanto, simplicidade deve ser um objetivo no design, e complexidades desnecessárias devem ser evitadas. Originada na Marinha Americana em 1960, a frase foi associada com o engenheiro de aeronaves Kelly Johnson.
O princípio é melhor exemplificado pela história de Johnson entregando a uma equipe de engenheiros de projeto algumas ferramentas, com o desafio de que as aeronaves a jato que estavam projetando deveriam ser reparadas por um mecânico comum em campo sob condições de combate apenas com essas ferramentas. Portanto, o "estúpido" refere-se à relação entre a maneira como as coisas quebram e a sofisticação das ferramentas disponíveis para repará-las, e não as capacidades dos próprios engenheiros.
Veja também:
É um acrônimo para You Aren't Gonna Need It - Você não vai precisar disto.
Sempre implemente as coisas quando você de fato precisar delas, nunca quando você prevê que precisará delas.
(Ron Jeffries) (XP co-founder e autor do livro "Extreme Programming Installed")
Este princípio da Extreme Programming (XP) sugere que os desenvolvedores apenas devem implementar funcionalidades quando elas forem necessárias, e evitar tentativas de prever o futuro e implementar uma funcionalidade que talvez seja necessária.
Aderir a esse princípio deve reduzir a quantidade de código não utilizado em um projeto, e evitar tempo e esforço sendo disperdiçados em funcionalidades que não agregam valor.
Veja também:
The Fallacies of Distributed Computing on Wikipedia
Também conhecidas como as Falácias da Computação em rede, as Falácias são uma lista de conjecturas (ou crenças) sobre a computação distribuídas, que podem levar a falhas no desenvolvimento de software. As suposições são:
- A rede é confiável
- A latência é zero
- A largura de banda é infinita
- A rede é segura
- A topologia não muda
- Existe apenas um administrador
- Custo de transporte é zero
- A rede é homogênea
Os primeiro quatro itens foram listados por Bill Joy e Tom Lyon por volta de 1991, e foram classificados por James Gosling como as "Falácias da Computação de rede". L. Peter Deutsch adicionou os itens 5, 6 e 7. No final dos anos 90, Gosling adicionou o item 8.
O grupo foi inspirado pela situação que corria na época dentro da Sun Microsystems.
Essas falácias devem ser consideradas com cuidado ao projetar um código que seja resiliente; supondo que qualquer uma dessas falácias possa levar a uma lógica defeituosa que falha em lidar com as realidades e complexidades dos sistemas distribuídos
Veja também:
- Foraging for the Fallacies of Distributed Computing (Part 1) - Vaidehi Joshi on Medium
- Deutsch's Fallacies, 10 Years After
Se você achou esses conceitos interessantes, você provavelmente vai gostar dos seguintes livros.
- Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson - Cobre os principais princípios do Extreme Programming.
- The Mythical Man Month - Frederick P. Brooks Jr. - Um volume clássico na engenharia de software. A Lei de Brook é o tema central desse livro.
- Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter. - Esse livre é difícil de classificar. A Lei de Hofstadter é desse livro.
- The Dilbert Principle - Scott Adams - Um olhar cômico sobre a América corporativa, do autor que criou o Princípio Dilbert.
- The Peter Principle - Lawrence J. Peter - Outro olhar cômico sobre os desafios de grandes organizações e sobre a gestão de pessoas, a fonte do Princípio de Peter.
Graças a contribuidores maravilhosos, Hacker Laws está disponível em vários idiomas. Por favor, considere em patrocinar os moderadores!
| Idioma | Moderador | Status |
|---|---|---|
| 🇮🇩 Bahasa Indonesia / Indonesian | arywidiantara |  |
| 🇧🇷 Português Brasileiro / Brazilian Portuguese | Eugênio Moreira, Leonardo Costa |  |
| 🇨🇳 中文 / Chinese | Steve Xu | Parcialmente completa |
| 🇩🇪 Deutsch / German | Vikto |  |
| 🇫🇷 Français / French | Kevin Bockelandt |  |
| 🇬🇷 ελληνικά / Greek | Panagiotis Gourgaris |  |
| 🇮🇹 Italiano / Italian | Claudio Sparpaglione | Parcialmente completa |
| 🇯🇵 JP 日本語 / Japanese | Fumikazu Fujiwara |  |
| 🇰🇷 한국어 / Korean | Doughnut | Parcialmente completa |
| 🇱🇻 Latviešu Valoda / Latvian | Arturs Jansons |  |
| 🇷🇺 Русская версия / Russian | Alena Batitskaya | Parcialmente completa |
| 🇪🇸 Castellano / Spanish | Manuel Rubio (Sponsor) | Parcialmente completa |
| 🇹🇷 Türkçe / Turkish | Umut Işık |  |
Se você quer atualizar uma tradução, abra uma pull request. Se você quer adicionar um novo idioma, crie uma conta no GitLocalize, depois abra uma issue pedindo ao administrador o idioma eu irei adicionar você no projeto! Seria muito útil se você conseguir abrir uma pull request que atualiza a tabela acima, adicionando link ao topo do arquivo.
- Tip of the Day - Receba diaramente uma lei ou princípio hacker.
- Hacker Laws CLI - Liste e visualize as leis de maneira aleatória no seu terminal!
Por favor, contribua! Abra uma issue se você deseja ver aqui algum conteúdo novo, sugerir uma alteração/correção, ou então abra uma pull request e proponha suas próprias modificações.
Certifique-se de ler as Diretrizes de Contribuição para saber sobre os padrões de texto, estilo etc. Esteja ciente do Código de Conduta ao participar de discussões sobre o projeto.
Olá! Se você parou aqui, clicou em um link para um tópico que não foi escrito ainda. Desculpe por isso, este trabalho está em andamento!
Sinta-se livre para abrir uma issue solicitando mais detalhes, ou abra uma pull request para submeter suas modificações.