Este é um artigo rapido, porém contém algumas sugestões que podem melhorar significativamente sua produtividade ao fazer código. Além de consultoria, meu foco é desenvolvimento backend, e programação em PHP, mas todas as ferramentas aqui que eu uso servem para mais de uma linguagem, e são gratuitas. É importante ressaltar que o fato de ser opensource não quer dizer que eu apenas sou um entusiasta de software livre: eu uso essas ferramentas porque, pra mim, elas são boas, e mesmo se eu encontrasse uma ferramenta comercial que fosse melhor e mais flexível do que estas em não me importaria em pagar. A questão é que para IDEs, ao menos quando não envolve pesadamente questões mais visuais ou que tenham que ser extremamente fáceis para o usuário, nenhuma outra IDE me faz mudar de ideia de forma consistemte.

Cada item desse artigo merece no futuro um ou mais artigos apenas para descrever em detalhes o que cito aqui. Porém desde já creio que serve como uma sugestão para quem quiser testar as sugestões que eu faço.

Use um sistema de controle de versão decente

O GIT é, sem dúvida, a melhor ferramenta para gerenciamento de controle de versões da atualidade, e duvido que apareça alguma coisa melhor antes de 2020. Exceto se usar MAC, em geral as ferramentas de interface gráfica dele não são muito amigáveis, e isso quer dizer que você terá, sim, que aprender comandos direto em alguma telinha preta. Isso te dá medo?

Boa parte do pessoal inicial nem percebe é que o GIT, por natureza, mantem praticamente a mesma cópia de forma descentralizada. Isso quer dizer que você pode ficar offline e ainda assim terá acesso a praticamente tudo que gostaria, como histórico de commits anteriores de outras pessoas, poder dar merges, criar branches e afins, sem nem mesmo estar conectado à internet, e só sincronizar quando você bem entender.

Se você é novo no mundo do GIT, e quer fazer testes, recomendaria brincar um pouco usando o https://github.com até ter intimidade.

Recomento a leitura de http://help.github.com/win-set-up-git/ , http://help.github.com/mac-set-up-git/ ,  http://help.github.com/linux-set-up-git/, que são as ajudas em inglês do Github sobre como setar a ferramenta.

O que eu uso

• GIT bash, Git GUI e gitk. 

Importante: nem perca tempo com outros sistemas que não são baseados em GIT. Exceto se for pago para isso. Sério.

Use uma IDE "pesada" para fazer serviços "pesados"

Eu também sou da teoria que programador bom é aquele cara que sabe fazer acontecer usando até um bloco de notas da vida. Mas, cá entre nós, isso faz diferença para mostrar sua habilidade, porém em um ambiente real, uma boa IDE ajuda na produtividade, pois tarefas como busca e/ou substituição de strings para arquivos, coleções de snippets/templates criados pelo próprio usuário volta e meia diminuem o estresse de tarefas repetitivas. E nem preciso mencionar algo como auto completar código. E quanto mais feliz você for fazendo código, melhor.

Algo que para quem programa é primordial e que toda IDE decente tem suporte e que você não deveria menosprezar. O primeiro é enquanto você usa um método de terceiros, ou mesmo um seu que você documentou, deve aparecer algum tipo de ajuda explicando como esse método é usado. Outro ponto é que ao apertar alguma combinação de teclas, dentro da sua própria janela, o editor deve levar você para o local aonde aquele método está definido. Essas duas rotinas que falei, todas as IDEs decentes tem suporte padrão, porém normalmente elas requerem que caso você insira bibliotecas que não são nativas do PHP ou que não estão na mesma pasta do seu projeto, que então vá em alguma parte da IDE e adicione o local dessa biblioteca como uma biblioteca usada no seu projeto. Se souber configurar essas duas rotinas que falei, você será mais feliz ao lidar com projetos de grande porte.

Outro ponto importante que faz diferença para quem não se habituou com o GIT, e ter um histórico de versão local dos arquivos. Pelo menos no Netbeans, por padrão ele mantem um histórico de cada arquivo individualmente a cada vez que é salvo, e permite de forma simples comparar a versão anterior com a atual, e através de alguns cliques decidir o que deve ser revertido da versão anterior para a atual. Mesmo ao usar o GIT, eu eventualmente uso isso pois, quando é algo mais simples, ou então quando é algo que aconteceu em um periodo intermediario entre commits (aka salvar versão) do GIT.

O que eu uso

• Netbeans

O que cogitaria também usar

• Eclipse e derivados diretos, como o Aptana
• Zend Studio

Use um editor "leve" para tarefas "leves"

Algo que em geral as IDEs "pesadas" tem em comum é que tendem a ser complexas demais quando você apenas precisa editar um arquivo. Algumas simplesmente tornam um martírio você querer fazer algo complexo sem ter que setar um projeto inteiro. Solução? Usar mais de uma IDE para rotinas diferentes. Independente da situação, mesmo seu editor leve deve ter, no mínimo, realçar sintaxe. Mas o que eu diria que realmente é importante é ele ser rápido e não travar.

O que eu uso

• Notepad++

O que cogitaria também usar

Em Linux, praticamente qualquer um atende esse perfil. Em Mac, não tenho experiência consistente para recomendar algo, mas opções neste perfil não são complicadas de encontrar.

Use editores que não tenham GUI

Esse é o tipo de coisa que envolve em especial o pessoal que lida com manutenção de servidores. Quando se trata de uma edição rapida, ou mesmo quando fazer o download de um arquivo em seu computador local, editar com ferramentas locais, e enviar para o servidor é uma tarefa que por questões técnicas é realmente dificultada, vale a pena entender como usar um editor não visual. Você não precisa ser um mestre, mas sim, saber pelo menos como abrir um arquivo editar e salvar. Não ria: editores não visuais em geral não tem uma barra de tarefas, e exigem uma combinação de teclas para fazer algumas rotinas como fechar o arquivo sem salvar. Então, apenas não entre em pânico, se estiver em algum momento que encontrar uma situação parecida com a que cito aqui, google a respeito de algum desses editores, e aprenda a usá-lo. Não é dificil encontrar tutoriais por aí a respeito.

O que eu uso

• VIM/VI

Documente seu código

Se você programa, em especial se é backend developer ou então frontend developer que trabalha também com Javascript, realmente vale a pena parar e aprender a documentar seu código. Eu entendo que as vezes ele pode parecer simples demais, porém o hábito de fazer isso provê retornos a médio e longo prazo. Combe documentar seu código bem, com organizar ele usando um controle de versão ou, pelo menos, ter todo o seu passado de código organizado de forma fácil, e sua agilidade ao fazer novos projetos será melhor.

Ter disciplina pra documentar faz diferença. Faça códigos bem feitos e flexíveis hoje, e em um próximo projeto, você poderá reusá-lo. E quando estiver nesse outro projeto, você irá ter que fazer mais código e, se por um lado você ganhou tempo "se copiando", será então o seu momento de parar e fazer código flexível e bem documentado que, sim, leva mais tempo, mas... o seu cliente não tinha ganho tempo por que você usou seus próprios pedaços de códigos de sua coleção? É uma troca justa. E se você pegou um gerente de projetos que quer inclusive mandar COMO você deve fazer seu código, dê a ele duas opções: sim e não.

O que eu uso

• Doxygen

Algo que eu já usei, e que é o mais comum para quem programa em PHP é o phpDocumentator, porém eu pessoalmente o desaconselho. Tudo que o phpDocumentator faz, o Doxygen, se configurado, faz uma documentação equivalente. E, a vantagem do Doxygen é que ele é mais flexivel: ele funciona também para outras linguagens. E, cá entre nós, já procurou usar o phpDocumentator para gerar a documentação de uma quantidade enorme de arquivos? Ele demora pois roda via o próprio servidor, enquanto esta outra sugestão que falo tem uma IDE especifica para gerar a documentação.

Enfim... e quanto ao perfil geral ao programar

Algo que em geral não vão falar pra você, se é que você já não chegou em uma fase em que sabe disso, é que quanto mais você produzir, mais vão querer que você produza caso você trabalhe para terceiros em regime a médio/longo prazo. A questão é que se você parar algum tempo, ainda que seja fora do seu horário de trabalho, e descobrir modos de fazer código decente ainda mais rápido do que já faz, isso ainda assim é bom. Percebo que tem pessoas que tendem a querer obscurecer o código, ou documentar o mínimo possível na esperança que, se for demitido, sentirão sua falta, e, se esse é seu caso, eu recomendo o contrário: substitua seu medo por um foda-se e seu certo egoísmo por um par de fones de ouvidos grandes e de boa qualidade e escute musicas utilizadas em terapias para concentração, como para o pessoal que tem déficit de atenção. Mesmo que o código atual não precise ser tão bem feito, se você procura ir, de forma gradativa, entregar algo melhor do que o pedido, isso faz você evoluir gradativamente. 

Um designer mostra uma imagem; um webdesigner mostra um site; um programador mostra o código; Se só você lê seu código, quer seja ao conseguir um parceiro programador para dar uma melhorada na sua vida, ou então ao procurar um emprego, é justamente esse tipo de comportamento, que poderia ser considerado como perda de tempo ou risco maior de "não ser tão necessário", é o que realmente vai importar e diferenciar em ser ou não contratado e por qual valor.

Ok que podem argumentar que, no final das contas, para o usuário realmente final, pouco importa se o código foi bem feito ou não, por ele nunca vai saber, mas se for parar para pensar, exceto para outras pessoas que lidam direto com código, mesmo as que trabalham com você, isso também importa pouco. Paciência: se escolheou ser programador não espere reconhecimento e, mesmo quando receber, certamente perto do trabalho que passou vai ser pequeno a um nível dentro da equipe que trabalhou que era melhor nem ter recebido. Olhando por esse aspecto, ou você vai acabar sendo desleixado com o que faz, ou vai entrar no clube do pessoal que faz o código pra si mesmo e ser mais feliz.

E bato na tecla de que o quanto e como o programador quer produzir acaba sendo até mais importante que metodologias, e o quanto ele gosta do que está fazendo. Isso faz diferença. E, em uma área competitiva, tem que ter sangue frio. Hoje, se eu fosse classificar em um macro-estilo de como fazer código, eu diria que os extremos são o modo mais individualista e o modo mais coletivista. Deixemos a questão de ética e de moral de lado e sejamos práticos, e nem vou parar para ressaltar vantagens sobre um perfil para o outro. Um supervisor teria receio de demitir ambos os perfis por motivos diferentes aka um "e quem eu colocaria no lugar dele na minha empresa?", ou um "e quem eu colocaria no lugar dele na minha empresa, e em qual empresa ele vai trabalhar depois que eu demitir ele?". Como você gostariam de ser lembrado?

• Ant
• Próx