hacker-laws-website

💻📖 hacker-laws

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

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

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:

Veja também:

Lei de Amdahl

Lei de Amdahl na Wikipédia

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

(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

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:

Lei de Brook

Lei de Brooks na Wikipedia

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’.

Veja também:

Lei de Conway

Lei de Conway na wikipedia

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:

Lei de Cunnigham

Cunningham’s Law on Wikipedia

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:

Número de Dunbar

Número de Dunbar na Wikipedia

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 Gall

Gall’s Law on Wikipedia

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:

Lei de Goodhart

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 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:

Veja também:

Navalha de Hanlon na wikipedia

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

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’.

Lei de Hutber

Hutber’s Law on Wikipedia

Melhoria significa deterioração.

(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

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

(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

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:

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 maneira mais inteligente possível, por definição, você não é inteligente o suficiente para depurá-lo.

Brian Kernighan

A Lei de Kerningham é nomeada por Brian Kernighan e derivada 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:

Lei de Metcalfe

Metcalfe’s Law on Wikipedia

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:

Lei de Moore

Lei de Moore na Wikipedia

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.

Lei de Murphy / Lei de Sod

Murphy’s Law on Wikipedia

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 levar 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:

Navalha de Occam on Wikipedia

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:

Lei de Parkinson

Lei de Parkinson

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.

Efeito de Otimização Prematura

Premature Optimization on WikiWikiWeb

Otimização prematura é a raiz de todo o mal.

(Donald Knuth)

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 entanto, 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.

Lei de Putt

Lei de Putt na wikipedia

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 o Princípio de Peter ou o Princípio Dilbert.

No entanto, deve-se enfatizar que leis como essa são vastas generalizações e podem ser aplicáveis a alguns tipos de organizações, mas não a outras.

Veja também:

Lei de Reed

Reed’s Law on Wikipedia

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 da Complexidade (Lei de Tesler)

A lei da Conservação de Complexidade na wikipedia

Essa lei sugere que em todos os sistemas 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.

A Lei das Abstrações Gotejantes

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á significantemente 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 tornar 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:

A Lei da Trivialidade

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 entanto, 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.

A Filosofia Unix

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.

O Modelo Spotify

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 conceito de Tribos, Guildas, Capítulos, que são outros componentes de sua estrutura organizacional.

Lei de Wadler

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.

  1. Semântica
  2. Sintaxe
  3. Sintaxe léxica
  4. 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 importância dessas funcionalidades.

Veja também:

Lei de Wheaton

The Link

The Official Day

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 pontos de vista, criticar, e, em linhas gerais, na maioria das interações que os humanos mantém entre si.

Princípios

Os princípios são como diretrizes relacionadas à design.

O Princípio Dilbert

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:

O Princípio de Pareto (Regra do 80/20)

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:

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:

O Princípio de Peter

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:

O Princípio da Robustez (Lei de Postel)

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.

SOLID

É um acrônimo para:

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.

O Princípio da Responsabilidade Única

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 significa 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:

O Princípio do Aberto/Fechado

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 estendido, 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 estendido 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 estendidos, mas evitamos projetar objetos onde o comportamento existente pode ser alterado de maneiras inesperadas.

Veja também:

O Princípio da Substituição de Liskov

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 evitar confusão entre usuários do sistema.

Veja também:

O Princípio da Segregação de Interface

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 estrutura 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 acoplamento entre componentes diferentes. Duck typing é uma metodologia que impõe esse princípio, eliminando interfaces explícitas.

Veja também:

O Princípio da Inversão de Dependência

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:

O Princípio DRY

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 Programmer.

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:

O Princípio KISS

KISS on Wikipedia

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:

YAGNI

YAGNI on Wikipedia

É 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 desperdiçados em funcionalidades que não agregam valor.

Veja também:

As Falácias da Computação Distribuída

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:

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:

Lista de leitura

Se você achou esses conceitos interessantes, você provavelmente vai gostar dos seguintes livros.

Traduções

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 gitlocalized
🇧🇷 Português Brasileiro / Brazilian Portuguese Eugênio Moreira, Leonardo Costa gitlocalized
🇨🇳 中文 / Chinese Steve Xu Parcialmente completa
🇩🇪 Deutsch / German Vikto gitlocalized
🇫🇷 Français / French Kevin Bockelandt gitlocalized
🇬🇷 ελληνικά / Greek Panagiotis Gourgaris gitlocalized
🇮🇹 Italiano / Italian Claudio Sparpaglione Parcialmente completa
🇯🇵 JP 日本語 / Japanese Fumikazu Fujiwara gitlocalized
🇰🇷 한국어 / Korean Doughnut Parcialmente completa
🇱🇻 Latviešu Valoda / Latvian Arturs Jansons gitlocalized
🇷🇺 Русская версия / Russian Alena Batitskaya Parcialmente completa
🇪🇸 Castellano / Spanish Manuel Rubio (Sponsor) Parcialmente completa
🇹🇷 Türkçe / Turkish Umut Işık gitlocalized

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.

Projetos relacionados

Contribuindo

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.

Em construção

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.

This site is open source. Improve this page.