Em um processo natural de desenvolvimento, todo profissional começa sua carreira como um programador iniciante e com o tempo passa a assumir cada vez mais responsabilidades com respeito ao projeto, ou projetos, da empresa para qual está prestando serviços. Este aumento da carga de responsabilidades é um indicador de que o seu trabalho esta sendo valorizado e que sua carreira está avançando.
Assumir responsabilidades é um dos pilares da profissão de programador. Mas tão importante quanto assumir responsabilidades, é também assumir seus erros. Seja honesto consigo mesmo, todos somos suscetíveis a falhas.
Em um antigo emprego já tive a oportunidade de liderar uma equipe com excelentes programadores, 100% de cobertura de testes, uma boa documentação e mesmo assim as coisas deram errado. Somos seres humanos e cometemos erros. A forma como lidamos com estas situações é que mostra o quão profissionais somos.
Ser arrogante não significa esconder seus erros. Eu valorizo pessoas que assumem suas ignorâncias e seus erros, e mais ainda os que se esforçam para aprender com eles.
É uma pena que tantas pessoas em cargos de responsabilidade congelem suas carreiras no meio da subida. Porque na minha visão, ter a coragem e a honestidade de assumir seus erros é um passo importante antes de chegar ao topo.
Gosto de uma passagem do famoso livro “The Pragmatic Programmer: From Journeyman to Master” que diz o seguinte:
Um turista visitando o Eton College na Inglaterra perguntou ao jardineiro como ele conseguia deixar o gramado tão perfeito. “É fácil”, ele replicou. “Você só precisa remover o orvalho cada manhã, cortar a cada dois dias e enrola-lo uma vez por semana.”
“É só isso?”, perguntou o turista.
“Absolutamente”, replicou o jardineiro. “Faça isso por 500 anos e você terá um belo gramado.”
Bons gramados precisam de um pouco de cuidado todos os dias. Bons programadores também.
Foto de Math Paul
Eu adotei esta tecnica a algum tempo, todos os dias eu tento aprender algo novo ou me aprofundar um pouco mais em algo que já conheço. Ao contrário do que muita gente pode pensar, isto não tem nada a ver com manter-se informado. Estar em dia com o que está acontecendo no mundo é muito importante para qualquer tipo de profissional, mas o conhecimento adquirido pela leitura de feeds, por exemplo, não é necessariamente algo que aumente o seu valor como profissional. Estou falando de estudar de verdade, mesmo que seja por 5 minutos, todos os dias.
Durante todo o ano passado eu tentei manter neste blog uma série diária sobre o que viria de novo nas próximas versões do Rails, e isto me ajudou a me manter atualizado ao mesmo tempo que me forçava a analisar cada vez mais profundamente o seu código. Hoje ainda continuo analisando o código, mas não escrevo mais com tanta frequência, já que agora muita gente resolveu fazer o mesmo.
Analisar o código de outras pessoas é um excelente meio de aprendizado. Como todo bom programador, não gostamos de ler documentação, gostamos de ler código. Mesmo programadores iniciantes podem tirar muito proveito ao participar de projetos open source.
Diferente de gramados, nós programadores ao adotar um regime sério de estudo diário, podemos ver os resultados em pouquíssimo tempo. E com o passar dos anos você ficará surpreso ao ver o quanto amadureceu como profissional.
Talvez você não concorde com tudo que eu escrevo por aqui, mas tem uma coisa que é praticamente unanime entre todos os programadores: reuniões são uma tremenda perda de tempo.
Reuniões nos fazem perder muito tempo que poderíamos estar programando, mas é um mal necessário. Uma reunião é um momento em que todos os envolvidos no projeto param para pensar no que estão fazendo. E é neste momento que são tomadas as decisões sobre como fazer o que quer que seja que você precise fazer.
Mas ainda mais importante que pensar no que precisa ser feito, é pensar no que você está fazendo enquanto você está fazendo. Não estou falando de parar por alguns instantes antes de começar a escrever código e pensar em como você vai escrever determinada funcionalidade. Estou falando de um processo contínuo de meditação – toda decisão que precisa ser tomada deve envolver um processo (mesmo que rápido) de meditação antes – que deve ocorrer a todo momento. Este processo é critico e deve envolver todos os aspectos da sua vida.
Foto de regolare
A maioria dos programadores codifica no piloto automático. Isto é um problema grave, porque você deixa o seu inconsciente tomar as decisões por você, quando na verdade cada decisão tomada deveria ser analisada antes. Seu cérebro é uma ferramenta surpreendente, com um pouco de esforço você pode tomar o controle e focalizar seus pensamentos de verdade na execução da tarefa que você está realizando.
No inicio isto pode parecer uma tarefa difícil, talvez seja necessário realizar certas pausas a cada 10 ou 5 minutos somente para pensar no que você está fazendo, mas com o tempo você conseguirá fazer isto de forma consciente ao mesmo tempo em que continua escrevendo. Mas nunca deixe esta tarefa no piloto automático.
PENSE! Não considere pausas para pensar como tempo perdido. Com o passar do tempo você perceberá que está mais envolvido com o trabalho e que você entende melhor o negócio da empresa para qual está trabalhando. O tempo gasto será pago, já que você será mais eficiente. E principalmente, você gastará menos tempo em reuniões já que você provavelmente já terá pensado na maioria dos problemas antes.
Tecnologia é um bem de consumo. Ter um carro potente é excelente, mas não faz você dirigir melhor. Ter um computador de ultima geração é muito bom, mas não permite necessariamente que você faça mais coisas em menos tempo.
Prega-se por toda a parte que programadores Ruby são mais produtivos e mais pragmáticos. Mas Ruby, assim como qualquer outra tecnologia é somente um bem de consumo. Um bom motorista, continuará sendo um bom motorista independente do carro que esteja dirigindo. Assim como um bom programador, continuará sendo um bom programador independente da linguagem de programação que estiver utilizando.
Programar não é apenas codificar. Como desenvolvedores de software precisamos entender o que estamos criando, precisamos entrar de cabeça no negócio da empresa para qual estamos trabalhando. Conheço péssimos programadores que desempenham papeis importantes nas empresas em que trabalham, não pelo seu conhecimento técnico, mas pelo seu domínio do negócio da empresa.
Não invista somente em tecnologia
Quem é mais produtivo, o cara que conhece todas as minucias da linguagem ou o cara que conhece todos os processos da empresa? Saber conversar com o seu cliente na “língua dele” é essencial. Imagine a expressão de satisfação no rosto do seu cliente se ao lhe perguntar: “Você sabe o que é um HPA456?”, você respondesse: “Sim, mas você não acha que utilizar um PDT8954 seria mais interessante para o seu negócio?”.
Para sermos produtivos precisamos ser pró-ativos. Mas para sermos pró-ativos temos de saber o que precisa ser feito.
Não leia apenas artigos técnicos, mantenha-se em dia com o negócio do seu cliente. Leia revistas especializadas. Provavelmente você não entenderá tudo que ler, mas seja persistente. Converse com seu cliente sobre a área de atuação dele, tire suas duvidas. Conhecimento nunca é desperdiçado.
Não invista tanto em ferramentas e tecnologia, invista em conhecimento.
O termo “coçar a sua própria coceira” já é usado a muito tempo pela comunidade de desenvolvedores de projetos open source. Isto significa que eles estão constantemente resolvendo seus próprios problemas.
Conforme eu já mencionei em um artigo anterior, programar é difícil. Sim, programar envolve assumir um série de responsabilidades e atividades que podem tornar o ato de codificar muito estressante. Durante o desenvolvimento de um software é comum aparecerem situações que exijam uma tomada rápida de decisão. Quantas linhas o usuário deverá visualizar por vez? Azul ou vermelho? Apagar o registro ou apenas marca-lo como apagado?
Afim de agilizar o desenvolvimento muitas vezes o programador decide por tomar estas decisões, e só delega esta responsabilidade ao cliente quando a questão é realmente séria. Cada decisão tomada pelo desenvolvedor se torna um novo débito no software, como uma bomba-relógio que pode explodir a qualquer momento. Ter conhecimento destas pequenas armadilhas dentro do projeto torna o desenvolvimento estressante e pode tirar o prazer do programador em escrever códigos.
Programadores open source não passam por isto, porque eles estão “coçando a sua própria coceira”, eles estão resolvendo os problemas que eles mesmo tem. Ao tomar uma pequena decisão, eles não estão chutando, porque eles são os cliente e sabem exatamente o que é melhor para eles.
Programar envolve tomar decisões o tempo todo. Quando temos um profundo conhecimento sobre a necessidade que o software está suprindo, e principalmente quando somos o nosso próprio cliente não precisamos nos preocupar com estes chutes, tomamos decisões de uma forma suave e isto torna o desenvolvimento mais ágil e prazeroso. É por isto que tanta gente passa o dia inteiro escrevendo código no trabalho e ao chegar em casa ainda senta na frente do computador para trabalhar em algum projeto open source, é um exercício de relaxamento.
É possível levar esta experiencia para o trabalho, mas para que isto aconteça é necessário que você domine completamente o negócio da sua empresa. Entenda porque está escrevendo cada uma da funcionalidades do software em que está trabalhando. Entre de cabeça no trabalho que está realizando, torne-se o seu próprio cliente e comece a coçar a sua própria coceira.
Não importa se você está programando em Ruby, C# ou Java. Se está usando Rails ou Django. O que importa é se você realmente entende o trabalho que está realizando e se está contente com o que está fazendo.
Foto de Jesper Rønn-Jensen
Quem acha que o mercado de software se resume à programadores e ao simples ato de escrever código não poderia estar mais enganado. Desenvolvimento de software tem tudo a ver com paixão.
Escolher uma linguagem de programação é quase como uma religião para muitos. Longas discussões são travadas sobre qual é a melhor linguagem ou sobre qual é a melhor metodologia a ser utilizada. Como se adotar uma determinada linguagem, ou uma ferramenta especifica fosse a resposta para o sucesso de um projeto ou a solução para o crescimento de sua empresa.
Pessoas apaixonadas estão dispostas a fazer tudo para demonstrar o seu amor por aquilo que acreditam. Aproveitando-se deste mercado centenas de empresas sobrevivem vendendo cursos, livros, certificações e principalmente ferramentas e novas linguagens de programação.
Se tornar um bom programador é um processo demorado e na maioria das vezes caro. Calcule quanto você já gastou apenas no processo de aprendizagem, desde um curso básico de programação até a compra do livro mais avançado sobre a sua linguagem preferida. Se você correu atrás de uma certificação, provavelmente você gastou muito mais. Mesmos autoditadas como eu, gastamos centenas de reais todo ano comprando novos livros.
O aprendizado nunca para nesta profissão, um bom programador sempre estará de olho em um novo livro, o tempo todo, mesmo que ainda não tenha terminado de ler os que tem em mãos. Agora some também a isto os gastos que você ou sua empresa tem com a compra de licenças de ferramentas, sistemas operacionais, computadores mais velozes e coisas do tipo.
Mas me deixa te contar um segredo, não existe uma “melhor ferramenta” e muito menos a “melhor linguagem de programação”. Mas existem pessoas, seres humanos com suas experiências e teorias. Desde o principio o homem tem se virado da melhor maneira possível com as ferramentas que tem em suas mãos. Limitações sempre nos fizeram bem, elas incentivam a inovação e nos forçam a manter o foco.
O melhor programador é aquele que sabe improvisar, se virar com o que tem em mãos. Ele tem prazer em resolver problemas que parecem impossíveis para os programadores ruins, aqueles que acreditam que somente uma linguagem de programação ou uma ferramenta única podem resolver todos os problemas.
Não invista muito em ferramentas, não compre um novo livro antes de terminar o que você está lendo e principalmente não compre tantos livros sobre a mesma linguagem de programação. Antes você programava em Java, C# ou PHP, agora você programa em Ruby, Erlang ou Scala, e amanhã você programará em alguma outra linguagem. Invista mais em você, e menos em uma linguagem de programação ou ferramenta porque estas coisas passam.
O melhor programador não costuma ser o que sabe mais, mas sim o mais criativo.
Programar é uma arte. Resume-se a ensinar um computador a fazer o que tem de ser feito. Não basta apenas sentar em uma cadeira e começar a escrever código, você não é apenas um mero codificador. Esta arte exige que você seja um bom ouvinte, aprenda com facilidade e acima de tudo seja um excelente interpretador.
Você deve ouvir os devaneios e desejos mais insanos de seus clientes e traze-los para o mundo real de uma forma que uma máquina possa entender. Seu trabalho deve ser feito de uma maneira que outras pessoas também possam trabalhar nele e é muito importante documenta-lo de uma forma que outros possam entende-lo. E tudo isto é feito com um cronometro ligado, você está lutando contra o tempo.
Sim, você realiza pequenos milagres todos os dias. Programar é difícil!
O Ruby on Rails possui algumas dezenas de geradores de código que visam automatizar tarefas repetitivas, economizando o tempo de desenvolvimento e evitando que o programador tenha que se repetir. Geradores de código tem tudo a ver com a filosofia “Don’t Repeat Yourself”.
Aplicativos que geram código
Se expandirmos nossos horizontes para outras linguagens de programação menos dinâmicas, talvez geradores de código possam ser muito úteis na criação de arquivos XML de configuração, justificando de maneira óbvia o seu custo. Ao usar ferramentas como o Microsoft Visual Studio eu simplesmente informava ao editor que desejava criar uma aplicativo MFC (Microsoft Foundation Classes) e ele gerava para mim um esqueleto com mais de 2000 linhas de código, uma economia de tempo incalculável.
Algumas pessoas são totalmente contra este tipo de gerador de código porque na maioria dos casos o programador que o utiliza não entende exatamente o que o código gerado está fazendo. Embora isto seja uma realidade, isso não deve ser uma justificativa para evitar ferramentas como essa, já que na maior parte do tempo o problema está no programador e não na ferramenta. No exemplo que dei acima, embora eu nunca tenha parado para analisar cuidadosamente o que cada uma das 2000 linhas de código gerados pelo Visual Studio faça, eu entendo no contexto o porque delas, e para mim isto sempre foi o suficiente para tocar um projeto à partir deste esqueleto.
No Rails também encontramos alguns geradores deste tipo na forma de scripts (./script/generate scaffold, por exemplo). Os scripts geradores de código do Rails nos ajudam a manter as convenções propostas pelo framework com mais facilidade, e normalmente incluem apenas algumas poucas linhas de código em cada arquivo gerado.
Raramente você achará útil criar um script ou aplicativo gerador de código para um projeto Rails. Mas ao criar um plugin ou mesmo o seu próprio framework em Ruby, talvez seja prático investir na criação deste tipo de gerador. Mas não se engane, construir um gerador de código deste tipo é uma tarefa que consome tempo e um grande esforço. Além do tempo gasto na codificação do gerador, também deve-se levar em consideração o esforço necessário para manter o projeto (atualizações, correções de bugs e inclusão de novas funcionalidades) e para treinar a sua equipe (e re-treinar após modificações).
A escolha do seu editor preferido também depende muito da capacidade que ele possui de gerar código. O TextMate, por exemplo, durante muito tempo foi (no meu caso ainda é) considerado o melhor editor para se trabalhar com código Ruby, e isto se deu graças aos seus famosos Bundles, que não são mais do que scripts geradores de código.
Muitos editores também permitem que você crie seus próprios “bundles”. Na maior parte do tempo é mais fácil e barato criar um script utilizando as ferramentas que seu editor lhe fornece do que criar um aplicativo do zero afim de automatizar a criação de códigos mais simples.
Metaprogramação
Usamos metaprogramação para criar softwares que tenham a capacidade de escrever código por si mesmo. Um bom exemplo disso é o ActiveRecord do Rails, que cria em tempo de execução todo o código necessário para a manipulação de informações de um banco de dados. Ao adicionar uma nova coluna no banco de dados, não precisamos alterar nenhuma linha no código do modelo, o ActiveRecord usando metaprogramação consegue identificar a nova coluna e automaticamente criará todos os métodos e atributos necessários para permitir o acesso a esta nova coluna.
Linguagens dinâmicas como o Ruby favorecem muito o uso de metaprogramação. Programadores mais avançados fazem muito uso destes recursos para diminuir repetições em seus códigos.
A ferramenta mais comum de metaprogramação é um compilador, já que ele permite que você escreva pequenos programas em uma linguagem de alto nível afim de gerar programas em linguagem de máquina. Uma brincadeira comum que envolve o exercício de metaprogramação é montar um quine, que é um programa que deve produzir uma única saída que é o seu próprio código fonte. Veja um exemplo em Javascript:
unescapeq="unescape(q=%22*%22).replace('*',q)"replace'*'q
Execute o código acima e você terá como saída um texto com exatamente o mesmo código gerador. Tente fazer o mesmo em Ruby, é um bom exercício!
Helpers
O diretório helpers não foi adicionado ao Rails à toa, ele está lá para ser utilizado. Helpers são fáceis de criar e podem ajudar a diminuir uma quantidade razoável de repetições em suas views. Quando criados utilizando-se de recursos de metaprogramação podem fazer uma grande diferença.
Linguagens de marcação como o Haml, servem de grande incentivo para estimular a criação de helpers em projetos Rails.
Finalizando
Geradores de código são ferramentas essenciais no dia-a-dia dos programadores e são extremamente importantes para aumentar nossa produtividade e evitar que tenhamos de escrever códigos desnecessários.
Faça uso dos geradores que você tem a disposição, e também crie seus próprios geradores quando forem realmente necessários. Mas mantenha-se longe de geradores que criem código que você não sabe para que serve ou que não entende.
Sim, ainda tem muita coisa a ser dita sobre DRY. Como eu disse no primeiro artigo sobre este assunto, “Don’t Repeat Yourself” não é apenas uma regra, conceito ou boa prática, é uma filosofia. Então vamos filosofar mais um pouco sobre isto…
Li há um tempo atrás no livro The Pragmatic Programmer que nós programadores estamos sempre em modo de manutenção. Isto é uma verdade já que raramente escrevemos código original. Se pararmos para pensar, um código só pode ser considerado novo por alguns minutos após termos lhe escrito pela primeira vez, pois poucos tempo depois você certamente terá de revisitá-lo e alterá-lo. Assim, chegamos a conclusão de que gastamos mais do nosso tempo dando manutenção em um código já criado, do que criando um código original.
Programadores estão sempre em modo de manutenção
Você cria um trecho de código, para alterá-lo logo em seguida. Cria mais um pouco de código e então precisa voltar e corrigir um bug encontrado. Escreve mais alguma coisa, e então perde algumas horas refazendo um código que lhe pareceu mau escrito (refactoring).
“Don’t Repeat Yourself” tem a pretensão de simplificar a manutenção de nossos projetos tornando-os flexíveis. Por isto é um conceito que deve ser levado muito a sério por qualquer programador que se preze, independente de qual linguagem esteja utilizando.
No caso do Ruby on Rails, embora isto também seja verdade para outras linguagens e frameworks, temos a nossa disposição milhares de gems e plugins que simplificam nossa vida, evitando a duplicação desnecessária de código e facilitando a manutenção do projeto. Também temos a liberdade de criar nossas próprias bibliotecas ou módulos de uma forma muito simples e rápida, afim de evitar repetições em nosso código.
Mas uma outra coisa que também é importante comentar quando falamos em DRY são as ferramentas geradoras de código. Quem trabalha com Rails já está acostumado a utilizar alguns scripts, como os famosos ./script/generate migration, ./script/generate scaffold ou se você utiliza o Rspec em seu projeto também deve usar o ./script/generate rspec_scaffold.
Estas ferramentas são ótimas e economizam muito do nosso tempo. Mas nem sempre os scripts existentes cobrirão todas as suas necessidades, então surgem algumas perguntas: Em que momento se torna prático gastar meu tempo construindo algo assim? Talvez seja necessário algumas horas ou até um dia inteiro para se construir um bom gerador de código, além do esforço necessário em manter o seu código e ensinar os outros programadores a utilizá-lo. Como decidir se o retorno deste investimento é o suficiente para justificar a criação de algo assim?
Falarei mais sobre isto no próximo artigo.
Uma das filosofias mais adotadas por programadores Ruby no mundo todo e amplamente evangelizada pelos maiores nomes da programação, independente da linguagem ou comunidade com o qual está mais envolvido é o “Don’t Repeat Yourself” (Não se repita, ou simplesmente DRY).
DRY é mais do que apenas uma boa prática de desenvolvimento, é uma filosofia que envolve evitar repetições. Trechos de código repetidos na maior parte dos casos (se não em todos) somente tornam nosso código mais obscuro e inconsistente. Quando repetimos trechos de código em nosso projeto ou mesmo em projetos diferentes, estamos aumentando a complexidade de gerenciamento e dificultando mudanças.
Ao criar código reutilizável estamos facilitando nossa vida no longo prazo. Se uma alteração importante é necessária para aumentar a segurança de seu sistema de autenticação, será muito mais fácil realizá-la se você estiver usando uma biblioteca única para este fim em todos os seus projetos. Mas imagine o trabalho que terá se cada projeto em sua empresa utilizar um sistema único de autenticação criado especialmente para ele.
Quando DRY é aplicado com sucesso em seu projeto ou empresa, a modificação de um único elemento não afetará nenhuma outra parte do seu sistema, com exceção de elementos intrincadamente relacionados.
O simples fato de criar bibliotecas não necessariamente significa que você está sendo DRY. Sistemas como o Enterprise Java Beans embora não exijam que você repita código em Java, lhe obrigam a duplicar arquivos de configuração. Isto não é ser DRY. (Uma nota aqui: Estou totalmente por fora do mundo Java e é possível que isto tenha mudado ou melhorado. Minha intenção é apenas exemplificar.)
O ActiveRecord do Rails é um excelente exemplo de uma biblioteca DRY. Não é necessário criar nenhum tipo de arquivo de configuração, e nem mesmo copiar e colar código entre seus modelos.
“Don’t repeat yourself” não é somente sobre duplicar trechos de código, também tem muito a ver com o comportamento funcional do seu código. Composição e herança em linguagens orientadas a objetos foram criados exatamente para suportar este tipo de filosofia. A idéia por trás do DRY é não só evitar duplicações de código, mas também múltiplas e divergentes maneiras de se realizar a mesma tarefa.
DRY também diz que cada pedaço do seu sistema de informação deve possuir uma representação única e inequívoca. Estou falando do seu banco de dados, seu esquema de testes, seu dispositivo de deploy e até mesmo da documentação do seu sistema.
Um projeto de software é muito mais do que o seu código. Você deve encontrar uma forma única de representar cada um dos recursos envolvidos na criação de seus projetos, caso contrário você terá de manter múltiplas representações diferentes de cada recurso, e no caso de uma mudança se prepare para ter muita dor de cabeça. E mudanças acontecem o tempo todo. Não se repetir é importante se desejar ser flexível quanto às alterações em seu sistema.
Quando estamos falamos apenas de código, a criação de uma biblioteca ou um módulo pode ser o suficiente para evitar repetições. Mas no que diz respeito ao banco de dados, por exemplo, talvez seja necessário uma outra abordagem como a criação de uma ferramenta geradora de código ou um sistema de automação, apenas para citar alguns exemplos.
Obviamente DRY não é infalível, em alguns casos o esforço para manter uma biblioteca única para todos os seus projetos, ou para evitar determinados tipos de duplicações em seus códigos pode ser muito maior do que o esforço necessário ao manter cópias diferentes do mesmo código.
“Don’t Repeat Yourself” – Ruby on Rails foi criado com este conceito em mente. Quase tudo que o fazemos no desenvolvimento de projetos com Rails visa evitar duplicações e repetições, mesmo quando falamos de banco de dados e testes. Por este motivo é que “não se repetir” se tornou o principal lema dos desenvolvedores Rails.