Category Archives: armadilhas

Quando o comentário realmente documenta o código

Como alguém que lida com muito código fonte que não é de minha autoria, neste post vou listar algumas dicas para tornar seus comentários no código realmente úteis. São hábitos simples que, se bem seguidos, tornam a vida de quem manterá aquele sistema mais fácil e, portanto, aumentam a produtividade de toda a equipe.

Naturalmente, não irei incluir aqui todas as dicas possíveis, razão pela qual no final deste post irei citar algumas boas dicas de leitura sobre este assunto.

Não vou falar do óbvio: “o comentário deve dizer o que aquele método ou classe faz” ou “comentar o óbvio é bobagem” ou “comente apenas o necessário” pois, convenhamos, é chover no molhado ou mero “preenchimento de linguiça”.

Tudo é história

Todo software é gerado dentro de um contexto: a situação da equipe no momento em que foi criado, quem o escreveu, assim como seus conhecimentos naquela época, quais as tecnologias estavam em voga, etc.

Conhecer este contexto é muito importante para compreender as razões pelas quais o código se encontra em sua situação atual. Infelizmente, na esmagadora maioria das vezes em que encontramos o código pela primeira vez só temos conhecimento do seu estado atual se ignorarmos seu histórico no sistema de controle de versões (seja sincero, quantas vezes já percorreu aquele histórico ao ter seu primeiro contato com uma base de código pré-existente?).

Lidando com o passado – reconstruindo o histórico perdido

 

Comentários podem ajudar e muito aqui. Neste momento entra a primeira dica: use um sistema de controle de issues e replique informações deste sistema nos seus comentários. Como fazer isto? Basta mencionar o número da issue em seu comentário. Seguem alguns exemplos:


/*
Classe responsável pelo envio de e-mails no sistema /* (isto é óbvio) */
Issue na qual se encontra documentado o requisito que deu origem ao
requisito: http://meusistemadeissues/issue/825
*/
class EmissorEmail {

É bastante simples: com isto seus comentários não ficam imensos e quem estiver dando manutenção no sistema poderá entender melhor o contexto no qual aquele código foi criado. Um excelente local para se incluir este tipo de comentários é em código no qual você esteja corrigindo um bug, tal como no exemplo abaixo:

int diasEntreDatas(Date dataInicial, Date dataFinal) {
/*
Havia um erro no código abaixo que não considerava sábados e domingos,
gerando resultados inválidos.
Issue: http://seusistemadeversoes/issue/847
Alterado por Henrique Lobo - 1/3/2016 - 14:20
*/
}

Entra a segunda dica: assine seus comentários. Com isto, caso alguém encontre problemas no código que você alterou, poderá lhe procurar para obter maiores informações a respeito daquela situação que, talvez, não se encontrem documentadas no seu sistema de issues ou qualquer outra fonte de documentação.

Mais do que assinar os comentários, creio que também seja muito importante incluir a data e hora no mesmo. Isto contribuí para entender o contexto histórico daquela alteração e muitas vezes agiliza ao extremo a compreensão do problema e aplicação da solução. Esta portanto é minha terceira dica: date seus comentários.

Três dicas simples relacionadas ao histórico que, se aplicadas em conjunto, facilitarão demais a vida de todos:

  • Use um sistema de issues e o referencie em seus comentários
  • Assine seus comentários para que as pessoas possam lhe procurar (quem não tem culpa no cartório não se esconde)
  • Sempre inclua uma data nos seus comentários para saber quando a alteração foi realizada

Lidando com o passado recente

Há também aquelas situações nas quais você fez uma alteração no código mas não se sente 100% seguro a seu respeito, mesmo que tenha escrito testes para validar o comportamento esperado. É normal e te entendo perfeitamente. Nestes casos, não há problema algum em deixar comentada a versão anterior do código apenas para comparação com o que você fez, tal como no exemplo a seguir:


int soma(int x, int y) {
return x + y;
/*
Acho a versão anterior pura frescura, por isto substituí pela
minha alterantiva melhor otimizada e que não usa ifs!
Issue: http://www.meusistemadeissues.com/issue/13
Henrique Lobo - 2/2/2012 - 13:13
return (x > Integer.MAX_VALUE || y > Integer.MAX_VALUE) ? -1 : x + y;
*/
}

Lidando com o futuro (usando lembretes)

Muitas vezes a pressão do dia a dia faz com que precisemos incluir débitos técnicos em nossos sistemas. É normal: no futuro você vai resolver estas questões (se se lembrar delas).

A maior parte das IDEs hoje, além de sistemas de análise estática de código como o SonarQube oferecem suporte a um tipo especial de comentário: o “TODO”. Nunca o viu? É simples: vamos a um exemplo rápido e completamente fora da realidade.


boolean autenticar(String login, String senha) {

/*
TODO: meu gerente me obrigou a isto para o release 1.0.0 do sistema
Henrique Lobo - 12/3/2004 12:00
Issue: http://www.meusistemadeissues.com.br/issues/666
*/
if (login == "dede") {
return true;
}
}

Comentários do tipo TODO mostram pontos a serem melhorados no sistema. Na imagem abaixo podemos ver um exemplo do uso deste tipo de comentário no Eclipse (práticamente todas as IDEs possuem este recurso atualmente):

todo_eclipse

Mesmo que você não se lembre de ter feito o que estava no comentário, alguém do futuro saberá a respeito e poderá fazer algo a respeito.

Refatorando comentários?

Se você usa um sistema de controle de issues e assina e data seus comentários, passado algum tempo você talvez precise refatorá-los. Como assim?

De duas maneiras: você pode excluir aqueles comentários que envolvam código antigo (pois o tempo já mostrou que as alterações realizadas funcionaram) ou você pode simplesmente remover aqueles comentários que não agregam coisa alguma.

Resumindo: de tempos em tempos é uma boa prática apagar os comentários inúteis. Lembre que você tem o sistema de controle de versões e nele já está presente todo o histórico de alterações.

Não divulgue segredos

Parece estranho o que vou dizer, mas seu comentário pode expor segredos relativos à sua empresa ou contratante. Apesar de ter mencionado no início deste post que não iria mencionar o óbvio, me assusta a quantidade de informações sigilosas que programadores publicam em seus comentários. Alguns exemplos:

  • Credenciais de acesso a serviços ou servidores
  • “Recados” a outros membros da equipe – “Kico, resolva isto depois, ok?”
  • Críticas ao empregador ou outros membros da equipe
  • Críticas à natureza do próprio código fonte (isto você documenta como débito técnico no sistema de issues normalmente)

Quer um bom exemplo histórico? Algum tempo atrás vazou o código fonte do Windows 2000. Que tal ler o que a mídia da época comentou a respeito?

Lembre que remover commits do sistema de controle de versões não é uma tarefa trivial.

Boas leituras

Há dois livros muito bons que possuem capítulos dedicados aos comentários em código fonte:

Code Complete – Steve McConnell – Editora Microsoft (diga-se de passagem, o melhor livro que já li sobre programação em geral, leitura obrigatória) – Traduzido para o português pela editora Bookman

Clean Code – Robert C. Martin – Editora Prentice Hall – Traduzido para o português pela editora Alta Books

As duas traduções são muito boas e ambos são leitura obrigatória apesar da minha preferência pelo primeiro.

Concluindo

Não creio naquela história de que “a documentação do meu sistema é meu código”, no entanto, se for o caso, pelo menos bons comentários irão lhe ajudar na manutenção futura deste sistema.

Sobre minhas críticas ao “código como única documentação”, provávelmente será meu próximo post neste blog (ou quando encontrar uma forma mais polida de lidar com este assunto). :)

“Legado” é um termo maldito

O termo “legado”, quando aplicado a software sempre me incomodou: tanto que algum tempo atrás busquei uma melhor definição para esta palavra dentro do nosso contexto de TI. Hoje volto ao assunto para dizer que não uso mais a palavra “legado” com meus clientes e colegas e explico minhas razões.

O termo que todo mundo busca a definição (inclusive eu)

Fui um dos palestrantes da trilha de legados da QCon Rio 2015 e, para minha sorte (ou azar), fui o último a falar, o que me permitiu assistir a todas as apresentações sobre o assunto. O que achei interessante é que quase todos (inclusive eu) apresentaram seu próprio conceito de legado.

(e neste texto ainda apresento mais definições sobre legado, o que mostra ser um fenômeno global, e não uma particularidade daquele evento)

Claramente há algo errado aqui: se dentro de um contexto bem definido (ou ao menos aparentemente) há tantas definições para uma mesma palavra, surgem duas possibilidades:

a) A palavra não possuí um significado real
b) Devíamos ou categorizar este termo ou mesmo buscar outras palavras

A  má impressão criada pela nossa indústria

Diversas vezes um cliente chega para nós pedindo que executemos manutenções ou evolução em seus sistemas com frases do tipo: “temos este sistema legado, que me disseram ser velho e ultrapassado, mas não tenho dinheiro para reescrever do zero”.

Lendo o código fonte observo que foram usadas tecnologias como Spring BootGrailsPHP, JavaScript, JSF ou qualquer outra que é ativamente desenvolvida hoje. Pior ainda: o sistema tem no máximo 5 anos de idade. Não poderia ser categorizado como “velho”, e levando-se em conta que normalmente está em uso, muito menos “ultrapassado” ou “obsoleto”, pois claramente está satisfazendo objetivos de negócio ali.

Fato é que muitas consultorias e profissionais normalmente ao invés de venderem a evolução do sistema preferem a reescrita por dizerem dar menos trabalho e sair mais barato (o que normalmente  é uma grande mentira e ainda escreverei sobre isto, mas enquanto isto, pode ler este excelente texto do Joel Spolsky).

A situação é ainda pior: já vi apresentações sobre “legados” na qual o palestrante usa o termo “evolução” e apresenta uma completa reescrita como resultado (atualmente uma das formas que esta reescrita vêm disfarçada é como micro-serviços).

Resultado: o termo “legado”, que deveria ter uma conotação positiva (conhecimento e experiência adquirida ao longo do tempo, conquista, satisfação por ter construído algo que é passado pra frente) passa a ser visto por muitos como um defeito.

(não creio que a maior parte dos profissionais e consultorias que vendam a reescrita imediata sejam mal intencionados. Na minha opinião o problema surge da nossa formação. Um dia ainda escreverei sobre isto)

Que termo uso agora

O mais óbvio e tedioso:  “software que você já tem” ou “software pré-existente” ou, ainda “software que não escrevi” ou algo similar pelas seguintes razões:

a) O cliente (que é quem realmente importa) entende o que estou dizendo imediatamente
b) Muitos clientes nunca ouviram o termo “legado”, o que evita a necessidade de explicar uma palavra que creio ser tão mal empregada em nosso idioma
c) Me fornece (e à indústria) um ponto inicial que possibilite uma melhor criação de sub-categorias que auxiliam na definição de estratégias

Sobre categorização

O termo “software que você já tem” é elementar: não consigo pensar em uma categoria superior a este (“software”, talvez :D) , mas consigo pensar em “tipos de software que você tem”. Segue uma pequena lista:

  • Aquele que temos o código fonte
  • Aquele que não temos o código fonte (sim, acontece e muito)
  • Aquele que é parte de sua infraestrutura (SGBD, Sistema Operacional, protocolos de rede)
  • Ou outra categorização qualquer que represente o nível de posse do cliente sobre um software

E esta categorização nos ajuda a pensar melhor o “seu software“. Ao analisar a situação do cliente (a mais importante), a comunicação fica mais simples e direta. É curioso que nas apresentações que vejo sobre legados só escuto sobre a primeira categoria: “aquele que temos o código fonte”. Aonde ele é executado? Como é o ambiente que o rodeia?

(é interessante notar que as pessoas confundem “legado” e refatoração, e esta é minha prinicpal crítica ao livro do Feathers – legado não é só o código)

A partir do momento em que um termo mais simples é usado na conversa, tudo flui, impressionante.

Minha antiga definição de “legado” não era uma definição

Ano passado busquei uma definição de legado e eis a que cheguei:

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

Leia atentamente o que acabei de escrever: isto é uma definição? Hoje creio que não, pois não defini um termo, mas sim o problema fundamental do seu software.

O que é legado? Em português (e pensando no contexto brasileiro) é um termo que causa mais confusão que o necessário, haja visto os pontos que expus. Sendo assim, não irei mais me preocupar com a sua definição ou mesmo seu uso.

(ainda escrevo sobre um possível hype envolvendo este assunto (hype este que não se desenvolverá de forma saudável devido às falhas em nossa formação que comentei em parênteses anteriores))

Meu problema com a infantilização

Tratar adultos como crianças, especialmente desenvolvedores, sempre me irritou. Algum tempo atrás inclusive escrevi sobre isto aqui no blog. O foco da minha opinião é o desperdício de algo fundamental: o processo de amadurecimento.

Vejo de forma muito clara este processo infantilizador se manifestando em vagas de emprego que buscam “padawans”, “jedis”, “super-heróis”, “rockstars” (vergonha alheia infinita). Isto sem mencionar grande parte da cultura “geek” que, devo confessar, não raro vejo carregada de fortíssimo caráter infantilizador. Isto sem mencionar “apresentadores” e “palestrantes” que se vestem como crianças. Nossa, quanta vergonha alheia!

Mas o que é amadurecer?

Para mim envolve a expansão intelectual. Vou partir de um exemplo banal. Ao encontrar alguém usando um chapéu de Mario e lhe pergunto por que o está usando. Normalmente a resposta é um “por que é legal”.

Por que o chapéu?  Por que é legal!

Por que o chapéu?
Por que é legal!

Esta é uma resposta válida, mas se forçar a barra e perguntar “por que é legal?”, não raro o indivíduo infantilizado não vai saber responder. Resumindo: a futilidade (um aspecto infantil resultante de uma percepção limitada) está se manifestando. Lhe interessa o ato de fazer graça. Então, como seria uma resposta adulta?

(já se perguntou por que, na sociedade ocidental na qual o riso é visto com desprezo, de repente ser uma pessoa “divertida e engraçada” passa a ser visto como algo super positivo? Dica de leitura)

“O que envolve o conceito do Mario é interessante e me agrada”. Me lembro quando era pré-adolescente e vi o Mario Bros pela primeira vez. Algo completamente diferente de todos os jogos que havia jogado até aquele momento: o cenário era muito rico e toda a mecânica era algo revolucionário para nós.

free_download_super_mario_bro_game

O que me impressionava era o puramente sensório: a experiência de controlar o Mario e todas aqueles elementos secretos no jogo eram algo fascinante para alguém com 12, 13 anos (muitas cores e surpresas, além de uma música top). A coisa ficou realmente interessante quando notei uma similaridade naquele jogo com algo que já conhecia.

smb3_mush2

Aquela história do Mario comer um cogumelo e de repente crescer. Já havia visto isto em algum lugar: em Alice no País das Maravilhas, mas ao contrário. Ela encolhia.

alice-on-mushroom-3

Caramba! E de repente, observando as ilustrações do livro de Lewis Carroll, conseguia ver no cenário que se movia do Mario elementos daquela história (Mario era um ser diminuto entre cogumelos?). Isto ampliou meus horizontes  e me fez começar a questionar outras coisas: quem criou o Mario? Foi a Nintendo. Mas quem dentro da Nintendo teve esta ideia? Foi o Myiamoto. Quem é ele? O que inspirou este sujeito?

Mario -> Alice no País das Maravilhas -> Nintendo -> Miyamoto -> Lewis Carroll -> Problemas lógicos -> Matemática

A rede cultural se expande: vejo mais pontos e ligações entre eles. Questiono estes relacionamentos e busco confirmações a seu respeito. Resumindo: saio de algo simples e  fútil:  termino em um universo totalmente novo que não para de se expandir conforme interajo com ele.

A pergunta “por que você usa este chapéu de Mario?” adquiriu profundidade. E neste processo de amadurecimento noto que até minha capacidade em aceitar críticas foi ampliada: ao ver um número maior de possibilidades no mundo, são grandes as chances de eu realmente estar errado e existirem alternativas muito superiores. Resumindo: eu venço outra barreira infantil que é a do solipsismo. Estou em um mundo rico com o qual interajo.

Amadurecer é bom e a vida adulta é maravilhosa. O adulto tende a ser sábio, ao contrário da criança. Então, o que ganho ao infantilizar? Para responder a esta pergunta, é importante responder outra: como é ser uma criança?

(algo fascinante: vejo esta “expansão intelectual” em praticamente tudo, basta tentar)

Como é ser criança?

Odiava ser criança. Brincar era legal, não havia trabalho (meus pais me mantinham), mas nem por isto meus problemas eram menores. Há adultos que te controlam e definem o que deve ser feito. Além disto, o mundo é assustador pois você não o conhece direito por ter uma visão limitada da realidade.

E justamente por ter uma visão limitada a criança se vê a mercê do adulto a quem deve obedecer de forma compulsória. O medo do desconhecido faz com que a criança se torne um ser quase solipsista, que vive em um mundo apenas seu, mas controlado por forças desconhecidas.

Seus problemas também não são tão menores como pensamos: basta se lembrar dos medos  que sentia ao se imaginar levando bomba na escola ou na possibilidade de perder seus pais, quem cuidaria de você? E se seus pais não fossem tão legais assim? E se você fosse adotado? Existem monstros no escuro?  Os medos da infância parecem tolos hoje que somos adultos, mas na época eram aterrorizadores.

Verdade seja dita: romantizamos a infância. Além da vulnerabilidade e dependência em relação aos adultos, sabe o que mais a “boa criança” costuma ser? Dócil. Afinal de contas, uma “criança boazinha”, tal como somos criados, é aquela que recebe “presentes do Papai Noel”, é aquele ser que não questionaque obedece.

Pra que infantilizar então?

Essencialmente por que você quer ter um controle maior sobre o outro, que não desejamos vir a se tornar um questionador. E que te admire, pois você estará, em relação ao infantilizado, como o adulto em relação à criança.

É curioso como em diversos casos de infantilização que observo os manda-chuva são pessoas extremamente adultas, formais, exemplares. Já notou isto?

E por que o fútil é tão valorizado? O que faz da fábrica de doces algo sedutor? Ela faz com que o adulto se esqueça dos problemas relativos ao seu amadurecimento. Você afunda o adulto em tolices para que ele se torne dócil.

Por que uma biblioteca de quadrinhos e não clássicos ou grandes livros? Por que os segundos são “chatos”? O que os torna chatos ou, ainda melhor, “quem” os vende como tal?

Por que me incomoda então?

Por que ao diminuir o indivíduo, termina por lotar de tolos o mundo. Confesso sentir calafrios ao pensar na formação de futuras gerações. Será este medo o resultado do meu envelhecer? Talvez.

Me incomoda muito pensar que as pessoas, em sua carência, acabam por se colocarem em uma posição inferior sem a menor necessidade.

Devo ser uma pessoa séria sempre então? Não: só tem de evitar se tornar um “retardado”.
(já notou que normalmente quem se da bem possuí uma forte tonalidade séria?)

PS:

controvérsias sobre a relação entre o Mario e Alice no País das Maravilhas, no entanto o simples fato de podermos fazer a conexão por conta própria já me parece algo incrível.

PS 2:

Sou contra o “trabalho infantil” :D

Meu problema com aplicativos de taxi (e as soluções)

Dentro do carro pela segunda vez minha esposa avisou o motorista que ele havia tomado o caminho errado. O carro acelera bruscamente, freia e para no acostamento.

_ Já que está tão ruim desçam do carro agora!

Em choque saímos do veículo (eu, minha esposa e uma amiga), mas a história não termina aí. O motorista também sai do carro, saca uma carteira da polícia e grita em nossa direção:

_ Vocês não estão lidando com qualquer um: vejam quem sou!

Percebo o motorista com algo estranho na outra mão, que está próxima da parte de trás do seu cinto. Por estar assustado temo ser uma arma e, para defender minha esposa e nossa amiga, parto em direção do sujeito aos gritos e este se acovarda, volta para dentro do veículo e parte para “atender” outros azarados passageiros.

Lendo as notícias recentes talvez em um primeiro momento você creia se tratar de um taxista “convencional”, certo? Errado.

Meu histórico recente

Pelo menos duas vezes por dia pego algum taxi (tradicional ou não). Estatísticamente a possibilidade de algo dar errado comigo é muito grande e, de fato, ocorre com frequência. Apenas algumas das situações pelas quais passei nos últimos seis meses:

  • Chamo um taxi, no aplicativo aparece um motorista e, quando o carro chega, é outra pessoa completamente diferente (inclusive há casos nos quais ao negar a corrida fui ameaçado de porrada)
  • Motoristas malucos que não respeitam um sinal qualquer e andam a 100 por hora
  • Um motorista louco que joga seu carro contra um carro do Uber
  • Gente que nega me devolver troco e faz um cavalo de pau comigo dentro
  • Um motorista que joga seu carro contra um ônibus por que “estava estressado”
  • Um motorista que quer “dar um susto” em seu colega e quase bate o veículo comigo dentro

A lista é longa e já virou até piada entre meus amigos. Não sei se ocorre com outros consumidores com perfil similar ao meu, mas ao menos comigo, em Belo Horizonte, ocorre bastante.

E agora o detalhe curioso: 100% dos incidentes que tive se iniciaram usando um aplicativo de transporte. O melhor serviço de transporte que uso é o ponto de taxi perto da minha casa, para o qual ligo pedindo um carro.

Dado que vou continuar usando estes serviços (não tenho escolha (por enquanto)), resolvi escrever este post pra ver se os responsáveis pelos aplicativos ouvem minhas reclamações (que agora estou tornando públicas) e sugestões.

A grande falha e minhas sugestões

Muitos destes aplicativos dizem que filtram os motoristas que os usam, no entanto com absolutamente TODOS que usei passei por algum inconveniente que colocou minha integridade em risco.

Todos dizem oferecer excelente suporte ao passageiro caso algo dê errado: você pode, por exemplo, dar nota a um motorista. Pode também entrar em contato com os responsáveis pelo aplicativo reportando o acontecimento, o que é ótimo. Alguns até te respondem!

Aí entra a falha: eu devo poder reportar que algo está errado não depois do incidente, mas sim antesdurante.

Se chamo um taxista e vêm outro, naquele momento devo alertar a operadora do ocorrido. Na maioria dos aplicativos, o máximo que posso fazer é cancelar a viagem. O problema é que este cancelamento ocorre com o “falso motorista” diante de mim. Resultado? Minha segurança agora está em risco e você muitas vezes se vê coagido a participar de uma viagem com alguém que não foi chamado.

(será que a nota que vejo do motorista é realmente a dele ou de outro que veio atender em seu lugar?)

Primeira sugestão: poder reclamar antes da viagem ocorrer

Todo aplicativo deveria ter esta funcionalidade: se não gostei do motorista ou se veio outra pessoa, naquele momento devo alertar os responsáveis pelo aplicativo, não depois.

Estou falando isto como usuário do Windows Phone, talvez para Android seja diferente. Falando nisto…

Segunda sugestão: a segurança do passageiro não deve depender do sistema operacional do seu telefone

Se você oferece um aplicativo de transporte, está lidando com a segurança dos seus usuários. E parte da segurança vêm justamente do modo como o usuário interage com o aplicativo.

O único aplicativo de taxi que usei e possuí qualidade para usuários Windows Phone é o Way Taxi. Tirando ele, os demais simplesmente fedem.

Lançar versões inferiores de um aplicativo que pode colocar os seus usuários em risco para outras plataformas só por que possuem menos usuários. Tenho um nome adequado para esta postura: irresponsabilidade.

Sugestão? Se vão lançar uma versão inferior para uma plataforma, não lancem.

Terceira sugestão: botão de pânico durante a viagem

O motorista pode causar uma boa primeira impressão e por sua vida em risco durante o trajeto. Logo, durante a viagem eu, como passageiro, devo poder notificar a operadora dos perigos que eu possa estar correndo E devo ser atendido prontamente.

Com isto posso atuar também durante a viagem.

Quarta sugestão: seguro

Talvez isto seja feito, mas nunca vi ser divulgado. Se pego um carro usando um aplicativo, e um acidente ocorra comigo motivado por imprudência do motorista, quem me cobre?

Se você oferece serviço de transporte, por que não mostrar que confia em seus motoristas também?

(dúvida: será que eu, enquanto consumidor, se sofrer algum acidente durante o percurso devido à imprudência do motorista que contratei pelo aplicativo, posso processar a empresa que mantém o serviço?)

Quinta sugestão: uma central de atendimento POR TELEFONE

O incidente ocorreu e você busca as opções de feedback no aplicativo: você está tenso, não consegue achar e, às vezes, realmente não existe. Por que não há um número de telefone de fácil acesso nestes programas???

Se houvesse um número e você pudesse ligar para uma central, que te fornecesse um número de protocolo ou qualquer coisa, a situação seria muito mais fácil. Falar é mais fácil que digitar, sabiam?

Lembram o incidente que mencionei no início deste post? Só pude reportar a operadora em casa, pois não encontrei a funcionalidade no aplicativo pra Windows Phone. Neste meio tempo o indivíduo estava atendendo outras pessoas pela cidade e as pondo em risco.

As antigas “centrais de taxi” tinham isto. Por que os aplicativos não podem ter também?

E mais: dado que vou ligar para reclamar por que algo está muito errado, não devo pagar por isto. Éticamente o correto é ser uma ligação gratuita.

O dia seguinte…

A operadora “prontamente” me respondeu três dias depois e, para não perder o cliente, me ofereceu R$ 20,00 de crédito. Bacana saber o preço da minha segurança, lhes disse que não queria o dinheiro mas mesmo assim o incluíram na próxima viagem que fiz com eles.

Por que fiz a próxima viagem? Me prometeram que nunca mais pegaria uma viagem com aquele motorista, idem minha esposa e minha amiga. Ok: parece justo, dei azar naquele trajeto. Não ocorrerá novamente: afinal de contas, todos dizem que este é o melhor serviço de transporte do país e que possuí o melhor atendimento, certo?

Algumas semanas depois…

Pela manhã minha esposa pede um carro pelo aplicativo. É o mesmo motorista. Ela cancela a viagem.

Então eu peço mais uma viagem com o mesmo aplicativo: o mesmo motorista, que devia estar perto de nós. Mas notei um detalhe escabroso: sua avaliação era de 4.8 estrelas (em 5).

Entrei em contato com a operadora, mas ela ainda não me respondeu.

Meu problema com micro-serviços

Micro-serviços em sua essência são mais uma estratégia de componentização e, sinceramente, acho muito difícil criticar qualquer tentativa de se chegar a este objetivo. Gosto muito da estratégia, mas algo “nela” me incomoda bastante. Sabe o quê? A maneira como muitas vezes a vejo ser vendida.

Neste post exponho algumas falácias que vejo repetidas vezes em apresentações e posts. Acredito que seja um esforço fundamental pois a desonestidade intelectual (muitas vezes acidental) dos defensores de qualquer posição comprometem significativamente aqueles que, iludidos, adotam equivocadamente aquilo que lhes foi transmitido. Sendo assim, vamos às falácias.

Uma aplicação monolítica é uma coisa, e uma mal feita, outra

Aplicações monolíticas não são bugs e a prova é a quantidade imensa de casos de sucesso acumulados ao longo da história da computação: temos mais de meio século de experiência em arquiteturas deste tipo. Negar este passado é loucura ou desonestidade intelectual (para dizer o mínimo).

O que esquecem de mencionar aqueles que defendem este ponto de vista  é que sempre há uma medida. Se o sistema for excessivamente extenso, naturalmente este será dividido em unidades fisicamente independentes. Esta divisão ocorrerá de forma evolutiva ou mesmo durante o processo arquitetural.

Reparem que usei a palavra extenso e não complexo. Complexidade independe do tamanho da aplicação e pode ocorrer tanto em pequenas aplicações de linha de comando quanto micro-serviços quanto aplicações monolíticas.

Bons argumentos em defesa de aplicações monolíticas você encontra neste post (leitura obrigatória). Outra leitura muito interessante sobre a estratégia monolítica encontramos neste texto do Chris Richardson, que inclusive expõe alguns pontos negativos.

E, bom: que tal irmos direto pra fonte e citar o Martin Fowler que foi um dos primeiros a escrever sobre o assunto e um dos principais responsáveis pela sua popularização:

não perca tempo considerando micro-serviços, a não ser que você tenha um sistema muito complexo para ser gerenciado como um monolito (tradução minha)

Esta dicotomia monolitos/micro-serviços é em si muito pobre. Sinto muita falta em apresentações de comparativos entre micro-serviços e outras estratégias de componentização que são simplesmente ignoradas.

A falsa novidade

Hoje para mim fica claro que micro-serviços não são uma novidade apesar de serem vendidos como tal. Os vejo como uma visão diferente do SOA. Um excelente texto sobre isto é este do Steve Jones. Também escrevi sobre isto, mas meu texto não é tão bom quanto o dele.

Historicamente é mais uma tentativa de componentização através de computação distribuída. Já vimos isto com o EJB, SOAP, CORBA, RPC, DCOM, OSGi, XDR e tantas outras tecnologias que vieram antes.

Em todas estas abordagens você tinha os pontos abaixo com graus variados de dificuldade na obtenção dos objetivos:

  • Processamento distribuído
  • A tentativa de se ter independência tecnológica (DCOM, EJB e OSGi conseguem isto através de algumas gambiarras estratégais)
  • Estratégias para se lidar com a ausência de um ou mais componentes externos
  • Monitoramento

Talvez a novidade seja o ponto de vista muito influenciado pela emergência da cloud (Larry Elison tinha um ponto de vista interessante sobre a nuvem apesar de muito criticado) que viabiliza economicamente a estratégia.

(quando você estuda a história da computação, novidades vão se tornando cada vez mais raras, e fica muito nítido que esporadicamente nos vendem o velho com um novo nome)

A velha falácia do espantalho

Aqui entra a desonestidade intelectual em sua forma mais pura. São apresentados exemplos absurdos envolvendo arquiteturas monolíticas: coisas que apenas um completo imbecil faria e que não fazem parte do cotidiano de praticamente ninguém.

Alguns exemplos: “usar um servidor de aplicações pesadíssimo para hospedar uma aplicação mínima”, “uma aplicação monolítica contendo altíssimo acoplamento entre seus componentes” (o que  ocorre em sistemas de qualquer escala). Na Wikipedia tem um texto legal sobre isto.

São argumentos que distorcem grotescamente o argumento do outro visando com isto ridicularizar o “oponente” diante dos demais.

Me lembram muito aquelas propagandas exageradas que passam de madrugada na TV, como… estas:

Normalmente desconfio de argumentos que tem como base a presença de alguém que não possua um cérebro fazendo bobagem.

A solução perfeita

Você questiona pelos custos da abordagem (seu lado feio) e simplesmente não obtém resposta. Ou então obtém uma resposta como “na realidade, escrever aplicações monolíticas é que é errado”.

Sério que existe uma solução perfeita e esta se chama micro-serviço? Sério que alguém realmente acredita nisto? Obviamente há custos envolvidos que não podem ser negados: você está lidando com  uma solução distribuída, e todas as dificuldades que envolvem este modelo se manifestam aqui. Quer uma lista rápida? Vamos lá:

  • Latência de rede
  • A possibilidade da falha de uma dependência remota
  • O custo do próprio protocolo que nem sempre é feito para se obter máximo desempenho (HTTP, JSON, XML)
  • A necessidade de um monitoramento mais forte
  • A necessidade de se ter um componente de descoberta de endpoints

E aqui ainda não mencionei os custos relacionados às mudanças culturais que sua equipe deverá passar, ou mesmo das complexidades envolvidas quando se possuí um ambiente tecnologicamente heterogêneo dentro de uma instituição.

Negar os custos é  desonesto. E uma desonestidade maior ainda quando te dizem que estes problemas podem ser minimizados usando-se uma solução que você vende.

Aliás, é mais que desonesto: é irresponsável.

Uma visão muito ingênua de escalabilidade

Você realmente acredita que basta incluir mais instâncias do seu micro-serviço para que ele escale? Escalabilidade vai muito além disto. Envolve arquitetura, boa qualidade de código, boas estratégias de otimização.

Escalabilidade vertical é realmente tão limitada assim? Qual o contexto? É curioso: esta palavra essencial, contexto, simplesmente não é mencionada. Por falar nisto…

A ausência de contextos

Nunca vi uma estratégia que, em si, seja ruim. Agora: uma estratégia no contexto errado, sim. Algo que sempre me surpreende em apresentações ruins sobre micro-serviços é o quão negligenciado este ponto é.

Se seu cliente possuí uma forte limitação de infraestrutura, será que micro-serviços realmente são uma boa opção? E se sua equipe não se adequa à aplicação dos micro-serviços? Sua equipe que é ruim ou você que é um tirano?

Se não me mostrar o contexto, a conversa acaba ali. É simples assim e não há muito o que dizer a este respeito.

Concluindo

Micro-serviços são uma estratégia interessantíssima, mas infelizmente correm o risco de serem vistos em breve como uma falácia devido ao modo como é descrita. Este post é quase uma continuação de algo que escrevi recentemente sobre palestrantes e acredito que seja um bom exemplo do que quis dizer naquele momento.

Caso se interesse pelo que penso sobre micro-serviços, tenho dois posts neste blog sobre o assunto que podem ser lidos aqui e aqui.

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.