O que você considera o primeiro princípio (s) de programação?

Eu sempre gostei de me perguntar "qual é o primeiro princípio (s) disso?" depois que aprendi as coisas básicas de algo (por exemplo, programação). É uma pergunta inspiradora, a IMO, que pode forçá-lo a pensar nos princípios mais importantes por trás de algo, especialmente em uma habilidade como programação.

Então, qual você acha que é o primeiro princípio (s) de programação? Vou dar a minha resposta abaixo um pouco mais tarde.

1. BEIJO - mantenha-o simples estúpido
2. SECA - Não se repita
3. YAGNI - Você não vai precisar disso

Escreva um código como se fosse você que tivesse que manter esse código.

Seja o mais preguiçoso possível.

Zen, parte I: programar é apenas a estrada, não o caminho.

Programar é apenas a técnica para ensinar ao computador o que ele precisa fazer. Ser bem-sucedido na criação de software rápido e confiável significa conhecer seus algoritmos, práticas recomendadas e todas as outras coisas não necessariamente conectadas à sua programação (linguagem).

Zen, parte II: Se você estiver com pressa, passeie devagar. Se você realmente estiver com pressa, faça um desvio.

Parece bobagem, mas não se comprometa a comprometer-se (realmente) depois. Eu tenho uma regra: se você está no centro de um programa, tente ser o mais preciso e bom possível. Se você estiver usando métodos do núcleo que são profundos em seu software, tente ser mais rápido na codificação. Se você estiver codificando acima desses dois, poderá ficar um pouco mais desleixado.

Os erros de projeto são os mais difíceis de encontrar e / ou corrigir; o próximo passo são os erros de programação nas partes em que todos confiam, depois as "partes reais do software que mostra". Se você precisar corrigir um erro de design no final de um projeto, ummm, isso não é bom ... ;-)

Zen, parte III: Conheça o seu caminho, Neo.

Conheça seu ambiente, ferramentas e tudo o que você confia diariamente e classifique-o para que funcione para você. Melhor se você usar seu "ambiente" de programação tão natural que você nem precisa pensar nisso. Se você precisar fazer um trabalho, não introduza "coisas novas e sofisticadas", mas faça seu trabalho. Esse material pode ser introduzido em um novo projeto, ou seja, quando você tiver tempo para prepará-lo e usá-lo.

BEIJO (mantenha-o simples, estúpido).

Realmente implora a pergunta "Como você define simples?" E também "Quando é algo simples demais para a tarefa em questão?" É por isso que você não pode se tornar um bom programador apenas conhecendo o primeiro princípio de programação.

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

Não reinvente a roda.

Entenda o problema primeiro!

YAGNI - Você não precisa disso . A idéia por trás do YAGNI é programar para seus requisitos, não para recursos potenciais em potencial. A premissa é que, mantendo o que você precisa programar, você (entre outras coisas) reduzirá o inchaço do código, reduzirá a complexidade, evitará a fluência de recursos e reduzirá as restrições sobre o que pode ser feito (e como isso pode ser feito) no futuro.

Suponho que funcione em conjunto com o design modular: os recursos futuros podem ser aumentados sem reprojetar o código existente.

Saber quando não programar.

Café dentro, código de saída.

Se não foi testado, está quebrado.

Existem duas maneiras de construir um design de software: uma maneira é tornar tão simples que obviamente não há deficiências, e a outra maneira é torná-lo tão complicado que não há deficiências óbvias. O primeiro método é muito mais difícil.

- Charles Antony Richard Hoare

1. Distinguir entre causa e efeito (trabalhando com computadores)

2. Distinguir entre fato e opinião (trabalhando com pessoas)

3. Tão simples quanto possível, mas não mais simples (design)

Programar é um meio, não um fim. Ou talvez "Can não significa que deveria".

1. Entenda por que o programa fará alguém feliz (caso contrário, por que você não está brincando lá fora com todas as outras crianças?). (Essa pessoa pode ser você.)
2. Desenvolva um modelo conceitual do domínio comercial que capture toda a complexidade necessária e não mais.
3. Desenvolva um modelo conceitual da arquitetura de software que capture toda a complexidade necessária e não mais.
4. Implacavelmente mantenha toda a outra complexidade de fora.

Na minha opinião, o princípio mais importante é a redução da complexidade pela criação de boas abstrações .

Isso inclui

• entender o problema a ser resolvido,
• projetar uma solução apropriada para ele e
• implementá-lo,
• de preferência de uma maneira que mantenha o código compreensível e sustentável,

mas também a determinação do ponto em que parar de criar abstrações e chegar às propriedades fundamentais das tecnologias de implementação (por exemplo, sistema de banco de dados, linguagem de programação) para impedir a criação de complexidade adicional evitável.

Programa com um público em mente. Por isso, não assuma que tudo o que você escreve não será lido e mantido por você ou outra pessoa.

Um corolário disso: prove que você entende o problema que está tentando resolver nomeando bem suas variáveis, funções e classes!

não funciona até que você mostrou isso em um teste

Pense primeiro, codifique depois.

Você não é nem de longe tão inteligente quanto pensa. Pergunte. Aprenda a valorizar seus colegas.

Ao depurar, a primeira resposta quase sempre estará errada.

O código que você escreve com a intenção de jogar fora tende a se tornar uma pedra angular de processos muito maiores. Nunca deixe nada escrito a esmo.

Qualquer problema pode ser resolvido com outra camada de indireção.

Conheça suas ferramentas.

Princípio: Software é captura de conhecimento .

Consequências: Muitas técnicas de representação do conhecimento, todas baseadas em Abstração . Dá-nos camadas, camadas, encapsulamento, separação de preocupações.

Muitas técnicas para representação de procedimentos, todas baseadas em Sequência , Escolha , Repetição .

Escreva um código para o próximo cara.

Sempre escreva um código como se a pessoa que o manteria fosse um serial killer psicótico que sabe onde você mora

Além disso, nunca pense que você sabe tudo sobre programação, continue aprendendo

Eu comecei a programar estudando a eletrônica digital, então acho que os portões lógicos básicos (não, e, ou, xor, implica) foram os primeiros princípios da programação.

É tudo sobre o usuário.

Garbage in - Garbage Out Não importa o quão agradável seja a sua interface do usuário se os dados estiverem ruins.

SECO, praticamente tudo o que gera. O KISS é a outra extremidade do ato de equilíbrio para garantir que você não busque a elegância do software em níveis de insanidade.

Comece com a saída e trabalhe para trás.