Procurando a motivao

Esse post no sobre cdigo. Mesmo se no souber programar, voc no deve ter dificuldades em acompanhar

Eu j ouvi bastante feedback no meu trabalho. O mais constante sendo melhorias de comunicao, que at hoje tenho certo problema.

Um problema que ocorria frequentemente era que as minhas explicaes que eram muito tcnicas. Na minha conversa com o time de produto isso complicava tudo. Por exemplo, eu explicava todo o contexto por volta de uma nova implementao de feature. Levantava as possibilidades que conseguia pensar, trazendo as facilidades e dificuldades que trariam na implementao inicial e na manuteno do cdigo. Eu estava pensando comigo mesmo e sendo transparente com todo mundo.

Isso era relevante se fosse discutir com pessoas mais seniores, mas raramente era o caso. O que aprendi com o tempo era entender o escopo do que as pessoas precisavam saber, e trazer isso a elas. Entender o porqu daquela comunicao existir, e relevar o que exatamente eu precisava comunicar de acordo com esse motivo.

Aplicando isso, as mensagens de Slack que eram 5 pargrafos gigantes explicando os pormenores da entrega viravam 5 frases breves focando no que a pessoa precisava saber. Pra escrever as 5 frases eu ainda demoro, mas a comunicao fica bem mais fluda assim.

Eu lembro quando eu criava testes de componentes React usando Enzyme. Foi timo aprender o mundo frontend com ele, porque eram simples, e qualquer um poderia criar testes sem esforo.

it('renders', () => {  const wrapper = shallow(<Component />);  expect(wrapper).toMatchSnapshot();})

Eu gosto de pensar nesses testes como "snacks", eles so rpidos de serem escritos e entendidos, e raramente quebram. Se quebrar, era um processo simples corrigir eles, geralmente eu apertava U no teclado e o snapshot atualizava sozinho, eu nem precisava verificar.

Mas uma coisa que ficava escondida para mim era que os testes, sendo fceis de serem mantidos, eram tambm muito inteis. Muitos bugs passavam nesse mtodo, e no final o valor dos testes era bem limitado.

React Testing Library chega na minha vida. Ela vem com um princpio:

The more your tests resemble the way your software is used, the more confidence they can give you.

Essa pequena frase afeta bastante. Para seguir esse princpio, a React Testing Library tem menos possibilidades do que a Enzyme, mas o que pra mim parecia um detrator da lib acabava sendo uma vantagem. Isso diminui o foco na estrutura do cdigo, e aumenta o foco no usurio como valor principal dos testes.

Eu s fazia testes porque era considerado boa prtica, mas nenhum momento eu tinha pensado em um Objetivo dos testes, que colocava valor nos testes em si. Eu nem precisava da React Testing Library pra aplicar esse princpio. Ao me restringir dentro do Enzyme, eu criava testes com mais valor.

DRY (Don't Repeat Yourself ou No Se Repita) um acrnimo bem popular de boa prtica no mundo da programao. A ideia dele reduzir retrabalho com a regra de no duplicar cdigo.

Essa regra aplicada no s no frontend, mas em todos os nveis de programao que j vi. E de longe a mais popular e mais implementada por times. Uma crtica recente a essa "boa prtica" que ela introduz cdigos complexos demais com o tempo.

O processo acaba sendo o seguinte: uma pessoa evita repetir o cdigo introduzindo uma abstrao. Outra pessoa, considerando que precisa dessa abstrao, usa ela e altera pro seu caso. E mais uma pessoa, e outra, assim vai indo. At que a abstrao no faz mais sentido, mas utilizada por todos.

Outras regras foram introduzidas para mitigar esse problema. WET (Write Everything Twice ou Escreva Tudo Duas Vezes) uma regra que diz: "Todo cdigo deve ser escrito no mximo duas vezes". uma regra que mitiga esses problemas, mas ao meu ver tem outra regra, ou melhor, ideia, que diminui a complexidade de cdigo, o AHA: "Avoid Hasty Abstractions" (ou Evite Abstraes Apressadas).

A ideia do AHA programming introduzir abstraes no cdigo quando elas forem necessrias, e diminuir o uso de abstraes simplesmente por abstrair.

A vantagem (e desvantagem) do AHA que ele no d uma regra fcil de ser seguida. Ele abre mo de uma regra definida para que a pessoa desenvolvendo consiga determinar vrios fatores que definam se tal abstrao necessria. Isso faz com que alguns casos apaream meio estranhos, por exemplo:

const DEBUG_QUERY_PARAM = 'shouldDebug'function Component() {  const { search } = useLocation()  // ...  const doSomething = () => {    const shouldDebug = new URLQueryParams(location.search)        .has(DEBUG_QUERY_PARAM);    if (shouldDebug) {      console.log('debugging happening');    }    // ...  }}

Esse cdigo tem duas abstraes relevantes: DEBUG_QUERY_PARAM e shouldDebug. Ambas existem mas s so utilizadas uma vez.

Se for se basear s nas regras de DRY ou WET, ambas as abstraes no fazem sentido, elas esto sendo usadas s uma vez no cdigo. Mas importante capturar o propsito real por traz delas antes de remov-las.

DEBUG_QUERY_PARAM tem uma valor de documentar o comportamento. Ele informa pra quem est lendo que existe uma funo de debug do cdigo, e ele controlado pela query param shouldDebug. A inteno do cdigo no reuso, mas sim documentao de uma feature.

shouldDebug tem o propsito de abstrair um cdigo complexo em um cdigo fcil de ser entendido por um humano, pode inclusive ensinar atravs dessa interface amigvel. Alm disso, ele representa melhor a inteno da pessoa que o criou, fazendo o trabalho de manuteno mais fcil caso haja algum bug.

Eu no estou necessariamente dizendo que o cdigo escrito um bom cdigo. Leve em conta o contexto dele antes de aplicar o mesmo racional.

Por qu?

Essas historietas esto conectadas por uma ideia, sintetizada por uma/duas palavra(s): "Por qu?" Pra trazer valor em uma tarefa, eu preciso entender o motivo dela.

J vi uma tcnica chamada "Os 5 porqus", criada com o objetivo de chegar raiz do problema. Nela, voc entra numa recurso: pergunta o motivo de um problema ocorrer, e depois disso procura explicar porque esse motivo existe, e continuamente.

Essa tcnica pode ser aplicada onde voc ainda no enxerga problemas. Tente entender a motivao por trs. Essa motivao no precisa ser a melhor do mundo, mas tem que ser sincera. Se voc quer usar TypeScript invs de JS, voc no precisa falar que tem mais qualidade ou os mesmos argumentos de sempre. Os argumentos podem ser baseados no seu contexto: talvez voc queira experimentar TS no seu projeto, ou voc queira melhorar seu portiflio profissional.

Post Scriptum

Sendo um pouco meta aqui e aplicando o post no prprio. Eu j tentei escrever muito, mas nunca terminei de escrever. Falei sobre esse assunto no post porque um assunto que tenho muito o que falar, o que facilita a escrever. E no final, quero escrever posts como esse como parte da minha vida profissional.