Em computação, um programador, desenvolvedor, coder ou engenheiro de software refere-se a alguém que faz programação de computadores e escreve software.
Um programador pode ser alguém que desenvolve ou faz manutenção de softwares em um grande sistema ou alguém que desenvolve software para uso em computadores pessoais.
Os desenvolvedores profissionais gastam menos de 10 por cento do seu tempo de trabalho escrevendo código, consomem cerca de 60 por cento do tempo de trabalho em um projeto, na análise de problemas, concebendo soluções, documentando as decisões, depurando, mantendo ou melhorando o código fonte.
Os 30 por cento restantes do tempo de um desenvolvedor é tomado por reuniões ou simplesmente desperdiçado (Às vezes, não há nenhuma diferença entre reuniões e tempo perdido.)
Se você estiver escrevendo um programa que é maior do que algumas linhas, então não é o bastante apenas sentar e começar a codificação. Você precisa dar três passos para tornar o seu programa o melhor possível.
Os 3 Ds – Documentação, Design e Depuração
- Documentação: Certificar-se de que outras pessoas podem ler o seu programa.
- Design: Ter certeza que seu programa resolve o problema certo e está organizado para que seja eficiente e potencialmente reutilizável.
- Depuração: Certificar-se de que seu programa não tenha nenhum erro e que ele responda adequadamente quanto a entrada de dados errados.
Documentação
Documentação torna possível ler, usar e manter um programa:
- Na programação, a documentação é toda a escrita associada ao seu programa que não seja um código.
- Em uma linguagem de programação, legibilidade é uma virtude nobre.
- Isso significa que seu código é parte da documentação também.
- Escolher bons nomes faz parte da documentação!
- LEMBRE-SE, programação, começa e termina com a documentação.
- Comece por escrever o problema que o seu programa se destina a resolver.
- Antes mesmo de começar a escrever o seu programa, é uma boa ideia escrever notas sobre o objetivo do programa.
- Finja que você precisa explicá-lo para outra pessoa, e se você tem alguém para ler a notas, melhor.
- Termine, certificando-se de que a documentação ainda corresponde ao programa.
Se você não escrever a documentação, você vai achar que é difícil usar ou manter o seu programa depois de passado seis meses (mesmo se você é a única pessoa que usa o programa).
Design
Projetar é realmente um atalho para duas partes interligadas de programação: análise e design.
O que você realmente quer?
Análise é o processo de determinar o problema que você está tentando resolver. É semelhante ao processo que um arquiteto faz você passar para remodelar a sua cozinha: “O que você realmente quer?”. Por exemplo, você pode querer escrever um programa para automatizar seus dados de backup. Essa é uma descrição geral, mas você precisa de uma lista mais específica das tarefas que você deseja que o programa realize, como:
- Quantas vezes você quer fazer os backups?
- Você quer fazer backup de todos os dados ou apenas dados alterados desde o último backup?
- Quanto tempo você quer manter os backups?
Se você está remodelando sua cozinha, então este é o ponto onde o arquiteto elabora um projeto. O projeto não é a própria cozinha; é o plano que deve ser seguido para a construção da nova cozinha. se você está escrevendo um programa, você começa a construir o contorno do programa, que é semelhante a uma planta. Na verdade, as pessoas que se concentram na análise e concepção de programas são frequentemente chamados de arquitetos de software.
A Pseudo codificação de seus pensamentos
Uma maneira de projetar seu programa é criando um esboço do tipo, usando o que é chamado de pseudo-código. Você escreve um esboço do que o seu programa vai fazer, utilizando as estruturas que você vai precisar usar quando você escrever o programa (como definições de classe e função, as declarações), mas você não deve se preocupar com os detalhes de sintaxe necessárias para escrever código de trabalho.
Pseudo-código tende a assemelhar-se a programas reais, por isso leva menos esforço para converter pseudo-código em código funcionando. quando o processo de pseudo-codificação é concluída, os detalhes são fáceis de escrever.
Depuração
Um bug é um erro em um pedaço do software que faz com que ele funcione de forma inadequada ou retorne resultados incorretos.
Ensine a Velhos Bugs Novos Truques:
O uso da palavra bug (pau em português) já era comum antes do software ser inventado, por exemplo, Thomas Edison usou em 1878 para descrever problemas com suas invenções. Algumas pessoas vão dizer-lhe, porém, que o termo deriva de um incidente no qual foi encontrado um inseto real que estava causando falhas dentro de um computador no início de 1947.
Embora um bug seja mais velho do que escrever programas, depuração tem sido uma parte inerente da escrita de programas desde que as pessoas começaram a escrever softwares. Um dos primeiros cientistas da computação, Maurice Wilkes, é conhecido por ter dito: “Eu me lembro do momento exato em que eu percebi que uma grande parte da minha vida a partir de então ia ser passar a encontrar erros em meus próprios programas.”.
Escrever um programa complexo é algo como a concepção de um edifício. O arquiteto restringe inclusão do tempo, dinheiro, bom gosto, e os limites estruturais dos materiais. Programação também requer um equilíbrio entre necessidades múltiplas, muitas vezes incluindo o tempo, o dinheiro, a solicitações de recursos de vários grupos de pessoas, e da disponibilidade de quantidades suficientes de cafeína.
Um exemplo de um bom trabalho é com bom humor, o pythonista Tim Peters contribuiu com 19 diretrizes para um bom código Python. Considerado a melhor destilação da filosofia da programação Python:
Bonito é melhor que feio.
Explícito é melhor que implícito.
Simples é melhor que complexo.
Complexo é melhor que complicado.
Plano é melhor que aninhado.
Esparso é melhor que denso.
Legibilidade conta.
Casos especiais não são especiais o suficiente para quebrar as regras.
Embora praticidade vença a pureza.
Erros nunca devem passar em silêncio.
A menos que explicitamente silenciados.
Diante da ambiguidade, recuse a tentação de adivinhar.
Deve haver um – e preferencialmente só um – modo óbvio para fazer isso.
Apesar de que o caminho pode não ser óbvio à primeira vista, a menos que você seja holandês.
Agora é melhor do que nunca.
Embora nunca é muitas vezes melhor do que agora.
Se a implementação é difícil de explicar, é uma má ideia.
Se a implementação é fácil de explicar, pode ser uma boa ideia.
Namespaces são uma grande ideia – vamos fazer mais desses!
-Tim Peters
Versão original: http://www.python.org/doc/humor/#zen
Ricardo Mantovani
Desenvolvimento Código Aberto 