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.