🙋 👧🏿 👵🏼 Leis de programação 👰🏿 🔓 👆🏾

Leis, teorias, princípios e padrões úteis para desenvolvedores

Introdução

Tradução de repositório github.com/dwmkerr/hacker-laws

Nas discussões relacionadas ao desenvolvimento de software, as pessoas costumam falar sobre leis diferentes. Este repositório armazena links e descrições de alguns dos mais famosos deles.

Ele contém explicações de algumas leis, princípios e leis, mas não há agitação a seu favor. Usá-los ou não é sempre um ponto discutível, e tudo depende do que você está trabalhando.

As leis

Lei de Amdahl

A lei de Amdahl é uma fórmula que demonstra o potencial de acelerar uma tarefa computacional que pode ser alcançada com um aumento na quantidade de recursos do sistema. Geralmente é usado em computação paralela e pode prever os benefícios reais de aumentar o número de processadores, levando em consideração as limitações de paralelismo do programa.

Nós damos um exemplo. Se o programa consiste em duas partes - parte A, que deve ser executada em um processador, e parte B, que pode ser paralelizada, é claro que as vantagens de adicionar vários processadores ao sistema que executa o programa são limitadas. Potencialmente, isso pode acelerar muito a parte B - mas a velocidade da parte A não muda.

O diagrama a seguir mostra exemplos de possíveis ganhos de velocidade:

Como você pode ver, mesmo que 50% do programa possa ser paralelo, os benefícios da adição de mais de 10 processadores separados serão desprezíveis. Se o programa puder ser paralelo em 95%, as melhorias serão visíveis mesmo após a adição de milhares de processadores.

Com a Lei de Moore desacelerando e o processador acelerando, a paralelização se torna a chave para melhorar a eficiência. A programação gráfica é um ótimo exemplo - a programação moderna baseada em shaders permite desenhar fragmentos da imagem em paralelo; portanto, nas placas gráficas modernas, você pode encontrar milhares de núcleos de processador (GPUs ou módulos de shader).

Teoria de janelas quebradas

A teoria das janelas quebradas alega que sinais visíveis de crime (ou falta de preocupação com o meio ambiente) acarretam um aumento no número e na gravidade do crime (e maior deterioração do meio ambiente).

Essa teoria foi aplicada ao desenvolvimento de software, sugerindo que a má qualidade do código (ou a chamada " dívida técnica ") pode causar a sensação de que todas as tentativas de melhorar a qualidade serão ignoradas ou subestimadas, o que levará ao aparecimento de um novo código incorreto. Esse efeito se desenvolve em cascata, e é por isso que a qualidade se deteriora com o tempo.

Brooks Law

A adição de recursos humanos adicionais a um projeto atrasado atrasou ainda mais sua produção.

A lei de Brooks diz que, em muitos casos, as tentativas de acelerar o lançamento de um projeto que já está atrasado, adicionando mais pessoas a ele, levam ao fato de que o projeto é lançado ainda mais tarde do que poderia. No entanto, Brooks enfatiza que essa é uma simplificação excessiva do problema. Ele argumentou da seguinte maneira: dados os custos do tempo necessário para comissionar novos recursos e a comunicação das pessoas entre si, a curto prazo, a taxa de desenvolvimento do projeto cai. Além disso, muitas tarefas podem não estar sujeitas à separação, ou seja, não podem ser facilmente distribuídas entre os recursos, cuja quantidade foi aumentada, portanto o aumento potencial na velocidade não é tão significativo.

O ditado comum "nove mulheres não podem dar à luz um bebê em um mês" refere-se à lei de Brooks, em particular porque alguns tipos de trabalho não podem ser divididos ou paralelizados.

Este é o tema principal do livro Mythical Man-Month.

Direito de Conway

A lei de Conway diz que as limitações técnicas do sistema projetado refletirão a estrutura da organização. Ele é frequentemente lembrado ao tentar melhorar a organização. A lei diz que, se uma organização estiver estruturada em muitos módulos pequenos e não relacionados, o programa criado será o mesmo. Se a organização for construída em torno de setores verticais, com base em determinados recursos ou serviços, seu software refletirá esse fato.

Cunningham Law

A melhor maneira de encontrar a resposta certa na Internet não é fazer uma pergunta, mas postar uma resposta deliberadamente errada.

Stephen McGeady diz que, no início dos anos 80, Ward Cunningham deu-lhe conselhos: "A melhor maneira de encontrar a resposta certa na Internet não é fazer uma pergunta, mas publicar uma resposta deliberadamente errada". McGeady chamou de "Lei de Cunningham", embora o próprio Cunningham negue e diga que é "citado incorretamente". Embora a frase se referisse originalmente à comunicação na Usenet, a lei já foi usada para descrever o trabalho e outras comunidades (Wikipedia, Reddit, Twitter, Facebook).

Número Dunbar

O número de Dunbar é um limite para o número de vínculos sociais permanentes que uma pessoa pode manter. Isso se refere a relacionamentos que envolvem o conhecimento das características distintivas de um indivíduo em particular, cuja conexão deve ser mantida, seu caráter, seu status social e suas conexões com outras pessoas.

O número exato desses relacionamentos é desconhecido. O próprio Dunbar sugeriu que uma pessoa pode suportar confortavelmente não mais que 150 dessas conexões. Ele o descreveu em um contexto mais social: "O número de pessoas em que você não hesita em se juntar sem um convite para beber juntos, se você acidentalmente se deparar com elas no bar". Normalmente, as estimativas desse número variam de 100 a 250.

Como relacionamentos estáveis entre as pessoas, manter o relacionamento de um programador com o código exige muito esforço. Quando confrontados com projetos grandes e complexos ou com a propriedade de muitos pequenos, contamos com certos acordos, políticas e procedimentos. É importante considerar o número Dunbar não apenas ao aumentar o número de funcionários, mas também ao determinar a escala da equipe ou o momento em que o sistema deve adquirir ferramentas auxiliares para modelagem e automação da logística. No contexto da engenharia, esse é o número de projetos (ou a complexidade normalizada de um projeto) para os quais você seria incluído com confiança no grupo de suporte de código.

Lei Goll

Um sistema complexo de trabalho necessariamente veio de um sistema simples de trabalho. Um sistema complexo projetado desde o início nunca funciona e é impossível corrigi-lo para que funcione. Você precisa começar de novo com um sistema de trabalho simples.

A lei de Goll sugere que as tentativas de desenvolver um sistema muito complexo provavelmente irão falhar. Sistemas de alta complexidade raramente são criados de uma só vez - eles evoluem dos mais simples.

Um exemplo clássico é uma rede mundial. No estado atual, é um sistema de alta complexidade. No entanto, foi inicialmente identificado como uma maneira simples de trocar conteúdo entre instituições. Ela lidou com muito sucesso com esses objetivos e evoluiu, transformando-se com o tempo em um mais complexo.

Lei de Goodhart

Qualquer padrão estatístico observado tende a entrar em colapso assim que a pressão é exercida para controlá-lo.

Também é frequentemente formulado como:

Quando uma medida se torna uma meta, deixa de ser uma boa medida.
Marilyn Strain

A lei estabelece que a otimização com base em determinadas medidas pode levar à depreciação dessas medidas. Medidas excessivamente seletivas (KPIs) aplicadas cegamente a um processo resultam em distorção. As pessoas se esforçam para otimizar o processo localmente, “enganando” o sistema para satisfazer uma determinada métrica, em vez de prestar atenção ao resultado global de suas ações.

Exemplos:

Os testes sem reivindicações atendem às expectativas de cobertura do código, apesar de essa métrica ter sido criada para que o programa seja bem testado.
A avaliação da eficácia do desenvolvedor com base no número de linhas contribuídas para o projeto leva ao inchaço injustificado do código.

Hanlon Razor

Nunca atribua malícia ao que é completamente explicado pela estupidez.

O princípio afirma que ações que levem a um resultado negativo poderiam ser realizadas não com más intenções. O resultado negativo é mais provável devido ao fato de que essas ações e suas consequências não foram bem compreendidas.

Lei de Hofstader

Sempre leva mais tempo para concluir uma tarefa do que o esperado, mesmo que você tenha levado em consideração a lei do Hofstader.

Você pode encontrar referências a esta lei ao lidar com estimativas do tempo gasto em um projeto. No campo do desenvolvimento de software, parece óbvio que não somos muito capazes de estimar com precisão o tempo necessário para concluir o projeto.

Citação do livro " Gödel, Escher, Bach: This Endless Garland ".

Direito Hutber

Melhorar é equivalente à destruição.

Esta lei afirma que a melhoria de uma parte do sistema leva à destruição de outras partes ou oculta outros tipos de destruição, o que geralmente leva à degradação do sistema em comparação com o seu estado atual.

Por exemplo, diminuir o tempo de resposta em uma determinada parte do sistema pode levar a um aumento na taxa de transferência e, como resultado, a problemas com a capacidade em algum lugar no caminho do fluxo de solicitação, o que pode afetar outro subsistema.

O ciclo do hype e a lei de Amar

Tendemos a superestimar o impacto da tecnologia no curto prazo e subestimá-lo no longo prazo.

O ciclo do hype é uma visualização do entusiasmo e desenvolvimento da tecnologia ao longo do tempo, originalmente criada pelo Gartner. É melhor ilustrado pelo gráfico:

após o advento da tecnologia, sua popularidade atinge o pico das expectativas inchadas, depois mergulha na depressão, sobe na encosta da iluminação e atinge o platô da produtividade

Em suma, o ciclo argumenta que geralmente surge uma fonte de entusiasmo em torno da nova tecnologia e de suas possíveis conseqüências. As equipes geralmente são viciadas rapidamente nessas tecnologias e geralmente ficam decepcionadas com os resultados. Talvez isso ocorra porque a tecnologia ainda não está suficientemente desenvolvida ou os métodos para sua aplicação ainda não foram pensados. Após um certo tempo, os recursos da tecnologia aumentam e o número de aplicativos práticos cresce, após o que as equipes podem finalmente se tornar produtivas.

Lei de Hiram

Quando você alcança um número suficiente de usuários da API, não importa quais recursos você prometeu a todos: para qualquer um dos recursos possíveis do comportamento do seu sistema, haverá um usuário dependendo dele.

A lei de Hiram postula que, se sua API tiver usuários suficientes, haverá um usuário dependendo dela para qualquer comportamento possível do seu sistema (nem mesmo descrito no contrato público). Um exemplo trivial seria recursos não funcionais da API, como tempo de resposta. Um exemplo mais sutil é o consumidor que depende da determinação do tipo de erro aplicando a função regex à sua descrição. Mesmo que o contrato público não diga nada sobre o conteúdo da mensagem e implique que os usuários devem usar o código de erro, alguns deles podem decidir usar a mensagem, e a alteração da mensagem interromperá a API para esses usuários.

Kernigan Law

O código de depuração é duas vezes mais difícil do que escrevê-lo. Portanto, se você escrever código até o limite de suas habilidades mentais, por definição, não terá inteligência suficiente para depurá-lo.

A lei de Kernigan tem o nome de Brian Kernigan e é retirada de um livro escrito por ele e Plauger: "Elementos de um estilo de programação".

Todo mundo sabe que o código de depuração é duas vezes mais difícil do que escrevê-lo. Portanto, se você estiver fazendo todos os seus esforços mentais ao escrever um código, como irá depurá-lo?

Embora a lei seja uma hipérbole, ela afirma que é melhor usar código simples do que complexo, pois a depuração de problemas que surjam em código complexo pode ser muito cara ou até impossível.

Lei de Metcalf

Na teoria das redes, a utilidade de uma rede cresce aproximadamente como um quadrado do número de seus usuários.

A lei é baseada no número possível de conexões aos pares dentro do sistema e está intimamente relacionada à lei de Reed. Odlyzhko e outros argumentaram que as leis de Reed e Metcalf exageravam o valor do sistema, sem levar em conta as limitações da capacidade humana de entender a rede; veja o número Dunbar.

lei de Moore

O número de transistores colocados em um chip de circuito integrado dobra aproximadamente a cada 24 meses.

A previsão de Moore , que é frequentemente usada para demonstrar a tremenda velocidade de melhoria das tecnologias de fabricação de semicondutores e chips, era surpreendentemente precisa e funcionou da década de 1970 até o final da década de 2000. Nos últimos anos, a tendência mudou ligeiramente, em particular, devido às limitações físicas da miniaturização de componentes. No entanto, o progresso da paralelização e as mudanças potencialmente revolucionárias na tecnologia de semicondutores e nos computadores quânticos podem significar que a lei de Moore pode permanecer verdadeira nas próximas décadas.

lei de Murphy

Tudo o que pode dar errado vai dar errado.

A Lei de Murphy, de autoria de Edward A. Murphy, postula que tudo o que pode dar errado necessariamente vai dar errado.

Esse ditado é frequentemente usado pelos desenvolvedores. Às vezes, coisas inesperadas acontecem durante o desenvolvimento, teste ou mesmo na produção. Pode ser associado à lei da maldade, que é mais frequentemente usada na Grã-Bretanha [na verdade, também é conhecida na Rússia / aprox. transl.]:

Se algo der errado, isso acontecerá e no pior momento possível.

Geralmente essas "leis" são usadas no sentido de humor. No entanto, fenômenos como viés de confirmação e erro sistemático de seleção podem levar as pessoas a gostar muito dessas leis (na maioria dos casos, quando tudo funciona como deveria, ninguém percebe isso, mas as falhas são mais visíveis e atraem mais discussões).

A navalha de Occam

Você não deve multiplicar as coisas desnecessariamente.

A navalha de Occam afirma que das poucas soluções possíveis, a solução que contém a menor quantidade de conceitos e suposições será a mais provável. Esta solução será a mais simples e só resolverá o problema em questão sem introduzir dificuldades aleatórias e possíveis consequências negativas.

Lei de Parkinson

O trabalho preenche o tempo alocado a ela.

No contexto original, a lei era baseada no estudo da burocracia. Pessimista, ele pode ser aplicado ao desenvolvimento de software, supondo que a equipe trabalhe de forma ineficiente até que o prazo do projeto comece a se aproximar e que tenha pressa em entregá-lo no prazo, o que torna a data final específica bastante arbitrária.

Se você combiná-lo com a lei de Hofstader, obtém uma visão ainda mais pessimista: o trabalho será expandido até preencher todo o tempo necessário para concluí-lo, e ainda levará mais do que o esperado.

O efeito da otimização prematura

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

No trabalho de Donald Knuth, “Structured Programming with GoTo”, ele escreveu: “Os programadores passam muito tempo pensando e se preocupando com a velocidade de execução de partes não críticas dos programas, e tentar torná-los mais eficazes tem um forte efeito negativo se você pensar em depurá-los e apoiá-los. Precisamos esquecer a eficiência sem importância de 97% das vezes: a otimização prematura é a raiz de todos os males. No entanto, em 3% dos casos críticos, não devemos perder nossa oportunidade. ”

No entanto, a otimização prematura também pode ser descrita como uma tentativa de otimizar algo antes de entendermos o que precisamos fazer.

Patt Law

O setor tecnológico é dominado por dois tipos de pessoas: aqueles que entendem que não controlam e aqueles que controlam o que não entendem.

Pela lei, Patta frequentemente conclui Patta:

Em qualquer hierarquia técnica, uma inversão de competência é desenvolvida ao longo do tempo.

Essas declarações sugerem que, devido a diferentes critérios de seleção e tendências da organização de grupos, sempre haverá um certo número de pessoas experientes nos níveis de trabalho da organização técnica, e sempre haverá pessoas no nível de gerenciamento que não têm idéia das complexidades e problemas do trabalho que gerenciam.

No entanto, vale ressaltar que essas leis são uma generalização muito grosseira e podem ser aplicáveis a alguns tipos de organizações e não a outras.

Lei de Reed

A utilidade de grandes redes, especialmente as redes sociais, aumenta exponencialmente com o crescimento do tamanho da rede.

Essa lei é baseada na teoria dos grafos, em que a utilidade é escalonada conforme o número possível de subgrupos, crescendo mais rápido que o número de participantes ou possíveis conexões aos pares. Odlyzhko e outros argumentaram que as leis de Reed e Metcalf exageravam o valor do sistema, sem levar em conta as limitações da capacidade humana de entender a rede; veja o número Dunbar.

A lei da conservação da complexidade (Lei de Tesler)

A lei afirma que o sistema tem uma certa complexidade, que não pode ser reduzida.

Parte da complexidade do sistema pode ocorrer sem intenção. É o resultado de estrutura deficiente, erros ou modelagem malsucedida do problema que está sendo resolvido. Complexidade inadvertida pode ser reduzida ou eliminada. No entanto, alguns tipos de complexidade são uma conseqüência integral da complexidade da tarefa em si. Essa complexidade pode ser movida, mas não eliminada.

Um dos elementos interessantes dessa lei é a suposição de que, mesmo com a simplificação de todo o sistema, sua complexidade interna não diminui, mas recai sobre o usuário, que tem mais dificuldade de se comportar.

A lei das abstrações fluidas

Todas as abstrações não triviais estão sujeitas a fluxo até um determinado limite.

Essa lei afirma que as abstrações, que geralmente são usadas na TI para simplificar o trabalho com sistemas complexos, em certas situações vazam, permitindo que os elementos dos sistemas subjacentes fluam para cima, e é por isso que a abstração começa a se comportar de maneira imprevisível.

Um exemplo é baixar um arquivo e ler seu conteúdo. A API do sistema de arquivos é uma abstração de sistemas de kernel de nível inferior, que são uma abstração dos processos físicos associados à alteração de dados em uma placa magnética (ou em uma memória flash SSD). Na maioria dos casos, uma abstração representando um arquivo como um fluxo de dados binários funcionará. No entanto, a leitura seqüencial dos dados de um disco magnético será mais rápida que o acesso aleatório a eles, mas os SSDs não terão esses problemas. Você precisa entender os detalhes detalhados para lidar com esses casos (por exemplo, os arquivos de banco de dados de índice são estruturados para reduzir o tempo de acesso aleatório), quando a abstração fornece um vazamento de detalhes de implementação que o desenvolvedor precisa conhecer.

O exemplo acima pode se tornar mais complicado ao adicionar novas abstrações. O Linux permite acessar arquivos pela rede, mas eles são visíveis localmente como "normal". Essa abstração vazará em caso de problemas de rede. Se o desenvolvedor as tratar como "normais", sem levar em consideração o fato de serem propensas a problemas com atrasos e falhas na rede, sua solução será abaixo do ideal e com erros.

No artigo que descreve a lei, supõe-se que o vício excessivo em abstrações, associado a um entendimento insuficiente dos processos subjacentes, em alguns casos até complique o processo de solução do problema.

Exemplos: inicialização lenta do Photoshop. Corri para este problemano passado. O Photoshop foi iniciado muito lentamente, às vezes levava alguns minutos. Aparentemente, o problema era que, na inicialização, ele lê informações sobre a impressora atual por padrão. Mas se essa impressora fosse de rede, poderia levar um tempo extremamente longo. A abstração, segundo a qual a impressora de rede é semelhante à local, causou problemas ao usuário em caso de comunicação deficiente.

Lei da trivialidade

A lei afirma que os grupos gastam muito mais tempo e atenção discutindo questões cosméticas ou triviais do que questões sérias e extensas.

Normalmente, um exemplo é o trabalho de um comitê que aprova os planos de uma usina nuclear, que na maioria das vezes discute a estrutura do estacionamento de bicicletas, do que as questões mais importantes do design da própria estação. Pode ser difícil dar uma contribuição valiosa para a discussão de tópicos muito grandes e complexos sem ter amplo conhecimento sobre esse assunto. No entanto, as pessoas querem ser notadas por fazer comentários valiosos. A partir daqui, vem a tendência de se concentrar em pequenos detalhes, fáceis de falar, mas que não são necessariamente importantes para o projeto como um todo.

O exemplo fictício dado acima deu origem ao termo "efeito de barracão de bicicleta", que descreve a perda de tempo na discussão de detalhes triviais. Existe um termo semelhante, “corte de cabelo de iaque”, que descreve uma atividade aparentemente não relacionada que faz parte de uma longa cadeia de etapas preparatórias necessárias.

Filosofia Unix

A filosofia do Unix é que os componentes de software devem ser pequenos e se concentrar em executar bem uma tarefa específica. Isso facilita o processo de construção de sistemas, recrutando módulos pequenos, simples e bem definidos, em vez de usar programas grandes, complexos e multifuncionais.

Práticas modernas, como a "arquitetura de microsserviço", podem ser consideradas a aplicação dessa filosofia - os serviços são pequenos, focados em uma tarefa específica, que permite criar comportamentos complexos a partir de blocos de construção simples.

Modelo Spotify

A abordagem à estrutura e organização da equipe que o Spotify promove . Nesse modelo, as equipes são organizadas em torno das funções do programa, não em torno da tecnologia.

O modelo também promove os conceitos de tribos, guildas, ramos - outros componentes da estrutura organizacional.

Lei de Wadler

Ao projetar qualquer idioma, o tempo total gasto discutindo um recurso desta lista é proporcional ao poder do número de posição desse recurso na lista.
0. Semântica.
1. A sintaxe.
2. Sintaxe Lexical.
3. A sintaxe lexical dos comentários.

Ou seja, para cada hora gasta em semântica, há 8 horas na sintaxe dos comentários.

Como a lei da trivialidade, a lei de Wadler postula que, ao projetar uma linguagem, a quantidade de tempo gasto em estruturas de linguagem é desproporcionalmente grande em comparação com a importância dessas estruturas.

Lei de Wheaton

Não seja uma cabra.

Esta lei concisa, simples e abrangente, formulada por Will Wheatan, visa aumentar a harmonia e o respeito dentro de uma organização profissional. Pode ser usado em conversas com colegas, ao realizar uma avaliação especializada do código, na busca de objeções a outros pontos de vista, nas críticas e, em geral, na comunicação profissional entre as pessoas.

Princípios

Os princípios costumam ser associados a conselhos sobre a criação de programas.

Princípio de Dilbert

Nas empresas, há uma tendência de atualizar funcionários incompetentes para gerentes, a fim de eliminá-los do processo de trabalho.

Conceito de gerenciamento desenvolvido por Scott Adams (criador dos quadrinhos de Dilbert), inspirado no princípio de Peter. De acordo com o princípio de Dilbert , os funcionários que não podiam ser considerados competentes são promovidos a gerentes para limitar os possíveis danos à empresa. Adams primeiro explicou esse princípio em um artigo para o Wall Street Journal em 1995 e depois o descreveu em detalhes em seu livro de 1996, The Dilbert Principle.

Princípio de Pareto (regra 80/20)

Na maior parte, tudo na vida é distribuído de maneira desigual.

O princípio de Pareto afirma que, em alguns casos, uma parte menor do investimento é responsável pela maioria dos resultados:

80% do programa pode ser escrito em 20% do tempo (e os 20% mais difíceis levam os 80% restantes).
20% do esforço fornece 80% do resultado.
20% do trabalho cria 80% do lucro.
20% dos erros levam a 80% das falhas do programa.
20% das funções são usadas 80% do tempo.

Na década de 1940, um engenheiro americano de origem romena, Joseph Juran, que costuma ser chamado pai da administração da qualidade, começou a aplicar o princípio de Pareto a problemas de qualidade.

Além disso, esse princípio é conhecido, como regra 80/20, a lei dos pequenos mais importantes, o princípio da deficiência de fatores.

Exemplos: Em 2002, a Microsoft informou que, após corrigir 20% dos erros mais comuns, 80% dos problemas e falhas relacionados ao Windows e Office serão corrigidos.

Princípio de Pedro

No sistema hierárquico, cada indivíduo tem uma tendência a subir ao nível de sua incompetência.

O conceito gerencial criado por Lawrence Johnston Peter observa que as pessoas que fazem um bom trabalho são promovidas até atingirem um nível em que não conseguem mais lidar ("nível de incompetência"). Uma vez que subiram o suficiente, já são menos propensos a serem demitidos (a menos que criem algum tipo de absurdo completo); portanto, permanecerão nessa posição, para a qual não possuem as habilidades necessárias, uma vez que suas habilidades de comportamento na organização não necessariamente coincidem. com as habilidades necessárias para um trabalho bem-sucedido nessa posição.

Esse princípio é especialmente interessante para engenheiros que começam a trabalhar com funções puramente técnicas, mas geralmente constroem uma carreira que leva ao gerenciamento de outros engenheiros - o que requer um conjunto de habilidades completamente diferente.

O princípio da confiabilidade (lei de Postel)

Seja conservador em relação a suas atividades e liberal em relação às contribuições de outras pessoas.

Esse princípio geralmente é aplicado ao desenvolvimento de aplicativos para servidores. Segundo ele, os dados que você envia para outras pessoas devem ser o menor possível e o melhor possível para cumprir o padrão, mas você mesmo deve aceitar dados não totalmente padronizados como entrada, se conseguir processá-los.

O objetivo do princípio é criar sistemas confiáveis que possam digerir dados mal formatados, cujo significado ainda pode ser entendido. No entanto, o recebimento de dados de entrada não padrão pode ter consequências associadas a uma violação de segurança, especialmente se o recebimento desses dados não tiver sido bem testado.

Com o tempo, a prática de receber dados não padronizados pode levar ao fato de que os protocolos deixarão de se desenvolver, pois aqueles que implementam a troca de dados começarão a contar com a liberalidade dos programas, criando novas funções.

SÓLIDO

A sigla para os cinco princípios a seguir:

S: Princípio de responsabilidade única
O: Princípio de aberto / fechado
L: Princípio de substituição de Liskov
I: Princípio de segregação de interfaces [ Princípio de separação de interface]
D: O princípio de inversão de dependência

Estes são os princípios-chave da programação orientada a objetos. Tais princípios de design devem ajudar os desenvolvedores a criar sistemas que são mais fáceis de manter.

Princípio da responsabilidade exclusiva

Cada objeto deve ter uma responsabilidade e essa responsabilidade deve ser totalmente encapsulada na classe.

O primeiro dos princípios do SOLID. O princípio afirma que cada módulo ou classe deve fazer apenas uma coisa. Na prática, isso significa que uma alteração pequena e única na função de um programa deve exigir uma alteração em apenas um componente. Por exemplo, para alterar o procedimento para verificar a senha quanto à complexidade, o programa precisa ser corrigido em apenas um local.

Teoricamente, isso fornece confiabilidade ao código e simplifica sua alteração. O fato de o componente que está sendo alterado ter a única responsabilidade deve significar que será mais fácil testar essa alteração. Alterar o componente de verificação da complexidade da senha do exemplo anterior deve afetar apenas as funções relacionadas à complexidade da senha. É muito mais difícil falar sobre o que será afetado por uma alteração de componente com muitas responsabilidades.

O princípio da abertura / proximidade

As entidades devem estar abertas para expansão, mas fechadas para mudança.

O segundo dos princípios do SOLID. O princípio afirma que as entidades (classes, módulos, funções etc.) devem permitir que seu comportamento seja expandido, mas seu comportamento atual não deve ser alterado.

Um exemplo hipotético: imagine um módulo que possa transformar um documento de marcação Markdown em um documento de marcação HTML. Se o módulo puder ser expandido para aprender a lidar com os novos recursos do formato Markdown sem alterar suas funções internas, o módulo estará aberto para expansão. Se o módulo não puder alterar o processamento das funções atuais do Markdown, o módulo será fechado para modificação.

O princípio está especialmente associado à programação orientada a objetos, onde você pode projetar objetos fáceis de expandir, mas não deve projetar objetos cujos interiores mudarão inesperadamente.

Barbara Liskov Princípio da Substituição

Deve ser possível substituir o tipo por um subtipo sem interromper o sistema.

O terceiro dos princípios do SOLID. O princípio afirma que, se um componente depende de um tipo, deve ser possível usar subtipos desse tipo para que o sistema não se recuse a trabalhar ou não exija detalhes desse subtipo.

Por exemplo, temos um método que lê um documento XML de uma estrutura que indica um arquivo. Se o método usar o arquivo de tipo base, a função poderá usar tudo o que vem do arquivo. Se o arquivo oferecer suporte à pesquisa reversa e o analisador XML usar essa função, mas o tipo derivado "arquivo de rede" se recusar a trabalhar com a pesquisa reversa, o "arquivo de rede" violará esse princípio.

O princípio está particularmente relacionado à programação orientada a objetos, onde as hierarquias de tipos devem ser cuidadosamente modeladas para evitar confusão para o usuário do sistema.

Princípio de separação de interface

As entidades de software não devem depender de métodos que eles não usam.

O quarto dos princípios do SOLID. O princípio afirma que os consumidores de um componente não devem depender das funções de um componente que ele não usa.

Por exemplo, temos um método que lê um documento XML de uma estrutura que indica um arquivo. Ele só precisa ler bytes, avançando ou retrocedendo no arquivo. Se esse método precisar ser atualizado devido a alterações em uma estrutura de arquivos que não está relacionada a ele (por exemplo, devido a uma atualização do modelo de controle de acesso que representa a segurança do arquivo), esse princípio será violado. É melhor para o arquivo implementar a interface "fluxo pesquisável" e o método XML para usá-lo.

O princípio está particularmente relacionado à programação orientada a objetos, na qual interfaces, hierarquias e tipos abstratos são usados para minimizar as conexões entre os componentes. Esse princípio força o uso da digitação de pato , uma metodologia que elimina interfaces explícitas.

Princípio de Inversão de Dependência

Os módulos de nível superior não devem depender dos módulos de nível inferior.

Quinto dos princípios do SOLID. O princípio afirma que os componentes de controle de níveis mais altos não devem conhecer os detalhes da implementação de suas dependências.

Por exemplo, temos um programa que lê metadados de um site. Presumivelmente, seu componente principal deve estar ciente de um componente que baixa o conteúdo de uma página da Web e de um componente que lê metadados. Se levarmos em conta o princípio da inversão de dependência, o componente principal dependerá apenas do componente abstrato que recebe dados de bytes e, por sua vez, do componente abstrato que pode ler metadados do fluxo de bytes. O componente principal não saberá nada sobre TCP / IP, HTTP, HTML etc.

O princípio é bastante complicado, pois inverte a dependência esperada no sistema. Na prática, isso também significa que um componente de controle separado deve garantir a implementação correta de tipos abstratos (no exemplo anterior, algo deve fornecer ao leitor de metadados do componente o download do arquivo via HTTP e a leitura de dados da metatag HTML).

Princípio não se repita

Cada conhecimento deve ter uma representação única, consistente e autoritária dentro do sistema.

Não se repita , ou DRY, ajuda os desenvolvedores a reduzir a repetibilidade do código e manter as informações em um só lugar. Foi mencionado em 1999 por Andy Hunt e Dave Thomas em seu livro Pragmatic Programmer.

O oposto do princípio DRY seco] deve ser o princípio da WET wet] - “Escreva tudo duas vezes” ou “Nós gostamos de digitar” [Nós gostamos de digitar].

Na prática, se as mesmas informações forem duplicadas em você em dois ou mais lugares, use o princípio DRY, mesclando-os em um único local e reutilizando-os conforme necessário.

Princípio do KISS

Seja simples, estúpido [Não complique, tolo]

O princípio do KISS diz que a maioria dos sistemas funciona melhor se não forem complicados; portanto, a simplicidade deve ser uma meta fundamental no desenvolvimento e a complexidade desnecessária deve ser evitada. Originou-se na Marinha dos EUA em 1960, e a frase é atribuída ao designer de aeronaves Clarence Johnson.

É melhor imaginá-lo usando um exemplo, quando Johnson deu um pequeno conjunto de ferramentas a uma equipe de engenheiros de design e instruiu-os a projetar um avião para que um mecânico comum pudesse consertá-lo em um campo em batalha usando apenas esse conjunto. Aqui estúpido denota a relação entre a forma como as coisas quebram e a complexidade das ferramentas disponíveis para repará-las, em vez das habilidades mentais dos engenheiros.

YAGNI

Sigla para Você não precisa disso [você não precisa].

Sempre implemente funções apenas quando você realmente precisar delas, e não quando achar que precisa delas no futuro.

O autor de extrema programação (XP) e o livro “Instalado extrema programação” Ron Jeffries sugere que os desenvolvedores devem implementar apenas a funcionalidade necessária no momento e não tentar prever o futuro, implementando a funcionalidade necessária posteriormente.

Seguir esse princípio deve reduzir a quantidade de código não utilizado no banco de dados, bem como o desperdício de tempo e energia na funcionalidade que não traz benefícios.

Equívocos da Computação Distribuída

Também conhecidas como falácias da computação em rede. Esta é uma lista de suposições relacionadas à computação distribuída que podem levar a falhas de software. Estas são as seguintes premissas:

A rede é confiável.
O atraso é zero.
A largura de banda é interminável.
A rede está segura.
A topologia não muda.
Existe apenas um administrador.
O custo de envio é zero.
A rede é homogênea.

Os quatro primeiros foram listados por Bill Joy e Tom Lyon em 1991, e James Gosling os classificou pela primeira vez como "Conceitos errôneos de computação em rede". Peter Deutsch acrescentou a 5ª, 6ª e 7ª ilusão. No final dos anos 90, Gosling acrescentou o 8º.

Um grupo de engenheiros foi inspirado pelos processos que ocorreram na época na Sun Microsystems.

Esses erros devem ser cuidadosamente considerados ao desenvolver código confiável. Cada um dos erros pode levar a uma lógica incorreta, incapaz de lidar com a realidade e a complexidade dos sistemas distribuídos.

Leis de programação