Desenvolvimento de Software1 April 2006 4:48 am
Essas são algumas dicas que realmente fazem diferença para quem quer ser um desenvolvedor profissional de software:
- Aprimore suas habilidades.
Por que passar a vida desenvolvendo software se você não se preocupa em fazê-lo direito? - Reflita sobre o seu trabalho
Desligue o piloto automático e assuma o controle. Constantemente critique e valide seu trabalho. - Forneça opções. Não dê desculpas esfarrapadas
Ao invés de desculpas, forneça opções. Não diga que não pode ser feito; explique o que pode ser feito. - Não conviva com janelas quebradas
Corrija designes pobres, decisões erradas e código ruim quando se deparar com eles. - Seja um catalisador de mudanças
Você não pode forçar as pessoas a mudarem. No entanto, você pode lhes mostrar como o futuro pode ser e convencê-las a participar da sua criação. - Olhe o quadro geral
Não mergulhe nos detalhes para não esquecer de olhar o que está acontecendo ao seu redor. - Faça da qualidade um requerimento obrigatório
Envolva seus usuários para conseguir capturar os requerimentos que impõem qualidades reais para o projeto. - Invista regularmente no seu portfolio de conhecimentos
Torne a aprendizagem um hábito. - Analise de forma crítica o que você lê e ouve
Não se abale com o que dizem os vendedores, a mídia especializada ou com dogmas. Analise a informação de acordo com a sua realidade e a do seu projeto. - O que você diz e como você diz
Nada adianta ter grande idéias se você não consegue comunicá-las de maneira eficiente. - DRY – Don’t Repeat Yourself (Não se repita)
Cada pedaço do conhecimento deve ter uma representação única, sem ambigüidades e de representativa autoridade no sistema. - Torne fácil de reutilizar
Se for fácil de reutilizar, as pessoas reutilizarão. Crie um ambiente que favoreça a reutilização. - Elimine o efeito de coisas não relacionadas
Projete componentes que sejam auto-contidos, independentes e com um único propósito bem definido. - Não existem decisões finais
Nenhuma decisão é gravada em pedra. Pense em cada decisão como sendo gravada na areia da praia e prepare-se para as mudanças. - Utilize o rastro das balas para encontrar o alvo
O rastro que as balas deixam leva você para em direção ao alvo na medida em que você experimenta novas coisas e vê quão próximo conseguiu chegar do objetivo. - Faça protótipos para aprender
Prototipação é uma experiência de aprendizagem. O seu valor não está no código produzido, mas sim nas lições aprendidas. - Programe próximo do domínio do problema
Planeje e codifique utilizando o vocabulário do usuário. - Estime para evitar surpresas
Estime antes de começar. Você descobrirá quais são os problemas em potencial para o futuro. - Interaja o cronograma com o código
Use a experiência você adquire a medida que implementa para refinar suas estimativas de prazo. - Mantenha o conhecimento com comentários claros
Comentários claros nunca ficam obsoletos. Eles ajudam a alavancar seu trabalho e simplificam o debug e testes. - Use o poder da linha de comando
Use a linha de comando quando a interface gráfica não suprir suas necessidades. - Use um único editor. E use-o bem
O editor deve ser uma extensão da sua mão. Certifique-se de que o seu editor é configurável, extensível e adaptável as suas necessidades. - Sempre use controle de versão
O controle de versão é a máquina do tempo do seu trabalho – Com ele você pode sempre voltar atrás. - Corrija o problema, não a acusação
Não importa se o bug é uma falha de outra pessoa – ele ainda assim é um problema e portanto precisa ser consertado. - Não entre em pânico quando estiver debugando
Respire fundo e PENSE sobre o que pode estar causando o bug. - "select" não está quebrado
É raro você encontrar um bug no sistema operacional, no compilador, ou mesmo em programas e bibliotecas comerciais. Na maioria das vezes o problema está mesmo na sua aplicação. - Não presuma. Prove
Prove suas suposições no ambiente atual, com dados reais e para as condições de fronteira. - Aprenda uma linguagem de manipulação de textos
Você gasta grande parte do seu dia trabalhando com textos. Por que não deixar que o computador faça algo mais por você? - Escreva código que escreva código
Geradores de código aumentam sua produtividade e ajudam a evitar duplicidade. - Você não pode escrever um software perfeito
Software não pode ser perfeito. Mas proteja o seu código e seus usuários dos erros inevitáveis. - Projete para contratos (Design by Contracts)
Utilize contratos para documentar e verificar que o código não faz nem mais nem menos do que aquilo que necessita fazer. - Falhe cedo
Um programa morto costuma causar menos estrago do que um programa aleijado. - Use asserções para prevenir o impossível
Asserções validam suas suposições. Utilize-as para proteger seu código do mundo incerto. - Use exceções para problemas excepcionais
Exceções podem sofrer dos mesmos problemas de manutenção e legibilidade dos clássicos códigos em espaguete. Reserve as exceções para coisas realmente excepcionais. - Acabe o que você começou
Sempre que possível os métodos e objetos que alocam recursos devem ser responsáveis por desalocá-los. - Minimize o acoplamento entre módulos
Evite o acoplamento escrevendo código “tímido” e aplicando a lei de Demeter. - Configure ao invés de integrar
Implemente as escolhas tecnológicas de uma aplicação como opções de configuração, não como partes integradas da aplicação. - Coloque a abstração no código e os detalhes em metadados
Programe para o caso geral e coloque as especificidades fora da base do código compilado. - Analise o processo para melhorar a concorrência
Explore a concorrência dos processos dos seus usuários. - Projete utilizando serviços
Projete em termos de serviços independentes, com interfaces consistentes e para objetos concorrentes e bem definidos. - Sempre projete para concorrência
Permita a concorrência e você irá projetar interfaces limpas e com poucas suposições. - Separe visões de modelos
Ganhe flexibilidade a um baixo custo projetando suas aplicações em termos de modelos e visões. - Use quadro-negro para coordenar processos
Use quadros-negro para coordenar agentes ou fatos discrepantes enquanto mantém a isolação e independência entre os participantes. - Não programe por coincidência
Mantenha-se nas coisas confiáveis. Cuidado com complexidade acidental e não confunda uma feliz coincidência com uma regra geral. - Estime a ordem dos seus algoritmos
Faça uma estimativa do que algoritmo precisa suportar antes de escrever código. - Teste suas estimativas
Análises matemáticas de algoritmos não lhe dizem tudo. Tente medir o desempenho do seu código no ambiente real. - Refatore cedo, refatore sempre
Assim como você remove as ervas daninhas e rearranja o jardim, reescreva e reestruture o código constantemente. Corrija na raiz do problema. - Projete para os testes
Comece a pensar como testar antes de escrever uma linha de código. - Teste o seu software; ou o seu usuário testará por você
Teste arduamente. Não faça o seu usuário encontrar os erros que você deveria ter encontrado. - Não utilize assistentes de código que você não entenda
Assistentes podem gerar toneladas de código. Esteja certo de que você entenda tudo o que foi gerado antes de incorporá-lo ao seu projeto. - Não colha os requerimentos – Procure por eles profundamente
Requerimentos raramente estão na superfície. Normalmente eles estão soterrados sob várias camadas de suposições, preconceitos e politicagem. - Trabalhe com o usuário para pensar como o usuário
Esta é a melhor maneira conseguir inspiração sobre como o sistema será utilizado. - Abstrações vivem mais do que detalhes
Invista na abstração, não na implementação. Abstrações podem sobreviver às barreiras criadas pelas mudanças de implementação e pelas novas tecnologias. - Use um glossário de projeto
Crie e mantenha uma fonte única com todos os termos e vocabulários específicos do projeto. - Não pense fora caixa – Encontre a caixa
Quando confrontado com um problema impossível, identifique as verdadeiras limitações. Pergunte a você mesmo: “Isso precisa ser feito dessa maneira? Isso precisa ser feito por completo?”. - Comece quando você estiver pronto
Você adquire experiência durante toda a sua vida. Não deixe passar desapercebido as pequenas dúvidas. - Algumas coisas são melhores feitas do que descritas
Não caia na espiral da especificação – em algum momento você precisa começar a codificar. - Não seja um escravo dos métodos formais
Não adote uma técnica sem antes analisá-la no contexto de suas práticas de desenvolvimento e capacidade. - Ferramentas caras não produzem projetos melhores
Não se impressione somente pelo preço estampado na etiqueta. Julgue as ferramentas pelos seus méritos. - Organize o time pela funcionalidade
Não separe os designers dos programadores nem os testadores dos modeladores. Forme os times da mesma maneira que você organiza o código. - Não use manual de procedimentos
Um script ou arquivo de lote pode executar as mesmas instruções, na mesma ordem, o tempo todo. - Teste cedo. Teste sempre. Teste automaticamente
Testes que rodam a cada build são muito mais eficientes do que planos de testes empoeirados em uma prateleira. - O código não está terminado até todos os testes rodarem
E ponto final. - Use sabotadores para testar seus testes
Coloque bugs propositalmente em uma cópia separada do código para verificar se os testes irão apontá-los. - Teste a cobertura de estados, não a cobertura de código
Identifique e teste estados significativos do programa. Testar apenas linhas de código não é o suficiente. - Encontre um bug uma única vez
Quando um testador humano encontrar um bug deve ser a última vez que um humano encontre esse bug. Utilize testes automáticos para verificar esse bug a partir de então. - O português também é uma linguagem de programação
Escreva documentos da mesma forma que você escreve código: obedeça ao principio do DRY (não se repita), utilize metadados, MVC, geradores automáticos, etc. - Crie documentação durante, ao invés de tentar encaixá-la depois
Documentação criada separada do código muito mais chance de estar incorreta e desatualizada. - Supere um pouco as expectativas dos seus usuários
Compreenda quais são as expectativas do seu usuário e então entregue um pouquinho mais do que ele estava esperando. - Assine o seu trabalho
Mesmo os primeiros artesões ficavam orgulhosos de assinar seus trabalhos. Você também deveria ficar.
Estas dicas foram extraidas do livro The Pragmatic Programmer
