Que tal aprender Elixir com a mão na massa?

Você já ouviu falar de Elixir não é? Linguagens funcionais vem ganhando cada dia mais atenção. Além das linguagens, os conceitos funcionais vem se tornando um assunto bem comum, mesmo em linguagens Orientada a Objetos.

Ruby é uma linguagem onde a Orientação a Objetos se encaixa muito bem com alguns conceitos de linguagens funcionais. Algum tempo atrás eu publiquei uma série de posts explorando mais a fundo esses Conceitos na Prática.

No entanto para realmente pensar de acordo com o paradigma funcional resolvi que era melhor utilizar uma linguagem fundamentalmente funcional! Na busca por uma linguagem para aprender eu acabei me deparando com Elixir e confesso que estou gostando bastante (talvez pela forte influência do Ruby ).

Por onde começar a aprender Elixir?

Por mais clichê que possa parecer, o site da linguagem elixir-lang.org é um excelente recurso. Ele traz tutoriais bem simples e diretos explicando os conceitos básicos da linguagem. É um bom ponto para começar.

Grok Podcast possui uma série sobre a linguagem com seu o criado José Valim. A série é bem interessante, principalmente se você quiser entender um pouco mais sobre como ela foi criada e as motivações.

Eu particularmente gosto de aprender sobre linguagens colocando a mão na massa e achei uma quantidade muito boa de materiais. Acho que a forte influência de Ruby vai além da linguagem, a comunidade Elixir é bem envolvida e possui muitos recursos para iniciantes.

Um projeto muito bom é o elixir-koans. Koan é uma prática budista para propiciar a iluminação, para linguagens de programação a prática é aplicada a partir de uma suíte de testes que deve ser corrigida. Cada teste vai abordar algum aspecto da linguagem e para prosseguir você precisa fazer o teste passar. Koans são uma técnica bem poderosa e várias linguagens possuem seu próprio conjunto de koans.

Outro projeto interessante é o 30-days-of-elixir, que é focado em aprender a linguagem com a mão na massa. Cada arquivo é um dia de aprendizado da linguagem e, apesar de possuir testes, a ideia não é corrigi-los, mas sim ver os conceitos em ação.

O awesome-elixir é um projeto que contém uma lista bem extensiva com vários recursos diferentes sobre a linguagem e suas ferramentas. É um bom recurso para procurar coisas novas para aprender ou se quiser algo mais específico.

Se você quiser saber mais sobre linguagens funcionais o podcast Tecnologicamente Arretado fez um episódio falando sobre linguagens funcionais. A conversa é bem legal e bem informativa.

E ai, quais outros recursos você recomenda para quem quer aprender Elixir? 😀

Por que você também iria gostar de utilizar Vim

IDEs e editores de textos estão entre os grandes motivadores de Guerras Santas entre desenvolvedores. Não vou falar que você deve user um ou o outro. Produtividade é muito subjetivo e pessoal, não existem regras que torna algo produtivo ou não, tem quem goste de trabalhar ouvindo música, tem quem goste de usar bermuda, e por ai vai.

Vou apenas dizer o por que eu gosto de utilizar o Vim, e me sinto mais produtivo, e o que você ganharia se utilizasse também.

Como os outros editores funcionam

Sublime, TextMate e Atom, todos possuem uma filosofia que é baseada no Emacs: extensibilidade. Existem comandos para copiar, colar, selecionar texto e por ai vai. A grande vantagem é que os comandos que são utilizados nestes editores são os que você já está acostumado a usar no sistema operacional, ctrl+c, ctrl+v, etc. Mas se isso fosse suficiente nenhuma IDE seria necessária.

A grande sensação dos editores avançados e das IDES é que você pode criar os seus próprios comandos, e distribuí-los também! No Sublime eu posso utilizar um plugin para indentar um código, comentar linhas ou blocos de código, etc.

Como o Vim funciona

Já no Vim, a grande desvantagem é que os comandos básicos do SO não funcionam, então nada que pra você faz sentido vai ser útil. Qual o sentido de digitar :w pra salvar um arquivo? Bem, qual o sentido de ctrl+s pra salvar um arquivo? Nenhum, mas estamos acostumados a utilizar a última opção, então ela faz mais sentido.

Mas, de novo, o básico não é suficiente. Precisamos criar comandos próprios pra agilizar tarefas, e é ai que eu vejo a ideia de composição do Vim brilhar. Os comandos do vim funcionam como pequenos comandos gerais que podem ser combinados para criar novas tarefas, bem semelhante ao conceito Unix.

Composição vs Extensão

Vamos supor que queremos criar maneiras mais interessantes de apagar caracteres, por exemplo, apagar uma linha toda, uma palavra toda ou até um determinado caractere. Poderíamos criar uma extensão do Sublime que faria ctrl+shift+d para apagar a linha, ctrl+shift+w pra apagar a palavra, etc. Perceba que não existe nenhuma conexão entre apagar uma linha e mover o cursor até o final da linha, ou mesmo entre apagar uma linha e uma palavra.

O Vim possui comandos que movem o cursor para o final da palavra, da linha e até mesmo até um caractere qualquer. Por exemplo, se você digitar w, o curso vai mover até o final da palavra, $ vai té o final da linhas, G até o final do arquivo. Outro comando do vim apaga o texto, basta digitar d e o que você quer apagar. Se quiser apagar até o final de uma palavra, faço dw, se quiser apagar até o final da linha, d$.

E se agora eu quiser selecionar o texto? No Vim também existe um comando para selecionar, basta digitar v. Então vw vai selecionar até o final da palavra. Se for até o final da linha? v$.

Sabendo que t move o cursor até um determinado caractere, por exemplo t+ vai mover o cursor até o caractere +, como posso apagar o código até o próximo caractere +? dt+. Utilizando y podemos copiar para o buffer do Vim, então o que yw faz? Exatamente o que você está pensando, copia até o final da palavra. E yt+ ? y$ ?

Bom, já deu pra entender o que eu quero dizer por composição. O funcionamento do editor utiliza o que você já sabe como base, e cada comando ou plugin tira vantagem disso.

Composição + Extensão

Quando saímos do básico é que as coisas ficam mais interessantes. No Vim existe um plugin que permite transformar uma palavra, por exemplo string, em “string” em ‘string’, ou até mesmo em (string). Claro que em outros editores também existem essa possibilidade, mas se quisermos adicionar strings numa linha toda?

Enquanto que seria necessário outra função para fazer isso no Emacs, no Vim basta utilizar o conceito de objetos, que são linhas, palavras, ou qualquer outra coisa que você quiser selecionar, e utilizar o mesmo comando mas com um objeto diferente, como exemplificado acima.

Vim Rocks, Sublime Sucks

Não. Como falei antes, nenhum dos atalhos do SO vai funcionar com Vim. Além disso, não dá pra simplesmente abrir o vim e começar a digitar, precisa entrar no modo de inserção, mas ai os atalhos não funciona, você precisa voltar pro modo normal e… tá, desisto, não é pra mim.

Existe uma grande barreira inicial para abordar o Vim. Mas, uma vez que você se acostuma aos modos e aprende os comandos básicos, é bem intuitivo utilizar o editor.

Tá, quero aprender, por onde começo?

Sugiro começar com o básico do vim, esse jogo http://vim-adventures.com vai te mostrar como navegar.

Depois que tiver mais acostumado com as teclas básicas, é hora de aprender sobre os plugins do Vim. A maneira mais simples que achei, quando estava começando, foi utilizar o Vim de alguém. O que eu usei por mais tempo foi o Janus https://github.com/carlhuda/janus. Ele já vem com vários plugins instalados e o README mostra como utilizá-los.

Outra opção é criar sua própria configuração, pra isso recomendo o Pathogen https://github.com/tpope/vim-pathogen que é um gerenciar de plugins.

O site vimawesome.com lista os plugins mais utilizados e como instalá-los.

Referências

https://medium.com/@mkozlows/why-atom-cant-replace-vim-433852f4b4d1

Pessoas > Papéis

Quantas vezes você já ouviu alguém falando algo do tipo “Os devs estão perguntando …” ou “Eu conversei com a equipe X e …”?

Eu escuto isso muito, quase que diariamente. Talvez esse não seja o seu cenário, o que é muito bom.

Mas se você também ouve isso frequentemente, gostaria de encorajá-lo a tentar mudar a situação.

Papéis

Uma das grandes mudanças na maneira de pensar quando se utiliza alguma forma de desenvolvimento ágil é o foco em pessoas. O primeiro valor do manifesto ágil mostra que o foco sai do processo e ferramentas para os indivíduos e as interações entre eles.

Se você observar algumas metodologias ágeis, é fácil notar a menção a papéis no lugar de cargos. Isso mostra que qualquer pessoa na equipe pode, ou deveria poder, atuar em qualquer papel dentro da equipe, desde que tenha aptidão e vontade para tal.

Geralmente as equipes que eu vejo são dividas em papéis tais como Desenvolvedor, Analistas de Qualidade, Analistas de Negócio e Gerente de Projeto/Iteração. A suas habilidades atuais lhe apontam qual o melhor papel que você pode desempenhar, já os seus desejos profissionais lhe guiam para quais papéis você poderá desempenhar no futuro, e quais habilidades você precisará desenvolver.

Toda essa conversa foi para mostrar que papéis são meras formalidades, já que podem ser intercambiáveis dentro da equipe/empresa. O foco real são as pessoas que compõe a equipe.

Pessoas

O primeiro grande erro de quem fala “Conversei com o time X” ou “Os devs me disseram …” é que essa “entidade” a qual a pessoa está se comunicando não tem nenhuma capacidade de comunicação. Simples, não é possível fala com “os devs” pois não existe “os devs” e sim um grupo de pessoas desempenhando tal papel.

Se alguém falou com “os devs” na verdade falou com algum desenvolvedor específico, ou talvez um par/grupo. Nesse caso ela falou com pessoas e não com o papel dessas pessoas. O quão difícil é então dizer que “Eu conversei com o João e a Maria”?

Posso não poder responder essa pergunta, pois não tenho capacidade de entender tal dificuldade, no entanto eu posso dizer que o benefício de falar “João e Maria” ao invés de “os devs” é gigantesco.

O primeiro grande benefício é a melhoria na Comunicação, que talvez seja a maior fonte de problemas (ou não) para projetos.

Suponha que a informação que João e Maria tem tenha sido difícil de encontrar. Seria menos dispendioso para outra pessoa perguntar diretamente para eles. Ou então, suponha que seja necessário confirmar alguma parte da informação dada. Sabendo quem proveu a informação fica mais fácil decidir a quem perguntar.

Ao citar os nomes a informação ganha credibilidade, caso mais detalhes sejam necessários já se sabe a quem perguntar. De novo, Comunicação é chave para o sucesso de um projeto, seja ele pequeno ou grande.

Um outro benefício é que, ao citar os nomes de João e Maria, eles automaticamente ganham o sentimento de donos da informação e sabem que são responsáveis por ela. Esse aumento na auto-estima tende a tornar as pessoas mais produtivas.

Pessoas>Papéis

Se esse texto não foi suficiente para lhe convencer a tratar as pessoas por nomes e não por cargos/papéis, então vou usar a minha carta na manga: João é João e Maria é Maria! Respeito é bom e proporciana um ambiente de trabalho saudável.

Aumentando a produtividade com TMUX

Se você faz uso pesado do terminal no seu dia a dia, provavelmente o tmux vai ser uma ferramenta que você vai adorar conhecer e utilizar.

Com uma rápida olhada na home do projeto (http://tmux.sourceforge.net) vemos as principais características do tmux:

  • Mudar facilmente entre programas rodando em um mesmo terminal
  • Sair de uma sessão deixando algo rodando em background
  • Voltar para uma sessão aberta

Além disso ele permite que mais de um usuário entre em uma sessão, ou seja, se você utiliza vim para desenvolvimento é possível parear remoto bem mais fácil e rápido. Mas uma coisa de cada vez.

A ferramenta

O tmux é um pacote bem fácil de instalar, basta um brew/apt-get/yum ou qualquer que seja a maneira que o seu OS cuida dos pacotes.

Tmux instalado, é só iniciar a ferramenta rodando “tmux”. A partir dai você estará num terminal com super poderes =]

A primeira vista nada anormal, só um terminal onde você pode utilizar os comandos normais. Vamos então criar uma nova janela: “Ctrl+b c” (‘Control’ e ‘b’ ao mesmo tempo, depois ‘c’)

‘Ctrl+b’ é a tecla lead do tmux, todos os comandos vão iniciar com essa tecla e mais na frente vamos ver como personalizar esse comando.

Screen Shot 2013-07-27 at 6.41.35 PM

Agora, com duas janelas abertas, perceba que abaixo de cada uma tem um número (na imagem: 0 e 1). A maneira como vamos para uma janela específica é usando lead e o número da janela. Isso já é melhor que usar abas no terminal pois podemos ir para uma janela específica sem precisar passar por todas.

Mas isso não é uma vantagem muito boa… agora experimente lead e ‘%’ (shift+5) ou lead e ‘”‘ (aspa dupla) =]

Screen Shot 2013-07-27 at 6.48.21 PM

Numa mesma tela temos várias janelas abertas, o que um terminal comum faz visualmente (ex: iTerm2), mas visualmente é bem mais lento que no teclado certo? E para ir de uma janela para a outra basta usar lead e a seta para o lado da janela que você quer utilizar.

Pra quem faz uso pesado do terminal, poder abrir várias janelas em um lugar só (e de uma maneira tão rápida e fácil) ajuda muito. Dá pra realizar consultas no banco enquanto o código fica aberto do lado, entre outras possibilidades.

Um detalhe é que o scroll do seu mouse não vai funcionar, caso queira fazer um scroll é preciso entrar em outro “modo” usando lead e ‘[‘. A partir daí você pode “andar” pelo histórico do terminal com as setas ou com o scroll. Também é possível configurar esse comportamento, vamos ver mais na frente.

Algumas funcionalidades legais

Já vimos que podemos criar várias janelas, inclusive dentro de outras janelas. Outra funcionalidade do tmux é que ele permite deixar programas rodando em background.

Já vi uma utilização bem legal disso onde uma sessão do tmux continha vários logs abertos para diferentes aplicação e finalidades. Sempre que alguém queria monitorar os requests ou acessos ao banco, bastava fazer um ‘attach’ ou um ‘detach’ para entrar e sair da sessão do tmux que continha todos os logs.

Falando nisso, para sair de uma sessão do tmux basta fazer o ‘detach’ utilizando lead e ‘d’. Com isso você vai voltar ao terminal padrão e as janelas vão continuar abertas em background. Se você sair da janela do terminal com um ‘exit’, a janela vai ser fechada. O tmux só será encerrado quando todas as janelas forem fechadas.

Para logar em uma sessão já aberta fazemos um ‘attach’. Para isso primeiro é legal saber quais sessões estão abertas, rodando ‘tmux ls’. Esse comando traz uma lista de informações das sessões, como data que foi iniciada e um atributo especialmente interessante: o id.

O id da sessão é o primeiro atributo que o ‘tmux ls’ mostra. No exemplo anterior, veríamos o seguinte:

Screen Shot 2013-07-27 at 7.07.43 PM

Com ele podemos fazer ‘tmux attach -t 0’ onde 0 é o id da sessão. A sessão pode ser nomeada de qualquer forma. Basta utilizar o seguinte comando ao iniciar o tmux: ‘tmux new -s marcos_working_from_home’.

Agora quando alguém fizer ‘tmux ls’ vai ver essa sessão e vai poder fazer ‘tmux attach -t marcos_working_from_home’ e logar nessa sessão.

Quando eu falo alguém estou falando de uma outra pessoa que fez um ssh dentro da mesma máquina que eu estou. E essa é uma das melhores funcionalidades do tmux: várias pessoas podem logar na mesma sessão (usando ssh) e todos vão ver o que está acontecendo.

Isso é especialmente bom quando se usa vim como editor de código, permitindo parear remoto praticamente sem interferências ou lentidão. No meu dia a dia isso ajuda bastante, principalmente quando preciso pedir ajuda de alguém que está em um escritório remoto.

Outra vantagem que eu vejo é que quando eu preciso rodar, em outra máquina, um comando que demora muito, posso abrir uma sessão naquela máquina pra rodar o comando. Caso eu perca conexão ou a energia caia, tenho certeza que o comando vai continuar rodando. Depois posso logar na máquina e fazer um attach na minha sessão para ver o progresso.

Customizando seu tmux

O tmux utiliza um arquivo especial (.tmux.conf) que fica na sua home e pode personalizar comandos e teclas. Um bom exemplo é remapear a tecla lead ou modificar o comportamento do scroll para aceitar a rolagem com o mouse.

Não vou entrar muito em detalhes sobre a configuração do tmux, mas é fácil achar exemplos na internet de configuração. A minha configuração, por exemplo, é essa:

#jump to last open window
bind-key 'C-b' last-window
 
#count windows from 1
set -g base-index 1
 
#change status bar
set -g status-left ""
set -g status-right "#[fg=white]#H #(date +'%a, %d %b %Y, %R')"
 
#highlight active window
set-window-option -g window-status-current-bg green
 
#mouse scrolling
set -g mode-mouse on

Espero que com isso você tenha ficado curioso para testar a ferramenta e espero que ela lhe ajude.

Resumão do Abril pro Ruby

Se você não pode ir para o Abril Pro Ruby que aconteceu agora 27 de Abril (2013), vou tentar falar um pouco sobre como foi o evento e as palestras que rolaram por lá.

O Evento

Abril Pro Ruby

O objetivo do evento foi reunir amantes de Ruby e todo o ecossistema que envolve a linguagem, desde o conhecido framework Rails até outras ferramentas (como Jekyl e Sinatra) e dicas de práticas como testes automatizados e TDD.

Contando com mais de 100 pessoas num sábado chuvoso, a comunidade Frevo on Rails fez bonito e compareceu ao evento que estava sob a organização de membros do grupo e apoio empresas locais e da faculdade Marista.

As palestras

A primeira sessão do evento foi um workshop com Bruno Luigi voltado para os iniciantes. Devido ao número limitado de participantes eu não participei do workshop, então não posso falar muita coisa.

Em seguida a palestra sobre as novidades do Ruby 2.0 com o entusiasta Bruno Andrade. A palestra mostrou algumas features novas da linguagem, desde named parameters até module prepend.

Na próxima palestra, nomeada Ruby e o Mundo Mágico dos Unicórnios, Lailson Bandeira mostrou com muito bom humor a história do Ruby a da dramática comunidade que fez essa linguagem ser o que é hoje.

Dois lightning talks foram realizados, Walmir Neto mostrou contou um pouco da sua experiência na transição de PHP para Ruby, principalmente sobre o apoio da comunidade. No segundo Rodrigo Vieira apresentou a ferramenta Jekyll e como ela pode ser utilizada para criar aplicações puramente estáticas utilizando Ruby de uma maneira bem leve e simples.

Tiago Sales abordou um assunto bem polêmico: segurança. Na palestra ele comentou algumas formas de ataques comumente utilizadas e como nós desenvolvedores podemos evitá-las seguindo as boas práticas do framework. Além disso também foi demonstrado como explorar a última grande vulnerabilidade do Rails que foi descoberta no começo do ano, lembrando para todos os presentes a importância de aplicar os patches mais recentes nas aplicações.

Um assunto que não pode faltar em eventos para devs é Testes Automatizados. Lukas Alexandre apresentou conceitos de TDD como testes unitários e outras variações. Além disso também mostrou algumas técnicas pra evitar testes redundantes e que podem deixar a sua suíte de testes mais rápida e eficiente.

No último lightnig talk do dia, Brunno Gomes mostrou as vantagens da simplicidade do Sinatra. Brunno mostrou que devido a simplicidade a ferramenta fica extremamente extensível e principalmente fácil de aprender.

Na última palestra do dia eu apresentei um pouco da minha experiência com metaprogramação em Ruby, mostrando algumas técnicas e principalmente os problemas da utilização dessa técnica. Se quiser dar uma conferida nos slides é só olhar no slideshare http://www.slideshare.net/marcosbrizeno/abril-proruby

Para encerrar o evento, foi feita uma mesa redonda com os palestrantes e o pessoal da organização onde todo mundo conversou sobre vários assuntos diferentes. No final o evento organizado pela comunidade e feito pra comunidade ressaltou o sentimento de união da galera e da procura pelo aprendizado.

Seis meses depois – Experiência de como entrar em um grande projeto

Ah algum tempo atrás eu escrevi um post sobre como foram os primeiros dias quando entrei em um grande projeto na ThoughtWorks.
Bom, seis meses depois eu parei pra refletir sobre o que eu fiz de certo/errado – e o feedback que recebi – e resolvi compartilhar a experiencia para quem quiser algumas dicas para entrar em novos projetos – grandes ou pequenos.

Entendendo o problema

Antes de falar o que deu certo ou errado é importante dar algum contexto para que os pontos positivos e negativos sejam avaliados corretamente e evitar interpretações erradas.

Time grande e distribuído

Talvez a característica mais forte do projeto que entrei seja o tamanho da equipe e o fato de que a equipe não está localizada toda em um único escritório. A equipe conta com mais de 15 pares de desenvolvedores além de possuir uma larga variedade de papéis como: Analistas de Negócios (BA), Analistas de Qualidade (QA), Gerentes de Iteração (IM), etc. Além da quantidade de pessoas, ainda pesa o fato de não estarem todas no mesmo local e nem no mesmo fuso horário, dificultando comunicação e sincronização entre os vários papéis.

Base de código grande e antiga

A base de código do projeto também é incrivelmente grande. O projeto possui mais de 5 anos de desenvolvimento e utiliza Ruby on Rails, desde a versão 1.2, como framework base. Então muitas das facilidades que já são providas por versões atuais do RoR não existiam naquela época, desde gerenciamento automático de Fuso Horário até as validações de modelos. Muito precisou ser feito e ainda estamos tentando remover alguns impedimentos para utilizar novas versões.
Some a isso um domínio complexo e não tão explorado que precisa ser entendido tanto por devs quanto por BAs, IMs, etc.

Infraestrutura complexa

Não só a base de código, mas também a infraestrutura para suportar o projeto também são igualmente complexas, desde memcached para realização de cache distribuída de objetos até tungsten para replicação de dados.
Além disso, as ferramentas utilizadas para o desenvolvimento na equipe também eram muito diferentes. Eu trabalhava com RoR e não utilizava nenhuma IDE, apenas editores de textos. A equipe toda utilizava como editor de texto o Vim o que aumentou ainda mais a dificuldade para conseguir se tornar produtivo.

O que deu certo

Em um projeto grande não se pode ter tudo
Acho que um dos conselhos que mais me ajudou foi o de não tentar entender todo o aplicativo de uma vez só. É difícil tentar entregar valor quando você não sabe o que precisa fazer, então eu tentei focar meus esforços em pequenas partes do sistema, assim, mesmo não entendendo a maioria do que era falado em reuniões, consegui entender bem o que eu conhecia.

Conheça a linguagem/framework base

Um fator que me ajudou bastante foi ter conhecimento sobre Ruby e Rails, mesmo que as versões utilizadas no projeto não sejam as mais recentes, que eu tinha estudado. Vale muita a pena conhecer a fundo a linguagem e o framework utilizados no projeto. Os posts mais recentes do blog são inspirados no que eu aprendi no dia-a-dia do projeto e ajudaram bastante a entender melhor decisões técnicas feitas.

Equipe grande pode ser bom

Apesar da equipe grande ser aparentemente um problema, é possível tornar isso uma vantagem pois você tem várias pessoas, provavelmente com conhecimento diferente do sistema, que podem lhe ajudar a superar as dificuldades.
Uma característica da ThoughtWorks é a forte utilização da programação em par, geralmente pareamos 100% do tempo, isso me ajudou bastante a ganhar experiência com o projeto, desde as mágicas que são bastante utilizadas por desenvolvedores experientes de ruby até utilizar os atalhos e configurações do vim.

Tire o máximo de proveito dos testes

Por ser uma base de código gigantesca, e por ser desenvolvido baseado nos princípios ágeis desde o começo, a suíte de testes é igualmente grande, o que facilitou bastante desenvolver novas funcionalidades, pois os testes explicavam muito bem como os objetos funcionavam e quais os relacionamentos entre eles.

Esteja perto do cliente

Por ser uma equipe distribuída, um dos problemas era ficar longe do cliente, o que dificulta entender os motivos para as decisões do negócio e você fica com a impressão de estar só entregando código. Geralmente o cliente é a própria empresa, então isso não chega nem a ser uma preocupação, mas quando o cliente está bem distante da equipe é muito importante conhecer o negócio e as pessoas que constroem ele.

O poderia ter sido melhor

Agora vou falar um pouco sobre coisas que fiz errado, baseado no feedback que tive de meus colegas e de reflexões próprias.

Quem tem medo de código? o/

Talvez o meu maior problema tenha sido o medo. Entrar em uma empresa grande e em um projeto grande é bem difícil, então eu tive muito medo de fazer a menor alteração que fosse no código. Isso me bloqueou de fazer sugestões ou tentar descobrir as coisas por mim mesmo. Depois de um tempo eu vi que a estrutura do projeto não era tão frágil assim e ai pude aprender mais (principalmente fazendo besteira com o git). Mas se desde o começo eu tivesse encarado diretamente o código, acho que teria feito um progresso mais rápido.

Conheça não só o código

Uma coisa que senti muita falta de conhecer o sistema e as funcionalidades. Após algum tempo eu conhecia alguma coisa sobre o código mas não fazia a menor ideia de como aquilo tudo se integrava ou fazia sentido. Isso atrapalha pois você fica alheio as decisões e não consegue opinar sobre as direções que o time deve seguir.

Melhore o seu aprendizado

Algumas pessoas, assim como eu, aprendem muito mais rápido alguma coisa visualizando ao invés de ler. Infelizmente eu não tirei muito proveito de modelos visuais logo quando entrei no projeto, principalmente devido a facilidade que um par mais experiente proporciona. O problema não é necessariamente sobre utilizar modelos visuais ou não, mas por confiar no seu par mais experiente e não se esforçar tanto para aprender.

Use e abuse de Feedback

Uma coisa que é bem enfatizada na ThoughtWorks é dar e receber feedback, eu acho que poderia ter feito mais isso, principalmente no começo quando você está tentando achar seu próprio caminho. Nesse ponto a programação em par ajudam muito, pois você sempre tem alguém próximo para perguntar como está indo.

Saber apertar o freio e pedir ajuda

Logo quando entrei foi muito difícil seguir o ritmo do time, com todas as reuniões e várias pessoas falando sobre vários assuntos. Uma coisa que poderia ter me ajudado bastante seria tomar notas de pontos durante a reunião para poder perguntar aos mais experientes depois.

Se eu não escrevi, então é legado.

Muita se fala sobre código legado, sobre práticas pra gerenciar código legado, como evoluir uma base de código legado, mas você já parou pra pensar o que é código legado?

Alguns dias atrás tivemos uma discussão com os membros da equipe utilizando como base o famoso livro “Working Effectively With Legacy Code” de Michael Feathers [1], e antes de entrar no livro eu propus que discutíssemos o que é código legado e chegamos a um conjunto de pontos interessantes sobre código legado.

Subjetividade

Michael Feathers define código legado como código que não possui testes [2], no entanto esta definição é um pouco antiga, pois o livro é de 2004, quando as práticas de testes automatizados ainda estavam sendo difundidas pela comunidade e as ferramentas começaram a aparecer.

O ponto de vista extremo do autor ressalta o fato de que código legado é um código que é difícil de ser mantido. Um código que não possui uma boa suíte de testes dificulta a análise do impacto de suas mudanças, e isso contribui para a inércia da equipe, que evita ao máximo realizar alterações profundas.

No entanto, hoje em dia com a grande abrangência e utilização de ferramentas de testes, não podemos confiar apenas nesse fato, pois um outro conjunto de fatores pode contribuir, talvez não com a mesma intensidade, para que a equipe sofra com mudanças.

É difícil escrever uma frase que defina totalmente o que é código legado, vamos então analisar um conjunto de pontos que podem facilitar essa análise e reflexão sobre o que um projeto legado.

Tecnologia

A tecnologia utilizada em um projeto modifica bastante o desempenho da equipe e sempre discutimos quais as melhores de acordo com cada situação. Com relação a código legado, será que a tecnologia faz um código ser legado ou não?

Os sistemas de pagamento que são escritos em cobol, podem ser considerado sistemas legados? Nesse caso a tecnologia não é mais presente no cenário atual de desenvolvimento, a dificuldade para manter esse tipo de sistema é muito grande, principalmente para encontrar desenvolvedores com conhecimento sobre a tecnologia.

Considere então um sistema que utiliza uma linguagem atual, mas que faz uso de bibliotecas, gems ou frameworks que não são compatíveis com novas versões. Nesse caso a tecnologia impede o aplicativo de continuar a evoluir e contribui para deixar a base de código legado, pois com a renovação da equipe fica difícil manter o conhecimento sobre versões anteriores.

No entanto a tecnologia não pode ser utilizado como único fator para indicar que o projeto é legado. Como um exemplo podemos analisar os aplicativos móveis que precisam manter compatibilidade com versões de sistemas anteriores. Apesar da tecnologia ser antiga o desenvolvimento continua ativo, apesar dos problemas com rotatividade de membros.

Manutenção

Isso leva a outro ponto interessante, o livro fala que código legado é código sem testes, mas qual é o papel da bateria de testes de um projeto? Talvez o mais importante seja facilitar a manutenção a longo prazo, ou seja, um código sem testes é muito difícil de ser mantido, caindo facilmente no limbo do código legado.

Um exemplo são sistemas antigos que ninguém mais altera com medo de fazer parar de funcionar. A solução na maioria dos casos é confiar que aquele monstrengo funciona e cercar ele de serviços que podem ser testados.

E quando a empresa não acredita em testes, então a linha que acaba de ser escrita já está legada? Não necessariamente, pois caso seja um sistema pequeno, onde é fácil entender e alterar (um CRUD simples, por exemplo), talvez os testes não sejam tão importantes.

Mas um sistema médio/grande que não possui nenhuma garantia de funcionamento está amaldiçoado a ser legado. Conforme o time for sendo renovado, os novatos precisarão de muita coragem e tempo de treinamento para realizar alterações, mesmo que sejam superficiais.

Abandonado

Passado algum tempo onde os desenvolvedores não tocam mais em uma determinada parte do sistema, ele começa a ficar abandonado. Um sistema, ou parte dele, que não é tocado por um longo tempo pode ser considerado legado?

Essa discussão leva a dois pontos, o primeiro é de que um desenvolvedor novo pode considerar o sistema legado e um mais experiente não. Isso geralmente acontece quando o conhecimento não está distribuído entre a equipe, então apenas uma pessoa do grupo fica “responsável” por atualizar aquela parte que realiza pagamentos.

O segundo ponto é de que o conceito de legado pode ser aplicado apenas em uma parte do sistema. No caso de sistemas realmente grandes pode ser que a utilização de determinada ferramenta que apenas uma pessoa da equipe conhece crie dificuldades para manter o sistema.

Idade

Um sistema velho pode ser considerado legado? A resposta depende do que é velho, que também é um conceito subjetivo. Um sistema de cinco anos que utiliza versões não tão atuais das tecnologias e que a equipe já foi completamente renovada, pode ser considerado legado?

É fácil perceber que não dá pra escrever um parágrafo que descreva o que é um sistema legado. A conclusão que nós chegamos foi de que, a partir de uma lista de conceitos relacionados a código legado podemos analisar se o nosso projeto é legado ou não. E essa discussão foi muito positiva, pois tratou principalmente sobre a confiança dos membros da equipe em alterar o sistema.

E o que é código legado para você? O quão confiável está você e sua equipe com o sistema que vocês desenvolvem?

Referências:

[1] FEATHERS, Michael C. Working effectively with legacy code.
[2] http://en.wikipedia.org/wiki/Legacy_code