Toda linguagem de programação moderna tem alguma forma de analisador de código que auxilia os programadores a encontrar problemas nem sempre óbvios. Porém, não é todo programador que sabe da existência desses analisadores e normalmente escreve-se código sem que este seja devidamente chancelado por um analisador de código.
Os analisadores são ferramentas antigas mas, mesmo assim, são poucos os programadores que fazem uso dos mesmos. No mundo unix, o Lint analisa código C fornecendo ao desenvolvedor um relatório de falhas potenciais que precisam ser avaliadas. O mesmo pode ser dito do Clang, um analisador para Objective C usado no XCode no desenvolvimento para plataforma Apple.
A utilização desses analisadores tem como principal função minimizar o trabalho de manutenção posterior do código pois indicam falhas potenciais que podem ser evitadas antes da entrega, durante o desenvolvimento. Além disso, auxiliam o desenvolvedor na compreensão de falhas que ele mesmo costuma cometer inconscientemente, melhorando a qualidade do código escrito.
Como eu tenho o costume de dizer, o conhecimento de uma linguagem de programação é apenas uma pequena parte do conhecimento necessário para que um desenvolvedor seja considerado bom. Algoritmos, estruturas de dados e conhecimentos sobre ferramentas de desenvolvimento que agilizem o trabalho também fazem parte do rol de conhecimentos necessários para um bom developer.
Referência: Lista de analisadores de código (link externo: wikipedia)
Tudo começou com um grande amigo meu que certa vez me disse que navegava na internet apenas usando tela cheia. A princípio achei isso um pouco estranho, talvez por estar habituado a ver tudo em uma janelinha. Porém, depois que iniciei minhas atividades no Mac OS X comecei a perceber o quanto o modo em tela cheia é interessante ao usuário no que tange ao foco de trabalho.
Ao trabalhar com várias janelas é difícil concentrar-se no que se está fazendo. É muita informação ao mesmo tempo e a atenção dispersa acaba por causar um grande dano na produtividade. O modo de tela cheia de uma aplicação permite que você foque seu trabalho completamente, sem distrações. No Windows pode-se realizar isso configurando-se a barra de tarefas para desaparecer automaticamente e maximizando a janela na qual está trabalhando. Alterar é simplesmente usar o velho truque do ALT-TAB.
O Mac OS X permite colocar as janelas em tela cheia e a alternância pode ser feita com ⌘ tab ou usando F3. Em ambos os sistemas isso é algo bem resolvido e fica a dica para que você use este recurso a seu favor. O foco na aplicação que está usando permite que você seja mais produtivo. Afinal, você só consegue usar uma única aplicação por vez. A ideia de ter vários programas em execução é interessante pois permite a alta disponibilidade dos mesmos, ou seja, alternar entre programas é mais rápido do que carregá-lo do zero.
De início é um pouco difícil acostumar-se a trabalhar com a tela cheia. No entanto,o ganho de produtividade justifica o impacto neste modo de operação pois você ganhará mais foco e maior produtividade.
Se você entrar nas redes sociais voltadas para profissionais, como o Linked-in, verá que a vaidade é a ordem do dia. A grande maioria das pessoas coloca em seus Curricula Vitae (está correto: estou falando no plural, para quem não sabe latim) cargos pomposos. E em alguns momentos você esbarra com CTO de empresa que não tem mais do que 20 anos com menos de 5 anos de experiência e que procura emprego como programador. Mentira tem perna curta.
Esse tipo de atitude nas redes sociais focadas em profissionais demonstra um fato corriqueiro e cotidiano do brasileiro: todo mundo quer o cargo, mas ninguém quer a função. Você quer ser lixeiro chefe, mas não quer recolher lixo. Você quer ser programador-chefe, mas não quer escrever código. Você quer ser analista-chefe, mas não quer analisar os requisitos do cliente.
Acordem: o cargo não significa absolutamente NADA. Em um mundo cada vez mais competitivo, a vaidade não tem lugar. O mundo precisa de gente que assuma a função pois é a função que faz com que as empresas destaquem-se no mercado. É preciso FAZER e não PARECER QUE FAZ. Aqueles que parecem que fazem têm vida curta no mercado. O próprio mercado se encarrega de dar um fim nessas pessoas.
Portanto, assuma a função. O cargo só serve para você deixar os amigos com inveja na roda de cerveja no boteco. Se você tem o cargo mas não assumiu a função, seus dias podem estar contados dentro da empresa onde trabalha.
Há alguns anos que uso o Doxygen, uma ferramenta de código livre para documentar o código que escrevo. A principal vantagem de usar o doxygen é justamente o fato de extrair do próprio código toda a documentação que pode ser usada como referência.
Apesar da grande vantagem que é criar documentação à partir do código, o mau uso do doxygen pode levar o código a ficar tão cheio de comentários que a manutenção do mesmo torna-se inviável.
É importante comentar o código, mas também é importante manter os comentários sempre atualizados a cada manutenção. Além disso, excesso de comentários ferem a legibilidade do código. Portanto, ao documentar seu código visando algum tipo de gerador de documentação, procure fazê-lo com racionalidade, evitando o excesso de documentação.
Ao documentar sua API é importante dizer o que ela recebe, como se comporta e o que lhe retorna de resultado. Nem mais, nem menos. Se você quiser escrever um guia de como usar sua API, o doxygen não é a ferramenta adequada para isso apesar de suportar essa característica.
O uso racional de recursos só é possível se você conhece bem o sistema para o qual está programando. Conhecer bem o sistema não quer dizer que você precise entrar nos detalhes do kernel. Basta, para isso, entender quais são os recursos que estão disponíveis e como fazer para gerenciá-los.
O uso de recursos em computação exige mais do que o simples conhecimento da plataforma. Também exige conhecimentos específicos como algoritmos e estruturas de dados. Os algoritmos são essenciais para minimizar o uso de processamento e as estruturas de dados são essenciais para descrever a informação de maneira mínima e racional.
Eu sempre bato nesta mesma tecla: algoritmos e estruturas de dados. Os estudantes de computação são levados a crer que é importante conhecer uma linguagem de programação em detrimento do conhecimento de algoritmos e estruturas de dados. Infelizmente, não poderiam estar mais enganados. Sem o bom conhecimento de algoritmos e estruturas de dados o resultado sempre é um programa excessivo: excesso de consumo de recursos, excesso de código desnecessário, etc.
Sou de opinião que a programação deve sempre orientar-se ao uso racional de recursos, ou seja, nunca partir da suposição que os recursos necessários estarão sempre disponíveis. Essa forma de pensar leva ao desenvolvimento de aplicações eficientes. Não basta apenas ser bonitinha: a aplicação precisa, também, ser rápida e responder prontamente ao usuário. Quanto mais uma aplicação demora, menor será a possibilidade de permanecer em uso. Afinal, o principal motivo das aplicações existirem são os usuários.
