Category Archives: paideia

books-pile

Minhas boas leituras de 2015

Não me lembro de um ano que tenha me ensinado tanto quanto 2015: realizei meu grande sonho de me dedicar totalmente à itexto (aguardem o post). Mais da metade das coisas que discordava até então se mostraram necessárias (virá um post) e minha visão a respeito do mundo foi impactada de maneiras que eu jamais poderia imaginar.

É curioso olhar pra trás e perceber um paradoxo: foi um ano pobre de leituras. Li muito menos, talvez devido ao fato de finalmente ter publicado meu segundo livro (Falando de Grails), o que é sempre bastante exaustivo para mim. Outra razão foi a itexto: este ano nosso foco foi aprender a como gerir o negócio da melhor maneira possível (e a isto agradeço à Nanna, pra variar), o que demandou boa parte do meu tempo.

Conservadorismo, direita, esquerda, centro… o que sou eu?

Em 2015 ficou claro que eu não sabia o que significava ser de direita ou esquerda. Ainda pior: percebi que termos como “conservadorismo” e “reacionarismo” me incomodavam sem que eu soubesse o que de fato significavam. E o mais interessante: o sentimento positivo que sentia pela “esquerda” também não tinha qualquer fundamento teórico. Como eu podia gostar ou desgostar de algo que não conhecia? Quem sou eu de fato?

Roger Scruton e o conceito de faking (falseamento)

Roger Scruton at Edinburgh International Book Festival 2014.  13th August 2014 Picture by Pako Mera/Writer Pictures WORLD RIGHTS (Writer Pictures via AP Images)

Roger Scruton

Alguns amigos (Túlio e Cyrio) me indicaram um autor chamado Roger Scruton, que se apresenta como conservador. Curiosamente, não me foi indicado devido a esta minha busca política, mas por meu interesse em estética.

Scruton nos apresenta um conceito que achei fascinante e se aplica perfeitamente à área de TI e desenvolvimento: “faking”. Grosseiramente o descrevendo, é aquela situação que com certeza leitores mais experientes já presenciaram: alguém se apresenta como profundo conhecedor de um assunto sem saber de sua própria ignorância e os demais ao seu redor – honestamente ignorantes sobre o tema – abraçam o indivíduo como uma fonte real de conhecimento (isto me motivou a escrever este post).

O autor trata de artes plásticas, performáticas e arquitetura, mas conforme ia lendo seus artigos sobre o assunto e participando de alguns eventos da nossa área ficou nítido que seu conceito de “faking” se aplica muito bem à nossa realidade (com certeza virá um post sobre isto).

Você pode ouvir o próprio Scruton falando sobre o assunto neste excelente episódio do programa “Point of View” da BBC: Faking it.

Há também um excelente artigo em inglês: “The Great Swindle”

E também há um livro que ainda não li: Beauty

Scruton conseguiu verbalizar uma intuição que tenho há anos.

Scruton conservador

scruton-conservador

Coincidentemente, no mesmo ano a editora Record publicou uma tradução do livro “How to be a conservative” do Scruton: comprei na hora. Finalmente pude entender o que o conservadorismo realmente significa e, ainda mais importante: identifiquei, chocado, muitos traços conservadores na minha personalidade (será que minha paixão por legados vêm daí?).

Scruton faz uma análise muito profunda do conceito de conservadorismo, mas você deve levar em consideração o fato do livro ser focado no contexto inglês, que é bastante diferente da nossa realidade nacional. Se conseguir levar em consideração este fato e não tomar o livro sem uma boa pitada de sal, com certeza aprenderá bastante com ele.

Finalizada a leitura percebi que tinha uma visão muito preconceituosa a respeito dos conceitos de direita, conservadorismo e reacionarismo. Mais que isto: percebi traços conservadores e mesmo reacionários em mim, o que me leva a assumir isto aqui publicamente sem qualquer vergonha.

Leia o livro antes de me julgar. :)

Bobbio como contraponto

direita-esquerda-bobbioScruton é tendencioso, então para contra-balançar, que tal ler um autor de esquerda falando sobre direita e esquerda? Reli “Direita e Esquerda” do Norberto Bobbio. O autor busca definir os dois termos no seu livro. Não me impactou tanto quanto a leitura de Scruton por não ser um texto novo para mim: comprei o livro em 2003 e nunca o havia lido com atenção.

É uma excelente leitura: no Brasil é publicado pela editora Unesp. Bobbio explica os conceitos do ponto de vista histórico e ideológico em um texto bem curto.

O que percebi? Que tenho familiaridade com alguns ideais de esquerda e direita. Minha busca pela minha própria definição ficou ainda mais confusa. :)

Leituras técnicas

Um ano de blogs

Finalmente coloquei o /dev/All no ar: um agregador de blogs nacionais sobre desenvolvimento de sistemas, TI e assuntos relacionados. O site cresceu significativamente: conta hoje com bem mais de 100 blogs e já estamos caminhando para os 200.

Li posts excelentes no site e (re)descobri alguns blogs que, acredito, vale muito à pena citar aqui:

Dado meu tempo reduzido, /dev/All foi vital para que me manter atualizado durante o ano. Estes foram os blogs que mais gostei e que me lembrei enquanto escrevia este post. Tenho certeza de que fui injusto ao não mencionar mais alguns, mas no futuro corrigirei este erro.

Docker e minha volta ao Linux

docker

Foi a tecnologia que me fez voltar ao Linux com força total e a que mais me impressionou nos últimos anos. De repente me vi com uma ferramenta que me permite realizar experimentos de configuração em servidores com uma produtividade que jamais imaginei ser possível.

Docker me deu a desculpa ideal para que eu pudesse finalmente me aprofundar no Linux. Seguem os textos e livros que mais gostei.

Docker

Docker Jumpstart – Foi o texto no qual realmente aprendi a usar o Docker.

Getting Started with Docker – Versão júnior do texto acima. Leia o Jumpstart primeiro, use este como referência

(em breve deve sair um guia da itexto sobre Docker)

Linux

Foi em 2015 que finalmente resolvi criar vergonha na cara e aprender a escrever shell scripts no Linux. Estes textos foram fundamentais:

The Linux Command Line – Um livro gratuito maravilhoso sobre a linha de comandos do Linux. Finalmente aprendi como dominar esta criatura e já escrevo alguns scripts com ela. Foi muito importante para que eu pudesse tirar um proveito ainda maior do Docker.

Conquering the Command Line – outro livro excelente sobre o mesmo assunto. Não tão bom quanto o primeiro, mas bom também. :)

AWK

Das linguagens de programação que vi em 2015 a que mais me impressionou foi AWK. É um monstro que provávelmente está instalado no seu Linux e você nem nota. Escrevi inclusive um post a seu respeito, que você pode acessar neste link.

Posso dizer com segurança que AWK me tornou uma pessoa mais produtiva em 2015. Interessado em conhecer a criatura?

An AWK Primer – Este livro está no Wikibooks e é um bom início.

GAWK: Effective AWK Programming – Trata-se do manual do projeto GNU para a sua implementação do AWK. A leitura é bem tranquila e também me ajudou bastante.

Git

Em 2015 troquei o Mercurial pelo Git. Inicialmente por que todos os nossos clientes preferiam o Git, depois por que comecei a estudar mais a fundo a ferramenta e aprendi diversas coisas interessantes a seu respeito.

Um dos resultados foi o primerio Guia da itexto: Usando o Git. Já estou trabalhando na segunda edição.

E o que mais gostei de ler sobre Git este ano?

Pro Git – Um livro gratuito escrito por Scott Chacon e Ben Straub que irá lhe expor essencialmente tudo o que você precisa (e não) saber a respeito do Git.

JavaScript

Por mais estranho que eu ache as pessoas amarem hoje uma linguagem que era odiada há poucos anos atrás, não pude deixar de me aprofundar um pouco mais no assunto. O que li e gostei?

JavaScript: the Good parts – Finalmente li este livro do Douglas Crackford. Me impressionou? Não, mas é um livro interessante. Gosto muito dos diagramas que ele usou para descrever a linguagem.

AngularJS – Comecei a usar o AngularJS. Após passar por diversos livros e textos horríveis sobre ele, acabei ficando com a documentação oficial mesmo, que foi a melhor coisa que li a respeito.

Dominando JavaScript com jQuery – escrito por Plínio Balduino e publicado pela Casa do Código. É um dos melhores livros sobre JavaScript que conheço (melhor que o do Crackford na minha opinião). Voltei a este material algumas vezes este ano. Ei: é um livro escrito aqui no Brasil com qualidade internacional! Se ainda não leu e quer entender JavaScript, LEIA!

Nota importante: minhas piores leituras

Minhas piores leituras foram relacionadas a JavaScript. Li muito material HORRÍVEL este ano, especialmente o relacionado a NodeJS e AngularJS. Se um dia escrever um texto sobre minhas piores leituras com certeza haverá uma longa seção sobre este conteúdo.

BASIC

BASIC

Sim, você leu certo: este ano estudei BASIC. Não para usar a linguagem, mas para escrever melhores textos técnicos (e outra razão que exporei abaixo). Por que melhores textos técnicos? Leia minhas sugestões de leitura e você entenderá. ;)

DartMouth Basic Manual – Publicado em 1964. É um dos textos introdutórios sobre programação mais didáticos que já vi. Repare que é uma fotocópia, e com marcações sobre a mesma! Pura simpatia.

Linguagem BASIC – MSX – Pouca gente se lembra do MSX: sou uma delas. E este foi o primeiro livro de programação da minha vida, quando eu tinha algo entre 6 e 7 anos.

10 PRINT CHR$(205.5+RND(1)); : GOTO 10 – E que tal um livro sobre um algoritmo escrito em BASIC que imprime um labirinto? Leitura divertidíssima para aqueles que, como eu, curtem história da computação. Excelente leitura!

O BASIC nos anos 80 era usado como ferramenta educacional para crianças (fui uma destas). Sabe este esforço recente de popularização da programação? O pessoal já fazia isto 30 ou 40 anos atrás (na minha opinião com muito mais competência e, talvez, honestidade).

Houve um curto período de tempo em 2015 no qual iniciei a implementação do meu próprio BASIC para a JVM, mas as motivações para este projeto e o que ocorreu são assunto para um outro post (esta era a segunda razão).

(que se dane o Dijkstra: eu curto BASIC!)

O que lerei em 2016?

Desejo a todos vocês um 2016 como foi meu 2015: rico em aprendizado e experiências que com certeza me tornaram uma pessoa melhor (assim espero!).

Gostaria muito de saber aqui quais foram as melhores leituras de vocês. O que mais gostaram de ler? Feliz ano novo!

amigo-da-onca

Como aproveitar ao máximo um palestrante

Então você está assistindo a uma apresentação em um evento ou um consultor está na sua empresa mostrando algo que pode tornar sua vida melhor. Terminada a palestra, em uma conversa entre colegas você critica o conteúdo ministrado e obtém como resposta algo como o clássico “quem é você para criticar fulano?”.

Ou então algo ainda mais interessante: a apresentação lhe deu um novo ânimo pois agora sabe que seus problemas acabaram! Você quer aplicar aquele conteúdo em sua vida e no dia seguinte começa a luta. Tudo nos primeiros momentos vai maravilhosamente bem, mas logo você nota que as rosas que lhe venderam possuem mais espinhos do que lhe contaram.

Sou consultor e de vez em quando palestro em eventos ou empresas. Como consultor estou cansado de ver pessoas tendo prejuízos monstruosos devido a algo que foi mal compreendido ou dito em uma apresentação. Como palestrante sempre temo que o que digo gere muito prejuízo a quem me ouviu falar (e creio que todos os palestrantes deveriam ter esta preocupação).

Neste post lhe darei algumas dicas para não cair nestas armadilhas. Como tirar máximo proveito do palestrante, aquela pessoa que aparenta ser tão mais carismática que nós?

Termos fundamentais

Este post gira em torno de dois conceitos que considero fundamentais quando vou avaliar qualquer palestra.

Responsabilidade e irresponsabilidade

amigo-da-onca

Simples e direto: responsável é aquele que será procurado após suas ações serem executadas, tendo estas sido bem sucedidas ou não. Já o irresponsável executa suas tarefas e parte.

Na esmagadora maioria das vezes o palestrante expõe o tópico e sai. Ele irá embora, mas a impressão permanece nos ouvintes. O expectador é o maior responsável pelo que faz com o conhecimento transmitido.

Arrogância

miniature-pinscher

No livro “Direita e Esquerda”, Norberto Bobbio dá a melhor definição do conceito que conheço: é “a confiança excessiva nas próprias habilidades”.

Eu e você já fomos arrogantes ao menos uma vez. Um esforço honesto de memória nos exporá situações nas quais realmente acreditávamos conhecer um assunto e transparecemos isto a alguém, para depois descobrirmos que não eramos tão bons assim naquilo.

Quem está falando?

who_is_talkingA pessoa é mais que um nome, e a pesquisa a respeito do passado do palestrante é um excelente detector de arrogância. Tudo bem que existem exceções, mas como levar a sério alguém que se apresenta para falar de um assunto, por exemplo, desenvolvimento de software e se apresenta assim?

Fulano Simpático é profundo conhecedor do assunto X e possuí três anos de experiência como desenvolvedor

Você busca o currículo da pessoa e descobre que destes três anos, um foi como estagiário, dois em apenas uma empresa e que o assunto X tem pelo menos 15 anos de existência. Se a apresentação for algo como a exposição da sua experiência, talvez seja interessantíssimo: é fascinante ver as dificuldades enfrentadas por iniciantes, mas se for uma aula detalhada sobre o assunto… desconfie: a genialidade infelizmente não é um artigo popular no Universo.

Havendo tempo, uma busca rápida pelo LinkedIn, blog, artigos publicados ou coisa similar já expõe bem a natureza do palestrante. Este é o primeiro passo: detecte a possível arrogância do sujeito. (redes sociais como Facebook não contam: é lugar de se postar trolagem (o meu pelo menos é)).

Experiência não é tudo: o mínimo de consistência também é importante. Se um dia a pessoa fala sobre X, em outro sobre Y, depois sobre Z, A, D, H, E, J  e os assuntos são distantes uns do outros, vejo algumas opções:

  • Estou diante de um especialista em porra nenhuma
  • É alguém que curte novidades e divulgá-las (e isto é positivo, desde que não se venda como profundo conhecedor dos assuntos tratados)
  • Dificilmente a pessoa teve tempo para trabalhar efetivamente com os assuntos tratados na prática

Mas conhecer melhor o passado do palestrante te traz outra vantagem: te ajuda a fazer melhores perguntas. Entenda: ninguém conhece a totalidade de um assunto, pois todo conhecimento é definido pelo contexto em que o sujeito se encontra. Se você me perguntar como se deve aplicar Groovy e Grails no processamento de Urânio não vou saber te responder.

E sabe qual a vantagem de boas perguntas? Elas te dão um monte de conteúdo. 

E o lado feio?

duascaras

Você vê a solução e ela parece linda. Mas não tem nenhum porém, nenhum lado feio, nenhuma limitação??? Na minha opinião esta é a pergunta mais importante: quanto custa?

Nos últimos anos a ausência desta pergunta gerou prejuízos imensos que pude ver em primeira mão. Seguem dois exemplos:

  • Equipes que abandonaram completamente o modelo relacional e abraçaram alguma solução NoSQL, como MongoDB, para depois perceberem que coisas “bobas” como integridade referencial não são algo “careta e ultrapassado”.
  • Empresas que realmente acreditaram que seria possível reduzir a complexidade dos seus sistemas adotando micro-serviços que se pegam em uma situação BEM pior que a anterior por que não se falou muito a respeito dos custos envolvidos.

Quando o palestrante não fala muito a respeito dos trade-offs, isto não quer dizer que a pessoa é má intencionada: está apenas apresentando seu aspecto irresponsável e talvez arrogante. Terminada a apresentação, a bola está com você.

Normalmente a pessoa está tão enamorada pelo assunto apresentado que não consegue ver suas limitações: qualquer um que já tenha se apaixonado sabe do que estou falando.

(dica: se o palestrante tem um slide mostrando os custos da tecnologia e o expõe rapidamente, peça para que fale mais a respeito do assunto ;) )

Desconfie do carisma/”atitude”

poison

Já reparou que na natureza as coisas muito coloridas (como a flor acima) normalmente são armadilhas? Numa palestra o que realmente interessa é o conteúdo, mas há aqueles palestrantes que são simplesmente excessivamente carismáticos.

São pessoas divertidas, simpáticas, engraçadas, bem articuladas. Ou então podem possuir aquela postura mais radical, quase agressiva. Aquele sujeito “adoravelmente desagradável” que conquista a sua simpatia. É difícil vencer esta tentação. Todo mundo quer ser como aquela pessoa, e se ela diz algo, deve ser o correto, certo? Certo?

dr_house

Minha dica? Dou tempo ao tempo. Tento resistir ao carisma e prestar atenção no conteúdo. Espero passar um mês e tento me lembrar do conteúdo. O que mais me impressionou? O palestrante ou o conteúdo?

(nos meus 36 anos fica claro para mim que a maior parte das pessoas que me influenciaram eram na realidade tolos carismáticos (e esta descoberta não foi decepcionante, mas sim um alívio))

Pergunte (não precisa ser na hora)

Eu sei que fazer uma pergunta em público pode dar uma vergonha danada. Talvez você fique com medo de dizer alguma bobagem na frente de todos e isto muitas vezes te cala. Mas quem disse que a pergunta precisa ser feita durante a palestra?

Todo palestrante expõe seus dados de contato. Se acha que não é interessante perguntar naquele momento, faça como eu: anote todas as suas dúvidas e em seguida lhe envie um e-mail. Nunca encontrei alguém que não me respondesse, por mais importante que fosse.

Estude antes da apresentação

Quando vou a uma palestra que realmente me interessa costumo estudar um pouco sobre o assunto antes do evento. Isto me ajuda bastante a fazer melhores perguntas e na compreensão do que vai ser exposto.

Não precisa ser um estudo profundo: muitas vezes uma leitura de 20 minutos antes do evento já é suficiente pra te contextualizar.

Peça pelas fontes

Dificilmente todo o conteúdo apresentado foi criado pelo palestrante. Pra tirar máximo proveito do que foi exposto sempre peça as fontes usadas na apresentação. Muitas vezes o que mais aproveito em uma palestra é justamente a bibliografia!

É uma oportunidade excelente de entrar em contato com textos que dificilmente você ouviria a respeito se não tivesse participado do evento. Se o autor não expor suas fontes, apenas pergunte por alguma sugestão de leitura.

Lembre que a bibliografia nem sempre é explícita, mas sempre está presente. Basta prestar atenção nos nomes citados durante a palestra.

Existe mais de uma realidade

infinitas_terras

Conhecer o passado do palestrante traz outra vantagem: você passa a entender sua realidade, que sempre é distinta da sua, e este é um ponto importantíssimo.

Muitas vezes o palestrante é criticado por que o ouvinte não consegue por em prática aquilo que foi exposto. Uma razão comum (quando bobagens não foram ditas) é o fato de estarem em realidades diferentes. Exemplo clássico: alguém que trabalhe em uma empresa gigantesca falando sobre sua infraestrutura de servidores. É uma realidade restrita, dado que a esmagadora maioria dos ouvintes comemora e muito se tiver mais de um (mesmo com a cloud).

Então para tirar máximo proveito do que foi exposto é fundamental a contextualização. O que está sendo apresentado funciona (ou não) dentro do contexto do palestrante. É sua responsabilidade portanto, se quiser aplicar o que viu, adaptar (se possível) o que foi exposto para a sua realidade.

Seja crítico e valorize suas próprias experiências

Não é raro estar em uma palestra e presenciar o palestrante desdenhar um conjunto de conhecimentos que fazem parte do seu dia a dia. Neste momento você deve se fazer o seguinte questionamento: se é tão ruim assim, por que têm funcionado para nós?

Esta é uma pergunta importantíssima. Já cansei de ver o clássico momento “Java sucks, use X que é melhor”. Se não for apresentada uma excelente justificativa para a troca, pulo fora na hora.

Não estou dizendo para você ser um reacionário: apenas para não desvalorizar os conhecimentos que já tem. Não é o fato do outro estar com o microfone na mão que o torna o dono da verdade.

Concluindo

Palestras e eventos são uma fonte praticamente infinita de riqueza intelectual quando bem aproveitados e de prejuízos imensuráveis se o ouvinte não adotar uma postura ativa, questionadora e crítica.

Ter uma postura crítica diante de uma apresentação não deve ser visto como uma postura negativa, mas sim como a tentativa de se extrair o máximo possível de eventos cuja finalidade é nos formar.

multibot

Choque de cargos: o que eu e você somos?

Apesar da minha vida acadêmica ser bastante conturbada, sempre soube o que queria ser: programador. E a imagem que tinha desta profissão é muito próxima da imagem abaixo, usada em tantos memes:

basic_programming_color_cart

Era uma visão bastante ingênua por razões óbvias (eu tinha menos de 10 anos), mas confesso que ainda a tenho ao menos em parte. Computação é minha musa e bandeira que defendo até as últimas consequências.

Curiosamente não fui direto para o mercado de TI: fui trabalhar em livrarias, depois para a faculdade de Filosofia e os programas que escrevia eram (e ainda são em grande parte) criados por puro prazer. Anos depois finalmente larguei a Filosofia (e livrarias) e entrei no mercado: foi um choque.

O choque dos cargos

De repente vi as pessoas atuando como programadores mas se chamando de “desenvolvedores”, “arquitetos”, “fullstack developer” (este último, mais recente) e raríssimas vezes como programadores. Aliás, eu via outro nome curioso: implementador. Aonde estavam os programadores?

Me perguntava: era ruim ser programador? Era inferior? Conheci arquitetos fantásticos: aqueles caras projetavam soluções completas e, logo em seguida, davam massa às suas idéias escrevendo seu código. E então ouvia que programadores de torre de marfim era algo negativo e toda aquela história que vários de vocês já devem ter ouvido.

Conforme o tempo ia passando mais choques apareciam: pra começar não bastava ser um programador, você era um developer e um developer X, aonde X correspondia ao nome de uma tecnologia como Java, PHP, C, Delphi, .net ou qualquer outra.

O que eu era? Quando entrei no mercado já “dominava” algumas linguagens: C, Pascal, Delphi, Visual Basic, Java, PHP, Javascript, VBScript… E em todas estas conhecia gente que criava coisas fantásticas. Que tipo de “gênio” eu queria (e poderia) ser? Queria todos.

Indo além, via também as diferentes atividades: havia o sujeito que projetava o sistema (e depois o implementava), aquele que testava, outro que programava, o sujeito que coletava requisitos, tinha também “o figura” que gerenciava e aquele outro que coordenava. Tantas atividades, que na teoria aparentavam ser tão distintas, mas que na prática deveriam interagir entre si mas acabavam ignorando-se umas às outras.

Eu via, por exemplo, o analista de requisitos que não conseguia entender como o programador pensava, o arquiteto “Niemeyer”, que projetava coisas quase impossíveis para os programadores “engenheiros” construírem, o programador que não entendia como o sujeito do teste pensava e acabavam pipocando conflitos, aquele gerente que buscava um Santo Graal da produtividade…

Ainda pior: cada programador focado em uma única tecnologia pensando de forma completamente diferente e, para meu horror, ignorando as soluções presentes em outras plataformas por pura e simples futilidade, vaidade ou ignorância. Programador que não entende programador???

Ficava óbvio pra mim que por mais que se tentasse a especialização, o especialista não podia ser um solipsista. A pessoa do QA precisa entender como pensam o programador, cliente, arquiteto, analista de requisitos, etc. E o mesmo para todas as outras áreas de atuação.

E aí virei “empresário”

A visão que tinha até então era a do funcionário e neste ano comecei a ver “o outro lado”: eu, como empregador, como vejo estes cargos? itexto é uma empresa de computação: não me interessa se vou lidar com C, Lisp, Java, C#, Delphi ou Clipper. A fundei para criar um estilo de vida profissional a ser compartilhado.

Meu objetivo é ajudar os profissionais de computação a se tornarem melhores  e as empresas a tirar melhor proveito dos seus recursos e necessidades computacionais com nossa consultoria. Aonde entra o especialista estrito? Neste momento apenas se for para nos ensinar sua especialidade.

O especialista é caro (especialmente quando sua empresa é pequena). E estou usando o sentido estrito do termo: o que ele me dará é pouco comparado ao que iremos investir. Ainda pior: há aqueles que criam barreiras a qualquer solução que sua especialidade não abrace e acaba por nos limitar intelectualmente. Não basta ter um retorno mínimo: muitas vezes causa dano.

Claro: alguma especialidade é necessária. A minha é software, não administração: resolvemos com a Maria Angélica, que nos liberou para poder fazer aquilo que sei. Mas o especialista não poderia dizer o mesmo, digo, que faz apenas X dentro do processo de software por ser apenas “aquilo que sabe fazer bem”?

Respondo: você pode até fazer apenas aquilo, mas obrigatoriamente deve conhecer as outras áreas para se tornar realmente útil a nós. Um sujeito .net que apenas critique Java (e vice-versa) e não reconhece as suas vantagens é nocivo. Um testador que chama de “preguiçoso” o programador por que este “se esqueceu” de executar um teste o vejo como um tóxico (negativo). Um gerente de projetos que joga prazos absurdos por acreditar que a equipe está “enrolando” não passa pela minha porta. O arquiteto que projeta algo ignorando as capacidades da sua equipe e do seu cliente para nós fede.

Software é uma atividade interdisciplinar em sua essência, negar este fato é dar tiro no pé. Mais que interdisciplinar, geramos produtos baseados não em uma tecnologia, mas várias, cada qual nos oferecendo um ou mais caminhos para resolver os problemas que nossos clientes enfrentam. Fordismo quando o assunto é software não rola.

Esta nova realidade abriu muito meus olhos: é impressionante a dificuldade que temos em contratar. É tanta gente se rotulando e com isto reduzindo suas possibilidades de mercado que me assusta, cargos como “CTO”, por exemplo, que soam tão imponentes mas na prática acabam se mostrando inúteis, o cara “fullstack” que só conhece uma linguagem de programação (JavaScript), gente que sonha em ser “chefe” e se torna de cara “gerente de projeto” sem nunca ter visto um sistema ser criado, arquiteto que nunca programou e está buscando o primeiro projeto… Quanta gente “cara”!

Cegos guiando (ou gerando) cegos?

bruegel_blinds

Será que estas pessoas sabem o que de fato estes rótulos significam, se é que significam alguma coisa? Confesso que sempre tive dificuldade em saber o que de fato EU sou.  Programador? Arquiteto? Empresário? Consultor? Talvez “programador” me soe melhor aos ouvidos, mas sei que não é uma boa definição para meu caso. Prefiro “profissional de computação”.

Recentemente estive em um evento no qual o palestrante levantou o seguinte questionamento: “existe programador velho? Alguém se aposenta como tal?” (ele não respondeu, mas sua postura claramente respondia que “não”).

Achei curiosa a definição de velho (mais de 30 (sou um ancião portanto)), ainda mais interessante a ideia de programador (não havia). Aquilo me incomodou (muito): pessoas em início da carreira na platéia, vendo um cego que acreditava enxergar usando termos como developer, fullstack developer, architect e tantos outros em inglês.

Um cego guiando outros (pior: gerando cegueira), provavelmente formado por outro (cego (talvez sua cegueira se chame arrogância)). Senti duas coisas naquele dia: alegria por estar na itexto e a obrigação moral de questionar estas coisas.

Então você é o legado?

O que é legado?

Santo Agostinho, que de santo mesmo tinha muito pouco.

Dica: você sempre encontrará frases divertidas em Santo Agostinho

De uns tempos para cá tenho notado que cada vez mais pessoas falando sobre “software legado”. E sabem o que acho mais interessante? Elas caem em uma situação parecida com a que Santo Agostinho enfrentou ao falar sobre o tempo.

“Que é, pois o tempo? Se ninguém me pergunta, eu sei; se quero explicá-lo a quem me pede, não sei.” – Santo Agostinho

Troque a palavra “tempo” por “sistema/software legado” e faça uma auto crítica. Se eu te perguntar o que é software legado você vai saber me responder de forma clara e imediata? Já falei aqui como lido com legado, mas nunca apontei uma definição para este. Neste post faço isto,  mas antes vou mostrar algumas definições faláciosas.

“Todo software que você escreve depois de um tempo vira legado, assim como todo aquele que não foi escrito por você.”

Esta definição é um contra-senso e dá pra provar com lógica pura, quer ver? Se digo que um software é legado, a palavra “legado” denota uma categoria (ou conjunto) no qual alguns softwares se encaixem e outros não. Legado é adjetivo. Se é adjetivo, diferencia, se diferencia, deve haver algo que não seja legado.

Se tudo é legado, não há diferenciação, portanto não há legado. O software que você está escrevendo não é legado pois ainda não foi para produção e para o cliente sequer existe de fato, então cairia fora desta definição, mas aí entra aquela outra que também é furada.

“Se foi para a produção virou legado!”

Também não se aplica, a primeira versão do seu sistema, a qual você possui completo controle sobre o código fonte e arquitetura, que está brilhando de lindo pode ser chamado de legado? Sabemos que não. É apenas uma variação da primeira definição que mostrei.

“Legado é todo aquele software que precisa ser substituído por ser obsoleto ou não servir mais!”

Também não. Este software não é legado, mas sim inadequado ao contexto em que se encontra. Entra aí o conceito de obsoleto. Em que sentido obsoleto? Regras de negócio que não se aplicam mais? Uma plataforma de desenvolvimento que NINGUÉM no MULTIVERSO conheça?

A história do ambiente de desenvolvimento críptico também é furada. Ok, você pode ter dificuldade em encontrar mão de obra especializada, mas nada além do custo (que nem sempre é tão exorbitante assim quanto nos vendem) impede que você treine ou aprenda aquele ambiente também antes né? (sempre me soa a preguiça)

“Código legado é código sem testes.” – Michael C. Feathers

Sim, eu li o livro

Sim, eu li o livro

Desconfio que esta falação toda em cima de código legado é motivada pelo livro do Michael C. Feathers que o Robert Martin tem divulgado bastante atualmente. Neste livro há uma definição bem interessante: “código legado é código sem testes”.

Em uma primeira análise é uma boa definição: se o código não tem testes você não sabe explícitamente o que ele faz, logo não há controle sobre ele. Você não sabe se vai quebrá-lo quando for implementar uma nova funcionalidade ou mudança.

O problema desta definição é o escopo: apenas o programador (e talvez o arquiteto). Para o programador código legado é aquele que considera ruim o que, normalmente não passa de uma questão de ego (Fabio Akita tem um texto excelente sobre isto) e ignorância a respeito do contexto que gerou aquele sistema. É simplesmente não ter uma resposta honesta para a pergunta “o sistema deveria ser deste modo por que eu quero ou por que realmente é uma necessidade?”.

(Sobre o livro, bom: me decepcionou pois é mais um livro de refactoring do que sobre arquitetura na minha opinião. Um dia ainda escrevo um review sobre ele. Resumindo: micro demais e macro de menos, mas mesmo assim recomendo a leitura.)

wizardofoz1

Então você é o legado?

O que é um sistema legado?

Sistema legado é aquele cujo controle foi perdido por seus principais stakeholders. – Definição Lobo Weissmanniana

Software legado tem valor e prova disto está no fato de ser usado. Ignorar isto é menosprezar seu cliente e divulgar aos sete ventos sua própria arrogância e cegueira.

Software legado é aquele cujo controle sobre sua evolução foi perdido pelos principais interessados. E ei: o principal interessado não é o programador ou a equipe de desenvolvimento, mas quem o financiou e os usuários finais. Minha diferença em relação a Feathers é o foco: o dele é a equipe de desenvolvimento, o meu o usuário final.

Testes são importantes? Não, são vitais pois garantem a malha de segurança para a equipe de desenvolvimento e tudo o mais que todos nós, desenvolvedores, já estamos cançados de saber. No entanto para quem financia são na prática apenas um dialeto desconhecido. No que diz respeito à proximidade dos testes com o cliente final o mais próximo que iremos ter é o BDD mas, convenhamos, o usuário executivo não se interessa tanto assim por eles quanto se interessa pelo sistema final NO MUNDO REAL.

Quão “antiga” é a plataforma de desenvolvimento também não fazem um sistema legado. Prova disto é a imensidão de sistemas feitos em Ruby on Rails, Grails, Spring, .net e outros feitos às pressas como “MVP” que deixam seus patrocinadores desesperados com uma quantidade imensa de bugs a serem resolvidos e evoluções caríssimas. Em contrapartida, temos um verdadeiro universo de sistemas feitos em COBOL, FORTRAN, DELPHI e VB cujas instituições financeiras possuem completo controle sobre si e não podem ser considerados como legado. A diferença entre um e outro? Controle.

Quando evoluo um sistema legado o objetivo final é simples: devolver o controle a quem interessa. Mas como se perde este controle? De imediato as seguintes causas me vêem à mente:

  • Perda de contato com a equipe responsável pelo desenvolvimento do sistema.
  • Complexidade ingerenciada: você mantém a equipe mas esta perdeu o controle sobre a complexidade do sistema devido a problemas arquiteturais.
  • Perda do próprio conhecimento do sistema decorrente de ausência de documentação ou alta rotatividade dos stakeholders envolvidos na confecção original.
  • Aparente perda de controle: sinistro mas já vi acontecer. Ocorre quando alguém diz que o sistema é ruim apenas para justificar sua reescrita sem apresentar fatos concretos. (muito comum, especialmente quando você está buscando consultorias no mercado para evoluir seu legado)
  • Perda do código fonte.
  • Ou qualquer outra ausência do elo que ligava você à idéia original que gerou aquele sistema.

Entenda: simplesmente refatorar uma base de código não restaura o controle ao stakeholder pois ele nos paga essencialmente para não ter de se preocupar com isto. Para o investidor ter novas funcionalidades ou evoluções e adaptações implementadas em um prazo e custo aceitável, em um todo que seja compreensível, isto sim é ter controle sobre um sistema. ISTO é evoluir um legado, ou melhor, atualizar um sistema.

(Sabe aquele sistema que “não serve mais” ou é “obsoleto”? Quando é verdade, você tem controle sobre ele, pois sabe que não mais se aplica. Por isto não considero legado. Nestas situações há consciência de que deve haver um descarte. O máximo de descontrole que pode haver neste caso são pessoas que ainda o usam.)

Concluindo

É sempre a questão de uma boa definição. Claro que outras definições existem e podem até ser melhor que a minha, no entanto o que observo é que raríssimas vezes vejo a palavra chave fundamental, controle, ser aplicada. Se você domina um sistema, não há problema, você sabe como ele pode e deve evoluir. De resto, é o mito do legado como bem descrito no blog do Fabio Akita que citei acima.

PS: uma definição alternativa poderia ser “o que separa o desenvolvedor infantil do aduto”, mas achei que poderia soar um pouco agressiva.

Nota – 7/5/2016

Hoje vejo que minha definição de legado na realidade não o define, mas sim o problema principal que envolve o conceito.

E também vejo que o termo legado sequer deveria ser usado. Explico as razões neste post.

books-pile

Minhas boas leituras de 2014

Este foi meu primeiro ano sem faculdade ou cursos: a perfeita oportunidade para realizar um sonho antigo: ler TUDO o que EU desejasse. O resultado foi bem interessante e é o conteúdo deste post que, sem dúvidas, é um dos que mais gosto de escrever neste blog. :)

Platão

platoPara meu segundo livro (mês que vêm!) optei por um formato bem diferente daquele que os leitores de material técnico estão acostumados (vocês verão). Este formato é influenciado principalmente por Platão, sendo assim, nada mais natural que ele me acompanhasse neste ano, e que companhia!

Já havia lido Platão antes do curso de Filosofia e durante também, mas confesso que nunca me chamou tanto a atenção tal como observo em alguns amigos: não caio na sedução platônica. Já aviso: raríssimas vezes Platão realmente diz algo – é o rei da aporia –  mas seus diálogos quando te pegam de jeito não te soltarão jamais. Foi o que ocorreu comigo. Aqui segue a lista daqueles que me mudaram este ano:

A República – Já a havia lido parcialmente, mas nunca inteira e neste ano cheguei a uns 80%. É fascinante: Platão vai desenvolvendo a ideia do que considera ser um Estado perfeito. É na República em que aparece a alegoria da Caverna (já escrevi sobre ele aqui, mas você pode saber mais a respeito vendo este vídeo), que é o mito fundador da civilização ocidental.

Lendo o modo como Platão vai descrevendo este Estado perfeito não me sai da cabeça aquela sensação de estar assistindo uma partida de Warcraft ou qualquer outro jogo de estratégia. É interessante, e apesar de Platão não chegar a quase nenhuma conclusão, é bacana de se ler, mas não é o que mais me chama a atenção. O que realmente me fascina é o diálogo de Sòcrates com Trasímaco no LIvro I. Trasímaco nos ataca afirmando que a “justiça é a conveniência do mais forte”. Sócrates até tenta provar o contrário, mas se você ler com um pouco mais de atenção, perceberá que a contra-argumentação exposta é bem… furada. :)

Laches – Neste diálogo Platão busca a definição da coragem (ou bravura). O que torna alguém uma pessoa corajosa? Claro: não haverá uma boa resposta, mas o que aprendemos é que a distinção entre o corajoso e o tolo normalmente não é clara. Por que vale à pena ler este texto tão pequeno? Ele te faz repensar aqueles momentos em que você se considerou corajoso e na realidade foi apenas um bobo.

Stephen King!

stephen-kingHouve um diálogo aqui em casa que me levou a ler Stephen King:

<Nanna> – Já leu Stephen King?
<Kico> – Não.
<Nanna> – COMO??? Há uma lacuna em sua formação!
<Kico> – Mas o Stephen King é vivo e faz muito sucesso. Aposto que é ruim Nanna! Deve ser tipo um Romero Britto da literatura!
<Nanna> – Você comeu cocô é?

No dia seguinte vi varios livros de Stephen King arremessados em minha direção. Só digo uma coisa: como fui preconceituoso e tolo! Stephen King foi a maior descoberta literária do ano para mim! Terminava um e iniciava outro quase que imediatamente. Mais do que isto: me fez ver que você pode arquitetar um texto literário. E ei! No meio do caminho ainda escrevi um esboço de romance que será meu quarto livro! Dois livros me marcaram.

carrieCarrie: a estranha – já havia visto o filme original e achava bem bacana, então acabou sendo o primeiro livro de King que li. ORGÁSMICO. Pequeno e profundo. Terminado você perceberá o claro: somos Carrie.

Esperava algo como uma história de terror padrão, mas não! No meio de um parágrafo aparece o próprio autor e começa a dialogar com você, e o modo como notícias de jornal, narrativa, pensamentos de Carrie e o próprio autor alternam entre si mudou radicalmente o modo como eu pensava o próprio ato de escrever. Este livro foi meu assunto principal por MESES.

Ah, e a história? Uma menina sem graça que é zoada na escola ao máximo, mas que tinha poderes telecinéticos e os usará para destruir todos os seus colegas e professores em um baile de formatura. Só isto.

miseryMisery – QUE COISA GENIAL E CRUEL!!! De novo o argumento simples: um autor de romances baratos (tipo Sabrina) que sofre um acidente de carro e é sequestrado por uma fã psicótica que o prende em uma cama e o tortura das piores maneiras. Há um bom filme baseado no livro cujo trailer você pode ver aqui.

Ok, uma história simples, qual a genialidade? A metalinguagem: o protagonista é um escritor? Por que não mostrar o processo criativo envolvido na escrita de um livro? E isto é feito de uma forma muito bacana: você se vê DENTRO do processo criativo, desde sua forma mais tosca até a mais avançada. GENIAL!

(sim, Stephen King atrasou meu livro sobre Grails, mas acho que valeu à pena, pois há “aspectos King” nele)

Literatura técnica

Grails – provavelmente neste ano li todos os livros já publicados sobre o assunto e confesso ter ficado muito decepcionado com o que encontrei. Isto irá gerar um novo post em breve no formato “bibliografia comentada”.

Steve McConnell!

Steve McConnell

Steve McConnell

Um dos livros mais importantes para minha formação foi o “Code Complete” do Steve McConnell. Imagine minha alegria este ano quando, em uma conversa com um amigo, este me indica mais DOIS livros do Steve McConnell? Os dois livros que irei citar podem ser comprados na Amazon para o seu Kindle, que foi o que usei para lê-los. :)

software-project-survival-guideSoftware Project Survival Guide – Uma visão muito pé no chão a respeito do modo como projetos de software devem ser conduzidos. Trata-se de um livro antigo, se não me engano este foi publicado na década de 90, antes de todo o hype envolvendo metodologias ágeis, o que talvez lhe agregue um imenso valor, pois nos mostra alguns aspectos destas metodologias ANTES das mesmas terem se popularizado.

Me fez repensar diversas coisas sobre o modo como eu via a gestão de projetos e também sobre o modo como devo conduzir aqueles que gerencio (2015 promete). São expostas soluções práticas e factíveis para diversos problemas que enfrentamos em nosso dia a dia. Leitura recomendadíssima!

software-estimationSoftware Estimation: demystifying the Black Art – este livro me fez repensar de forma profunda o modo como faço minhas estimativas e, acredito, após sua leitura me tornei muito melhor nesta tarefa.

Vai ser exposta uma visão crítica de alguns métodos de medição e também serão expostos alguns exercícios muito interessantes. Dica: faça-os! Leia com muita atenção este livro, pois finalizada sua leitura você irá adquirir uma bagagem conceitual importante para lidar com este tipo de tarefa e que lhe ajudará demais a lidar melhor com seus clientes e colegas de trabalho.

Minha seleção de uma mina quase infinita de livros técnicos gratuitos!

Este ano descobri um projeto no GitHub fantástico: o Free Programming Books (guarde este link!). Há uma infinidade de livros gratuitos de programação neste site, muitos dos quais são simplesmente fantásticos. Segue abaixo uma pequena seleção.

Software Architecture – A. Bijlsma, B.J. Heeren, E.E. Roubtsova, S. Stuurman –  Este livro é um achado. Trata-se de uma introdução bem superficial à Arquitetura de Software que é usado em alguns cursos de graduação. É bacana para se aprender e transmitir conceitos, e estou indicando para diversos amigos que desejam entrar na área. Link.

Making reliable distributed systems in the presence of software errors – Joe Armstrong (um dos criadores do Erlang) – Neste paper o autor busca responder a pergunta que lhe dá o nome. É uma leitura interessantíssima se você se interessa pela escrita de sistemas REALMENTE robustos e tem alguma curiosidade a respeito do Erlang. E a leitura é bastante tranquila, pois trata-se de uma prosa muito bem escrita. Link.

Guide to Software Engineering Book of Knowledge –  Pense em um PMBOK voltado para o desenvolvimento de software. Soa chato e o texto é chato, mas fornece uma visão global sobre o desenvolvimento de sistemas que tratará de temas pouco falados aqui no Brasil como, por exemplo, economia e manutenção de legados. Vale à pena a leitura pelo menos para abrir um pouco nossa cabeça sobre processo de desenvolvimento. Link.

Manager’s Handbook for Software ManagementNASA –  A NASA tem um altíssimo nível de sucesso no gerenciamento de projetos de software. E ei: já quis saber como a NASA gerencia seus sistemas? Se esta curiosidade já passou pela sua cabeça, o link é este!

Don’t just roll the diceNeil Davidson – Como cobrar pelo seu trabalho? Esta é a pergunta fundamental que o livro tenta responder. É um texto curto mas bastante rico e que cumpre o que promete: me fez repensar bastante o modo como cobro pelo meu trabalho. Link.

Livros gratuitos sobre SQL Server no site da Red Gate!

Neste ano lidei três vezes com projetos nos quais foi adotado o SQL Server. Como meu conhecimento sobre o assunto era mínimo, precisei fazer uma pesquisa a respeito e por sorte topei com um site FENOMENAL com livros gratuitos sobre o tema.

Trata-se do site da empresa Red Gate (o “Don’t just roll the dice” citado acima é deles!), no qual é possível baixar todo este material extremamente bem escrito. Li o livro deles sobre plano de execução do SQL Server e também sobre programação defensiva. Baixe este maravilhoso conteúdo neste link.

Qual linguagem de programação comecei a aprender este ano? FORTH

Uma que provavelmente jamais irei usar e você também não: FORTH! Trata-se de uma linguagem baseada em pilhas e que só vi ser usada uma vez em um sistema de controle de radares. É um exercício interessante para tirar algumas idéias.

A beginner guide to Forth – O nome já diz tudo. Link

Programming Forth – Stephen Pelc – Mais um texto introdutório e bem agradável sobre a linguagem. Link.

Por que quis aprender Forth? Simples curiosidade. :)

A melhor documentação que li este ano: Spring Batch

Vou iniciar um projeto que envolve processamento em lote e na pesquisa que fiz topei com o Spring Batch. Se você se interessa neste tipo de aplicação, a documentação do Spring Batch é leitura obrigatória MESMO QUE VOCÊ NÃO USE O PRODUTO.

Ela expõe a visão arquitetural por trás deste nicho e apresenta alguns erros comuns. É uma leitura muito enriquecedora. Link.

Concluindo

Todo ano espero pelo dia no qual exponho as leituras que mais gostei no período. Espero que tenham gostado desta seleção.

PS: Semana Groovy volta em Janeiro de 2015, assim que eu resolver alguns “problemas adoráveis”. ;)

ridiculously-old-computer

Código legado: um exercício de arqueologia e compaixão

Na esmagadora maioria das vezes que escuto alguém reclamando do fato de estar lidando com código legado me vêm um dos dois pensamentos a seguir : “chorão detected” ou “tá reclamando da coisa errada”. Também não é raro ver software ser jogado fora para ser reescrito do zero e sentir aquela certeza de que irá dar errado e dá. A postura diante do legado é errada. Amo legado e vou te contar as razões.

Minha evolução com o legado

evolution

Quando comecei a programar sequer pensava na possibilidade de lidar com código alheio. Aliás, eu só via código que fosse um exemplo ou outro que usava para aprender por simples cópia. Até que o legado caiu sobre mim e, junto com ele, hoje percebo, uma forte dose de arrogância.

“Arrogância é a confiança excessiva nas próprias habilidades.” – Norberto Bobbio

Olhava  para o código escrito por outros colegas, a maior parte pessoas que não atuavam mais na empresa (e jamais conheci) e os tinha como algo tosco. Me perguntava como a pessoa não sentia vergonha de deixar aquele “legado”. Pegava aquele “trem” e reescrevia do zero. Sentia o triunfo e me orgulhava do feito: expunha aos demais como um troféu que erguia alto para que todos vissem.

(e hoje vejo diversas daquelas mesmas pessoas como heróis)

“Curiosamente” tempos depois eu precisava alterar novamente aquele código que havia reescrito por que “um ponto ou outro não haviam sido levados em consideração”. O tempo passou e hoje fica claro que era um sintoma.

O tempo voa e trabalhei em projetos iniciados e finalizados por mim, apenas iniciados por mim e tantos outros que não foram iniciados por mim. E nesta história bem mais de 50% da minha carreira foi gasto manipulando código que não fui o pai, mas no máximo um padrinho ou tio generoso.

Aos poucos passei a gostar do legado que foi se tornando meu maior professor. Aprendo, cresço e enriqueço hoje graças a ele. Enquanto foi meu adversário eu era símio: hoje que o tenho como parceiro sou “sapiens” (ou penso ser (arrogância?)).

Como o legado se tornou meu parceiro

Percebi o valor do legado quando minha arrogância me socou a cara. Lembra no início deste post quando falei de um “certo sintoma” que ocorria quando eu reescrevia algo do zero? Yeap: eu estava jogando fora conhecimento importante sem me dar conta. Não estava melhorando a criatura, mas piorando-a. E sabem o que é legal? Só caiu a ficha quando o Joel Spolsky “me contou”. Bendito tapa!

Foi quando percebi que eu só olhava para o código e não o lia. Por coincidência na época fazia uma matéria no curso de Filosofia sobre hermenêutica e este acabou me indicando o caminho: não era apenas ler, mas sim interpretar e absorver. Eu devia “absorver como Kico” e “interpretar como quem o escreveu”.

(Quando você acorda para o fato de que mais de 85% da vida do software ocorre depois que é entregue fica nítido que a sua visão de mercado “talvez” fosse bem limitada. :) )

Legado como arqueologia e compaixão

Minha dificuldade ao interpretar o legado estava em meu ego. Por que com tantos SGBDs disponíveis o sujeito tinha de usar JUSTO O MALDITO MICROSOFT ACCESS para aquela aplicação Delphi/VB? Por que tantas classes anônimas naquela aplicação desktop Java? Por que aqueles padrões de projeto tão fora da nossa realidade naquele projeto Java EE?  Te respondo: por que quem escreveu o sistema muito provavelmente (quase 100% de certeza) aprendeu a fazer daquele jeito.  Duvida? Leia algum livro antigo sobre Delphi, Java ou Java EE. Como sei isto? Nas fotos abaixo está uma mínima parcela das “evidências” que acumulo no escritório (e que se um dia Nanna jogar fora teremos uma briga séria).

java_magazines

Revistas antigas valem OURO

pilha_de_ouro

Livros antigos também (e alguns tem diamantes no meio!)

Quando um cliente me procura com um sistema antigo uma das primeiras coisas que me diz é: “acho ele velho, gostaria que fosse reescrito do zero”. Meu primeiro passo é discordar e iniciar o trabalho arqueológico: compro livros publicados na mesma época das tecnologias usadas naquele software, corro atrás de revistas relacionadas, navego por antigos fóruns, artigos, blogs, enfim: inicio um processo de pesquisa profundo, como se fosse um livro.

O objetivo é ter compaixão. O que é compaixão? É o posicionar-se no lugar do outro e com isto entender seu modo de agir. Se conseguir acesso direto ao programador, melhor ainda! Posso saber mais a respeito do seu ambiente de trabalho na época, talvez suas frustrações e como isto influenciou o seu código. Isto me permite inclusive, quando meu ego está fora de alcance, saber se aquela pessoa de fato sabia o que estava fazendo (tem noção da quantidade de pessoas (me incluo) que aprendeu a programar usando arquivos de ajuda?).

Muitas vezes tento construir um ambiente de desenvolvimento próximo ao da época. Consigo isto tendo em casa alguns computadores mais antigos, de preferência com o software daquele tempo. Isto me permite eliminar o risco de estar lidando com incompatibilidades com versões atuais das bibliotecas, sistema operacional (máquinas virtuais valem ouro), etc.

(acredite, quando você se depara com uma máquina cujo HD tem 80 Mb e seu PC 16 Mb de RAM você passa a entender imediatamente o porquê da forma daquele código)

Agora que tenho o modo de pensar e o ferramental da época posso trabalhar com segurança e ver como o software funcionava naquela época.

Como evoluo legado

Com base nestas informações, aí sim altero o código fonte. Se fica nítido que o programador não conhecia a tecnologia, o trabalho fica fácil: consigo melhorar a qualidade apenas aplicando as boas práticas da época. Repare: não vou fazer uma transposição direta para o presente ainda. Chamo esta fase de “restauro” pois não estou evoluindo arquiteturalmente a criatura, mas sim “colando alguns cacos soltos com testes e muita paciência”.

Sim, eu adoro "Mestres da Restauração" que passa no History Channel!

Sim, eu adoro “Mestres da Restauração” que passa no History Channel!

Feitas estas melhorias implemento uma ou outra nova funcionalidade que o cliente queira. Normalmente a produtividade está alta neste ponto pois já conheço a criatura. O processo de upgrade é gradual e nunca direto. Por exemplo: se o sistema é feito em Delphi 3, não vou migrá-lo direto para o Delphi XE. Primeiro passo pelo Delphi 4, depois 5 e por aí vai. (faço muito isto com versões antigas do Grails).  Muitas vezes há recursos da época que não foram usados na aplicação: em alguns casos é quase um upgrade.

(e este processo de upgrade de plataforma muitas vezes é desnecessário. Será que seu sistema em Grails 1.3 precisa realmente do Grails 2.4?)

Se a plataforma tecnológica não é mais suportada (FoxPro, Visual Basic, Clipper, algum framework que “não existe mais”), sei exatamente em qual ponto parar. Daí pra frente precisamos decidir se há de fato algo que possa ser reaproveitado naquele sistema, se é possível encapsulá-lo de alguma forma ou mesmo se a partir daquele momento podemos iniciar um trabalho de reescrita (sempre o último caso) tendo como base a geração de alguma forma de documentação.

Se algo funciona torço para que meu ego não a quebre.

Minha visão de TI graças ao legado

O principal ganho que o legado me trouxe foi uma visão muito mais rica sobre as tecnologias que vejo serem lançadas. É incrível como diversas das coisas que as pessoas hoje bradam como novidade são apenas a reencarnação de algo que funcionou muito bem (ou não) no passado. Virtualização como algo moderno? Na década de 60 o OS/360 já tinha. Execução dinâmica de código? CODASYL previa na década de 50. Manifesto reativo? Olha para os mainframes. E por aí vai…

Você adquire mais pontos para fazer conexões entre as coisas: fica mais fácil assimilar a “novidade” que, na maior parte das vezes é uma nova roupagem ou ponto de vista sobre algo que já foi resolvido no passado e agora estão redescobrindo ou aperfeiçoando.

Não é raro que eu leia sobre tecnologias do passado que provavelmente nunca vou tocar (mainframes, COBOL, Clipper). Não tanto por que eu “adquira mais pontos”, mas sim por que passo a ter um respeito muito maior por aqueles profissionais do passado que com tão “pouco” criaram as bases deste mundo incrível que temos hoje.

(tenho uma imensa lista de heróis entre estes profissionais)

Concluindo?

Espero neste post ter exposto o aspecto positivo do legado que, a meu ver, supera em muito o “negativo”. As reclamações que fazemos ou ouvimos costumam gerar esta imagem terrível de algo que, convenhamos, além de ser um mercado imenso e muito maior que o “green field” também nos fornece uma visão de TI muito mais profunda.

Acredito que  este “mal estar” diante do legado se deva em grande parte à nossa formação. Nas faculdades e cursos técnicos é muito raro termos exercícios que exijam dos alunos interpretar e entender código: na maior parte das vezes você apenas escreve. Talvez se houvesse uma matéria de “arqueologia” ou mesmo hermenêutica a coisa fosse muito diferente.

Também acredito que seja importante saber do que estamos reclamando. Será que é do código legado ou da empresa que não nos permite lidar direito com ele devido a uma má gestão? Será que a reescrita é realmente o melhor caminho sempre? Será que os problemas que temos não é a simples falta de compaixão e nossa pressa exagerada para resolver logo o problema e com isto nos impede de pensar (e aprender)?

Esta é minha visão sobre o legado. Torço para que tenha mudado a opinião de alguém aqui.

PS:

e só pra lembrar: o legado também serve para separar as crianças dos adultos. :)