Os princípios de programação mais estranhos dos quais você nunca ouviu falar

Propaganda

Já orientamos você pela princípios de programação mais essenciais 10 princípios básicos de programação que todo programador deve seguirSempre escreva um código que possa ser mantido por qualquer pessoa que possa acabar trabalhando no seu software. Para esse fim, aqui estão vários princípios de programação para ajudá-lo a limpar seu ato. consulte Mais informação você precisa saber, mas há outra classe de princípios de programação que podem provar ainda mais benéfico Do que aqueles.

Considerando que os princípios acima mencionados ensinam como ser inteligente com seu código, os seguintes princípios o ensinarão a ser sensato com o seu código. Alguns deles são estranhos e muitos são engraçados, mas todos são igualmente práticos e importantes. Preste atenção!

1. O princípio de inchaço

Este tem tantas variações que é difícil escolher uma como a principal. Talvez a versão mais “oficial” seja a Lei do Envelope de Software, mais comumente chamada Lei de Zawinski, nomeado após Jamie Zawinski e mencionado em A arte da programação UNIX:

“Todo programa tenta expandir até poder ler e-mails. Os programas que não podem expandir-se são substituídos por outros que podem. ”

Ele está falando sobre a tendência dos programas de atrair mais e mais recursos ao longo do tempo e, inevitavelmente, desviar para o aumento da complexidade. Você pode saber isso como característica fluência, que é a adição contínua de novos recursos que não têm nada a ver com o objetivo principal do programa. A fluência do recurso leva ao inchaço, e o inchaço geralmente é indesejável.

Isso também pode se aplicar ao desempenho do software:

"O software se expande para consumir todos os recursos disponíveis."

Nos anos 90, os discos rígidos, as CPUs e a RAM eram muito mais restritivos do que são hoje e os programadores trabalharam duro para se encaixar o máximo possível dentro dos limites. No entanto, agora que temos unidades maiores, CPUs mais rápidas e mais RAM, ainda lutamos para respeitar os limites. Tudo fica inchado com o tempo. É seu trabalho manter isso sob controle.

2. A mentalidade "pior é melhor"

Quase como se em resposta ao Princípio Bloat, temos a Pior é melhor mentalidade, cunhado pela primeira vez por Richard P. Gabriel, em um ensaio que ele escreveu sobre qualidade de software:

"Software limitado, mas simples de usar, pode ser mais atraente para o usuário e para o mercado do que o contrário."

Em outras palavras, é aconselhável descobrir o um problema seu software tem como objetivo resolver e ser muito bom nessa única coisa. Mantenha simples. Quanto mais você se espalha, mais incontrolável se torna o projeto e mais indesejável se torna para os usuários.

O que acontece quando você ignora isso? Você acaba com o Princípio de Peter de software:

"Um projeto excessivamente complexo acabará se tornando complexo demais para ser entendido mesmo por seus próprios desenvolvedores".

Vem do princípio mais amplo de Peter, que afirma que quando os funcionários são promovidos com base em seus competência e não a competência esperada em sua próxima posição, todos os funcionários acabam em uma posição de incompetência. Pegue esse princípio e aplique-o ao software, e você verá por que um software pior costuma ser melhor.

3. Lei de Eagleson

"Qualquer código que você não veja há seis meses ou mais pode ter sido escrito por outra pessoa."

Esse ditado aparentemente desmotivacional é realmente algo a abraçar. O fato é que ninguém é perfeito. Você pode pensar que é um programador genial agora, mas há sempre algo mais que você pode aprender, sempre mais espaço para crescer. Se você olhar para trás em código antigo e se encolher, provavelmente significa você aprendeu algo novo desde então.

Dito de outra forma: se você olhar para trás em um projeto antigo e não conseguir ver nada que possa melhorar ou faria diferente da próxima vez, provavelmente está estagnado como programador.

4. Princípio da menor surpresa

"Se um recurso necessário tem um alto fator de espanto, pode ser necessário redesenhar o recurso".

Publicado pela primeira vez no IBM Systems Journal Em 1984, esse princípio ainda é surpreendentemente relevante hoje - talvez mais do que nunca.

Essencialmente, ele toca no delicado equilíbrio entre inovação e familiaridade: se um software é muito diferente de outros de seu tipo e não está em conformidade com as expectativas do usuário, então eles provavelmente não vão adotá-lo. É melhor buscar melhorias incrementais que são grandes o suficiente para serem impressionantes, mas pequenas o suficiente para se familiarizar.

5. Lei da Entomologia Cibernética

"Sempre há mais um bug."

Frequentemente chamado Lei da Entomologia Cibernética de Lubarsky, não está claro quem é esse Lubarsky. No entanto, o princípio dele soa verdadeiro para todos os programadores: não importa o quão limpo você escreva seu código, não importa quão de maneira robusta, você testa seus módulos, não importa quantas vezes refatorar suas classes, sempre haverá outro erro.

De certa forma, este é um princípio libertador. Enquanto deveríamos definitivamente esforçar-se para código sem erros, também é importante lembrar que o perfeccionismo é o inimigo do bem. Procure por erros, corrija-os quando surgirem e depois siga em frente.

6. Lei de Kernighan

“A depuração é duas vezes 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, o mesmo que co-autor a bíblia da linguagem de programação C Por que ainda vale a pena aprender programação CC não é uma língua morta. De fato, a revista IEEE Spectrum a classificou como a segunda melhor língua em 2017. Aqui estão cinco razões pelas quais. consulte Mais informação , é famoso por essa lei perspicaz. O cerne disso é: escrever Boa código, escreva legível código, escreva simples código, qualquer coisa, desde que não seja esperto código.

Tentar flexibilizar seus músculos de programação com a complexidade da torre de marfim é exatamente o oposto do que significa escreva código limpo e melhor 10 dicas para escrever código mais limpo e melhorEscrever código limpo parece mais fácil do que realmente é, mas os benefícios valem a pena. Veja como você pode começar a escrever um código mais limpo hoje. consulte Mais informação . Quanto mais difícil for o seu código, mais difícil será a depuração quando inevitavelmente quebrar.

E como Robert C. Martin explica, também não se trata de depuração:

“De fato, a proporção de tempo gasto lendo e escrevendo é bem superior a 10 para 1. Estamos constantemente lendo código antigo como parte do esforço para escrever um novo código... [Portanto,] facilitar a leitura facilita a escrita. ”

7. Depuração de pato de borracha

Este não é tanto um princípio, mas uma técnica, mas é tão útil e estranho que seremos negligentes em deixar de fora.

Contado pela primeira vez em O programador pragmático, depuração de pato de borracha é quando você depura um software corrompido, explicando seu código a um objeto inanimado (por exemplo, um pato de borracha) uma linha de cada vez. Funciona porque o ato de explicação desencadeia diferentes partes do seu cérebro e é mais provável que você encontre inconsistências e descubra onde errou.

Por esse motivo, um pato de borracha pode ser um presente surpreendentemente bacana para programadores Os melhores presentes de nerd para programadores: 20 idéias para codificadores e nerdsProcurando um presente para um programador? Aqui estão os melhores presentes para geeks, que variam de teclados mecânicos a mesas de pé e muito mais. consulte Mais informação , seja para você ou para um amigo de programação.

8. A regra dos noventa e noventa

“Os primeiros 90% do código representam os primeiros 90% do tempo de desenvolvimento. Os 10% restantes do código representam os outros 90% do tempo de desenvolvimento. ”

Este pequeno provérbio insolente de Tom Cargill está no centro de por que a programação pode ser tão frustrante: não importa o quão perto você pense que está de terminar, você está muito mais longe do que até as suas melhores estimativas. Quando você pensa que terminou, está apenas na metade do caminho.

Isso anda de mãos dadas com a Lei de Hofstadter:

"Sempre leva mais tempo do que o esperado, mesmo quando você considera a lei de Hofstadter".

9. Lei de Parkinson

"O trabalho se expande para preencher o tempo disponível para sua conclusão."

Esse princípio, cunhado por Cyril Northcote Parkinson, é um princípio mais amplo que se aplica absolutamente à programação e vai de mãos dadas com a regra dos noventa e noventa: acima, no entanto, quanto tempo você precisa para concluir um projeto é exatamente quanto tempo vai demorar leva. No desenvolvimento de software, "terminar cedo" é praticamente um mito.

A lei de Parkinson é a razão pela qual prazos adequados são cruciais se você deseja finalizar e enviar seu software. É por isso que os programadores profissionais modernos frequentemente recomendam princípios ágeis de gerenciamento de projetos Como usar os princípios de gerenciamento ágil de projetos para organizar sua vidaO Agile, mais conhecido como método de gerenciamento de projetos, é uma ótima estrutura para gerenciar sua vida pessoal. Mostraremos quais princípios você pode emprestar - download gratuito da planilha incluído! consulte Mais informação e ferramentas de gerenciamento de projetos como o Asana Trello vs. Asana: A melhor ferramenta gratuita de gerenciamento de ...Escolher entre Trello e Asana é difícil. Aqui, comparamos os planos gratuitos e ajudamos você a decidir qual ferramenta de gerenciamento de projetos é melhor para sua equipe. consulte Mais informação .

10. Lei de Brook

"A adição de mão de obra a um projeto de software atrasado torna-o mais tarde."

Na próxima vez em que você estiver atrasado em um projeto, o que é provável, já que a maioria dos projetos de programação precisa de mais tempo do que o previsto, lembre-se de que adicionar codificadores não o resolverá mais rapidamente.

De fato, provavelmente levará mais longo completar. Você não apenas precisa atualizar o (s) novo (s) codificador (es), como provavelmente colidirá com os codificadores existentes. Mais coisas precisarão ser documentadas, mais burocracia será necessária para manter todos na mesma página, e mais atritos surgirão em toda a experiência de crise.

Avançando como Programador

Agora que você conhece esses princípios, você está realmente mais adequado para o mundo real de programação, não apenas o que você encontrou na escola, em um curso na web ou em um campo de inicialização. Esses princípios vêm de anos e anos de experiência e falhas.

Com essa nova sabedoria, agora você pode estabelecer um carreira de programação de alta demanda 10 trabalhos de programação de computadores que estão com demanda no momentoComo conseguir um trabalho de programação pode ser difícil no cenário atual, considere se concentrar em uma das seguintes concentrações para melhorar suas chances de sucesso. consulte Mais informação com expectativas mais realistas. Para isso, aprenda como maximize suas oportunidades de carreira em programação Como melhorar suas oportunidades de carreira em programaçãoSe você deseja iniciar, reiniciar ou melhorar sua carreira de programação, não é fácil. Se você está na faculdade, a hora é agora. Aqui estão algumas dicas que podem levá-lo longe. consulte Mais informação . E se você decidir que a programação não é para você, não se preocupe - considere um destes trabalhos de tecnologia sem codificação A codificação não é para todos: 9 trabalhos de tecnologia que você pode obter sem eleNão desanime se você quiser fazer parte do campo da tecnologia. Há muitos empregos para pessoas sem habilidades de codificação! consulte Mais informação .

Qual desses princípios lhe parece mais verdadeiro? Conhece algum outro princípio de programação estranho que perdemos? Deixe-nos saber nos comentários abaixo!