Pesquei este post de um bloq antigo (2012) e ainda acho que é interessante. Está do modo que foi publicado, e em breve dou uma revisada para ver se tem coisa a melhorar. Mas enquanto isso, fica essa versão.
Vi uma frase interessante hoje: “The more you sweat in training, the less you will bleed in battle.”, ou “Quanto mais você se esforça no treinamento, menos você sangra na batalha”. Isso me “incomodou” bastante, e decidi compartilhar algumas idéias de como treinar em programação. Seguem as três primeiras:
Aprenda algum outro jeito de fazer um trabalho: eu trabalho profissionalmente, hoje em dia, com PHP. E o modo padrão de fazer debug em PHP é usar o bom e velho var_dump. Daí se enche de var_dumps o script, e na hora da execução é um pandemônio, porque você precisa ver se o valor está sendo exibido e, caso seja um objeto complexo ou um array com muitos itens e sub-itens, achar onde está o item necessário. Fica nojento, mas muita gente se acostuma com isso, eu mesmo estava, apesar de incomodado.
(Antes que perguntem: eu não poderia contar com alterações no php.ini ou .htaccess para gravar os logs de erro).
Até o dia que eu li, não lembro onde, um artigo falando sobre gravação de log. Aquilo abriu a mente: “pô, gravar log! é só abrir um arquivo usando o fopen, usar o sprintf e o fwrite, e eu tenho um arquivo que acompanha a execução sem emporcalhar a minha saída na tela.”. Por coincidência, uns dias depois apareceu um debug complicado, de código que eu não conhecia, e usando essa técnica consegui identificar os pontos de funcionamento e rastrear cada uma das variáveis que eu precisava.
Qual a lição disso? Com um pouco de pesquisa e ferramentas que eu já conhecia, consegui pensar de outra forma e resolver um problema de um modo melhor. No caso do debug, particularmente, solucionou dois problemas, o do sistema e o meu.
Pra começar olhe para o trabalho que você faz atualmente e pense no que te incomoda de verdade. Procure alguma solução diferente, tente olhar o “problema” de outro ponto de vista.
Conheça ferramentas diferentes. E ferramentas não são apenas linguagens de programação, mas também editores de texto, IDE’s, sistemas operacionais. Não é necessário conhecer para dominar, mas ao menos brinque um pouco, instale, entenda o funcionamento e estude mais a fundo as coisas que gostar mais.
Este artigo, por exemplo, está sendo escrito usando markdown, que é uma sintaxe de marcação de textos voltada para produção de html. Simplifica bastante a geração de textos, e existe um plugin de wordpress para que o editor de postagens aceite a sintaxe markdown (plugin que eu uso, aliás). E para gerar documentações mais complexas, você pode abrir mão dos pesados editores de texto e usar LaTeX, que gera documentos profissionais com bastante qualidade. E a partir de um único arquivo-fonte, ele gera saída em diferentes formatos. Depois que você monta um modelo simples, gerar documentação fica muito simples.
Linguagens diferentes como haskell e python trazem novos conceitos que podem ser aplicados no momento da codificação (no meu caso, conhecer as listas de python me ajudou a melhorar o modo como uso arrays no PHP).
Assim como ter trabalhando anteriormente com ASP.Net e C# me ensinou algumas lições importantes sobre organização e arquitetura de sistemas um pouco mais complexos (onde muitas vezes a complexidade é imposta pelo processo/ferramenta, e não pelo projeto, com algum motivo não muito claro no princípio), e aprender a resolver problemas comuns de deploy em soluções compiladas.
Editores como o Vim te obrigam a pensar antes de digitar e aprender sequências de comandos para executar tarefas de edição de textos, de modo mais eficiente. E pode, também, ensinar expressões regulares.
Enfim, são ferramentas diferentes que, cada uma à sua maneira, mostram que não existe bala de prata, e sim muitas idéias interessantes para serem reusadas quando necessário.
Pra começar escolha uma linguagem qualquer que te chame a atenção e siga um tutorial completo dela, do começo ao fim, sem o compromisso de dominar totalmente a linguagem que está aprendendo, e sim de aprender coisas novas.
Lembre que conhecimento não tem data de validade e você leva pra onde quiser seja para sua vida profissional, para a faculdade, para o mestrado, para outro emprego, para sua própria empresa. A preguiça mental de fazer “como todo mundo faz” faz com que os profissionais sejam comparados apenas pelo conhecimento de digitação de código e implementação de coisas parecidas. Os poucos que conseguem resolver problemas de modo inteligente são os que se sobressaem.
E outra coisa: conhecimento elimina o “encosto da gambiarra”. Sabe o Padrões de Projeto (Design Patterns), aquele livro que todo programador que pensa em passar da categoria “júnior” deve ler? Ele tem várias saídas interessantes para coisas que são feitas na base gambiarra, mas que na verdade são atestados de ignorância e despreparo do programador. Outros livros de padrões, como o Domain-Driven Design e o Patterns of Enterprise Application Architecture também demonstram outras soluções úteis (como o ActiveRecord que a camada de dados do Ruby on Rails usa).
Mas não adianta só ler os livros. Praticar é importante, praticar muito é mais importante, praticar sempre é essencial (olhe novamente a frase do começo do texto). E não adianta também decorar os livros, saber todos os padrões de cabeça e achar que eles são as únicas melhores soluções para qualquer problema, porque eles são apenas referências, são apenas martelos, chaves e coisas parecidas que ganham utilidade na mão de gente que sabe usar.
Pra começar, pela Internet você encontra diversos livros e artigos sobre padrões de projeto. Procure conhecer e depois implemente pelo menos cinco destes padrões em algum projeto pessoal (ou coisa parecida), e compare a qualidade de seu código antes e depois deste conhecimento. Dois padrões interessantes para implementar são o Strategy e o Factory.
Comments