65 dicas para ser um programador melhor

30 Jun 2017 às 12:29 0 1065 Programação

Algumas dicas que podem ajudar muito a sua maneira de programar e pensar.

Segundo o Autor Willian Justen resolvel ler alguns livros e segundo ele um dos livro era incrível, e resolvel pegar as dicas dele e passar para seu Blog.

Dicas

Se preocupe com o que constrói - Por que se gastar sua vida desenvolvendo software se você não se preocupa com ele ser bom?
Pense! Sobre o seu trabalho - Desligue o piloto automático e tome o controle. Constantemente critique e avalie o seu trabalho.
Dê opções, não crie desculpas - Ao invés de dar desculpas, dê opções. Não diga que não pode ser feito; explique como pode ser feito.
Não conviva com janelas quebradas - Corrija designs ruins, decisões erradas e código ruim quando vê-los.
Seja um catalisador de mudanças - Você não pode forçar as pessoas a mudarem. Mas você pode mostrá-las como o futuro pode ser e ajudá-las a participar na criação disso.
Veja o quadro geral - Não fique tão focado só nos detalhes que esqueça de verificar o que está acontecendo ao se redor.
Faça da Qualidade um requisito - Envolva os usuários para determinar a real qualidade que o projeto precisa ter e cumpra.
Invista regularmente no seu Portfolio de Conhecimento - Faça do aprender um hábito.
Analise criticamente o que você lê ou escuta - Não seja influenciado pelo hype das coisas. Analise a informação em termos de você e seu projeto.
É o que você diz e a maneira que você diz - Não faz sentido você ter grandes ideias se você não consegue comunicá-las efetivamente.
DRY - Don’t Repeat Yourself (Não se repita) - Cada pedaço de código deve ser único e o mais genérico possível.
Faça ser fácil de reutilizar - Se é fácil de reutilizar, pessoas vão reutilizar. Crie um ambiente que suporte o reuso.
Elimine os efeitos colaterais entre coisas não relacionadas - Crie componentes que sejam auto-contidos, independentes e tenham um único e bem definido propósito.
Não existem decisões finais - Nenhuma decisão é escrita em pedra. Ao invés disso, pense que as decisões são escritas em areia de praia, e se planeje para ir sempre mudando e adaptando.
Use “tracer bullets” para achar o alvo - Faça as coisas e as deixe serem vistas, assim você pode ver o quanto elas chegam do que seu cliente realmente deseja.
Faça protótipos para aprender - Prototipar é uma experiência de aprendizado. O seu valor não está no código em que você produz, mas nas lições que aprendeu para montar.
Programe perto do problema - Crie e codifique na linguagem do seu usuário, como se você fosse ele.
Estime para evitar surpresas - Estime antes de começar. Você irá possivelmente ver problemas a frente e conseguirá se organizar melhor.
Itere o tempo com o código - Use a experiência que você ganha construindo a aplicação para refinar a escala de tempo do projeto e ter melhores estimativas.
Escreva e Rabisque - Textos e rabiscos nunca se tornam obsoletos. Eles ajudam a melhorar o seu trabalho e simplificar depurações e testes.
Use o poder da linha de comando - Use linha de comando quando interfaces não são necessárias.
Use um bom editor - O editor precisa ser uma extensão da sua mão, tenha certeza que seu editor é configurável, extensível e vocês trabalham bem juntos.
Sempre use versionamento de código - Versionamento de código são como máquinas do tempo para o seu trabalho, aqui é possível voltar atrás!
Corrija o problema. Não fique culpando - Não importa se o bug é sua culpa ou de outro, é um problema e precisa ser corrigido.
Não entre em pânico quando estiver debugando - Respire bem fundo e pense! sobre o que pode estar causando o bug.
O “select” não está quebrado - É muito raro achar um problema que seja de fato do sistema operacional ou do compilador. O bug na maioria das vezes está na sua aplicação.
Não assuma, prove! - Prove suas premissas num ambiente com dado real e sob as mesmas condições.
Aprenda manipulação de texto na sua linguagem - você passa boa parte do tempo trabalhando com textos. Por que não deixar o computador fazer um pouco desse trabalho para você?
Escreva código que faça código - Geradores de código aumentam sua produtividade e ajudam a evitar duplicações.
Você não pode escrever um software perfeito - Softwares não podem ser perfeitos. Proteja seu código e os usuários dos erros inevitáveis.
Faça o Design com contratos - Use contratos para documentar e verificar se o código faz o que se é pedido.
Quebre cedo - Um programa morto normalmente dá menos problemas que um programa deficiente.
Use assertions para previnir o impossível - use assertions para validar suas premisas. E use para proteger seu código de incertezas.
Use exceptions para problemas excepcionais - Exceptions podem prejudicar a leitura e manutenibilidade do projeto, criando os famosos código spaguetti. Reserve exeptions para coisas de fato excepcionais.
Termine o que você começou - Quando possível, a rotina ou objeto responsável por alocar aquele recurso, precisa ser responsável por desalocar também.
Minimize o acoplamento entre os módulos - Evite o acoplamento aplicando a Lei de Demeter.
Configure, não integre - implemente escolhas de tecnologia para uma aplicação como se opções de configuração, não somente como processo de integração ou código agregado.
Coloque abstrações no código, detalhes no metadata - Codifique para o caso geral e coloque os casos específicos de forma separada do código base.
Analise o Workflow para melhorar a concorrência - busque formas de realizar código em concorrência no workflow de seu usuário.
Desenvolva usando serviços - Codifique em termos de serviços, independentes, bem definidos e com interfaces consistentes.
Separe as Views das Models - Para ganhar flexibilidade a baixo custo, desenvolva sua aplicação em termos de models e views.
Não programe por coincidência - Confie em coisas confiáveis. Tome cuidado com a complexidade acidental e não confunda uma feliz coincidência com o plano final.
Estime a ordem de seus algoritmos - Tenha uma ideia de o quão demoradas as coisas podem acontecer antes de escrever seu código.
Teste suas estimativas - Análises matemáticas de algoritmos não dizem tudo. Teste seu código sempre no ambiente mais próximo do real.
Refatore cedo, refatore frequentemente - Assim como você pode arrumar e reorganizar um jardim, reescreva, retrabalhe e rearquitete seu código sempre que necessário. Corriga a raiz dos problemas.
Codifique para testar - Comece pensando sobre como testar antes de escrever uma linha de código.
Teste seu software, ou seus usuários irão testar por você - Teste implacavelmente. Não deixe seus usuários acharem bugs para você.
Não use código mágico que você não entende - Mágicas podem gerar códigos complicados. Tenha certeza que você entende tudo que o código faz, antes de implementá-lo em seu projeto.
Não pegue requisitos - cave até eles - Os requisitos raramente estão só na superfície. Eles estão enterrados em camadas de premissas, equívocos e política. Veja além do que foi pedido.
Trabalhe com o usuário para pensar como o usuário - Teste com o usuário, é a única maneira de saber como ele de fato será usado. Pegue todos os insights possíveis assim.
Abstrações vivem mais que detalhes - Invista em abstrações, não na implementação. Abstrações podem sobreviver as mudanças de diferentes implementações e tecnologias.
Cria um Glossário do projeto - Crie e mantenha um lugar com todos os termos e vocabulários do projeto, pessoas novas podem não saber certas definições do projeto.
Não pense fora da caixa, ache a caixa! - Ao enfrentar com problemas impossíveis. Pergunte a si mesmo: “Isso precisa ser feito dessa maneira? Isso realmente precisa existir?”.
Comece quando você estiver pronto - Você tem adquirido experiência com o tempo, não ignore as dúvidas que tiver.
Algumas coisas são melhor quando feitas do que descritas - Não caia numa espiral de criar especificações e pensamentos, uma hora você precisa começar a codificar.
Não seja um escravo de métodos formais - Não adote cegamente uma técnica sem colocar no contexto do seu desenvolvimento e suas capacidades.
Ferramentas caras não produzem designs melhores - Tome cuidado com o hype das ferramentas, dogmas da indústria e custos. Julgue suas ferramentas pelos seus méritos.
Organize equipes por funcionalidades - Não separe designers de desenvolvedores, monte equipes da mesma forma que você cria o código.
Teste cedo, teste frequentemente, teste automaticamente - Testes que rodam a cada build são muito mais efetivos que testes esporádicos.
O código não está pronto até que os testes rodem - só isso.
Use sabotadores para testar seu teste - Introduza bugs de propósito em partes separadas do código somente para verificar se os seus testes vão pegar.
Teste o estado de cobertura, não a cobertura do teste - Identifique e teste os diferentes estados do código. Testar só linhas de código não é o suficiente.
Ache bugs uma única vez - Uma vez que um humano encontrou um bug, essa deverá ser a última vez que ele irá achá-lo. Crie testes para sempre verificar o bug.
Inglês é uma outra linguagem de programação - Escreva documentos como você escreve código, honre o princípio do DRY, use metadata e geração automática.
Assine o seu trabalho - os grandes construtores ficam orgulhosos de assinar suas obras, você também deveria se orgulhar.

Conclusão

Espero que depois dessa leitura, você tenha identificado várias das suas falhas e também vários dos seus acertos e se organize para seguir sempre assim. E lembre-se o aprendizado é algo contínuo e importante, então sempre dê uma lida nessas dicas e pensa se está utilizando tudo que está ali ou se está se sabotando em algum momento.

Fonte: Autor Willian Justen - Desenvolvedor Front End de willianjusten.com.br