DEV Community: Henrique Lobo Weissmann (Kico)

Meus primeiros passos com Go (inclui bibliografia comentada)

Henrique Lobo Weissmann (Kico) — Mon, 02 Oct 2023 10:34:54 +0000

Fiz uma imersão em Go e neste post compartilho com vocês minhas primeiras impressões. Aproveito e também exponho meu plano de estudos que talvez ajude quem estiver dando seus primeiros passos na linguagem.

Já adianto: por que não fiz esta imersão antes???

Neste post há minhas primeiras impressões : leia da forma mais crítica possível, ok?

Meus objetivos

A plataforma Java não sai de mim e dificilmente sairá, mas há alguns requisitos para os quais ela ainda não é ideal quando precisamos implementar soluções que sejam:

Nativas para realizar integrações de mais baixo nível.
De rápida inicialização (para lambda functions, por exemplo).
Baixíssimo consumo de memória e recursos computacionais.
Baseadas em linha de comando (para tooling em alguns de nossos projetos).
Que possa ser compiladas para diferentes plataformas (embarcados é um plus interessante aqui).
Se for possível implementar APIs baseadas em HTTP, ótimo (é um plus).

Todos os pontos acima consigo hoje na plataforma Java (especialmente após o GraalVM), mas não é natural na plataforma ainda. Então nestes casos buscamos alternativas, dentre as quais uma que se mostrou bastante interessante foi Rust (escrevi a respeito aqui). É impossível não fazer comparações com ela neste post.

Meu plano de estudos

Comecei a imersão definindo os objetivos que me permitiram ter uma visão prática de Go:

O primeiro é escrever uma ferramenta de linha de comando que seja realmente útil para mim. Então criei uma que gera arquivos no formato JSON tendo como entrada algumas planilhas que uso em meu dia a dia.
O segundo foi escrever uma API REST usando como base de dados os arquivos gerados pelo primeiro projeto.

Com isto o primeiro objetivo me forneceu a segurança que eu precisaria para poder sair do core da linguagem e, assim, experimentar frameworks e bibliotecas mantidas pela comunidade e assim sentir (friso o termo “sentir” pois são primeiras impressões ainda) como as pessoas lidam com este ecossistema.

Planejo meus estudos com minha própria metodologia que pode ser lida neste link.

Bibliografia rápida e comentada

Optei por focar na documentação oficial para começar, clicando sobre o link “Learn” do site oficial (https://go.dev). Aqui você verá as três opções expostas no print abaixo:

Meu erro foi ter começado pela documentação (Documentation) e não pelo tour (Tour of Go). Se estiver tendo seu primeiro contato sugiro começar pelo Tour.

Começando pelo Tour of Go – https://go.dev/tour

Tem a profundidade de uma moeda mas te prepara para dar os primeiros passos na linguagem pois ao contrário da documentação oficial, é linear. É um destes tutoriais interativos nos quais há uma explicação do lado esquerdo e código para você experimentar do lado direito.

Em aproximadamente uma hora (no máximo duas se você estiver brincando com a linguagem no processo). Recomendo que você faça inteiro (preferencialmente experimentando ao máximo).

Há tradução para o Português do Brasil, mas se você sabe inglês recomendo que evite esta tradução pois encontrei algumas coisas como as expostas nos prints abaixo:

pode “close”?

segmento significa “thread”?

Caminho alternativo ao Tour of Go – vídeo

Não gosto de vídeos para estes primeiros contatos com linguagens mas a documentação oficial indica este vídeo (em inglês) cheio de chavões (musiquinha feliz, introdução enche linguiça…) que talvez possa te ajudar. Não é ruim, mas pessoalmente não gosto (me falta paciência).

Indo para a documentação oficial – https://go.dev/doc/

Após ter seguido os tutorias básicos (ao menos o interativo) a documentação oficial fornece o aprofundamento que precisava para poder entender os detalhes da linguagem que farão toda a diferença. Seguem aqui então os links da documentação que mais me ajudaram.

Um dos pontos fotes do Go é o modo como lida com concorrência. Dado que este é apenas seu primeiro contato e os projetos iniciais são bem simples, não irei tocar nestes assuntos (busque por “goroutines” ;) ).

O básico sobre módulos

Se você vêm do Java ou .net o conceito de pacotes do Go pode te parecer confuso: não por ser complexo, mas por ser simples. Então leia estes dois links na sequência:

Tutorial: getting started – é um Hello World que vai ser usado adiante, faça só pra treinar.
Tutorial: Create a Go Module – você vai criar seu primeiro módulo
Getting started with multi-module workspaces – você definitivamente vai sentir falta de não conhecer o conceito de workspaces do Go quando for implementar seus projetos maiores (sofri um pouco com isto), então preste muita atenção neste link.

Organizando seu código

Você que vêm do Java vai sentir saudades do Maven em seu primeiro contato. Ao escrever sua primeira aplicação que envolva mais de um arquivo esta saudade irá apertar. Este link (How to Write Go Code) te ensina como seu código fonte deve estar organizado e também tornará mais clara a distinção entre módulo (module) e pacote (package). (um módulo contém pacotes ;) )

Outro link que vai ajudar é este: Organizing a Go module.

Effective Go e FAQ

Vai te ajudar bastante também conhecer as convenções adotadas pela linguagem. O link “Effective Go” me ajudou a responder diversas dúvidas simples mas que podem tomar bastante seu tempo, tais como: quando uso ponto e vírgula? Como lido com erros? E estas funções que retornam mais de um valor como resultado?

O FAQ também tem coisas úteis. Não acho que você deva lê-lo de cabo a rabo, mas pelo menos dar uma passada de olhos pelo índice já ajuda a descobrir dúvidas que você ainda não sabe que tem.

Biblioteca padrão – https://pkg.go.dev/std

Em diversos momentos você lerá na documentação que a biblioteca padrão é bastante rica e bla bla bla. Então é interessante ver os módulos que compõem a biblioteca pra se ter uma noção do que de fato está ali. E tem coisas muito legais , tais como funções para se gerar HTML, JSON, funções de hash, logging, testes, etc.

Fica bem claro que é possível, por exemplo, escrever uma aplicação web sem um framework externo.

Material para desenvolvimento web

Até este momento tudo o que expus satisfaz o primeiro objetivo do meu plano de estudos. Para o segundo objetivo (a API REST) segue aqui algum material com avisos.

Frameworks

Todos que vi até agora achei muito parecidos, me lembrando muito micro frameworks como Flask, por exemplo, e pelo que pude aprender até agora todos usam inclusive como base a biblioteca padrão do Go para tal.

Gin Web Framework – https://gin-gonic.com/

O framework que adotei para o segundo objetivo foi o Gin e por uma razão bem boba: segui o tutorial que estava presente na própria documentação oficial da linguagem que pode ser acessado neste link: Tutorial: Developing a RESTful API with Go and Gin.

A documentação do Gin é péssima, e você pode acessar neste link. Você encontrará um quickstart extremamente básico com um“hello world” e não muito mais além disto.

Infelizmente os autores do framework acreditam que uma boa forma de se ensinar é a partir de exemplos, então você terá de navegar por eles, que podem ser vistos neste link.

Um vídeo interessante

Minha impressão de que os frameworks que vi eram basicamente sempre a mesma coisa se confirmou neste vídeo: https://www.youtube.com/watch?v=JECZTdEJnOI

Primeiras impressões

Ferramentas

Não senti falta de nada e até agora tudo o que usei achei excelente. Tenho usado o VS Code como IDE e os plugins recomendados funcionam perfeitamente.

Para facilitar minha vida instalei Go usando o asdf com o plugin golang. O Asdf nos permite ter instalações concorrentes de basicamente todas as ferramentas de desenvolvimento que você pode imaginar. Se ainda não conhece, recomendo que leiaeste tutorialque escrevi a respeito no site da itexto.

As ferramentas de linha de comando do Go nos permitem também fazer tudo o que precisamos é como se o Maven tivesse um filho com o Cargo do Rust:

Gerenciar dependências (muito parecido com o Cargo do Rust).
Compilar os projetos (óbvio!)
Executar testes
Criar módulos
Buscar erros no projeto
Instalar ferramentas adicionais (há várias!)

A velocidade do compilador impressiona. É muito rápido.

A linguagem

Orientação a objetos?

Aqui percebi que com o tempo realmente fui me tornando uma pessoa viciada em orientação a objetos (Kico de 15 anos atrás olha pra mim e diz: não te disse???). Go não é orientado a objetos tal como estamos acostumados no caso do Java ou C# por exemplo (este vídeo é interessante).

Há sim objetos, mas não há classes ou herança: a norma claramente é programação procedural aqui. E sabe de uma coisa? Confesso que senti alívio enquanto escrevia meus mini projetos e via como é possível escrever código muito mais simples para estes contextos (aplicações simples) sem orientação a objetos (o Kico de dez anos atrás também me cutucou aqui).

(Orientação a Objetos não é uma boa prática de desenvolvimento: é um paradigma de programação que tem seu lugar de aplicação. Infelizmente isto não é claro pra muita gente ainda hoje…)

Há polimorfismo, e o conceito de interfaces aqui é muito interessante. É vista como algo implícito (você não precisa daquelas instruções implements). Duck typing basicamente.

Simples!

Não é exagero dizer que se você terminar o Tour of Go vai ter o ferramental necessário para implementar tudo o que me propus nesta imersão. A linguagem é realmente muito simples e torna simples coisas que são complexas em outras.

Um modelo de strings simples. Não é algo complicado como o que temos em C ou ainda mais complicado como o que temos em Rust (este vídeo sobre strings em Rust é muito útil).
Você tem ponteiros que são fáceis de entender.
Um esquema de pacotes e módulos simples de entender (ao contrário do que temos em Rust que apesar de poderoso leva um tempo até pegar o jeito).
Um modelo de dados muito básico: os tipos numéricos que precisamos (inclusive unsigned, algo que sempre senti muita falta no Java (pense em integrações de baixo nível que você vai me entender), um único tipo de string, structures (que só entraram no Java recentemente), maps, slices (como listas) e ponteiros (que já falei)

A sintaxe também é muito simples. Me lembra Groovy, mas ainda mais simples, o que me leva a outro ponto importante.

Curva de aprendizado

Em um dia usando apenas a documentação oficial consegui cumprir os dois objetivos que me propus sem nenhum conhecimento prévio sobre a linguagem. Importante: estou falando sobre mim, que atuo na área desde 1996 e já passei por diversas linguagens e ambientes de desenvolvimento , mas normalmente quando vou aprender algo novo do zero, com o tempo que tenho disponível hoje, leva pelo menos uma semana.

É impossível para mim não fazer aqui uma comparação com Rust. Não acredito que em uma semana você consiga se tornar realmente produtivo na linguagem, mas com Go, se for para desenvolver inicialmente ferramentas como o primeiro objetivo que me propus, acredito que sim.

E é muito mais fácil treinar uma equipe em Go que em Rust por outra razão: a simplicidade da documentação também. Experimente tentar aprender Rust pelo material indicado pela comunidade (o livro “The Rust Programming Language”) e compare com o guia que expus neste post.

(Antes que chegue um fanático aqui: não estou dizendo que Rust seja ruim, mas sim que sua curva de aprendizado é um problema real)

Testes

Assim como Rust, Go também trás as funcionalidades necessárias para que você possa escrever seus testes unitários e integrados. Tem inclusive recursos bem legais como por exemplo a escrita de benchmarks, fuzzing (passagem de valores aleatórios para funções) e algumas outras funcionaliddes.

Se você ler a documentação oficial encontrará links como este (Add a test no Tutorial dos módulos que indico no início). Mas sabe o que não está incluído nas bibliotecas? Asserções! Você terá de usar projetos como este para que sejam incluídas em seus testes.

Aqui está o ink para a documentação do módulo testing, que é o oficial para a execução de testes.

Acesso a bases de dados relacionais

Na biblioteca padrão o módulo database (dividido nos pacotes sql e sql/driver) me chamaram a atenção. Temos ali padronizadas todas as interfaces a serrem seguidas pelos fornecedores de bases de dados relacionais usando um modelo muito parecido com o que temos no JDBC do Java.

Este é um diferencial importante em relação ao Rust que, até onde sei, ainda não tem algo similar padronizado na própria linguagem. E por que isto é importante? Por que facilita muito a adoção da linguagem no ambiente corporativo no qual não raro o SGBD relacional é Rei.

Começando

É raro eu ter uma primeira impressão tão positiva de uma linguagem de programação (a última foi Groovy): não acredito que seja a primeira impressão que fica, mas sim a última, quando os problemas reais vão se mostrando conforme desafios maiores surgem.

A simplicidade da linguagem associada a uma biblioteca padrão que me fornece tudo o que preciso pra começar a trabalhar, assim como um ferramental que já vêm praticamente pronto após a instalação colocou Go pra mim como uma alternativa muito interessante para os cenários que mencionei no início do post.

Na minha opinião, quanto menor for o tempo que você tiver para treinar sua equipe em uma linguagem para estes cenários, maior a probabilidade de sua escolha ser Go ao invés de Rust.

The post Meus primeiros passos com Go (inclui bibliografia comentada) appeared first on /dev/Kico.

Desenvolvimento Android nativo com Jetpack Compose – Um plano de estudos

Henrique Lobo Weissmann (Kico) — Thu, 08 Jun 2023 23:32:40 +0000

Uma das coisas que mais tenho gostado de estudar atualmente é desenvolvimento nativo para Android com Jetpack Compose. Com alguns projetos em execução e os resultados tem sido incríveis (vou escrever mais sobre isto em breve), mas o processo de aprendizado não tem sido trivial.

O motivo é irônico: apesar de a documentação oficial do Google ter me parecido excelente , não é claro qual caminho você deve seguir ao navegar por ela. É muito extensa e fácil de você se perder. Tanto que terminei com uma página enorme de links no meu Obsidian (app lindo, experimente) que acabei transformando neste post.

Meu objetivo é lhe dar os insumos para que você possa começar a desenvolver suas próprias aplicações nativas no Android sem precisar gastar um centavo sequer com cursos (não que estes sejam ruins (muitos são), mas por que para o caminho que vou expor se tornam desnecessários).

Minha sugestão é que você guarde este post: primeiro o leia do início ao fim e, na sequência, execute os treinamentos que sugiro (todos gratuitos) e guarde os links que cito aqui para que você possa se aprofundar. Muita atenção aos alertas que darei daqui pra frente.

O primeiro passo é ter a última versão do Android Studio em seu computador. Você pode baixá-lo aqui, e ele é a ferramenta que você precisará para fazer tudo.

Este mundo nativo do Android

A primeira coisa é saber aonde você está: neste post falo sobre desenvolvimento de aplicações nativas para Android usando Jetpack, que é a abordagem atual recomendada pelo Google para o desenvolvimento de aplicações nativas hoje.

Isto quer dizer que há dois caminhos a serem seguidos:

O desenvolvimento antes do Jetpack : baseado em Views (layout baseado em XML) e Java.
Desenvolvimento baseado em Jetpack – que é o novo modo recomendado pelo Google para começar novos projetos.

Se você navegar pela documentação oficial do Android hoje este direcionamento para o novo modo de desenvolvimento é claro: está mais difícil encontrar o conteúdo sobre views e Java (vai lá: tenta!).

Então precisamos começar entendendo o que o Google está chamando de “novo caminho para o desenvolvimento Android”. A primeira mudança radical diz respeito à linguagem de programação.

Sai Java, entra Kotlin

Ainda é possível usar Java para o desenvolvimento de novas aplicações Android, mas você não conseguirá (ou pelo menos terá muita dificuldade) em usar o Jetpack Compose (que é o novo toolkit gráfico para construção de interfaces gráficas) em seus projetos. Então o primeiro passo aqui é ignorar o Java ( :( ) e partir pro Kotlin.

Na minha experiência como “javeiro” (desde 1996), as maiores dificuldades podem ser:

O modo como Kotlin lida com nulidade pra evitar os famigerados NullpointerExceptions da vida. Leva tempo até pegar o jeito da coisa (ao menos pra mim levou (a linguagem deixa bem claro o trauma com estes problemas e realmente é uma solução interessante para a questão gerando código que pode ser bem mais seguro)).
O uso que a linguagem faz de funções: você não precisa ter classes em um arquivo Kotlin, pode ter só funções. Isto me gerou muito estranhamento. Se você tem uma boa experiência com o conceito de lambdas no Java (a partir do 8) então a coisa vai ser bem mais tranquila.
A sintaxe: não se iluda achando que “é muito parecida com Java”. É ilusão.

Minha dificuldade só não foi maior devido à minha longa experiência com Groovy. Então aqui seguem os primeiros materiais que sugiro para vocês.

Alguns alertas

Na minha experiência há duas formas de se aprender uma nova linguagem de programação: apanhando e pondo seus clientes em risco ou maximizando seu tempo e minimizando o risco para seus clientes. Opto por falar sobre a segunda alternativa aqui.

Nos cursos que cito abaixo, execute-os do início ao fim, sem pular. As aulas muitas vezes são encadeadas: se você ignorar uma delas terá dificuldades em entender o conteúdo posterior.
No caso dos cursos há exercícios: faça-os. Se não houver, tente reproduzir o código dos instrutores no seu ambiente de desenvolvimento local. Aprendi horrores assim.
Se você vêm do Java, não caia na ilusão de que já sabe como os elementos básicos do Kotlin irão funcionar. Há diferenças e elas podem te tomar boa parte do seu tempo.
Cuidado com as traduções do Google : vou incluir vários links que direcionam para a documentação oficial do Android e esta normalmente é traduzida, mas em alguns pontos encontrei erros.
Você não conseguirá fazer muita coisa (se é que conseguirá fazer algo) sem ter noções mínimas de Kotlin.

Voltando ao conteúdo sobre Kotlin

Bootcamp Kotlin para Programadores na Udacity (grautito) –https://www.udacity.com/course/kotlin-bootcamp-for-programmers–ud9011

É um treinamento bem interessante: totalmente em inglês. Confesso que minha maior dificuldade foram os instrutores que, apesar de bons, são “divertidos demais” pro meu gosto. Mesmo com este “problema”, foi meu primeiro contato com Kotlin e ajudou muito.

Se o inglês for um problema, não desanime, há um outro treinamento muito legal também que encontra-se no site do Google e que possui tradução para o português:

Treinamento Kotlin para programadores – https://developer.android.com/courses/kotlin-bootcamp/overview

É essencialmente o primeiro treinamento, mas com uma vantagem (pra mim): sem os vídeos dos instrutores que mencionei acima.

Finalmente, há a documentação oficial da linguagem , que também é bem legal como fonte de referência (não é um curso) e pode ser acessada neste link: https://kotlinlang.org/docs/home.html

Assuntos que você deve prestar muita atenção:

Coroutines – é a solução para programação assíncrona não bloqueante no Kotlin que será vital no desenvolvimento de aplicações Android. Link na documentação oficial: https://kotlinlang.org/docs/coroutines-overview.html
Null safety – especialmente você javeiro! Como Kotlin lida com nulidades de forma segura. Link para a documentação oficial: https://kotlinlang.org/docs/null-safety.html
Lambdas – https://kotlinlang.org/docs/lambdas.html
Data classes – a solução para “DTOs” em Kotlin – vai ser muito útil na criação de DTOs, especialmente quando precisar escrever clientes REST. Link para a documentalção oficial: https://kotlinlang.org/docs/data-classes.html
Sealed classes – especialmente para você javeiro! Em Kotlin é possível escrever classes que impossibilitem a criação de subclasses. Muito útil. – https://kotlinlang.org/docs/sealed-classes.html
Generics em Kotlin – https://kotlinlang.org/docs/generics.html

Muito além do Android

Houve um momento que me empolguei com Kotlin: foi quando descobri que existe uma versão nativa da linguagem que permite gerar executáveis que não dependem de uma máquina virtual. Trata-se do projeto “ Kotlin Multiplatform ” que permite escrever aplicações para Android (claro), iOS, Windows, Linux, macOS e web. Mais detalhes neste link: https://kotlinlang.org/lp/multiplatform/

Pode inclusive ser uma alternativa bem interessante ao Rust em alguns cenários (vou escrever sobre isto no futuro, pode aguardar). Bora voltar pro Android?

MAD – Modern Android Development

Você encontrará este termo MAD (“MAD Skills” – link oficial) em diversos materiais no site oficial do Android: é este o tal “novo modo” de se desenvolver aplicações. É composto por essencialmente três componentes:

Kotlin ao invés de Java (já falei a respeito).
O conjunto de bibliotecas Jetpack.
Compose para interfaces.

Arquitetura

Antes de pular para o Jetpack e o Compose (que tá dentro do Jetpack :) ) é muito importante que você entenda os conceitos essenciais por trás da arquitetura de uma aplicação Android e, talvez mais importante, conhecer as recomendações dadas pelo Google a respeito.

Eu sei: há aquela ansiedade em pular no código e escrever as aplicações o mais rápido possível, mas recomendo que você dê uma lida neste material aqui antes. Não precisa se aprofundar: uma leitura rápida inicial já vai servir para que ao menos você entenda os conceitos principais.

Aviso: vale muito à pena investir algum tempo neste ponto. A maior parte das coisas que mencionarei adiante ficarão muito mais claras passando pelo treinamento que menciono a seguir. (nem que seja uma passada rápida pelos textos)

Curso Modern Android App Architecture – https://developer.android.com/courses/pathways/android-architecture

Acho muito interessante que você passe por este curso. Nele você vai entender quais as recomendações do Google para que organizemos nosso código de tal forma que obtenhamos projetos que sejam fáceis de serem mantidos no longo prazo (e no curto e médio também) e, talvez mais importante: adquirir vocabulário.

Pontos que você deve prestar muita atenção:

Entenda as camadas: UI (interface gráfica), Data (dados), Domínio.
Eventos: vai te poupar muito tempo em seus primeiros protótipos (quando você topar com situações do tipo “por que meus dados só aparecem quando rotaciono o device?” lembre disto)
Estado: como a interface mantém o estado (esta é uma das coisas mais difíceis na minha opinião)

O treinamento acima é demais pra você? Tem um caminho um pouco mais curto mas que pode te ajudar também. É este link da documentação: Guide to app architecture – https://developer.android.com/topic/architecture

Jetpack

É o conjunto de bibliotecas desenvolvidas pelo Google com o objetivo de facilitar a vida do desenvolvedor provendo diversas funcionalidades que podem ser aplicadas tanto em novos projetos quanto pré existentes do Android. Cito os que, para o meu caso, tem sido mais importantes:

Room – ORM para persistência de dados no SQLite.
Camera – para lidar com a câmera do celular.
Navigation – biblioteca usada para que você possa implementar a navegação de uma forma muito fácil entre as telas da sua aplicação.
Hilt – uma implementação do padrão de injeção de dependências pra Android (pense no Spring pessoal do Java, mas simplificado)

O perigo aqui é que são diversas bibliotecas, e você não terá tempo hábil para ver todas elas. Então o que recomendo é que você comece pelos links abaixo:

Getting started with Android Jetpack – https://developer.android.com/jetpack/getting-started– vai te mostrar como incluir as bibliotecas no seu projeto e também dá uma visão geral sobre o Jetpack. Aproveite e navegue pelos links expostos na barra lateral. Não precisa se aprofundar, apenas leia o que está aqui (é um conteúdo bem pequeno).

Navegue pelas bibliotecas – https://developer.android.com/jetpack/androidx/explorer?case=data – Para não ficar preso apenas às bibliotecas que mencionei aqui, é legal ver a variedade incrível de bibliotecas liberadas pelo Google. Tem biblioteca pra quase tudo aqui.

Dica sobre a documentação das bibliotecas: atenção aos links “User Guide” e “Codelab” que aparecem no título de cada biblioteca, tal como no print a seguir:

Clique nestes links! São cursos muito bons, práticos e que mostram como aplicar a biblioteca de uma forma bem fácil de entender.

Sobre Java: até onde vi a maior parte das bibliotecas vai funcionar no Java (até por que o Kotlin é compatível), mas nem sempre. O Compose por exemplo não é tão simples assim de ser adotado nesta linguagem. De novo: aprenda Kotlin pra prosseguir, é importante.

Links para aprofundamento

Use estes links para se aprofundar em algumas bibliotecas muito importantes do Jetpack.

Codelab do Room – https://developer.android.com/codelabs/basic-android-kotlin-compose-persisting-data-room – para você aprender como este ORM opera.

Using Hilt in your Android app – https://developer.android.com/codelabs/android-hilt – conforme sua aplicação cresce você uma hora ou outra precisará lidar com a complexidade. E o Hilt como container de injeção de dependências pode ajudar HORRORES.

Working with Preferences DataStore – https://developer.android.com/codelabs/android-preferences-datastore#0 – para diversas aplicações o SQLite é mais complexo que o necessário. Se você precisa armazenar apenas informações simples e não tão bem estruturadas, pense no DataStore.

Testando – https://developer.android.com/training/testing/fundamentals – é vital que você aprenda a testar seus projetos. Dica: use os testes para aprender as bibliotecas do Jetpack! Vai te poupar muito tempo e é uma ferramenta pedagógica bem interessante.

Jetpack Compose

Deixei meu favorito para o final: a primeira vez que comecei a brincar com o Jetpack Compose foi meu momento “eureka” pro desenvolvimento nativo com Android. Muda bastante o modo como é feita a construção das nossas interfaces gráficas.

Ah: o Jetpack Compose é o toolkit gráfico usado para criar interfaces para Android nativo.

Até então nós tínhamos o desenvolvimento do frontend baseado nas Views do Android, que sempre me lembraram muito o XAML da Microsoft, o JSF do Java ou mesmo o HTML. Você essencialmente cria suas páginas usando XML ou um editor visual e faz todo o desenvolvimento baseando-se no modelo baseado em eventos (“ao clicar”, “ao pressionar”, etc).

É um modelo bacana pra se trabalhar: e o fato de existir um editor visual ajuda bastante. Tenho uma notícia ruim aqui: não temos este editor visual com o Compose, mas sim um outro modelo de desenvolvimento, declarativo, baseado em estado “imutável” e muito, muito parecido com o que temos no desenvolvimento com React (especialmente o Native), Flutter ouSwift UI.

Se você já tem experiência em qualquer uma destas ferramentas acima o Compose vai te parecer bastante familiar. Aliás, recomendo que você leia este texto (Thinking in React) pois as ideias ali descritas são muito parecidas com as que serão expostas no Jetpack Compose. Não é por acaso que a própria equipe do Google lançou sua “versão” deste texto: Thinking in Compose (https://developer.android.com/jetpack/compose/mental-model). Leia antes de começar.

Um bom caminho pra começar são os cursos abaixo.

Jetpack Compose for Android Developers – https://developer.android.com/courses/jetpack-compose/course

Este treinamento é composto por trilhas. Faça ao menos a primeira: Compose Essentials. Você irá adquirir o “feeling” sobre como trabalhar com o Compose para coisas bem simples. Repito: coisas bem simples.

Na sequência siga para as outras trilhas:

Layouts, Theming and Animation – aqui você vai aprender como deixar sua aplicação bonita.

Architecture and State – de longe na minha opinião a parte mais difícil do aprendizado. E aqui você vai me agradecer por ter lhe pedido para que antes de chegar aqui lesse um pouco sobre arquitetura. Você irá aprender como as aplicações gerenciam seu estado (isto é, as “variáveis” por trás de cada view). Faça e refaça quantas vezes for necessário esta trilha até que tudo fique claro.

Cuidado: este curso é de 2022 e há alguns pontos desatualizados nele. Especialmente no que diz respeito ao uso do Android Studio.

É ali que você aprenderá o que são os view models, que são um componente essencial da arquitetura. Se você já conhece o padrão de projeto MVC, pense nos view models como o “Controlador” da história.

Lembra lá no início quando falei pra você começar pelo Kotlin? Aquele esforço se pagará muito aqui.

O “outro” treinamento (o “grandão”)

Há um outro treinamento online que você também pode tirar proveito: “ Android Basics with Compose ” –https://developer.android.com/courses/android-basics-compose/course

Este é o treinamento completo: vai desde o básico do Kotlin, passa pelo Compose, lida com as camadas de dados, ensina a fazer requisições à Internet (REST), como lidar com execução em segundo plano e até mesmo como integrar projetos que usam Views (legado) com Compose.

Se você tiver muita paciência e seguir apenas este treinamento já te dá um belo passo a frente. Por que não falei dele antes? Por que quis te dar alternativas. Pense neste como o “resumão da obra”.

Conteúdo adicional sobre o Compose

Se você realizou o treinamento acima vai ser importante você se aprofundar em alguns temas. Seguem aqui mais alguns links para que você possa se aprofundar.

Codelab do Navigation – https://developer.android.com/codelabs/android-navigation – para que você possa se focar neste ponto que é muito importante.

Material Components and Layouts – https://developer.android.com/jetpack/compose/layouts/material – Material é a linguagem de design do Google, e neste link você irá aprender a como começar a tirar proveito dele. Muita atenção ao uso do “scaffolding”, que pode poupar MUITO tempo no desenvolvimento.

ViewModel Overview – https://developer.android.com/topic/libraries/architecture/viewmodel – digo e repito: minha maior dificuldade foi entender o conceito de estado em aplicações Android. Quanto mais você ler sobre o ViewModel, melhor. E este texto pode te ajudar a entender os conceitos por trás deste elemento.

E isto é só o começo

Espero que este guia lhe seja útil tal como tem sido para mim e nossa equipe. De tempos em tempos voltarei a este post para atualizar os links caso mudem ou para adicionar mais conteúdos.

E meus próximos posts aqui serão sobre como tem sido nossa experiência no desenvolvimento deste tipo de aplicação e por que tem nos parecido tão interessante. Até lá!

PS: “one more thing”

Lembra quando mencionei o “Kotlin Multiplatform”? Então: existe também o Compose Multiplatform, que permite usar a mesma base de código para Android, iOS, desktop e web. Ainda em desenvolvimento, mas bastante promissor. https://www.jetbrains.com/lp/compose-multiplatform/

The post Desenvolvimento Android nativo com Jetpack Compose – Um plano de estudos appeared first on /dev/Kico.

Eu e o “Clean Code” – Parte 4: Fim da Leitura

Henrique Lobo Weissmann (Kico) — Wed, 24 May 2023 21:09:29 +0000

Finalmente estou fechando esta série de posts sobre o livro “Código Limpo”: agora finalmente escrevo minhas impressões finais sobre a leitura e tudo o que envolve este texto.

Para ter uma visão completa sobre o que estou falando recomendo que você leia as três primeiras partes:

Minha própria estratégia narrativa

Falei tanto sobre a estratégia narrativa do Robert Matin, então pra começar entrego aqui a minha: meu objetivo nesta série foi mostrar alguns aspectos relacionados tanto à escrita do livro quanto ao que ocorre ao seu redor:

Por que acredito que há uma postura dogmática em relação ao que ali é escrito (primeira parte).
Em que medida o autor pode ser responsável por este comportamento dogmático (segunda parte).
Expor a linguagem tóxica presente no texto original. Faço isto mostrando a construção de uma figura de autoridade na segunda parte e apresentando de forma explícita como esta toxicidade se manifesta na terceira parte quando disseco o quarto capítulo (“Comentários”).
Deixar bem claro que há não um livro “Código Limpo”, mas vários: o original e as inúmeras versões alternativas do texto que se manifestam a partir dos comentários que são publicados a seu respeito em todo lugar.

Comecei mostrando o elefante branco que estava na sala, na sequência apontei o dedo para a linguagem exposta no texto e pra finalizar mostrei aonde a estratégia tóxica do texto aparece de forma mais explícita no livro (clássico mineiro comendo pelas beiradas).

Agora rasgo o verbo dizendo o que penso sobre o livro.

Código bem escrito é uma coisa e “Código Limpo” outra

Apesar da expressão “Código Limpo” fazer uma referência a código bem escrito acho importante tornar clara uma diferença aqui: quando usamos o termo “Código Limpo” estamos nos referindo ao livro “Clean Code” e a todos os produtos que Robert Martin vende (tem até logotipo).

É um fenômeno muito similar ao que ocorre quando nos referimos a palha de aço como “Bom Bril”, por exemplo. Acho isto ruim pois na prática acabamos por fazer marketing gratuito ao referenciarmos algo que deveria não estar ligado a uma pessoa/empresa, mas a uma área: estratégias para a escrita de código bem feito.

As práticas descritas no livro não são invenção de seus autores (leia a parte um para entender este plural), mas hábitos que já existiam e foram documentados por outros autores (veja na terceira parte quando mostro que o Capítulo 4 possui uma versão anterior “atóxica” escrita por Steve McConnell no Code Complete anos antes).

Aqui entra então um problema que o sucesso do livro trouxe: esta confusão de termos e a personalização de práticas.

Sendo assim daqui pra frente quando eu disser “Clean Code” ou “Código Limpo” me refiro ao livro, não a código bem escrito.

Nem todo código bem escrito segue a cartilha de “Código Limpo”

Apesar de ter achado o vídeo “Clean Code Terrible Performance” do Casey Muratory (há um texto dele também que pode ser lido aqui) muito tendencioso (merece um post a parte) amei o fato de ter vindo à tona e, de um certo modo, foi o pontapé que eu precisava pra finalmente escrever esta série de posts.

Apesar dos pesares foi levantado um fato muito importante ali: seu código não deve obrigatoriamente seguir o que está sendo dito em um livro apenas pelo fato de… estar em um livro muito conhecido e recomendado. E este talvez seja o único ponto no qual concordo 100% com Casey Muratory apesar dele não dizer isto de forma explícita em seu material.

Por que o termo “princípio” que é aplicado às técnicas apresentadas no “Código Limpo” é uma aberração e acredito que nos trouxe sérios problemas. Usamos o termo “princípio” para denotar ou o início de algo ou a base para a construção de alguma coisa (há inclusive uma conotação moral aqui – veja o que falo a respeito na segunda parte da série).

Observe os resultados que aparecem pra mim ao buscar “Princípios do Clean Code” no Google:

O último resultado grita para mim: “quais são as boas práticas de programação? “.

Em diversos artigos (como este no LinkedIn) “Clean Code” é descrito como: “conjunto de práticas recomendadas para a escrita de código considerado ‘limpo'”. Há um problema sério aqui que é o seguinte:

uma “boa prática” só faz sentido quando é adequada ao contexto!

E apesar de no próprio livro os autores mostrarem o contexto em que suas refatorações são aplicadas, na prática o que vemos é as mesmas serem aplicadas como princípios. Aliás… o termo “prática” também acho ruim. Um termo muito melhor na minha opinião é “estratégia” pois já trás em si implícita e explicitamente a necessidade de um contexto.

E vou além: a partir do momento em que o termo “princípio” se popularizou também se cria a impressão de que no “Código Limpo” estão todas as estratégias possíveis para se escrever bom código. Ignora-se todos os livros que cito na primeira parte desta série e que listo aqui de novo:

Code Complete – Steve McConnellA Philosophy of Software Design – John OusterhoutTrabalho Eficaz com Código Legado – Michael FeathersThe Pragmatic Programmer – Andrew Hunt e David ThomasBeautiful Code – Andy Oram e Greg WilsonRefatoração – Martin Fowler (aqui tenho várias críticas, mas é um bom livro)The Practice of Programming – Brian Kernighan e Rob Pike (yeap: o “cara” do C e do Go)Os padrões definidos pela sua linguagem (ou linguagens) de programação e sua documentação oficial.Livros sobre a linguagem de programação também costumam expor boas práticas.

Resumindo: “Código Limpo” é apenas um pequeno conjunto de estratégias que só devem ser usadas quando o contexto realmente é o adequado.

A responsabilidade do autor

Um dos comentários que recebi é de uma riqueza imensa e me fez pensar bastante:

Wellington, na terceira parte da série

Como alguém que já viu a própria toxicidade gerar efeitos terríveis me senti muito seguro em responder o Wellington. Autores (geradores de conteúdo em geral) acabam construindo fama, autoridade e se tornando modelos para outras pessoas, especialmente aqueles que estão dando seus primeiros passos.

E faz parte da civilidade saber dar feedbacks que não sejam agressivos, mas honestos, especialmente para aqueles que ainda estão construindo a própria segurança. Quem está começando aprende com quem tem mais experiência, é assim que funcionamos.

(Kant descreve este aprender pelo exemplo como imperativo categórico (eu tinha de meter um filósofo aqui, né?))

E este livro é normalmente oferecido a iniciantes, que por sua vez tem a tendência de seguirem o exemplo dos mais experientes (no caso o autor) e, com isto, podem perpetuar posturas que, apesar de carismáticas, são ruins. O Wellington concordou comigo depois (aliás, foi uma bela conversa ali).

Fechando o livro

Concluindo: ainda acho que todo mundo deveria ler este livro aqui no Brasil pela sua importância e influencia, mas não pela sua qualidade.

(pessoalmente o único capítulo que gosto é o segundo – “Nomes Significativos”, escrito pelo Tim Ottinger)

O grande mérito do livro foi ter criado toda esta excitação em relação à escrita de código bem escrito, entretanto do ponto de vista cultural o considero um desastre pelas razões que expus em toda esta série e finalizei neste post.

E agora vocês sabem o que digo presencialmente a todos aqueles a quem indico a leitura deste livro.

PS:

O José Yoshiriro (tivemos uma discussão bem acalorada nos comentários) escreveu um livro sobre Clean Code publicado recentemente na Casa do Código.

Ele havia me pedido para lhe dar minha opinião sobre o mesmo durante a escrita. Na época lhe disse que não via sentido no livro por que era mais jogo ler o original. Yoshiriro, eu tava errado!

O fato de você ter escrito um livro sobre o mesmo assunto mas com uma linguagem bem melhor é uma excelente razão para que as pessoas o leiam ao invés do Código Limpo original.

Além do Yoshiriro o Alexandre Aquiles escreveu um livro sobre SOLID também pela mesma editora. Apesar de ter duas cópias impressas do livro (uma delas o Alexandre me deu de presente) até hoje não consegui ler, mas também recomendo a leitura pois tenho certeza que a linguagem é muito boa.

PS 2:

São estratégias, não princípios!

The post Eu e o “Clean Code” – Parte 4: Fim da Leitura appeared first on /dev/Kico.

Eu e o Clean Code – Parte 3 – O Nefasto Capítulo sobre Comentários

Henrique Lobo Weissmann (Kico) — Sun, 14 May 2023 13:28:00 +0000

Finalmente começo a comentar alguns dos capítulos do “Código Limpo” mais a fundo contando minhas experiências a respeito. O termo “experiência” aqui é o mais adequado pois vou falar sobre os efeitos que vi do capítulo 4 (“Comentários”) do livro em pessoas com quem trabalhei, projetos nos quais atuei e histórias que chegaram a mim.

O termo “Nefasto” também foi bem pensado: na minha experiência este é um dos textos que mais problemas trouxe para a nossa área.

A ideia essencial por trás deste capítulo é que os comentários são um mal necessário e que só existem por que não conseguimos nos expressar de forma clara através do nosso código. Com o tempo as pessoas foram percebendo que esta é na realidade uma ideia muito ruim, inclusive seus mais ardorosos defensores criaram um novo termo: “comentários estratégicos”.

Então neste post vou primeiro analisar como o texto é escrito e depois apresentar minhas próprias ideias sobre o tema baseadas em outros autores que li e minhas próprias experiências.

Alguns avisos

Aqui falo sobre a tradução do livro “Clean Code” para o português feito pela editora Alta Books. Para esta análise não levo em consideração o texto original.

Esta terceira parte é fundamentada no que apresento nas duas primeiras desta série nas quais analiso o modo como o texto é escrito e como, acredito, este gera comportamentos exageradamente exaltados em parte dos seus leitores. Caso não as tenha lido e se interesse, seguem os links:

Não se exalte nos comentários deste blog. Ele é meu, pessoal, e bloqueio quem eu quiser. Todos são bem vindos para discutir, mas ninguém é obrigado a ler tratados e comentários agressivos aqui.

Tal como nos outros textos não quero estar certo, mas levantar uma discussão para que seja possível termos uma leitura mais crítica e rica do texto e crescer neste assunto.

Este não é um texto sobre política (mas toca no tema (contraditório hein? (é))).

Em 2000 eu trabalhava em uma livraria…

Com 21 anos tive meu primeiro emprego que achava realmente “sério”: trabalhava como vendedor (“livreiro”) na Livraria da Travessa em Belo Horizonte, que era focada em livros da área de Ciências Humanas. Foi um período importantíssimo para minha formação pois tive contato com diversos autores que me forjaram e alguns que me enganaram.

Dentre os autores que me enganaram havia um em especial que me seduziu inicialmente pelo comportamento dos seus leitores. Eles chegavam a mim desconfiados, falando baixo, olhando para os lados com medo de serem vistos pedindo seus livros. Diziam que era alguém com opiniões muito fortes e que tecia críticas ferozes aos intelectuais e mídia da época.

(eu sempre achava que estes leitores iam me pedir algum livro pornográfico e ficava decepcionado depois quando descobria o que realmente queriam…)

Eu tinha 21 anos, não sabia nada da vida (ainda não sei) e alguém que xingava só podia ser coisa boa. Li alguns dos seus textos naquela época e o achei realmente brilhante. Era cativante por que o modo como criticava o mundo me fazia sentir que eu era parte de um grupo seleto que agora via as coisas “como realmente eram”.

No ano seguinte entrei para o curso de Filosofia e tive contato com outros autores, foi quando resolvi reler o tal autor de forma mais atenta e fiquei chocado com a quantidade de bobagens e absurdos que este dizia de forma tão sedutora. Era absurdo: escrevia sobre Aristóteles, por exemplo, como se fosse um expert, mas nunca o havia lido no original (neste caso é necessário), relativizava escravidão e, no final das contas era só um infeliz cuja escrita exteriorizava suas próprias frustrações e alimentava o ressentimento alheio.

(Quem não tem frustrações? Quem não se sente confortado ao ver alguém atacando a fonte de nossos ressentimentos?)

E esta sensação de desconstrução da genialidade (aka “perceber que era uma grande bobagem que havia me iludido”) que tive ao ler atentamente este autor e a postura de diversos dos seus leitores que se mostraram pessoas fanatizadas com o tempo (“catequizadores”) me lembram muito a minha experiência com o texto do capítulo “Comentários”. O autor a que me refiro foi o Olavo de Carvalho.

Minha primeira impressão sobre este capítulo foi tão positiva que em 2016 escrevi neste blog sobre o assunto e ao final recomendava este texto. Duvida? Aqui o link.

A ideia de que eu só escrevia comentários por que meu código não era claro o suficiente foi por um tempo inclusive um incentivo para que eu escrevesse código mais fácil de ser mantido. Entretanto com o tempo ficou claro que a questão era bem mais profunda e muito mais rica.

Um aviso sobre olavo de carvalho

Apesar de ter comparado Robert Martin a Olavo de Carvalho este texto não é sobre Olavo de Carvalho.

As similaridades acabam nos pontos que mencionei (a constatação de que o capítulo sobre Comentários não era genial, mas tóxico e parte dos seus leitores que se tornaram catequizadores). Robert Martin não tem um passado tão terrível quanto carvalho, nem disseminou desinformação (até onde sei) durante a pandemia, o que pode ter causado a morte de pessoas (no caso do Brasil, muita gente ).

Robert Martin deixará um legado positivo, ao contrário de carvalho (mesmo tendo escrito este capítulo sobre o qual escrevo).

(e eu não vou aceitar comentários sobre carvalho neste blog (é meu, aceito o que quiser aqui))

De qual Código Limpo estou falando?

Tal como disse no primeiro post da série há claramente duas versões do livro: a oficial e a não oficial. A segunda diz respeito aos comentários e diversas interpretações ao texto que, neste caso, mudam bastante o significado do que está na versão oficial.

Aqui falo da versão oficial e, tal como dito na introdução, da tradução para o português feita pela editora Alta Books. Mas vou contar mais adiante uma história que me aconteceu relativa à versão “alternativa” do livro.

Construção do argumento

O início do capítulo é o momento em que o autor nos seduz para concordarmos com seu argumento usando as estratégias que já vimos nas primeiras duas partes: metáforas morais, expressões controversas e um claro apelo à emoção.

Logo no início o leitor será induzido a ter uma percepção negativa sobre comentários e isto fica bem claro nas citações que trago abaixo, presentes logo no começo do capítulo:

“Nada pode ser tão prejudicial quanto um velho comentário mal feito que dissemina mentiras e informações incorretas”

Robert C. Martin – primeiro parágrafo do capítulo – já começa com metáforas morais

“Comentários não são como a Lista de Schindler. Não são o “bom puro”. De fato, eles são, no máximo, um mal necessário.”

Robert C. Martin – segundo parágrafo do capítulo – (aqui se vê problemas na tradução inclusive). Observe o apelo á emoção na referência ao filme.

“O uso adequado de comentários é compensar nosso fracasso em nos expressar no código”

Robert C. Martin – terceiro parágrafo do capítulo – (discordo muito sobre isto e falarei mais adiante) (de novo, repare que tradução ruim na colocação dos termos)

“Por que eu não gosto de comentários? Porque eles mentem “

Robert C. Martin – quinto parágrafo do texto. Atenção para o uso de metáfora moral tal como aponto na segunda parte desta série.

Mesmo quando vai falar sobre quando comentários são positivos, o autor nos solta um…

“Tenha em mente, contudo, que o único comentário verdadeiramente bom é aquele em que você encontrou uma forma para não escrevê-lo”

Robert C. Martin – primeiro parágrafo da seção “Comentários Bons” do capítulo. Novamente, atenção para a má tradução da seção e até mesmo o mal gosto da expressão usada pelo autor.

Na sequência o autor vai expor o que considera serem comentários válidos: observe que interessante.

Informações legais – comentários sobre licença de uso, por exemplo.
Comentários informativos (no texto é propositalmente vago o que ele chama de “comentários informativos”).
Explicitação da intenção (a maior parte dos comentários na realidade é a explicitação da intenção).
Esclarecimentos.
Alertas sobre consequências.
TODOs.
Destaques.

Observe que são tipos de comentários realmente super válidos, mas sabe o que é interessante? Na tradução para o português é gasto o dobro de páginas para falar sobre comentários ruins.

É interessante observar a linguagem adotada pelo autor na descrição dos comentários ruins: é muito parecida com aquela adotada por pessoas que agridem seus colegas (normalmente iniciantes) em seus code reviews. Vamos a um exemplo:

Às vezes você vê comentários que nada são além de “chiados”. Eles dizem o óbvio e não fornecem novas informações:

/**

Default constructor

*/

protected AnnualDateRule() {

}

Ah, sério? Ou este:

/** Dia do mês */

private int dayOfMonth;

Robert C. Martin – Capítulo 4 – Seção comentários ruidosos. Grifo do autor.

Consigo imaginar um leitor neste momento me questionando: “Kico, sério? Isto aí que você está falando é mimimi!!!” ( detesto a expressão “mimimi”). Respondo: sério. Na minha experiência um dos maiores danos que você pode causar a quem está iniciando é justamente este tipo de linguagem em um code review.

Mas aqui há uma razão para tal: faz parte da estratégia do autor de conquistar o leitor pela rabugice e ridicularização tóxica de erros muito comuns por quem está começando (o que gera a sensação de pertencimento a um grupo seleto de seus leitores). Há personagens que usam a mesma estratégia para conquistar o espectador: Dr. House, Chefe Ramsay, juízes cruéis de reality shows, Steve Jobs…

(a glamorização do babaca)

Se você já tem muitos anos de experiência, tal como eu, talvez tenha se esquecido que quando começou os comentários muito provavelmente eram o que te ajudavam a ter segurança nos seus primeiros códigos. Atacar esta “muleta” do iniciante da forma como é feito neste livro é um desfavor.

E aí consigo imaginar o leitor me questionando de novo: “então como posso abordar o tema dos comentários com um novato, Kico?“. Respondo: tal como Steve McConnell faz no seu livro “Code Complete”. Ele mostra como alguns comentários podem ser ruins, mas não os ridiculariza e nem usa metáforas morais para te convencer disto, usa apenas fatos.

E sabe onde Steve McConnell fala sobre comentários? No capítulo 32: “Self Documented Code”, que é essencialmente o que Robert Martin tenta fazer neste capítulo nefasto. Sabe o que é ainda mais interessante? Este capítulo está na segunda edição do Code Complete, publicada em 2004. A primeira edição de Clean Code é de 2008. Robert Martin não cita Code Complete neste capítulo.

(A primeira edição de Code Complete é publicada em 1993 e foi um livro bastante influente. É importante ter esta informação histórica aqui neste parêntese (que é um comentário))

E esta é a argumentação básica de Robert C. Martin neste capítulo. Sabe o que é mais triste? Ele termina o capítulo mostrando como refatorar comentários ao final, mas não diz o que seria intelectualmente honesto aqui para informar o leitor no decorrer de sua argumentação: comentários não são eternos e são alterados conforme o código muda no decorrer do tempo.

Em 2016 eu já estava na itexto…

Oferecemos um tipo de consultoria chamado “suporte de aquisição” na qual intermediamos quem adquire serviços de desenvolvimento e quem presta estes serviços. O objetivo não é policiar ou fiscalizar,mas sim ajudar as duas pontas evitando conflitos e reduzindo custos: com isto detecto possíveis problemas no que está sendo construído antes que ele chegue ao cliente e, ao mesmo tempo, ajudo o cliente a entender o que de fato está comprando.

(e, claro, ajudo os fornecedores a não perderem seus clientes)

Em um dos nossos primeiros casos lidei com a aquisição de uma plataforma enorme. Era um projeto que já estava terminando o primeiro ano de desenvolvimento e estava atrasado em pelo menos três meses. Ainda pior: a equipe interna de desenvolvedores do cliente não conseguia absorver o trabalho contratado pois não havia documentação sobre a arquitetura do projeto.

Conversando com o fornecedor ouvi algo que mudou minha visão inicialmente positiva do capítulo “Comentários” do Clean Code:

“Nós não documentamos nossa plataforma por que seguimos os princípios ágeis pregados pelo Clean Code, segundo o qual o código já se auto explica.”

Vindo da liderança técnica da equipe

Meu trabalho inicial consistiu então em documentar a arquitetura que havia sido construída junto com este fornecedor. Em dois meses salvamos o projeto: cliente e fornecedor entenderam o que estava sendo construído e até hoje este fornecedor atende este cliente com sucesso.

E aqui entra o “Clean Code alternativo”: em momento algum do livro é dito que arquiteturas não devam ser documentadas. Nem no livro “Clean Architecture”, publicado em 2017 algo assim é dito.

E sabe o que era mais interessante neste caso? A plataforma foi escrita em Java, mas a equipe só tinha experiência com .net. Resultado: usaram os padrões de codificação do C# para um projeto Java.

Eu e os comentários

A argumentação óbvia de que comentários em excesso são algo ruim na minha opinião é redundante: qualquer coisa em excesso é ruim. Simples assim, é uma crítica que portanto nada diz.

Mas há pontos que com o tempo foram se tornando mais claros para mim.

Código totalmente auto explicativo é uma ilusão

A história que conto de 2016 é um bom exemplo disto: para a equipe que desenvolvia a plataforma o sistema era óbvio. O problema é que existe mundo externo e a percepção deste pode ser diferente da de quem codifica. Resumindo: o que é óbvio para você não necessariamente é para o outro.

(a experiência foi meses depois do meu próprio texto que mencionei aqui – incrível como mudou de repente minha visão sobre o livro)

E não é raro encontrar pessoas que se isolam no ato de programar, geram coisas maravilhosas, que funcionam super bem mas que, infelizmente, são de difícil compreensão para o resto do time. Talvez até mesmo por terem uma formação específica que não seja a mesma que a da equipe (matemáticos, por exemplo). Nestes casos comentários agregam, e muito.

Indo além, sempre há um contexto: o código nunca existe por si mesmo. Existe um contexto em que ele foi gerado. Este contexto pode ser histórico (a situação da empresa naquele momento). Ter esta informação ajuda muito a entender por quê foi codificado daquela maneira e, mais importante: por que funciona ou não.

E há outro fator também: equipes mudam, mas raramente muda o stakeholder do projeto. E este precisa do máximo de informação possível para que possa manter sua posse sobre o mesmo.

(Knuth tentou algo similar com literate programmingmuitos anos antes e a ideia não vingou)

Sobre comentários “mentirosos”

Atuo profissionalmente desde 1996: na minha experiência nunca vi alguém mentir em um comentário. O que já vi foi algum comentário desatualizado. Mas sabe de uma coisa? Nestes casos quem dava a manutenção simplesmente os atualizava e o problema estava resolvido.

Nunca foi um problema.

Comentários redundantes

É chato encontrar um comentário redundante? Sim, concordo: mas nunca vi um comentário redundante ferir a produtividade de alguém. Indo além, tal como disse neste mesmo texto, normalmente quando os encontro são escritos por quem está começando e os usa para ter alguma segurança sobre o que está sendo produzido.

E aí como você resolve o problema? Simples: no momento do code review você os remove se forem realmente redundantes e explica para o autor dos mesmos por que o fez de forma civilizada.

Contextualização histórica

Em 2016 escrevi sobre como você pode usar comentários para contar a história daquele sistema. Ainda mantenho minhas posições sobre o que disse ali (só discordo da recomendação literária que faço ao final). Caso queira ler, segue o link.

Sobre a questão de créditos e autoria nos comentários

Discordo de Robert Martin quando ele diz que não faz sentido incluir créditos e autoria do código dado que temos sistemas de controle de versão.

Se você lida com código que implementa algoritmos muito específicos (matemáticos ou físicos por exemplo) é muito útil ter a autoria ali, pois fica muito mais fácil saber a quem procurar. E convenhamos: é bem mais fácil que ficar consultando log de commits, né?

Comentários como ferramenta de design

É interessante o livro não mencionar isto, mas observo em mim e outras pessoas o uso de comentários como ferramenta de design. Direto me pego escrevendo comentários antes do código que vou construir para tornar mais claro para mim o que de fato quero fazer ali.

Os escrevo no topo das classes ou funções, e na sequência simplesmente os traduzo para código fonte. E sabe o que é mais legal? Costumam virar uma documentação super útil para quem vai dar manutenção depois, pois fica claro ali qual era o objetivo inicial daquele código.

Ano passado fiquei muito surpreso ao ler isto no livro “A Philosophy of Software Design” no qual o autor descreve exatamente este processo de criação. Aliás, neste livro estão os melhores capítulos que já li sobre o tema “Comentários”. Recomendo muito a leitura, especialmente por ter um contraponto muito interessante em relação ao “Código Limpo” no que diz respeito a este assunto.

Concluindo?

Levou anos para escrever este texto, mas finalmente saiu! Na época não podia narrar estas experiências pois estava atuando no projeto que mencionei e este post poderia ter gerado um grande constrangimento desnecessário. Mas hoje com tudo resolvido, fica muito mais fácil escrever a respeito.

Me impressiona como estas vinte páginas do texto geraram problemas ao longo do tempo: nem tanto pelo texto em si, mas muito mais pelas interpretações muito equivocadas do mesmo (me pergunto inclusive se estas pessoas realmente leram este livro).

Acho que no final das contas este é o pior capítulo do “Clean Code” e aquele sobre o qual mais vejo problemas. Repito o que disse na primeira parte desta série: ainda acho importante a leitura do livro pela importância que ele tem na formação de gerações de programadores aqui no Brasil.

Espero que com esta série eu possa ter lhe mostrado como extrair um pouco mais da leitura deste livro e mesmo outros que possam seguir a mesma (pobre) linha argumentativa.

No caso deste capítulo tenho uma sensação diferente: tal como já escrevi, os textos que mais gosto são aqueles dos quais discordo pois a leitura se torna um diálogo com o qual aprendo. Não é o caso aqui: a argumentação tóxica nos trouxe problemas no futuro, e não vejo muitas pessoas escrevendo a respeito, o que só aumenta o problema.

Talvez eu escreva mais sobre o livro, mas agora vou aproveitar que voltei a escrever para falar sobre outras coisas por enquanto. Até lá!

The post Eu e o Clean Code – Parte 3 – O Nefasto Capítulo sobre Comentários appeared first on /dev/Kico.

Eu e o “Clean Code” – Parte 2: Descompilando

Henrique Lobo Weissmann (Kico) — Mon, 08 May 2023 03:47:47 +0000

Terminei a primeira parte da minha análise com a seguinte pergunta: “o modo como o livro foi escrito pode induzir a este comportamento dogmático/apaixonado?”

Quando falamos de “Clean Code” muitas pessoas se exaltam. Não lembro de ter visto este comportamento com outros livros. Este fenômeno é péssimo pois dificulta uma visão crítica sobre o assunto e, consequentemente, impede que todos avancem na qualidade do código que escrevemos.

Meu objetivo neste post é reduzir esta paixão para que possamos ter conversas melhores sobre este tema. Para tal vou dissecar a estrutura narrativa do livro, isto é, como o autor (qual deles?) organiza sua argumentação para nos convencer do que aqui é tratado.

A partir do momento em que estas estratégias estiverem claras a pergunta com a qual iniciei este post poderá ser respondida.

Alertas sobre o que você lerá

Para este post não me interessa a versão original, mas sim a tradução para o português publicada pela editora Alta Books por ser a edição mais popular no Brasil e, portanto, aquela que mais nos influencia.

Tal como no primeiro post meu objetivo não é estar certo, mas levantar questões para que possamos iniciar leituras mais críticas do material técnico que chega a nós.

Muito do que aqui escrevo se baseia nos argumentos que apresentei na primeira parte desta série, sendo assim recomendo que você a leia primeiro (link).

Cito alguns trechos do livro nos quais identifiquei alguns comportamentos bem peculiares. Não caberia aqui citar todos os trechos aonde os mesmos ocorrem. O objetivo não é tirar do contexto o que foi dito (pelo contrário, em todos os casos digo exatamente onde encontrar a citação), mas sim ajudar você que irá ler ou reler o livro a ter uma visão mais fria da obra.

Quem escreveu o livro?

Se você perguntar para a maior parte das pessoas elas lhe respondem prontamente: “Robert C. Martin, o Uncle Bob!”.

A resposta está parcialmente correta: ele escreveu o livro, mas também o organizou, e não é o único autor. Há outros:

Brett Schuschert – “Concorrência” e “Apêndice A – Concorrência II”
James Greening – “Limites”
Jeff Langr – “Classes” e “Emergências”
Kevin Dean Wampier – “Sistemas”
Michael Feathers – “Tratamento de Erro”
Tim Ottinger – “Nomes Significativos” (meu capítulo favorito)

Se você colocar estes autores em perspectiva, verá que na realidade são responsáveis por aproximadamente um terço do livro:observe o gráfico que fiz mostrando o número de capítulos por autor.

Esta informação parece boba mas faz toda a diferença na sua releitura pois lendo atentamente, apesar da tradução homogeneizar os estilos, verá que são visões e estratégias narrativas diferentes presentes no texto.

Levando em consideração que Robert Martin escreveu no mínimo dois terços do livro e é o responsável por compilar o trabalho dos demais autores, daqui para frente neste texto levarei em consideração apenas este como o autor e não levarei em consideração em minha análise os capítulos que não são de sua autoria.

Primeira indução – o título

A estrutura narrativa deste livro usa e abusa de emoções e valores a começar pelo título: “Código Limpo”. A escolha do título na minha opinião é um feito de marketing genial: é normal encontrar pessoas que referenciam qualquer boa prática de codificação como “código limpo” ou “clean code” (mesmo que estas práticas sequer estejam presentes no livro).

Limpeza aqui entra no mínimo como um valor estético do ponto de vista metafórico. O único caso que conheço de personagem que encara a sujeira como virtude é o Cascão (criado por Maurício de Souza). Este é o primeiro momento de indução do leitor a emoções que vão além de uma leitura técnica padrão.

Todo mundo quer fazer parte de um grupo que seja referência em seu ofício. Você quer ser um “clean coder” quando está começando e também quer “codificadores limpos” em sua equipe.

Segunda indução – o personagem “Uncle Bob”

Antes uma história envolvendo eu, Wittgenstein e Hegel

Por muitos anos um dos meus maiores heróis foi Wittgenstein. Lembro que apesar de não entender nada do que ele escrevia pensava comigo: “não entendo por que deve ser algo brilhante”. De fato era genial, muito mais do que imaginava na época com meus 21 anos.

E eu lia tudo sobre Wittgenstein: há vários livros fascinantes sobre sua época (A Viena de Wittgenstein), e biografias maravilhosas (Wittgenstein, o Dever do Gênio). Até que percebi algo curioso: o que realmente foi meu motivador inicial pra gostar tanto de Wittgenstein não era sua obra, mas sua vida (que é incrível e cercada de personagens históricos tão fascinantes quanto ele).

Wittgenstein: a maior parte dos problemas da Filosofia se deve a uma má compreensão da linguagem. (da TI também)

Quando percebi este meu desvio consegui pela primeira vez ler Wittgenstein direito e aprendi horrores no processo: até hoje é um dos autores que mais me influencia e mais me fez crescer, mas me arrependo de ter sido seduzido por todo este “glamour” no início: perdi muito tempo.

Outro autor que me influenciou demais foi Hegel: mas este teve uma vida que ao contrário da de Wittgenstein, era um tédio absoluto (não qualquer tédio, O Tédio Absoluto).

A escrita de Hegel é muito mais difícil e complexa que a de Wittgenstein, mas a entendi muito mais rápido. Na realidade, pra surpresa de todo mundo foi imediato, meu foco estava no conteúdo que Hegel escrevia, e não no Hegel.

O que aprendi com isto? Personagens carismáticos podem te desviar do foco principal ou construir uma aura que te impede de ver as coisas de forma fria.

De volta ao “Uncle Bob”

Na primeira parte desta série falei um sobre a construção da autoridade. A personagem do autor entra nesta fórmula também e claramente há a elaboração de uma personagem aqui, a partir do próprio nome (palavras são poderosas): “Uncle Bob” (o “Tio Bob”).

A escolha do apelido é novamente algo muito inteligente: reduz a gravidade do nome original do autor (Robert Martin) e ao mesmo tempo constrói proximidade com o leitor. A proximidade se dá não só pelo apelido mas também por serem apresentados no texto pequenos detalhes sobre a vida privada desta personagem. Um exemplo sutil mas doce é a ilustração de entrada do capítulo 2 (“Nomes significativos”).

(a história que contei sobre mim serviu a dois fins: te aproximei de mim ao mesmo tempo que mostrei como personagens podem nos seduzir ;) )

E claro, há inúmeras palestras que você encontra na Internet nas quais a personagem vai se construindo: falando sempre de forma direta (adora gestos), segura (aponta o dedo), bem humorada, madura, e cheio de exclamações. Ao mesmo tempo diversas menções a elementos de cultura geek são realizados (Star Trek, Star Wars) alimentando com isto o estereótipo do nerd.

Observe como no texto de Robert Martin (o “tio”) há as mesmas exclamações. No primeiro capítulo (“Código Limpo”) você encontra um exemplo clássico logo na segunda página:

(…) E que não precisarão mais de programadores, pois as pessoas criarão programas a partir de especificações.

Bobagens! Nunca nos livraremos dos códigos (…)

Robert Martin – Capítulo 1 – Código Limpo

A linguagem adotada na maior parte das vezes é coloquial, o que ajuda a criar o elo entre leitor e autor. Ele gosta das mesmas coisas que você, e tem uma linguagem simples, parecida com a sua.

Terceira indução – valores morais e falsas equivalências

Por todo o texto há menção a valores morais e estéticos, o que na minha opinião é perigosíssimo quando o assunto é código fonte. Entenda: não estou negando que haja um fator artístico ou ético no ofício, mas é um risco enorme quando estes aspectos projetam suas sombras sobre a engenharia.

No Epílogo do livro ao contar sua participação em uma conferência sobre desenvolvimento ágil em 2005 quando recebe uma fitinha verde de punho de Elisabeth Hedrickson na qual se encontrava escrito “Obcecado por testes” chega a dizer:

(…) Descobri que eu não poderia retirar minha fitinha do punho. Não por que ela estivesse presa a ele, mas por estar moralmente presa. A fita fazia uma afirmação evidente sobre minha ética profissional (…)

Robert Martin – Epílogo do livro Clean Code

E o uso de metáforas morais é encontrado em muitos pontos no livro. No capítulo 4 – Comentários -, por exemplo, você encontra o seguinte trecho:

Por que não gosto de comentários? Por que eles mentem. Nem sempre, e não intencionalmente, mas é muito comum.

Robert Martin – Capítulo 4 – Comentários

Na citação acima talvez você ache que estou pegando no pé, entretanto após ler as quase 400 páginas do livro encontrando metáforas morais como esta o tempo inteiro, não há como negar que um iniciante acabe por absorver toda esta “moralidade” e, com isto, adquirir uma leitura apaixonada pelo texto.

(Um post que preciso escrever é sobre este capítulo 4, que é um dos mais danosos da história da computação na minha opinião. Podem me cobrar isto)

É também comum o uso de exemplos extremos para se justificar a aplicação de boas práticas. No primeiro capítulo há uma comparação com medicina que é um belo exemplo:

(…) e se você fosse médico e um paciente exigisse que você parasse com toda aquela lavação das mãos na preparação para a cirurgia só porque isso leva muito tempo?

Robert Martin – Capítulo 1 – Código Limpo

Observe como são comparadas duas situações de gravidade absolutamente distintas: uma cirurgia (específica) e o ato de codificar qualquer coisa (absolutamente genérico). Lendo atentamente o texto você encontrará exemplos similares pelo texto. Não são situações equivalentes com este tipo de generalização no segundo caso.

Outro exemplo do apelo à estética você encontra na introdução do capítulo 5: “Formatação”:

Quando as pessoas olham o código, desejamos que fiquem impressionadas com a polidez, a consistência e a atenção aos detalhes presentes. Queremos que reparem na organização. Desejamos que suas sobrancelhas se levantem ao percorrer os módulos; que percebam que foram profissionais que estiveram ali.

Robert Martin – Capítulo 5 – Formatação

Observe que interessante o apelo a estética, à impressão que os outros terão de nós, é um chamado portanto à necessidade que todos tempos de sermos bem recebidos a um grupo se sobrepondo à necessidade real da formatação: facilitar a leitura.

Estes são apenas alguns exemplos que você encontrará no texto do livro. São trechos extremamente eficazes em manter o leitor colado ao texto, sem dúvidas, mas ao mesmo tempo induzem o leitor a emoções que acabam por gerar as situações que descrevi na primeira parte desta série.

O trecho sobre “Escolas de Pensamento”

Antes de finalizar esta segunda parte preciso falar sobre o trecho “Escolas de Pensamento” pois muitas pessoas o referenciaram para mim dizendo que neste trecho o autor se exime do comportamento dogmático dos leitores. Discordo.

Logo no primeiro parágrafo encontramos:

(…) Apresentaremos nossos conceitos como verdades absolutas, e não nos desculparemos por nossa austeridade. Para nós, a essa altura de nossa carreira, tais conceitos são absolutos. São nossa escola de pensamento acerca do que seja um código limpo.

Robert Martin – Capítulo 1 – Código Limpo – grifos do autor

Na sequência é feita uma comparação muito pobre com escolas de artes marciais. Não há sentido na comparação pois diversas das práticas mencionadas no texto são recomendações comuns em nossa indústria (funções pequenas, separação de responsabilidades, etc) e não “novidades” exclusivas trazidas por esta “escola de pensamento”.

O uso da metáfora “escola de pensamento” é inclusive bastante controverso pois fica parecendo que o autor está comparando sua escola a um “time” e seus “seguidores” a torcedores.

Respondendo à pergunta inicial e prosseguindo

Na minha opinião, sim, o modo como “Código Limpo” é escrito pode induzir seus leitores a um comportamento dogmático.

Há uma série de fatores aqui que levam a isto:

Tal como disse no primeiro post, o fato de se terminar um livro é considerado um grande feito (e é) por muitos e, como tal, é comum a defesa do conteúdo com unhas e dentes.
É criada uma conexão direta com o leitor a partir da construção de uma personagem que é o autor.
O uso repetido de metáforas baseadas em valores estéticos e morais induz aqueles que estão iniciando a terem uma visão mais focada em princípios morais (do autor) que técnicos.

É por esta razão que sempre digo para ler este livro com muito cuidado e, ainda mais importante, junto a outros materiais. As práticas ali contidas não foram criadas pelos autores que ali escrevem, são o resultado do trabalho de outras pessoas e da prática coletiva do ofício de construção de sistemas.

Há uma oportunidade perdida neste livro: já que há tantas metáforas morais/estéticas, é uma pena que sejam apenas metáforas, e não tenha havido aqui um aprofundamento nas mesmas.

(talvez haja fora do livro, mas não conheço)

Você não deve fazer um julgamento moral pelo modo como este texto foi escrito: esta foi a estratégia adotada pelo autor e que foi muito bem sucedida. Talvez se não o tivesse feito desta forma uma multidão de pessoas jamais lesse um livro sobre boas práticas de construção de software.

Infelizmente esta linguagem apaixonada acaba por gerar o comportamento que menciono no primeiro post. Uma pena: empobrece algo que tem muito valor. Como dizem por aí “é bom, mas é ruim”.

Meus próximos posts serão sobre capítulos específicos do “Código Limpo”. Começarei pelo capítulo 4 – Comentários, que na minha opinião nos trouxe mais problemas que soluções.

PS: uma última citação

Quando terminei o texto me lembrei do Prefácio do livro, escrito por James O. Coplien.

(…) Comprei dois pacotes dessa iguaria essa manhã e nela veio este antigo ditado dinamarquês:

(… – tá escrito em dinamarquês)

“Honestidada em pequenas coisas não é uma coisa pequena”. Era umb om presságio para com o que eu já desejava dizer aqui.

James O. Coplien – Prefácio de Código Limpo

Não falei??? O prefácio já nos avisa! :D

PS 2: algo que ajuda nas leituras técnicas

Autores carismáticos são adoravelmente perigosos. Eles te seduzem sem que você perceba. Algo que sempre me ajudou bastante é conhecer as falácias lógicas mais comuns. Seguem alguns links legais:

Your Logical Falacy Is – lista as falácias lógicas mais “populares” – https://yourlogicalfallacyis.com/
Falácia do Espantalho – Wikipedia – https://pt.wikipedia.org/wiki/Fal%C3%A1cia_do_espantalho
Falsa Equivalência – Wikipedia – https://pt.wikipedia.org/wiki/Falsa_equival%C3%AAncia

The post Eu e o “Clean Code” – Parte 2: Descompilando appeared first on /dev/Kico.

Eu e o Clean Code (o livro) – Parte 1: Catequização

Henrique Lobo Weissmann (Kico) — Mon, 01 May 2023 15:46:57 +0000

Faz muito tempo que digo para tomar cuidado com o livro “Código Limpo”: nunca cheguei a detalhar as razões… bem, o momento chegou. Como o texto inicial ficou enorme o dividi em partes.

Começo pela minha maior crítica que não é ao livro em si, mas ao modo como é lido, divulgado e comentado (ou seria melhor dizer… catequizado?).

Importante: no decorrer do texto ao usar o termo “Clean Code” me refiro ao livro original escrito e organizado por Robert C. Martin em inglês, não às práticas.

O termo “Código Limpo” será usado como referência à tradução para o português do livro.

Disclaimer: narro aqui a minha experiência pessoal/profissional com este livro que pode ser diferente da sua. Meu objetivo não é estar certo, mas levantar uma discussão.

“Código Limpo” é leitura obrigatória? Na minha opinião, sim.

Se na sua área de atuação muita gente fala sobre um livro é importante que você pelo menos dê uma passada de olhos nele para entender do que se trata e, ainda mais importante, poder entender do que as pessoas falam e se o que é dito de fato faz sentido.

Por mais que você odeie este livro não há como negar que hoje ele faz parte da nossa formação: mesmo que você não o tenha lido com certeza encontrou alguém que fala ou programa influenciado por algo que é dito ali.

Então, se você está iniciando na área, é importante ler o livro para entender sobre o que provavelmente seus colegas estão falando. Se você exerce papel de liderança é ainda mais importante ter lido pelos mesmos motivos. O que varia aqui é a intensidade da leitura crítica, que por natureza é menor no primeiro caso, mas obrigatória no segundo.

Aceite: “Código Limpo” é um livro influente por mais que você o deteste (disclaimer: não o detesto, apenas acho raso (o que não tratarei nesta primeira parte)).

A próxima questão é: de que “Clean Code” estamos falando?

Como o conteúdo chega a nós

Platão apontando para o “mundo das ideias” e cagando as regras que complicariam nossa vida no futuro?

Uma historinha de Filosofia

Se você teve a matéria de Filosofia no primeiro ou segundo grau (ou faculdade) provavelmente já ouviu falar sobre o “mundo das ideias” de Platão: se nunca ouviu, te conto o que é.

Segundo Platão para todas as coisas que vemos diante de nós há um equivalente “ideal” em outro plano, o “mundo das ideias” que é a representação conceitual de cada objeto. Então você vê uma cadeira diante de si, mas todas as cadeiras tem uma representação conceitual única no “mundo das ideias”, da qual participam e que as definem como… cadeiras.

Resumindo de forma bem rasa este é o “mundo das ideias” de Platão. Interessante, né? Agora é buscar na obra de Platão onde ele fala do mundo das ideias. Você não encontrará. Ou talvez… sim!

Talvez você encontre “mundo das ideias” em uma edição traduzida para o português. Mas por que eu disse que não encontrará? Por que a metáfora do mundo das ideias foi na realidade criada pelos comentadores de Platão, que a usaram para poder explicar ao leitor como era tratada a questão dos conceitos na obra do autor.

E o processo de tradução de uma obra quando bem feito nunca o é de forma direta, tal como um computador (ou um ingênuo) o faria: o tradutor mesmo que não queira leva para o resultado final do seu trabalho suas próprias pré concepções. E assim o que é dito por um comentador do século XIX vai parar na boca de Sócrates, em um texto de Platão no século V a.C…

(dica: qualquer tradução só pode ser considerada boa quando há um capítulo no livro explicando como foi feita e qual a metodologia aplicada)

No texto original, em grego, não há “mundo das ideias”.

Fontes primárias e secundárias

Fonte primária é o texto original. No nosso caso, o texto em inglês do livro “Clean Code” organizado (nem todos os capítulos do livro são escritos por ele) e escrito por Robert C. Martin.

As fontes secundárias são qualquer conteúdo que comente ou cite o livro “Clean Code”. E sabe o que também pode ser considerado uma fonte secundária? O livro “Código Limpo” traduzido para o português e publicado no Brasil pela editora Alta Books cujo tradutor sequer é citado na capa.

E sabe o que mais pode ser considerado fonte secundária? As interpretações que as pessoas fazem sobre o material, ou seja, o que seus colegas de trabalho dizem a respeito.

Neste momento o leitor deve se questionar: o que sei sobre “Clean Code” é de fato o que foi escrito por Robert C. Martin ou a opinião, interpretação ou releitura de alguém?

E muito cuidado com suas fontes secundárias: elas podem estar erradas e serem muito sedutoras.

Kico, você tá me dizendo então pra só levar a sério o Clean Code em inglês?

Não! Pelo contrário, a edição mais influente no Brasil é a da editora Alta Books e não o original. Logo, para o nosso contexto local, a leitura do original sirva mais para criticar/entender a tradução e entender o que se diz sobre o livro fora do país.

Ler esta tradução pode falar bastante sobre nosso mercado de trabalho atual (foge de mim me aprofundar neste post a respeito, fica pro próximo).

Fonte primária é melhor que secundária?

Não necessariamente. Como o próprio nome diz, a fonte primária apenas diz aonde começa o assunto, não onde ele obrigatoriamente vai ser melhorado.

As críticas feitas ao Clean Code tornaram o assunto “código limpo”, por exemplo, muito melhor e mais rico quer o dito no texto original.

(neste caso o conceito de melhor diz respeito às práticas, não à análise do conteúdo original)

Dogmas

O que é um dogma? É qualquer doutrina defendida como indiscutível. E infelizmente “Código Limpo” é visto e usado desta forma por muita gente. Aí que mora a maior parte dos meus problemas com o livro.

Você provavelmente já passou por situações assim: lhe é imposto um padrão de codificação e então você o questiona. E a resposta final é algo como “Código Limpo”. Você questiona “Código Limpo” e na sequência é fuzilado por olhares ou ações que te acusam de heresia. Quem nunca?

O mais interessante é que na esmagadora maioria dos casos que presenciei o que se falava sobre “Código Limpo” na realidade não era sobre o livro em si, mas sim sobre fontes secundárias.

O livro “Código Limpo” e seu original sofrem as consequências do seu sucesso: criaram uma horda de fanáticos que dificultam a leitura crítica do que ali é escrito.

Os seguidores: a questão da autoridade e o nascimento dos dogmáticos

Quando você publica um livro ou artigo, palestra em eventos, produz conteúdo e este é consumido em massa (em massa = mais de uma pessoa :) ) você adquire autoridade no assunto se for bem recebido.

Afinal de contas em teoria você sabe o suficiente sobre o que diz ao ponto de ter a segurança de se expor. No caso de livros esta autoridade é ainda maior pois este formato (o livro) sempre veio acompanhado de adoração. Culturalmente a escrita quase sempre foi (merecidamente) muito valorizada.

(confesso que nesta época na qual ser contra a ciência virou moda esta autoridade literária me gera alívio)

A autoridade da qual falo tem duas faces: a primeira é a do autor, a segunda é a do leitor, e talvez você ache o que vou dizer agora agressivo.

Não dá pra negar que vivemos em uma sociedade que lê pouco. Sendo assim não é raro que uma pessoa ao concluir a leitura de um livro veja este feito como uma conquista pessoal.

(aqui falo com experiência pessoal pela época em que trabalhei como livreiro (livreiro é aquela pessoa que trabalha em livrarias vendendo e indicando livros))

E terminar um livro de fato é uma conquista pessoal, dado que é muito mais difícil ler um livro que assistir a um filme/seriado/palestra/podcast. A leitura precisa ser ativa, sua atenção precisa ser redobrada, que requer exclusividade no processo e talvez você sequer saiba ler de fato (escrevi sobre isto aqui), o que talvez explique pro que tantas pessoas não gostam de ler.

E as pessoas querem defender sua conquista e o farão com unhas e dentes quando só tiverem lido este livro: nasce aqui o “dogmático do código limpo”. Mas a pessoa não vira este monge dogmático só por ter terminado a leitura, vejo mais fatores aí:

A estrutura narrativa do “Clean Code” leva a isto (é o tema do meu próximo texto, aguarde).
Existe um ecossistema criado ao redor do “Clean Code” que induz ao leitor que aquele é O CAMINHO a ser seguido para se obter qualidade (e você sempre quer estar entre aqueles que considera os melhores)
A insegurança pessoal: se você está dando os primeiros passos e encontra um livro (uma autoridade) que te dá suporte, você naturalmente se agarra a ela.

E ser dogmático na nossa área é péssimo pois tudo é definido pelo contexto e este sempre varia por mais que tentem nos dizer que não.

Como evito ser um “monge do clean code” então? Simples: lendo outros livros. Só assim você vai conseguir ver que há diferentes visões sobre o mesmo tema, muitas vezes contraditórias entre si.

E aqui entra o problema: se estas diferentes visões são contraditórias entre si, qual a correta? A que tá dentro do contexto em que você se encontra.

O processo de catequização

Observo algumas situações o tempo inteiro:

No LinkedIn a pessoa posta orgulhosa uma foto do kit de boas vindas da empresa: nele há uma edição de “Código Limpo”.
Livros são publicados sobre “Código Limpo” que até agregam algumas informações adicionais mas não críticas ou pontos de vista discordantes do que é dito no Clean Code.
O mesmo dito sobre os livros repito sobre apresentações e vídeos e lives.
A pessoa chega na empresa e lhe é dito que deve seguir o “Clean Code” à risca como prática mínima de desenvolvimento sem questionar.
No currículo a pessoa diz que segue “as boas práticas do Clean Code”.
Olhares incrédulos para quem questiona “Código Limpo”.

Observo que é um processo que normalmente surge no topo das hierarquias das empresas (ou dos produtores de conteúdo) como um dogma: regras que devem ser seguidas. Do ponto de vista pragmático e preguiçoso faz muito sentido: em teoria já estão ali no livro as práticas e todas em teoria muito bem justificadas.

(Além disto se alguém questionar você sempre pode soltar a velha carta do “tá no livro, cadê o seu?” pra usar. É prático!)

Problema: quem originou a indicação da leitura o fez de forma crítica avaliando-o em relação ao contexto em que atua? Outra pergunta: quem está indicando o livro possui experiência técnica?

Já vi Clean Code ser indicado pelo RH, donos/gestores de empresas ou por líderes técnicos que só sabem do conteúdo do mesmo por fontes “terciárias”. Não raro motivados por pensamentos como “código é tudo igual”, “programador é tudo igual” e não raro algum trauma com desenvolvimento no passado. É a busca por qualidade usando-se uma solução que parece ser a mais fácil: diligenciar a uma autoridade.

(já vi ser indicado por muita gente boa de serviço também, tá?)

Há uma soma de autoridades aqui: literária, cultural (produtores de conteúdo que são formadores de opinião e portanto manipuladores da cultura) e a hierárquica (empresa/mercado). Você entra em uma empresa ou quer fazer parte, é uma pessoa iniciante, então o que pensa? Vou seguir a dica!

Até aí, problema algum: mas e se não seguir os “mandamentos do Clean Code” e for obrigado a fazê-lo mesmo quando não faz sentido para o seu contexto? Quando se tem experiência, você argumenta, quando não se tem, normalmente se cala por não se sentir seguro para tal.

E após repetidas vezes seguindo os “mandamentos do Clean Code” o que ocorre? Você os aceita e se este for o único livro de boas práticas que leu agora você é um dogmático e sequer se deu conta disto. E quer ver piorar? Você vai ascender na carreira e continuará todo o ciclo novamente.

Isto é triste pois você contrata gente justamente por ser… gente: pessoas que vão pensar diferente e trazer soluções interessantes para o seu dia a dia. Nada contra bons padrões de codificação, mas quando são impostos como dogmas e não como possíveis caminhos a serem seguidos você vê gente sendo tratada como robôs (que podem ser facilmente substituídos) e não como seres criativos (que é onde está o valor).

E isto tudo é feito dentro de um contexto no qual se cria a impressão de que o único livro sobre boas práticas de construção é o Clean Code. Resultado: sua visão de mundo vira o… “Clean Code” seja lá o que é que estão chamando de “Clean Code”.

Por que você tá chamando de catequização?

Por que é a imposição de uma cultura e hábitos sobre outra que não aceita o diferente: que por pura ignorância (e arrogância) impõe uma visão de mundo monolítica, por ser baseada em uma única fonte.

O que narro aqui é esta visão limitada da realidade quando o assunto é qualidade ou boas práticas na construção de software. Uma visão que, inclusive, tal como a dos jesuítas, não é a original, mas sim a resultante de camadas e mais camadas e mais camadas de comentários a respeito sendo que boa parte são no final das contas bobagem.

Como sugiro resolver o problema

Só vejo uma forma: lendo outras coisas além do Clean Code e entendendo que o que há nele é a visão de mundo dos seus autores. Uma visão que não é a única, nem a melhor, nem a pior.

Tenho indicação de livros pra dar? Claro, seguem apenas alguns:

Code Complete – Steve McConnell
A Philosophy of Software Design – John Ousterhout
Trabalho Eficaz com Código Legado – Michael Feathers
The Pragmatic Programmer – Andrew Hunt e David Thomas
Beautiful Code – Andy Oram e Greg Wilson
Refatoração – Martin Fowler (aqui tenho várias críticas, mas é um bom livro)
The Practice of Programming – Brian Kernighan e Rob Pike (yeap: o “cara” do C e do Go)
Os padrões definidos pela sua linguagem (ou linguagens) de programação e sua documentação oficial.
Livros sobre a linguagem de programação também costumam expor boas práticas.

Mas não se baseie nesta lista que passei: busque por si próprio, há inúmeros que não mencionei aqui. O fundamental é ver que há outras visões além do Clean Code.

Continua…

Nesta primeira parte não falei do Clean Code em si. Não disse que é um texto ruim nem bom. Meu objetivo é fazer uma leitura crítica do texto.

Minha crítica aqui foi ao modo como o livro infelizmente é usado. Ok, aí não é culpa do livro, certo?

Não necessariamente. O modo como ele é escrito talvez induza este fenômeno que descrevi aqui.

É a questão que quero levantar no meu próximo post, em que vou analisar a estrutura narrativa do texto que sim, pode alimentar este comportamento dogmático que descrevi aqui.

Até lá!

The post Eu e o “Código Limpo” (o livro) – Parte 1: Catequização appeared first on /dev/Kico.

Minhas boas (e não tão boas) leituras de 2022

Henrique Lobo Weissmann (Kico) — Mon, 01 May 2023 13:52:53 +0000

Aquele post anual que escrevo desde 2011: então pra manter a tradição viva tenho um monte de coisas boas que vi e consumi este ano que compartilho com você aqui. Vão desde livros técnicos (muito bons, outros não tanto), passando por boas leituras de ficção (MUITO boas) e também uma leitura especial que levei vinte (VINTE) anos me preparando para iniciar.

Leitura técnica geral

Como li coisas boas este ano! Começo então pelos que mais me impactaram positivamente.

A Philosophy of Software Design – John K. Ousterhout

Se você já foi guiado por mim sabe que sempre indico livros de formação (Code Completedo Steve McConnell como sendo meu favorito e Clean Code do Robert Martin como o livro que você deve criticar). Sempre senti falta de uma leitura introdutória de boas práticas (estratégias seria um termo melhor) mais leve que o Code Complete para quem está iniciando e acho que finalmente encontrei.

Este livro (bem barato na versão Kindle) na minha opinião é muito importante pelo fato de finalmente alguém estar se contrapondo ao Clean Code. Um problema muito comum que encontro são leitores fãs deste livro que o seguem de forma indiscriminada. Entendo perfeitamente isto, eu mesmo já gostei em excesso do Robert Martin até a ficha cair para o fato de ser um autor que se baseia em sua maior parte em si mesmo e basear boa parte da sua argumentação em afirmações carismáticas mais que em pesquisas realizadas fora de sua bolha pessoal (eu poderia escrever páginas e mais páginas do por quê não recomendo mais a leitura do Clean Code, mas isto fica para outro post).

Os capítulos mais interessantes pra mim foram o segundo (The Nature of Complexity) em que o conceito de complexidade é tratado de forma teórica e prática (muitos insights interessantes ali), os capítulos sobre comentários (12 – Why write comments? The four excuses, 13 – Comments should describe things that are not obvious e 15 Write comments first).

Os capítulos sobre comentários são leitura obrigatória na minha opinião (especialmente o 13) pois são um antídoto as péssimas ideias expostas de forma carismática no Clean Code. Você irá entender por que dizer que “comentários são desnecessários se o código é fácil de entender” são uma grande falácia: por que existem aspectos não óbvios em código fonte.

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable and Maintanable Systems – Martin Kleppmann

Sabe aquela história que você gosta tanto que sente prazer em escutá-la em suas mais variadas versões? Este é meu sentimento em relação a este livro. Apesar de muito denso não aprendi muitas coisas novas aqui por causa da minha estrada e por ter tido a sorte de encontrar excelentes professores ao longo do caminho. Se você está iniciando agora ou não fez faculdade, este é o melhor livro que já encontrei sobre os assuntos ali tratados.

É um livro sobre dados: eu diria que condensa muito bem semestres da matéria “banco de dados” que normalmente é dada nas faculdades. E faz isto muito bem. Tem tudo o que busco em um livro técnico excelente:

Praticamente todas as afirmações feitas pelo autor são fundamentadas em alguma pesquisa.
A narrativa é muito boa: a sequência dos capítulos faz todo o sentido.
É absurdamente bem escrito (é o livro que gostaria de ter escrito).

Você deve lê-lo de cabo a rabo. A primeira parte é sobre os fundamentos: como os dados são obtidos em bancos de dados, esquemas de concorrência, armazenamento, etc. A segunda é sobre sistemas distribuídos: após entender tudo o que pode dar errado em sistemas que executam em uma única máquina você verá os desafios de se ter diversos bancos de dados trabalhando em paralelo. Finalmente, na terceira parte lidamos com processamento em lote, streaming e um pequeno exercício de futurologia ao final.

Minha crítica ao livro? Não ter encontrado uma tradução para o português.

Continuous Architecture in Practice – Murat Herder, Pierre Pureur e Eoin Woods

Foi uma leitura muito enriquecedora não por concordar cegamente mas sim por ter me permitido questionar cada um dos capítulos. Descobri o livro por indicação do Adriano Tavares (sempre me indica bons livros, devia ser livreiro) e coincidiu muito com meu momento profissional no qual a arquitetura passa a tomar mais de 80% dos meus afazeres.

Os princípios da arquitetura contínua são descritos de forma prática neste livro (daí o título). Cada um destes princípios por si só valeria um livro pois levantam questionamentos sobre como pensamos o ofício de arquiteto de uma forma profunda e, no meu caso, extremamente conflitantes. O que o pensamento dos autores diz sobre requisitos fucionais vs qualidade, por exemplo, é um ponto com o qual não consigo concordar, porém me fez questionar tantas coisas que por si só já valeu o investimento na leitura.

O Adriano iniciou uma comunidade só pra tratar destes temas – The Roosters. Vale muito à pena participar se este assunto te interessa. Segue o link: https://theroosters.org/

Um ponto importante sobre este livro: o tempo inteiro faz referências ao anterior, “Continuous Architecture“, que não li. Sendo assim, recomendo que você não cometa meu erro e inicie por este livro.

Outras leituras técnicas interessantes

Os três livros acima foram os que mais me impactaram, mas é importante fazer menção a outros que li no ano que também achei interessantes.

Introdução ao GraphQL – Eve Porcello e Alex Banks

Quer uma introdução interessante aos conceitos do GraphQL? Este livro quase consegue. A primeira parte é realmente muito útil, mas a segunda na qual faz uma narrativa prática é absolutamente dispensável pois é basicamente Apollo, Apollo, Apollo. Quase escrevi um post só falando como é frustrante ler algo que começa tão bem e descamba de forma tão brusca. Primeiros três capítulos: ok, depois… Mais jogo você ler a documentação oficial do Graphql.

Kubernetes Básico: mergulhe no futuro da infraestrutura – Brendan Burns, Joe Beda e Kelsey Hightower

Não sei se Kubernetes será de fato o futuro da infraestrutura pois já é o presente nas ideias que trouxe. E este livro como introdução à tecnologia é excelente. Precisava de um contato inicial com a tecnologia e foi exatamente o que encontrei aqui. Foi tão bom, aliás, que me deu argumentos muito bons não apenas para adotar o Kubernetes mas também para oo contrário (o mais importante na minha opinião).

OAuth 2.0 – Proteja suas aplicações com o Spring Security OAuth2 – Adolfo Eloy

Fazia tempo que eu buscava uma introdução legal pra OAuth 2.0 e finalmente achei aqui uma que chega bem perto. Este livro do Adolfo Eloy é a melhor introdução que já vi sobre o assunto: fácil de entender, os conceitos são bem descritos e a abordagem mão na massa pra quando você precisa implementar os padrões OAuth em seus projetos.

Por que não é perfeito (e é por muito pouco)? Por que ainda faltam alguns detalhes que geram dúvida no pessoal no primeiro contato, e o Spring OAuth 2 por resolver quase todos os problemas em aplicações baseadas em Spring Framework acaba por não expor estes detalhes.

Effective Kafka – Emil Kountanov

Precisei me aprofundar em alguns aspectos do Kafka em 2022: até então o usava essencialmente como mecanismo de mensageria (eu sei.. eu sei…) e este livro foi o que me fez entender diversos pontos do Kafka que fizeram toda a diferença no meu ano. Ele vai desde como você deve projetar suas aplicações, passando por como tunar o Kafka, sua arquitetura, segurança, gestão de transações, armazenamento… Foi de longe o melhor material que já encontrei sobre o assunto.

Blockchain

Em 2021 blockchain entrou no meu radar como um possível mercado para consultorias para a itexto e no ano passado lançamos uma iniciativa interna de pesquisa sobre estes assuntos. Nisto encontrei material muito legal que compartilho aqui com vocês.

Livros do Andreas Antonopoulos

Ao consultar o pessoal que entende muito do assunto (David Gibbin, Armando Dutra, Marco Jardim) este nome sempre aparecia como principal referência. Então eu… li praticamente tudo o que encontrei dele e aqui seguem as minhas impressões.

The Internet of Money – Primeiro, Segundo e Terceiro livros

São as transcrições de diversas palestras do Antonopoulos: todos os três estão inclusive disponíveis no Kindle Unlimited para quem é assinante. O que há de bom: é uma visão de alto nível para o pessoal de negócios sobre cripto moedas e aplicações da blockchain. Ele fala de coisas como defi, criptomoedas, e todas as maravilhas que a descentralização trás.

Você deve ler estes livros com muita cautela e de forma crítica pois pintam um mundo bonito demais pra ser levado a sério. Sinceramente não sei se recomendo ler os três como fiz pois com o tempo vai ficando repetitivo (os assuntos se repetem nas palestras), mas como visão de evolução do autor, é interessantíssimo.

Mastering Bitcoin: Programming the Open Blockchain

Que livro legal: apresenta uma descrição técnica muito detalhada não do bitcoin em si, mas da rede blockchain usada por ele. Todos os detalhes são tratados ali, inclusive como programar para esta rede: é importante lembrar que este livro é de 2017, então se você comprou a versão impressa, algumas coisas vão ter mudado.

“Se você comprou a versão impressa”… este livro foi liberado pela licença Creative Commons, e o texto atualizado pelo autor e corrigido pelos leitores está disponível no Github. Olha que legal: https://github.com/bitcoinbook/bitcoinbook

Mastering Ethereum

Mesmíssima pegada do Mastering Bitcoin, só que voltado para a rede Ethereum. É interessante ter lido antes o livro sobre Bitcoin para entender os conceitos de blockchain.

Os conceitos são muito bem explicados (finalmente entendi o que era o “tal do token”). A primeira metade do livro é expondo a infraestrutura básica do Ethereum e na parte seguinte como funciona o desenvolvimento de smart contracts. Não espere aqui um tutorial de solidity: a linguagem é exposta de uma forma bastante superficial pois não é o objetivo do livro.

Tal com o Mastering Bitcoin aqui também temos o livro liberado como código aberto no Github e atualizado pelos leitores. Link: https://github.com/ethereumbook/ethereumbook

Importante: agora o Ethereum está adotando a proof of stake, e este livro não está tão atualizado, mas como base, é bem legal.

Ethereum

Blockchain Ethereum: Fundamentos de arquitetura, desenvolvimento de contratos e aplicações – João Kuntz

É um livro bem atualizado, de março de 2022, bem no formato popular da Casa do Código, isto é, bem prático. Não é um livro ruim: é dividido em três partes. Na primeira uma descrição arquitetural da rede Ethereum, a segunda o ambiente de desenvolvimento e na terceira algumas questões de segurança.

É um livro ruim? Não. Recomendo a compra? Não, pois batendo o conteúdo do livro com a documentação oficial do Ethereum esta, além de ter grandes partes já traduzidas para o português é fonte primária de informação e portanto mais atualizada e segura. É mais interessante portanto ir direto pra esta.

Documentação oficial do Ethereum

Fiquei encantado com esta documentação. É realmente muito boa e trás tudo o que a gente precisa para entender como a rede funciona e também pra já poder ir pondo a mão na massa e ir desenvolvendo os smart contracts.

O Learn Hub é muito impressionante, e a seção “basics” pra ter uma visão de negócio e “Ethereum protocol” pra entender como as coisas funcionam por baixo dos panos é realmente muito interessante. Mas cuidado: por ser a documentação oficial há aqui uma visão muito enviesada positivamente sobre a tecnologia. Leia de forma crítica tudo o que encontrar. Busque ler sobre limitações do Ethereum e principalmente sobre os custos.

Link pro site do Ethereum: https://ethereum.org/en/learn/

Leituras não técnicas

Por “não técnicas” entenda não diretamente relacionadas a desenvolvimento de software (no final das contas tudo tá relacionado).

Literatura geral

Planeta dos Macacos – Pierre Boulle

Que livro! Se em 2021 o livro que me impressionou foi “Laranja Mecânica”, em 2022 sem sombra de dúvidas foi “Planeta dos Macacos”. A ideia de nós, humanos, não estarmos mais no topo da cadeia alimentar e de repente sermos vistos como animais de estimação é incrível.

O livro te faz pensar muito sobre a questão da racionalidade animal (eras atrás quase fui pra este ramo de pesquisa enquanto aluno da Filosofia, mas ao ser apelidado de “Dr. Doolittle de BH” desisti da ideia (shame on me)) tratada no livro é incrível. Você começa a se questionar se o conceito de civilização é estritamente humano e mesmo se o modo como tratamos nossos animais de estimação é o mais adequado.

E o final… épico.

Nunca mais olhei pra Kica do mesmo modo. :)

Kica

Tropas Estelares – Robert Heinlein

Eis um livro que meu preconceito impedia de levar a sério (sempre lembrava do filme). Aí um dia resolvi dar uma chance e… no contexto da guerra da Ucrânia rolando… QUE LIVRO!

Achei que seria apenas um livro de ação boba de humanos lutado contra uma espécie alienígena que no final descobriríamos ter sentimentos, mas não: é muito mais que isto. Pra começar são pouquíssimos os chavões. Há reflexões aqui sobre a natureza da guerra que me chamaram muito a atenção.

Claro, não é um livro perfeito: há longos períodos de puro tédio no qual se descreve os pormenores da vida das tropas, mas estas reflexões (os diálogos com os generais e professores especialmente) valem a leitura.

Children of Time – Adrian Tchaikovsky

Um livro que me caiu em mãos por absoluto acaso. A sinopse me ganhou: no futuro a humanidade busca um novo planeta para habitar e salvar a espécie e o encontra. Então desenvolve um vírus a ser aplicado em macacos para que evoluam neste novo habitat: um acidente faz com que o vírus não atue sobre os macacos mas sim sobre… aranhas que desenvolvem sua própria civilização enquanto a humanidade está a caminho para habitar este novo planeta.

COMO NÃO VOU LER ALGO COM ESTA SINOPSE??? Uma civilização de aranhas? Como seria a cultura desenvolvida? Como seriam aranhas racionais, como interagiriam entre si?

(olha o tema da racionalidade animal voltando)

E a pergunta mais importante de todas: como nós, humanos, conseguiríamos (será que é possivel?) nos comunicar com uma espécie totalmente alienígena?

Descobri que tem tradução para o português, mas li em inglês. Há lá alguma cafonice no texto, mas a ideia é muito legal.

Um mundo que não foi feito para humanos ou que humanos são pets? hmmm…

Assista este filme, você vai gostar.

Ciências sociais e filosofia

Coisas interessantíssimas aqui: e para uma delas me preparei 20 anos. Vamos lá.

Pele Negra, Máscaras Brancas – Frantz Fanon

Que livro maravilhoso: foi sem sombra de dúvidas uma das leituras que mais impactou meu ano. O que me surpreende (e ao mesmo tempo é bastante ilustrativo) é o fato de tê-lo descoberto por acaso ao ouvir este episódio do podcast “History of Indian and Africana Philosophy”.

Fanon descreve com uma escrita muito particular (é incrível o modo como escreve, realmente muito interessante) os efeitos psicológicos do racismo e do colonialismo sobre nós, os colonizados. Frantz Fanon escreve sua experiencia nas Antilhas, mas enquanto brasileiro me identifiquei bastante com o que é narrado ali.

O modo como ele expõe a manifestação dos preconceitos através da linguagem e literatura é fenomenal. Leitura fascinante: que livro, que livro, que livro!

O Capital – Livro 1 – Karl Marx

Quando entrei no curso de Filosofia em 2001 me disseram: “há autores que você deve evitar ler durante o curso se é muito jovem, tal como Marx, pois ele vai enviesar sua visão do mundo e ferrar o restante do seu curso”.

Aí ano passado apareceu o Livro 1 do Capital no Kindle Unlimited: comecei e ler, me interessei e acabei comprando a edição impressa da editora Boitempo cuja tradução foi feita pelo Rubens Enderle. Dias depois chega um pacote do tamanho de um tijolo para mim: era o livro.

Esta edição é maravilhosa: contém uma série de artigos de Jacob Gorender, Althusser e Giannotti que devem ser lidos ates de chegar ao texto em si. São muito bons e dão a contextualização que precisamos pra ler o texto.

Finalmente, chegando ao texto, me impressionou MUITO a riqueza de referências que há ali: vai desde Balzac até elementos de química. Não é um texto fácil, é fundamental ter o contexto histórico para não termos uma leitura pobre da obra e, mais importante, tentar se distanciar ao máximo de preconceitos que temos em relação a Marx (o termo marxismo hoje é carregado de uma série de preconceitos que se não for levado em consideração na leitura irá destruir sua experiência).

O primeiro capítulo sobre o conceito de Mercadoria deveria ser lido por todo desenvolvedor (principalmente pelo pessoal que gosta tanto de cripto moedas). Tem sido uma leitura muito enriquecedora, mas difícil. Você pode precisar de ajuda, sendo assim segue minha última dica de leitura.

Para entender o Capital Livro 1 – David Harvey

Estou lendo o livro 1 do Capital junto com este livro do David Harvey que vai dando o contexto histórico político em que a obra foi criada. É uma leitura muito bacana pois vai tratando capítulo por capítulo do livro 1.

Então você pode ir lendo de forma concomitante os dois, como se fosse um curso universitário.

Concluindo e adicionando um pouco mais

Nem só de livros foi o ano, mas muito violão também (acho que não compensa colocar aqui o que li a respeito) cujo progresso fui registrando no YouTube. Mas dentre as coisas que mais gostei sem sombra de dúvidas foi minha assinatura da Darkflix. O app é horrível, mas o acervo de filmes de terror que eles tem é maravilhoso. Dentre os flmes excelentes que vi:

Peixe Cru (genial)
Crimes do Futuro
Mary Morbida (genial)
Além da Imaginação (a série clássica)
V (a série clássica, não lembrava ser tão poucos episódios)
Viagens Alucinantes
A Descendência
E mais uma infinidade de filmes horríveis que adoro

Música foi muito John McLaughlin, Mike Stern, Miles Davis, Al di Meola, Larry Coyrell e outros que inclui nesta playlist.

Basicamente, é isto. 2023 chegou e tem livros que quase pararam nesta lista. Só não entraram por que… é 2023.

Mas estou pensando em durante o ano fazer reviews mais detalhados aqui destes livros. Vamos ver.

The post Minhas boas (e não tão boas) leituras de 2022 appeared first on /dev/Kico.

Minhas boas leituras de 2021

Henrique Lobo Weissmann (Kico) — Mon, 04 Apr 2022 08:31:20 +0000

O projeto MundoKico

Acho que posso dizer que 2021 foi 2020 com esteroides: a pandemia continuou e com ela nosso isolamento social. Mais tempo longe do contato físico com os colegas e amigos acabou por ter efeitos inesperados em mim, razão pela qual antes de falar sobre os livros que li (foram tantos!) falo sobre o projeto que prometi ano passado, o MundoKico.

Minha ideia era criar um blog e um canal só pra poder falar durante todo o ano sobre as coisas que ia lendo. Acabou acontecendo mas de forma totalmente inesperada. Apesar de ter sido um ano glorioso pra itexto também foi um período muito difícil pra mim pessoalmente, então acabei reatando contato com um velho melhor amigo: o violão clássico.

Apesar de ser quase auto didata neste aspecto resolvi após quase 20 anos (ou 20 anos?) voltar a ter aulas (na adolescência fiz curso de musicalização e piano na Fundação de Educação Artística de Belo Horizonte) pra me aprofundar no assunto a partir do meio do ano. Comecei tendo aula de harmonia e improvisação com o Magno Alexandre, que é um músico de Jazz maravilhoso aqui de BH e que você deveria ouvir (link pro Spotify dele): tem sido uma luta fantástica por que são assuntos muito difíceis pra mim e a vivência que o Magno me passa é única. Aí depois veio o Gustavo Bracher que tá lapidando minha técnica de violão e é um monstro tanto no violão quanto na didática (aqui tá o canal dele no YouTube). Ambos estão me levando pra um outro nível da coisa e tem me feito um bem danado!

Então o projeto MundoKico acabou virando... eu tocando violão sem parar, o que você pode acompanhar neste canal que criei pra poder compartilhar com estes dois gênios que citei acima o meu progresso.

Esta minha volta ao violão em parte foi motivada também por experiências bastante negativas que tive nas redes sociais ano passado e final do ano retrasado sobre as quais só direi isto: a consequência principal foi decidir me afastar do "mundo dev". Não mais escrever no blog, paralisar o projeto do livro que estava atualizando e me focar apenas naquilo que realmente fosse o essencial e valesse à pena pra mim, minha família e meu time.

Isto quer dizer que na realidade produzi muito conteúdo que não foi publicado (será este ano), li muito mais e, mais importante: que estes limões serviram pra que eu não fizesse uma limonada, mas sim uma infinidade de variedades cujos frutos serão vistos este ano e nos seguintes. Aprendi pra daná!

Então vamos aos livros?

Aviso

Os livros que gosto não necessariamente são aqueles com os quais concordo e a visão que mostro a respeito do conteúdo que exponho aqui é pessoal. Eu não gostar de um livro não quer dizer que ele seja ruim: livros ruins eu sequer cito para que você não corra o risco de os ler (só vou te indicar se não gostar de você mesmo, ok?).

E não fique triste se xingar muito um autor aqui ou indicar alguém que você não gosta.

Livros técnicos

Foi um ano de releituras importantes. Então começo por um autor que foi um conflito pra mim começar a letura.

Releituras

Robert C. Martin (o "Uncle Bob")

Em 2019 notei várias críticas a este autor referente às suas opiniões políticas que são inclusive incompatíveis às minhas. Surgiu o conflito: devo consumir conteúdo de alguém com estas posições? Seria ético? É possível separar o autor da obra? Depois de muito "matutar" noto que estes são problemas provavelmente insolúveis e alguns fatores me levaram a dar uma segunda chance:

Meus sentimentos conflitantes em relação ao "Clean Code". A primeira leitura que fiz deste livro foi muito ruim: me soou raso, a linguagem me parecia artificialmente pessoal (talvez fruto da tradução?).
Apesar de tudo o autor tem um papel muito importante na formação técnica dos profissionais brasileiros. Sempre há citações, então talvez a minha primeira impressão estivesse errada e, mais importante: isto me ajudaria a entender melhor o modo como nós, brasileiros que programam, pensamos e somos formados.
Sempre li o que quis independente da opinião alheia: bastou me lembrar disto para resolver o conflito na hora.

Clean Code - Código Limpo

Normalmente quando as pessoas entram pra área de desenvolvimento (especialmente os auto didatas, como é o meu caso (só depois que entrei pra faculdade)) optam como primeiras leituras livros sobre linguagens de programação ou frameworks, o que hoje vejo como um erro. Eles até mostram boas práticas, mas voltadas para aquele contexto específico (o da linguagem ou framework), não vão além (deveriam?).

Na outra ponta há os livros de formação que vão tratar das "coisas que você deveria saber" sobre o ato de programar, são as boas práticas e as armadilhas do dia a dia. Código Limpo entra neste grupo. Se for o seu primeiro livro neste assunto é um bom livro. Você vai ler sobre como tratar exceções, escrever boas classes, concorrência, etc. Temas que são vistos em detalhes na faculdade condensados nestas páginas.

Como uma introdução, é um bom livro: como guia pro resto da sua carreira é raso.

É um livro pequeno que não assusta quem está dando os primeiros passos. A linguagem do autor é até agradável: passa a sensação de alguém experiente te contando as dores pelas quais já passou com algumas pitadas de "rabujice amável".

Meu problema com Clean Code é que antes eu havia lido algo muito melhor que é o Code Complete do Steve McConnell. Acho muito difícil alguém que tenha lido antes o Code Complete não achar Clean Code raso.

Se vai pegar o seu primeiro livro de formação, pega este, não o Clean Code!

Code Complete vai muito além do Clean Code: é mais aprofundado e tem muito mais conteúdo. Trata, por exemplo, do relacionamento com membros da equipe, algo que quem está começando não leva em consideração e é tão importante ou mais (na minha opinião, bem mais) que boas práticas de codificação.

Mostra estratégias adicionais de desenvolvimento (baseada em tabelas, por exemplo), mas possui uma linguagem mais técnica. Enquanto no Clean Code temos o "programador experiente", aqui estamos lidando com um "consultor experiente". Há mais referências sendo citadas e também mais ferramentas (as checklists brilhantes ao final dos capítulos são um exemplo) que te agregam ao final. É muito menos subjetivo que Clean Code e isto é necessário para que os iniciantes não caiam na tentação de reproduzir estereótipos tolos.

Então por que as pessoas falam mais do Clean Code que do Code Complete? Não sei mas especulo: na itexto temos ambos os livros e não raro os iniciantes se assustam com o Code Complete quando notam ser um livro bem mais grosso e com fonte menor. Talvez seja esta primeira impressão, mas não raro os que optam pelo caminho do Code Complete acabam tendo uma formação inicial bem melhor.

Veredito final agora: continuo achando Clean Code uma introdução bem leve e rasa às boas práticas, mas também amando o capítulo sobre nomeação de variáveis, funções e classes (segundo capítulo) uma das melhores coisas que já li e indico para toda a minha equipe sempre.

Arquitetura Limpa - Clean Architecture

Desta vez li duas vezes pra confirmar que realmente é um livro do qual adoro discordar, o que enriquece a leitura: me ajudou a confirmar diversas das opiniões que tenho e sobre as quais é bem possível que venha a escrever algo aqui no futuro a respeito.

Se você leu Clean Code como seu primeiro livro de formação, então leia Arquitetura Limpa logo na sequência pois é um complemento na minha opinião obrigatório para que fique claro como os princípios expostos no primeiro se aplicam em situações reais.

Clean Architecture tem como objetivo ser uma introdução à Arquitetura de Software, mas aqui temos uma visão muito pessoal do que é a arquitetura de software. Sendo assim, se você não leu Clean Code, a melhor forma de ler este livro é saber que "é a visão pessoal do Robert C. Martin sobre o assunto e suas experiências a respeito", ok? Se você ler sob este viés vai ter uma experiência muito rica, caso contrário é possível que você só discorde e a coisa morra aí, o que seria uma pena.

O livro tenta trazer uma visão de alto nível para o desenvolvimento: o que é arquitetura (na opinião do autor), o que são valores, paradigmas de programação até chegar em "princípios de design". Estes princípios são o SOLID, cunhados pelo próprio autor, só que agora aplicados a elementos de mais alto nível (componentes, sistemas). A coisa fica interessante neste momento, mas se estende demais, ao ponto de ficar repetitiva. Daí vai tratar de conceitos como dependências entre elementos da arquitetura, limites, etc.

Como uma introdução é legal: se você quer se aprofundar, fuja daqui. Todos estes assuntos já li inúmeras vezes na minha vida profissional, então a coisa fica tediosa pra mim, mas não pra quem tá começando. Há inclusive alguns exemplos práticos e experiências de vida do autor que agregam bastante.

O que realmente gosto deste livro é o capítulo 29 sobre arquitetura de software embarcado. Se eu pudesse ter um "Clean Architecture" a la carte só compraria este capítulo. Não pelo que é dito sobre software embarcado (é só o óbvio pra quem conhece o assunto), mas sim sobre os insights que me trouxe sobre software legado. Se for ler este livro, preste muita atenção neste capítulo específico.

Trabalho Eficaz com Código Legado - Michael C. Feathers

Esta releitura foi a mais importante do ano pra mim e que realmente agregou. Continuo achando a definição de "software legado" aqui péssima: "é software sem testes". Sobre isto inclusive já escrevi bastante aqui no blog. Péssima por que reduz toda uma categoria de software a um problema que seria a ausência de testes, simples assim.

Tirando esta definição ruim de código legado, se lido como um guia de refatoração é fantástico, inclusive muito melhor que o Refactoring do Martin Fowler. O modo como as técnicas são tratadas aqui são excelentes e o que gosto muito é que não são simplesmente regras lançadas a esmo, é exposto também como aplicá-las.

Aprendizado de máquina - Machine Learning

Fiz um bootcamp este ano sobre machine learning para me atualizar sobre o assunto, adquirir vocabulário e obter novas referências para que pudesse me aprofundar a respeito não enquanto desenvolvedor, mas sim gestor para poder participar mais ativamente junto com a equipe da itexto na execução de projetos nesta área (a empresa cresceu tanto que não participo mais de todos os projetos, acredita?).

Foi uma experiência válida (apesar de bem pobre) pra que eu pudesse solidificar alguns conceitos e também ler coisas interessantes a respeito. E deu muito certo: hoje temos projetos muito bem sucedidos nesta área!

Foco em estatística primeiro

Algo que ficou claro no bootcamp que fiz: os instrutores chegavam mostrando os diversos algoritmos mas qusae não mencionavam a base estatística da coisa. Resultado: pessoas boiando entendendo muito pouco do que lhes era apresentado. Então voltei pros meus livros de estatística e sigo com uma releitura e um livro novo que me ajudaram bastante.

Estatística - O que é, para que serve, como funciona - Charles Wheelan

Já falei deste livro aqui e volto a indicar: é uma introdução aos conceitos da estatística descritos por um jornalista. Então te fornece uma visão de altíssimo nível mas, mais importante, o vocabulário pra que você possa mais a frente se aprofundar nos assuntos tratados.

(dica de estudos: sempre comece aprender algo pelo vocabulário, caso contrário você sequer consegue escrever uma busca no Google)

Mais que apresentar o vocabulário, Wheelan também ensina o autor a como interpretar notícias que usam estatísticas como base, o que te fornece uma visão muito mais crítica não só no mundo técnico mas social também. Por isto sempre recomendo este livro.

Estatística Prática para Ciência de Dados: 50 conceitos essenciais - Peter Bruce e Andrew Bruce

Recomendo ler este segundo livro na sequência pois aqui já temos uma visão mais matemática da estatística. Foi a partir da leitura deste livro que os conceitos de machine learning passaram a fazer bem mais sentido pra mim.

Ferramental de Machine Learning

É um livro no formato técnico clássico e faz exatamente o que se propõe: vão ser apresentados os conceitos estatísticos essenciais passando por análise exploratória de dados, regressão, classificação, etc.

Ferramental de Machine Learning

Uma outra falha no bootcamp foi uma apresentação extremamente rasa das ferramentas de machine learning, então precisei correr atrás. Ano retrasado já havia iniciado um estudo mais intenso de Python, o que me ajudou bastante, mas eu precisava de um livro que pudesse condensar estas ferramentas para que, enquanto gestor/arquiteto, pudesse participar mais ativamente destes projetos na itexto. Então encontrei o livro abaixo.

Mãos à Obra: Aprendizado de Máquina com Scikit-Learn & Tensor Flow - Aurélien Géron

Se tivesse visto este livro antes não teria feito o bootcamp, simples assim. É um guia que vai além das ferramentas, mostra também os principais algoritmos de machine learning e os conceitos envolvidos. Novamente segue a minha dica: só vá para este livro se você já tem os conceitos de estatística fixados na sua cabeça, caso contrário será uma leitura bem rudimentar da coisa (vai te faltar vocabulário).

A didática do livro é bem legal: você na prática irá executar alguns projetinhos e com eles experimenta a aplicação destes conceitos na prática.

Rust

Tá aí uma tecnologia que me impressionou muito este ano. Aprendi horrores a respeito e inclusive publiquei um guia de estudos pra quem está começando que pode ser acessado neste link que contém inclusive uma bibliografia comentada que aumenta bastante este post.

Mas é importante fazer uma menção honrosa a um livro em particular:

Rust: Concorrência e alta performance com segurança - Marcelo Castellani

É publicado pela Casa do Código e já ouvi falar que estão trabalhando em uma segunda edição. Simplesmente é o melhor livro sobre Rust que já li e em português. Foi graças a este material (e principalmente o Júlio Brito) que a tecnologia se viabilizou na itexto e tivemos um projeto de muito sucesso com ela.

É leitura simples e bem guiada, que dá um caminho muito bom pra quem está começando e o melhor: 100% nacional!

Building Microservices: Designing Fine-Grained Systems - Sam Newman

É raro encontrar livros tão densos quanto este: em aproximadamente 250 páginas vai te dar uma aula sobre como projetar micro serviços mostrando não só o lado vendável da coisa mas, mais importante: os desafios.

Todos os conceitos essenciais de micro serviços são abordados nestas poucas páginas: definição de domínio, monitoramento, segurança, integração, testes, implantação, escalabilidade... e vai inclusive além quando trata da lei de Conway, segundo a qual as empresas tendem a expor sua organização interna nos sistemas que usa/produz. É leitura obrigatória se você quer se aprofundar nestes assuntos.

Cito este livro por que finalizada a leitura uma pergunta vinha à minha mente: como a gente foi parar em um mundo tão complexo? Seria esta complexidade toda realmente necessária ou nós que nos colocamos nela? Estas questões tomaram boa parte do meu ano.

Apostila Microservices com Spring Cloud - Alexandre Aquiles

O título é péssimo pra melhor coisa que já li sobre micro serviços. Apesar do Alexandre usar o Spring Cloud como ferramenta que guia o leitor durante todo o material, ele é usado apenas como ferramenta de apoio. Tirando isto, são expostos todos os conceitos por trás dos micro serviços e com inúmeras referências ali.

Há a parte prática com Spring Cloud que ajuda bastante e inclusive já vi ser aplicada "as is" em alguns projetos legados que toquei e ela é muito bem descrita.

O mais interessante destas referências é que, ao contrário do livro do Sam Newman, estas são locais, pessoas daqui, do Brasil, ou seja: são casos próximos a nós. E o aprofundamento conceitual também é fenomenal: o Alexandre levanta várias questões ao apresentá-los e vai muito além de uma mera apostila.

Aliás... não é uma apostila, é um livro que deveria ser publicado como tal.

E está totalmente acessível de graça neste link do Github. Fantástico termos outro material nacional de altíssimo nível nesta lista, hein?

Livros não técnicos

Houve um tempo em que via a minha menção a livros não técnicos como algo "off topic": hoje já vejo como algo totalmente "in topic" pois está bem claro pra mim que os melhores profissionais são aqueles que vão bem além do teclado. Faz todo o sentido se você pensar que software interage com o mundo humano.

Laranja Mecânica - Antony Burgess

No meu post do ano passado disse que estava finalizando Laranja Mecânica e só o fiz em janeiro, então ele entra nesta lista. Mas mais do que isto: foi o livro que me acompanhou durante todo este período graças à minha relação com Alex, o protagonista.

Burgess mostra neste livro como a linguagem e a ignorância de Alex expõem sua visão de mundo (determinismo linguístico clássico!). Enquanto parte de um grupo extremamente ignorante ao ponto de, por falta de vocabulário (notaram como estou usando esta palavra aqui?) criar um idioma próprio e depois, mais vivido e culto, o abandono deste vocabulário próprio e adoção de um mais civilizado, deixando pra trás seu passado criminoso.

Enquanto alguém de 42 anos (43 dia 9) me pegava pensando no meu duplo papel enquanto leitor: como alguém mais velho que interage com uma geração mais nova e me lembrando quando era mais jovem e como interagia com a geração mais velha. Este diálogo interno entre mim, Alex e o mundo enriqueceu horrores o meu ano.

A Peste - Albert Camus

Já que estou em uma pandemia, por que não, né? Neste caso foi quase uma releitura, pois meu primeiro contato com este livro se deu quando tinha uns 16, 17 anos. E ao reencontrá-lo em 2021 percebi que não havia entendido NADA daquela primeira leitura. :D

É fascinante você observar os paralelos entre a realidade descrita por Camus e o que vivemos neste ano. A desinformação, o momento em que negamos uma realidade que pode se mostrar terrível, a aceitação da mesma, o pânico... é quase uma descrição de 2020 e 2021 aqui no Brasil. Valeu cada página.

Lula, volume 1: Biografia - Fernando Morais

Em tempos polarizados (será que estamos tão polarizados assim hoje?) mencionar uma personagem como Lula pode gerar reações interessantes. O que posso dizer então? Goste ou não de Lula (o curioso da pessoa que me critica por ter lido a biografia do Lula mas lê a do Hitler...), pode ler esta biografia, é magistral.

É uma biografia diferente: não segue o formato clássico do momento do nascimento até o último momento da personagem. Começa a narrativa a partir da prisão de Lula em 2018 e faz uma narrativa quase que de hora em hora do que aconteceu. É Fernando Morais clássico: se você já leu os outros trabalhos dele sabe o que vai encontrar.

Pode ler como literatura, é certo que você vai gostar e muito da coisa. Há os que dirão que é um material político... com certeza é, mas se for pra ser, que seja algo muito bem escrito pelo menos. Fazia muitos anos que não lia uma biografia tão boa.

A Criação do Patriarcado: História da Opressão das Mulheres pelos Homens - Gerda Lerner

É um soco no estômago enquanto homem este livro: que narra desde a antiguidade até os tempos atuais como foi criado o patriarcado e de que formas se manifestou a opressão às mulheres e as hipóteses apresentadas pela autora são fascinantes. Se você gosta de história tá aí um belo livro: muitas referências e uma pesquisa claramente muito bem feita. Me impactou bastante.

A introdução escrita para esta edição por Lola Aronovich já te ganha. Está disponível no Kindle Unlimited caso você seja assinante.

O Genocídio do Negro Brasileiro - Abdias Nascimento

E aqui um soco no estômago enquanto branco: este livro do Abdias Nascimento me foi indicado pela Nanna para que fosse lido. Tem uma história curiosa: o texto aparece pela primeira vez em 1977 para ser apresentado em um congresso na Nigéria e que é duramente sabotado por mostrar, já naquela época, uma visão sobre a história brasileira discordante da que nos foi imposta pelos militares durante a ditadura e que tem seu retorno com os bolsonaristas atuais.

É importante ler este texto hoje pra que tenhamos uma visão mais dura da monstruosidade a que foram submetidas estas pessoas e pra entender que sim, há uma dívida histórica.

Uzumaki - Junji Ito

Eu pagando língua aqui: sempre achei animes muito, muito, muito chatos. Mas ouvi um episódio do podcast Mundo Freak Confidencial que me deixou curioso sobre o autor e... que negócio maluco! Que narrativa bizarra! Me ganhou.

Primeiro por que como nunca tinha lido um anime (então como eu achava "muito muito muito chato"? puro preconceito) então li ao contrário primeiro. Aí vi que tinha de ler do outro modo. Dos dois modos gostei bastante. Leria mais coisas do autor? Não: confesso que me exauriu ali, mas fica aqui minha sugestão de quadrinho pra quem curte pois realmente gostei muito deste.

1177 B.C: The Year Civilization Colapsed - Eric H. Cline

Você sabia que houve um colapso civilizatório neste ano? Eu também não: e este livro que descobri por acaso quando o YouTube me mostrou este vídeo chamou muito minha atenção então acabei com este material em mãos.

E é fascinante e assustador como Cline faz paralelos entre o que ocorre na era do bronze e os tempos atuais. Como uma curiosidade histórica é bem interessante. Não cheguei a buscar críticas a este livro, mas como leitura, vale à pena. Tem no Kindle.

Projeto pra leituras de 2022

Enquanto escrevia este post não me saia da cabeça a impressão de que estava esquecendo algum material que tenha me sido importante. Talvez não tenha sido tão importante assim já que o esqueci, mas poderia ter sido importante para alguém que leia este blog. Sendo assim vou tentar durante este ano ir publicando aqui as coisas interessantes que leio. Não prometo, mas vou tentar, ok?

Que 2022 seja melhor que os dois anos anteriores que tivemos.

https://www.youtube.com/watch?v=5V9i6ndGwD8

The post Minhas boas leituras de 2021 appeared first on /dev/Kico.

O que pode prejudicar seu aprendizado no desenvolvimento de software

Henrique Lobo Weissmann (Kico) — Mon, 04 Apr 2022 05:06:07 +0000

Conforme a empresa cresce boa parte do meu tempo hoje é investida na formação de pessoas que estão iniciando na carreira de desenvolvimento de software na itexto, InvestTools ou em nossos clientes. Esta experiência já tem uns bons anos (desde a fundação da itexto) e acabei detectando alguns padrões que dificultam muito o processo de aprendizado de quem está dando os primeiros passos na área. Antes de começar, dois pontos importantes:

Esta não é uma lista exaustiva, mas sim os comportamentos que observo com maior frequência: leve em consideração que estou tratando do meu ambiente de trabalho que pode ser (e é) bem diferente do seu.
Estou escrevendo para quem está começando a programar e sente dificuldades em assimilar tanto conteúdo e não para aqueles que tem como função formar estes profissionais.

Ilusão de poder

É fácil se enganar achando que desenvolver software é fácil: não é, e pela minha experiência tem se tornado mais difícil com o tempo (na minha opinião involuímos (nota mental: escrever um post mostrando historicamente como isto ocorreu)). Acredito que dois fatores criam esta ilusão, sendo primeiro deles a volta da oralidade.

(Na minha experiência a maior parte dos desistentes existe ao caírem nesta armadilha)

A volta da oralidade

"Volta da oralidade"? Na Grécia arcaica dominava a oralidade: a Ilíada e a Odisseia, textos fundadores da cultura Grega, eram passados oralmente. Com o tempo a escrita substituí a oralidade e gera questionamentos na época: no Fedro (de Platão), Sócrates chega a dizer que apesar da escrita parecer ser um remédio para a memória, na realidade seria um mal (ironicamente este diálogo é escrito).

Em tempos recentes algo similar volta a acontecer: o YouTuber é o novo Homero, só que muito mais carismático. Não me leve a mal: há material MARAVILHOSO publicado (talvez a maior parte) tanto no YouTube como na forma de cursos online baseados em vídeo. São bem produzidos, os autores de uma eloquência incrível, gente muito bem preparada mesmo. Porém não raro há uma falha que pode ser fatal: raríssimas vezes há erros nas gravações. Tudo flui com perfeição: o código é escrito de tal forma que funciona de primeira. Iniciante, não se engane: as aulas sempre são ensaiadas (até pra que tenham a qualidade que tem).

(é por isto que meus treinamentos sempre são ao vivo: todos aprendemos HORRORES com meus vacilos (que não são raros)!)

E aqui o problema não está em quem produz conteúdo, mas no espectador pelo modo como o consome passivamente. Todo conteúdo didático deveria ser consumido como um diálogo entre espectador e autor, não como se fosse um filme de ação. Então, como você, iniciante, deveria consumir este conteúdo? Seguem algumas sugestões:

Não use a funcionalidade de aceleração de conteúdo: a informação não é transmitida apenas pelas palavras, mas também pela entonação do autor. Uma pausa pode representar, por exemplo, uma ironia.
Use e abuse da possibilidade de poder assistir o mesmo trecho várias vezes: não entendeu o que a pessoa disse? Volte e assista de novo quantas vezes for necessário.
Questione o que está sendo dito: ouviu o que a pessoa disse, será que está certo mesmo? Mentalmente você consegue conceituar aquilo que foi dito?
Se é código fonte sendo exposto, programe junto! Pause o vídeo: abra seu editor ou IDE e experimente o código exposto por si mesmo. Evite copiar me colar: digite. Deu errado? Tente de novo até entender aonde está seu erro.
Tem dúvidas e existe um canal de comunicação? Use-o! Não tenha vergonha de perguntar: é obrigação moral de quem está instruindo considerar todas as dúvidas válidas.
Há exercícios? Faça-os e no processo pense em como o conteúdo apresentado se relaciona aos problemas que você está resolvendo.
Não há exercícios? Invente os seus próprios, se questione sobre o que está aprendendo.
São mencionadas outras fontes no conteúdo? Se sim, explore todas, se não, desconfie do curso (mais sobre isto falo neste link).

Resumindo: tenha paciência no consumo do conteúdo e o faça de modo interativo e não passivo. É por isto que como avaliador (e não só eu) não dou tanto valor a "certificados de conclusão" de cursos online: como saber se você de fato interagiu e aprendeu no processo?

Agora posso ir para aquela que considero ser a segunda causa da "ilusão de poder": você pode estar aprendendo ao contrário.

Aprendendo ao contrário

Os aprendizado é construído como sedimentos, de baixo pra cima

Todo conhecimento (ou quase todo (desenvolvimento de software com certeza sim)) se constrói de forma sedimentar. Você aprende alguns conceitos elementares, fixa-os em sua mente (os sedimenta), brinca com eles, tenta aplicá-los a elementos do seu dia a dia (a la Paulo Freire).

Na sequência, com base nestes conceitos elementares, que agora formam uma camada em sua mente, começam a ser depositados conceitos e ideias baseados na camada abaixo. E segue assim sucessivamente, sempre criando novas abstrações sobre o que já está sedimentado. Há vezes em que você irá sedimentar camadas que ultrapassam mais de uma abaixo, mas elas vão se montando, e com o tempo, tal como na imagem acima, você passa a entender como as camadas foram se formando.

Você não aprende a escrever frases sem antes aprender as palavras e as letras, o espaço... Aí na sequênciaaprendemos diferentes tipos de pontuação (a exclamação, a interrogação, as reticências...), e aí você começa a escrever seus primeiros parágrafos, textos, capítulos, livros.

No desenvolvimento de software vejo ocorrer o contrário: a pessoa aprende primeiro o framework (React Native, por exemplo), no meio do processo uma coisa no meio é exposta de forma praticamente acidental (a linguagem (JavaScript, TypeScript, outra qualquer)), surgem umas ferramentas que compilam seu projeto e de repente ele tá executando no seu celular como mágica.

Não raro o primeiro projeto aprendendo assim costuma dar certo por serem coisas bem simples (lista de to-dos...), mas passado pouco tempo você começa a se sentir perdido por não entender COMO as coisas funcionam, POR QUÊ é deste jeito? Por que não funciona mais? Por que tá dando tão errado?

Eu adoraria que tivéssemos evoluído ao invés de involuir tecnicamente, mas você precisa conhecer os fundamentos se quiser ir além de projetos que servem como introdução a frameworks e ferramentas. Há uma pletora de coisas que é necessário conhecer: a linguagem de programação, lógica de programação (há quem diga que não, mas não levo a sério este papo), algoritmos, o que vêm a ser um framework de fato, aonde seu código irá ser executado...

É muita coisa: talvez você não tenha tempo de aprender tudo isto. Talvez a faculdade não seja uma opção pra você (eu mesmo só fiz faculdade anos após estar no mercado (sim, recomendo muito)), talvez você tenha sido aceito em um novo emprego, usem uma ferramenta e você precise aprendê-la rápido. Então, o que sugiro?

Busque os conceitos durante o aprendizado - se vai começar aprendendo ao contrário, na leitura do material busque identificar os conceitos. Identificou os que acredita ser essenciais? Se possível, pare o que está fazendo e busque uma definição rápida dos mesmos.
Use e abuse da documentação oficial. Não raro esta possui duas seções: Tutorial e Guia do desenvolvedor. Evite começar pelo Tutorial e vá para o guia maior, pois normalmente é lá que os conceitos principais da ferramenta são tratados.
Descubra onde esta ferramenta é executada: se é um framework, qual a linguagem de programação? Se é o desenvolvimento de uma aplicação móvel, trata-se de qual plataforma? É baseado em outro framework, se sim, qual ou quais? Com base nestas informações, caso esteja cru nestes assuntos, pause o aprendizado da ferramenta e comece por estes outros assuntos.
Planeje seus estudos - deveria ter sido primeiro item da lista. Infelizmente não somos ensinados a fazer isto. Bom: criei uma metodologia pra tal que você pode ver neste link.

Rápido disclaimer sobre a "ilusão de poder"

Não é raro que eu levante o tema "ilusão de poder" e seja chamado de "gate keeper", "elitista", etc. Entenda: não estou dizendo que desenvolver software seja algo pertencente apenas a uma elite, pelo contrário: estou te mostrando que há um caminho a ser seguido que te permite construir as estruturas mentais para que possa ir muito além, minimizando com isto a frustração.

Não raro encontro pessoas desesperadas sem entender por que não conseguem avançar no desenvolvimento de seus projetos e adivinha a causa? Duas: consumo passivo de conteúdo e aprendizado superficial dos frameworks que estão sendo adotados.

Você se ilude achando que é fácil, consegue entregar o primeiro projeto e a partir do terceiro ou quarto, conforme a confiança dos outros sobre você aumenta, também aumenta a complexidade do que lhe será pedido. Normal: é a vida.

Uma apresentação muito limitada do mercado

Tratei deste assunto no meu último post aqui (A Web Como Martelo), mas talvez o lugar daquele post seja este. Tal como ali disse, talvez seja apenas minha impressão, mas a mídia especializada reinante hoje sobre desenvolvimento de software fala tanto de desenvolvimento web, e apenas de desenvolvimento web, que muitas vezes para quem está querendo entrar no mercado cria-se a impressão de só haver... desenvolvimento web.

E isto é péssimo pra quem está começando: cada um é um, então será que a dificuldade que você está enfrentando em aprender desenvolvimento de software seria por que desenvolvimento web neste momento é complicado demais pra sua condição atual? Não me leve à mal: talvez você tenha mais facilidade em outra área pra começar, como, por exemplo, programação de baixo nível, desktop, científica, etc. Você poderia começar por outra área na qual se sente mais à vontade (e se descubra) e depois, melhor preparado, voltar ao desenvolvimento web, o que me acha?

Vejo isto com muita frequência: aí o que faço é apresentar estas outras áreas à pessoa. Convenhamos: a web requer uma série de conhecimentos que não raro se relacionam de forma muito íntima e difícil pra quem está começando. Nem tanto por serem assuntos complexos (são), mas por serem muitos.

Então, se você está tendo muita dificuldade em aprender a desenvolver software e começou pela web, vou mencionar algumas outras áreas aqui pra que você pesquise a respeito. Quem sabe você não se apaixona/descubra em uma destas?

Desenvolvimento desktop - ainda existe (e muito). Setor financeiro, por exemplo, adora.
Jogos (ignore os jogos pra web :) neste primeiro contato!)
Algoritmos científicos - existe todo um mercado de pesquisadores que precisam de programadores que materializem suas ideias.
Financeiro - implementação de cálculos, protocolos de comunicação e integração, ferramentas de auditoria (há muito desenvolvimento web também, mas acho interessante mencionar apenas estes pontos aqui).
Ferramentas de linha de comando - como os comandos do Linux, por exemplo. Existe todo um mercado pra isto, e você ainda pode explorar projetos muito interessantes, como o cURL, por exemplo.
Desenvolvimento de baixo nível, como o do Linux, por exemplo.
Criação de aplicações gráficas (meio que cai no universo desktop).
Implementação de protocolos de comunicação (o cURL que citei acima é um belo exemplo).
Segurança da informação.
Inteligência artificial.
Ferramentas de desenvolvimento de software. Pra quem tá começando? Sim! Talvez a sua dificuldade seja na realidade a oportunidade de ajudar outras pessoas em um problema comum, porém não identificado ainda.

A lista é quase infinita, e a que coloquei acima é bem limitada. O importante é saber que existe muita vida além da web.

Ter paciência com o conceito

Quando se está começando há sempre aquela ansiedade em se ir pra prática o mais rápido possível. É normal: passei por isto também (ainda passo), porém este é talvez o maior problema e está conectado à questão da "volta à oralidade" que mencionei no início deste post. Resumo: você precisa ler sequencialmente e ser paciente em relação ao seu processo de aprendizagem (mais ou menos o que Hegel chamava de "paciência do conceito").

(quase doze anos atrás (!!!) escrevi sobre isto aqui)

Há muitas fontes de informação que você pode seguir: livros, cursos, vídeos, palestras, documentações, forums, etc. E aí está um problema: é impossível consumir tudo isto ao mesmo tempo, mas a nossa ansiedade acaba nos forçando a tal. E aí o que ocorre? Consumimos picadinho tudo isto e no final do processo absorvemos muito pouco.

Minha sugestão aqui é que você escolha uma das opções que surgirem em sua frente, agarre-a e leia do início ao fim, especialmente se for um livro ou curso. Quem cria este tipo de conteúdo traça para você um caminho (daí o nome "curso") de aprendizado que acredita ser o ideal para que se construa o conhecimento essencial ou uma boa introdução sobre o tema. Se você é um iniciante provavelmente não sabe ainda qual o melhor caminho a seguir, certo? Então: alguém já traçou um pra você e isto é ótimo!

O problema das inúmeras fontes no entanto ainda persiste. Neste caso indico de novo minha metodologia de planejamento de estudos pois nela mostro como você pode selecionar e categorizar todas estas fontes de aprendizado para otimizar melhor seu tempo (aqui o link).

Mas a questão vai além: muitas vezes lemos inúmeras vezes um texto e não conseguimos entender que está ali. No meu caso, por sorte percebi ser quase analfabeto funcional quanto tinha mais de vinte anos. Tive de literalmente reaprender a ler. E esta é uma pergunta que você deve se fazer com muita coragem e honestidade: estou realmente sabendo ler? Anos atrás relatei esta minha experiência neste texto.

Como você pode verificar se está conseguindo conceituar bem o que está aprendendo? Escreva: crie um blog (pode ser anonimamente), mande seus textos a alguém. Se a pessoa entender o que está escrito ali, é provável que você tenha aprendido.

Concluindo

Se você chegou até aqui talvez já tenha conseguido (ou está conseguindo) superar o problema da paciência do conceito ( :) ). O importante é que você tenha a consciência de que aprender realmente é difícil para todo mundo: não há atalhos, mas a partir do momento em que o problema é reconhecido o caminho fica mais nítido. Bons estudos!

The post O que pode prejudicar seu aprendizado no desenvolvimento de software appeared first on /dev/Kico.

A web como martelo

Henrique Lobo Weissmann (Kico) — Mon, 04 Apr 2022 00:08:13 +0000

A criança nunca sabe o que é um martelo, até confundir o dedo com um prego.
Stephen King

Ah, aplicações web: se você está começando a programar agora é grande a probabilidade de até este momento só ter desenvolvido aplicações web, certo? Talvez ela tenha um front-end feito com algum framework de mercado (Vue? Angular? React?), talvez seja apenas um conjunto de endpoints (aka "API" (alguém ainda usa SOAP?)). No entanto, já se questionou quais seriam os limites da web?

Como deveria ser a interação com uma aplicação web?

Do ponto de vista de interação com usuários (sejam estes humanos ou não) em teoria deveríamos ter todas as interações baseadas no princípio de requisições ao servidor que nos retornem rapidamente um resultado ou que, pelo menos, não nos bloqueiem após termos realizado a requisição ao servidor.

Mesmo que a aplicação web não tenha um servidor e seja executada inteiramente no browser, o ideal é que seja responsiva. Aliás, não é por acaso que ainda hoje o JavaScript adota um modelo não bloqueante de desenvolvimento quando o assunto é I/O, né?

E é aqui que aparece problema.

O problema está em achar que programar se limita a escrever aplicações web

Não me entenda mal: gosto de escrever aplicações web e a maior parte do que faço são sistemas que usam a web como meio. Mas mais do que programar, a maior parte do meu trabalho é evoluir sistemas que não foram projetados ou programados por mim (link), e na minha experiência o que observo como um dos principais problemas arquiteturais é justamente o que chamo de "web em excesso".

Explico: chamo de "web em excesso" quando todo processamento no sistema é inteiramente executado em requisições web. Com certeza você que programa já topou com situações assim: aquela requisição que realiza longos cálculos que demoooooram a fornecer uma resposta ao usuário final, aquela importação de dados a partir de um endpoint que recebe milhares de registros a serem processados que poderia ser feita de forma assíncrona ou mesmo aquelas tarefas agendadas que são executadas no seu monolito, lembra delas? Resumindo: requisições que duram demais.

E é muito fácil cometer este erro: estamos tão habituados em escrever aplicações web (e apenas aplicações web...) que fica difícil muitas vezes (especialmente em dias apertados) projetar um processamento que não seja iniciado, desenvolvido e finalizado em uma única requisição. E quando usamos frameworks full stack como Rails ou Grails, devido à própria facilidade no desenvolvimento, mesmo que estejamos incluindo toda a lógica de negócio em serviços acabamos por esquecer algo importante: requisições web devem ter vida curta.

Repare: não estou dizendo que os processamentos devam ser rápidos, mas que as requisições que os iniciam tenham vida curta. Resolver este problema no desenvolvimento de aplicações é relativamente simples e possui longa bibliografia: você pode começar a pensar e programar assincronamente, mover o esforço pesado para processos externos, modularizar melhor sua aplicação, enfim: há diversas soluções pra isto. A questão da requisição longa é apenas um sintoma de um problema maior.

(arquiteturalmente falando o ideal é que a web seja um componente do seu sistema, e não TODO o sistema se for uma aplicação grande)

Quando a web te limita profissionalmente

Estou nesta vida desde 1996: dado que hoje estou com 43 anos, mais da metade do meu tempo na Terra foi desenvolvendo software. Comecei quando o desenvolvimento era centrado no desktop e vivi o trauma da transição para a web: foi horrível e muitos colegas da época não conseguiram fazer a transição que, no meu caso, se consolidou MESMO só lá pros idos de 2004, 2005.

E neste tempo todo passei por vários ambientes de desenvolvimento e, graças à itexto, por uma gama de mercados que pouquíssimas pessoas tiveram o privilégio de conhecer, o que me permitiu escrever, projetar ou participar direta e indiretamente de softwares de uma infinidade de tipos: integrações, aplicações desktop, linha de comando, ferramentas de baixo nível, sistemas comerciais, corporativos, segurança, protocolos de comunicação, drivers, sistemas de arquivo, plataformas de e-commerce, jogos, sistemas operacionais (indiretamente), comunicações, embarcados, gráficos (tipo CAD), automação industrial, aplicações científicas, engenharia, matemáticas, financeiros, linguagens de programação (desculpe!), inteligência artificial, áudio, aeroespacial (!)...

Após ter passado por tanta coisa sabe o que me choca? Gente jovem que pensa em desenvolvimento de software estritamente como... desenvolvimento web "apenas". Nada de errado em ser excelente em desenvolvimento web, mas a pergunta que me faço é: será que estas pessoas não poderiam ser ainda melhores se explorassem também outras áreas do desenvolvimento? E os sistemas que projetam, não poderiam ser ainda mais fantásticos?

Tenho visto muitas discussões sobre a dificuldade de pessoas iniciantes em entrarem no mercado. É realmente muito difícil, mas será que não fica ainda mais difícil por se focar o aprendizado de desenvolvimento e engenharia de software apenas no mundo web quando a esmagadora maioria das pessoas olha apenas para este mercado?

E todos estes outros nichos que não aparecem tanto na "mídia especializada" (que convenhamos, hoje é dominada por um monte de "influencers" que ao menos pra mim parecem todos iguais), será que não mereciam um pouco mais de atenção nas publicações/vídeos/podcasts/lives? Pouco tempo atrás o Adriano me mostrou uma realidade que não acreditei num prieiro momento: uma IMENSA quantidade de vagas para desenvolvedores... C++! Realmente: o mercado de engenharia precisa deste pessoal, mas pouco se fala a respeito.

(aliás, já notou como a mídia escrita para desenvolvimento praticamente morreu? (algo a se pensar))

Meses atrás implementei uma automação industrial de baixo nível com equipamentos usando Rust e comunicação por sockets apenas. Poderia ter sido feito em Java/C#/C++/VB/JavaScript ou qualquer outra linguagem que permita comunicação neste formato. E sabe que me chamou a atenção? Um iniciante poderia facilmente aprender o suficiente para se tornar produtivo em pouco tempo. Você não seria um expert, claro, mas conseguiria se virar sozinho. (e há menos pra se aprender ALI do que no desenvolvimento web pra ser eficiente, acredita?)

Resumindo: na minha opinião se você quando pensa em um sistema já começa decidindo que este deveria ser web sem sequer vislumbrar outras possibilidades talvez seja o sintoma de uma percepção bem limitada do mercado.

Concluindo

Amo projetar e programar sistemas: talvez este "excesso de web" seja uma percepção equivocada minha, resultado do meio em que vivo, mas talvez haja alguma coisa por trás desta fumaça.

Semanas atrás dei uma relida no Kant que levanta a possibilidade do nosso conhecimento ser muito limitado pelo modo como percebemos o mundo (e a estrutura interna da nossa mente). Talvez este excesso de web quando programamos nos cegue para todo um Universo que pudéssemos explorar por aí.

Quem sabe? Bom: anos atrás escrevi algumas coisas sobre "determinismo linguístico", que você pode conferir nestes links. Faz muitos anos que escrevi isto, mas minha opinião não mudou muito. Você encontra estes textos neste link do "Essencial de /dev/Kico".

The post A web como martelo appeared first on /dev/Kico.

O framework "Maria vai com as outras"

Henrique Lobo Weissmann (Kico) — Mon, 21 Jun 2021 13:46:48 +0000

Texto escrito em 2012

"Sabe Kico, eu acho Grails muito legal, mas fico receoso em usá-lo no meu novo projeto porque não é um framework muito popular. O que você acha disto?". Escuto esta pergunta umas 4 ou 5 vezes por semana. Então resolvi me aprofundar nesta questão e, como resultado, surgiu este post, que não deve ser lido como algo específico sobre Grails, mas sim meus pensamentos aplicados a qualquer tecnologia "nova" ou "menos popular".

Definição de popularidade

A definição mais ingenua seria "aquilo que é muito usado" porque só leva em consideração a quantidade, ignorando completamente "quando" e "onde".

Muitas vezes escuto a seguinte frase: "tecnologia X não é muito popular, pois não conheço muitas pessoas que a usam". É um argumento idiota: basta pedir ao sujeito que saia um pouco da sua zona de conforto e pesquise direito antes de falar bobagem. 90% dos profissionais com quem lido trabalham com Java. Isto quer dizer que .net seja impopular?

Outro bom contra-exemplo: Cobol. Não conheço nenhum programador COBOL, mas um estudo de 2007 da Gartner descobriu que 75% (SETENTA E CINCO PORCENTO) das aplicações corporativas eram escritas em... bem: Cobol.

Sendo assim, antes de pensar na popularidade de uma tecnologia, remova as suas impressões pessoais sobre o assunto.

Popular então é algo que possua um grande número de usuários em um certo domínio em um dado momento. Ok, uma definição mais completa, mas que não adiciona nada (ao menos pra mim), e que levanta a seguinte questão:

Qual o grande "ganho" da popularidade?

Mais gente pra falar a respeito e maior suporte da "indústria". Além disto, também há aquele sentimento imbecil de que "se é muito usado, é porque deve ser muito bom".

Gerentes cretinos amam, pois fica mais fácil encontrar mão de obra e substituir elementos problemáticos. Se você pensa na sua equipe como uma linha de montagem de software, a popularidade de um framework é fundamental.

Pessoalmente tenho nojo desta linha de raciocínio porque só serve para uma coisa: alimentar a mediocridade gerada pela massificação.

É inegável o sentimento de segurança provido pela popularidade de um framework: afinal de contas, peixes muito grandes torcem para que isto ocorra, pois assim conseguem reduzir os custos de produção.

(só pra lembrar, o uso em massa de uma tecnologia acarreta na redução do seu custo que, no caso do software, é a mão de obra, ou seja, você desenvolvedor)

Qual o grande risco da "impopularidade"?

Óbviamente o desaparecimento da tecnologia. Porém este risco só é real se esta for fechada e o acesso a seu código fonte inexistente. Mas como hoje open source domina, no pior dos casos você ainda poderia dar manutenção naquela base de código sozinho. Afinal de contas, migrar de framework em 99,999% dos casos equivale à reescrita completa da aplicação, certo?

O que realmente importa?

Atender bem ao cliente. Não vou usar um framework só porque todas as pessoas "legais" do meu bairro o fazem também, mas sim porque me sinto à vontade com ele e o resultado do seu uso gera um produto cujo nível de qualidade satisfaça (e bem) as necessidades do meu cliente.

Tenho cá minhas dúvidas se realmente é possível atingir a qualidade sem o prazer na execução do trabalho. Eu pelo menos nunca consegui. E outra: se o projeto é seu, por que ficar usando o que não gosta só porque é popular? Pra aparecer bonito na fita?

No final das contas...

Há dois caminhos a serem seguidos: ser pastor ou cordeiro. Escolhi o caminho mais caro que é o primeiro e até hoje não me arrependi. :)

Armadilhas para desenvolvedores: a síndrome do contato alienígena

Henrique Lobo Weissmann (Kico) — Mon, 21 Jun 2021 13:45:26 +0000

Texto escrito em 2012

Nos últimos dias tenho pensado muito sobre os poucos casos que conheço nos quais o uso do Grails foi um fracasso. Nisto encontrei um elemento em comum que, acredito, pode ser aplicado à adoção de qualquer tecnologia. Chamo-o de síndrome do contato alienígena.

Analogia alienígena

Considero alienígena qualquer objeto com o qual me deparo e em um primeiro momento não encontro qualquer analogia que me ajude a compreendê-lo melhor. Nestes momentos, é como se aquele ser não se parecesse com nada que conheço. É portanto alienígena!

Este contato alienígena me oferece algumas alternativas:

Fico parado observando o objeto (desespero)
Inicio um processo de tentativa e erro manipulando o alienígena buscando algum comportamento que me pareça familiar (repare como parece uma autópsia) (desespero++)
Busco mais informações sobre aquele elemento

As duas primeiras alternativas caracterizam a síndrome do contato alienígena, enquanto a terceira é a única via sensata que conheço. Há uma razão pela qual estou usando repetidas vezes a palavra analogia: esta é a base do aprendizado, que é o problema que estou tratando neste post.

( sobre analogia e cognição, recomendo muito a vocês que assistam a esta palestra do Douglas Hofstadter. )

Reproduzindo em escritório a síndrome do contato alienígena

Você precisará dos seguintes igredientes:

Um profissional mediocre ou desmotivado (qualquer um com preguiça de aprender, ao menos pra mim, está afogado na mediocridade)
Uma tecnologia com a qual este profissional não possua contato anterior
Ausência de introdução a esta tecnologia

É um cenário muito comum em fábricas de software. Como há forte pressão para que o lucro seja o maior possível, muitas vezes o contratado não é o melhor, mas sim o mais barato e que "dará conta do recado". Como em cima deste indivíduo é colocada a forte necessidade de que suas tarefas sejam entregues no prazo, este passa a ver seu trabalho não como algo do qual possa tirar proveito, mas sim como um problema desagradável que precisa ser resolvido rápido.

Como "agilidade" é tudo e nosso amigo medíocre não possui tempo ou motivação suficiente para pesquisar a respeito, o que lhe resta fazer? Resta buscar desesperadamente qualquer semelhança entre aquela tecnologia e qualquer outra com a qual já possua alguma experiência, por mais mínima que seja.

Um caso

Um bom exemplo deste comportamento está em uma frase que ouvi de um "profissional" ao se deparar com Grails. Segue a pérola:

"Sabe, como não vou ficar muito tempo neste projeto, vou programar em Grails exatamente como faço em Java, pois é o que conheço"

Óbviamente, o fruto do "trabalho" deste indivíduo foi retrabalho para os que precisaram depois arrumar a casa. Na realidade, o único fruto foi esta frase, cuja autópsia vou iniciar agora.

(...) como não vou ficar muito tempo no projeto (...)

Chamo este trecho de "imbecil detector". Não é necessário me aprofundar muito nesta sub-pérola. Fica nítido que o sujeito não possui comprometimento com a sua equipe ou com a qualidade do próprio trabalho.

(...) vou programar em Grails exatamente como faço em Java, pois é o que conheço

Olha ai a síndrome explícita. Primeiro quando o sujeito diz "vou programar em Grails", expõe a sua ignorância completa sobre o assunto. Não se programa em Grails, mas sim em Groovy, que é a linguagem na qual o framework se baseia.

Logo em seguida, a busca desesperada por uma analogia fácil: "como faço em Java, pois é o que conheço". Neste caso, Groovy realmente é uma linguagem próxima do Java, mas não é Java. O resultado foi que Grails, apesar de ser o framework mais produtivo que conheço, neste caso foi um dos mais desastrosos que já vi.

Uma terapia

Faça uma introdução gentil à ferramenta

É errado enfiar tecnologia em um profissional que não a conhece (ei! seres humanos não possuem entrada pra cartuchos, sabia?). De fato: fazer isto é o mesmo que implorar pela mediocridade. O mais interessante é, em situações de contato alienígena, fornecer ao indivíduo um tempo (1 a 2 semanas) para que se adapte à tecnologia fora do ambiente de trabalho (de preferência, com algum material que possa ser usado como ponto de partida).

Por que fora do escritório? Para reduzir a pressão sobre o seu aprendizado. Nada pior que alguém o tempo inteiro lhe perguntando: "e ai? tá entendendo melhor agora?". Além disto, é também um modo interessante de se medir o interesse do indivíduo pelo seu trabalho.

Se passado o período, o sujeito continua completamente cru no assunto, então é sinal de que não vale a pena o investimento naquela pessoa.

Comprometa-se com a tecnologia

Se a ferramenta X te oferece um modo de trabalhar parecido com o de Y que você já conhece, trabalhar com X como se fosse Y é burrice. A adoção de uma tecnologia envolve comprometimento.

Toda tecnologia envolve riscos, porém ter medo de usá-la plenamente é bobagem. Se você vai usar Grails ou Camel ou Erlang ou qualquer outra coisa no seu projeto, mergulhe de cabeça. Pense de acordo com o paradigma adotado pelo que você está usando, e não pelo que gostaria de usar.

Se mesmo assim você ainda estiver inseguro com relação à ferramenta adotada, acredito que auto crítica seja fundamental. Eu sempre me faço a seguinte pergunta:

Esta tecnologia foi desenvolvida por pessoas altamente capacitadas (muito provávelmente mais capacitadas que eu). Será que o problema está na ferramenta, comigo ou no fato de não ser a opção certa para o meu projeto?

Se acreditar que não é a escolha certa para o seu projeto, e esta não foi uma decisão sua, neste caso, o ideal é procurar o responsável por esta decisão. Normalmente (se esta pessoa não for debilóide) há uma excelente razão para que esta escolha tenha sido tomada.

Concluindo

Vejo duas causas possíveis para este "contato alienígena".

Gerência mediocre: quando não são dadas ao indivíduo as condições necessárias para que este se adapte (e quem sabe, até venha a gostar) da tecnologia.
Profissional medíocre: quando o sujeito sequer pensa em pesquisar a respeito do assunto e já de cara inicia um processo de tentativa e erro buscando alguma forma barata de extrair suco de pedras

Resumindo: se não houver o esforço para que o aprendizado ocorra, sua realidade não será terrena jamais! :)

PS: normalmente a mediocridade é o resultado de você estar fora do seu lugar