DEV Community: Edson Cunha

Dicas para revisão de código e equipes saudáveis

Edson Cunha — Mon, 27 Jul 2020 12:39:36 +0000

Primeiro, as premissas:

1) Ninguém é dono/a do código

Pessoas vêm e vão. É parte da vida. Além disso, um projeto de software é feito em equipe. As pessoas do time precisam se sentir confortáveis para mexer no código e co-proprietárias dele (atenção para o prefixo "co-"!).

2) Receber comentários não é um demérito

Isso é parte da construção coletiva de um projeto, e decorre naturalmente da premissa 1. Além disso, ninguém sabe absolutamente tudo.

Agora, as dicas:

1) Desapegue

Ideias melhores do que as suas podem vir de colegas que estão revisando.

2) Incentive a revisão no seu código

Mesmo se você for uma liderança ou referência técnica, incentive que revisem seu código. Ou melhor: especialmente se você for, faça isso para dar o exemplo! Lembre-se da premissa 1: todo mundo tem propriedade do código. Subiu um pull request? Incentive as pessoas a revisarem.

3) Seja gentil

Hoje, você está revisando o código de alguém. Amanhã, alguém vai revisar o seu. Lembre-se que a pessoa escreveu aquele código dando o melhor de si nas circunstâncias que teve para gerá-lo.

4) Seja propositivo/a

Ao apontar um problema, pode ser que a pessoa não saiba como resolvê-lo. Por isso, sempre proponha alternativa(s).

5) Receba as sugestões de bom grado

Você aprende algo novo e o código fica melhor com a colaboração proposta. Se você discordar, debata amigavelmente.

Quando todo mundo participa do código de cada pessoa, a equipe fica mais parceira e se fortalece tecnicamente.

Desapegue!

Organizando o código com máquinas de estados

Edson Cunha — Fri, 05 Jun 2020 17:20:29 +0000

É nosso dever, enquanto profissionais que fazem software, deixar nossos códigos em ordem. Às vezes, porém, sentimos que vai ficando cada vez mais difícil modificar determinadas partes do projeto.

O problema

Com o tempo, fica cada vez mais difícil resolver bugs e acrescentar requisitos. Não poder excluir um pedido depois que ele já foi enviado, não poder excluir um usuário se ele já fez uma compra, verificar os estados de vários flags, colocar ifs com base nesses flags em várias partes do código, e por aí vai.

O código, depois de algumas entregas...

De modo geral, os sintomas são estes:

Aparecem atributos remetendo a estados e datas. Exemplos: data_criacao, data_alteracao, data_exclusao, criado, inativo, cancelado.
Existem variações importantes de comportamento associadas a datas e/ou flags. Se o estado é criado, algumas ações são possíveis, se excluido, as ações possíveis são outras, e assim por diante.
Fica cada vez mais sofrido acrescentar novas ações e corrigir problemas conforme o tempo passa.

Um Estudo de Caso

Imagine que você tem que fazer um site de reclamações sobre empresas, o Resmungue Aqui :)

Os requisitos básicos são os seguintes:

Uma reclamação pode ser editada quantas vezes a pessoa quiser, até que decida submetê-la.
Uma vez submetida, ela entra em estágio de avaliação.
O site torna públicas apenas as reclamações aprovadas.
Reclamações aprovadas podem ser respondidas por representantes de empresas.

Você implementa e o código está bonito, pequeno, tudo certo.
Depois de um tempo, chegam mais modificações:

Reclamações em avaliação não podem ser editadas por ninguém.
Reclamações em avaliação podem ser aprovadas ou reprovadas.

Mais um tempo se passa e você tem que implementar o seguinte:

Reclamações reprovadas podem ser editadas para nova análise.
Reclamações já aprovadas, se editadas, voltam à fase de análise.

Consegue imaginar a dificuldade crescente em lidar com esse código e todas as variações (atuais e futuras!) das reclamações do Resmungue Aqui?!

Solução

Uma das maneiras mais eficientes de lidar com a complexidade é fazer desenhos.
Podemos então fazer um mapeamento entre os estados e as transições possíveis entre eles. Para isso, construímos uma máquina de estados, que nada mais é do que um grafo direcionado.

Os vértices são os estados e as arestas são as ações que levam de um estado a outro. Se uma reclamação é submetida, ela passa do estado de Rascunho para o estado de Em avaliação por meio da ação submeter(), que conecta os dois estados.

A partir desse modelo, fica bem mais fácil compreender quais ações são possíveis conforme o estado de uma reclamação. Ele nos ajuda a gerenciar a absorver melhor a complexidade, além de podermos usá-lo para conversar sobre os requisitos do projeto.

Como implementar a máquina?

Agora, ficou mais fácil compreender que cada estado (vértice do grafo) pode ser envelopado em uma classe específica. Pela sua concisão, todos os exemplos de código do texto serão dados em Kotlin:

class Rascunho: EstadoReclamacao

class EmAvaliacao: EstadoReclamacao

class Reprovado: EstadoReclamacao

class Aprovado: EstadoReclamacao

O pulo do gato

As ações na reclamação variam conforme seu estado corrente. Portanto, cada estado trata a ação à sua maneira:

abstract class EstadoReclamacao {
    fun editar(reclamacao: Reclamacao)

    fun submeter(reclamacao: Reclamacao)

    fun aprovar(reclamacao: Reclamacao)

    fun reprovar(reclamacao: Reclamacao)  

    fun acaoNaoSuportada() = throw NotSupportedException()
}

class Rascunho: EstadoReclamacao {
    fun submeter(reclamacao: Reclamacao) {
        // seu código
    }

    fun editar() {
        // seu código
    }

    fun aprovar(reclamacao: Reclamacao) = acaoNaoSuportada()

    fun reprovar(reclamacao: Reclamacao) = acaoNaoSuportada()
}

class EmAvaliacao: EstadoReclamacao {
    fun submeter(reclamacao: Reclamacao) = acaoNaoSuportada()

    fun editar() = acaoNaoSuportada()

    fun aprovar(reclamacao: Reclamacao) {
        // seu código
    }

    fun reprovar(reclamacao: Reclamacao) {
        // seu código
    }
}

// etc

Por fim, escrevemos o código para que o objeto reclamacao repasse as ações submeter(), editar(), aprovar() e reprovar() ao seu estado corrente.

class Reclamacao(val conteudo: String, internal var estado: EstadoReclamacao) {
    fun editar() = estado.editar(this)

    fun submeter() = estado.submeter(this)

    fun aprovar() = estado.aprovar(this)

    fun reprovar() = estado.reprovar(this)
}

E as mudanças de estados?

Até agora, movemos com sucesso as responsabilidades que dependem de cada estado. Mas como mudar de um estado a outro? O que fizemos até aqui foi delegar o comportamento específico a cada estado.

Existem pelo menos três maneiras de fazer as transições:

a) uma classe gerenciadora, que tenha a visão do todo e gerencie as comutações. Alguns frameworks, como o Spring, funcionam desta maneira. Por um lado, essa abordagem facilita no entendimento global de quais são as possibilidades daquela máquina de estados. Por outro, ela tende a favorecer classes inchadas, o que não gosto.
b) cada estado indica o estado seguinte, conforme a ação que é disparada dentro dele. Prefiro esta abordagem. Com ela, os testes unitários ficam bem mais expressivos e elegantes.
c) um comutador que receba tanto os estados quanto as ações como objetos. É a opção (a) com esteroides, e fica bem bacana.

Por brevidade, seguirei a abordagem (b). Nela, portanto, se o estado vigente é EmAvaliacao e ele processar a ação aprovar(), é o próprio código da classe EmAvaliacao que atualizará o estado da nossa reclamacao para Aprovado:

class EmAvaliacao: EstadoReclamacao {
    // ...

    fun aprovar(reclamacao: Reclamacao) {
        reclamacao.estado = Aprovado()
    }

    // ...
}

Falar é de graça
Você pode conferir o código-fonte no Github.

O que achou? Se quiser discutir implementações específicas, envolvendo linguagens e frameworks de mercado, deixe um comentário ou mande uma mensagem.

(Publicado originalmente em https://edsoncunha.github.io/simplificando-codigo-com-padrao-state)

Lessons from learning music: how to get better at software

Edson Cunha — Fri, 05 Jun 2020 17:11:38 +0000

Programming is only for geniuses. Music is only for the gifted few. Right?

As a professional software developer and musician in training, I don’t think so. These are long journeys, where genius is not mandatory. Here are some tips that music can give a career in software and vice versa:

Take one step at a time

No one plays a solo or writes a sophisticated program with half a dozen classes. This ability is gained in small daily doses, with much repetition. Those who learn to play wind instrument first learn to produce the notes, then connect them, and only then study scales to be able to perform melodies.

As per the cliché, it takes much more perspiration than inspiration. What matters isn’t how long the step is, but to not stop walking at all. The experience is accumulated during the journey.

No one learns programming by just opening an IDE. Before that, people learn to interpret and solve problems, structure the solution in plain English or pseudo-code and only then start to work with code at all. There is a lot of ground to cover between inception and major architecture design.

Do your bodybuilding

Professional musicians study each day from their first contact with the instrument. Among French horn players (which has the most beautiful sound in the world!), there is even a debate about whether or not to have a day off.

In order to be able to play, musicians practice regularly so that their movements are precise and automatic and their bodies and minds are always in a position to play.

If you are already programming daily, it is very likely that this strengthening happens naturally. If not, try to exercise. Even with all his decades of experience Uncle Bob practices katas everyday to test and keep his skills sharp. Repetition makes us write code more automatically and frees the brain for other concerns. This is very important as we cannot pay attention to everything at once.

Hit the nail on the head

When you study a solo, for example, you don’t spend much time going over what already sounds good enough. Instead, you practice the stretches that are often bad or not good enough. These are played bar by bar, slow at first then faster, until things are better and the song is played well from start to finish.

Do you already write code comfortably but are unsure about writing tests? Set aside some time for yourself. Read Kent Beck’s TDD book , or Steve Freeman and Nat Price’s version , then start cooking!
Anticipating a future discussion: delivering tested code is your obligation!

Rest, alternate and insist

The muscles and brain get tired. Sometimes we get stuck at some point and repetition at a slower pace doesn’t help. Coffee and small talk usually helps. The next day, coming back to the problem with rested muscles and brain, the struggle evaporates like magic.

Are you reading a snippet of a technical book you can’t understand? Get up and drink some water. Go do something else and then go back to reading. It’s late in the day, you’ve been racking your brain for 40 minutes and still can’t find the root cause of that bug? If it’s not very urgent, get up and go home. You will come back the next day and find out the solution in just 5 minutes.

Learn from multiple sources

Everyone has a unique story. The best musicians in the world go through various teachers and this is absolutely normal as everyone has their own strengths, experiences and levels of knowledge in music making. When starting a class, my first teacher will always make me play several scales (major, minor, harmonic minor… etc), whilst the second will require my bass to sound like a foghorn.

Drinking waters from various sources makes you understand water better. Donald Knuth, the greatest living computer scientist, advises us to read code from more experienced people. Read books from people in the industry too. They exist in large numbers and are excellent for learning from professionals with decades of experience. Did you buy a book and see no value in it? Keep it, because the Dunning-Kruger effect is probably running through your veins. I assure you that after a few years you will have had many problems in practice — and the knowledge of that book will most likely help you alleviate this pain.

Pay attention to your surroundings

Rehearsal is when you learn from your peers. You need to bring your part ready from home. It is time to understand how harmonies, melodies, solos and accompaniment fit together, work on the interpretation and make the audience cry in their chairs — of emotion, preferably.

It’s true we have no essay in this format in the software industry. But we do not work alone. Soft skills and good communication are key. I don’t know a company or coworker who is interested in people who just do their part and who doesn’t connect with what happens around them. Don’t isolate yourself behind the headset. Listen to the environment. Tell your opinions. Help your peers. Allow them to help you.

Prefer environments where it is safe to make mistakes

Have you tried singing to the point you crack your voice? Have you blown a note so high the note actually cracked? It’s a must! :-)

Having the time and place to make mistakes without being punished is critical to gaining the courage to try. Courage, in turn, is transformative.

There are many ways to catch problems before they are eventually deployed to production. Good companies, besides encouraging the use of this tooling, understand that people are in different stages of development. They get more experienced people to nurture those who are coming and encourage them to try.

-- Who will be in the trenches beside you?
-- Does it matter?
-- More than the war itself
(Ernest Hemingway)

(Originally published at https://edsoncunha.github.io/licoes-da-musica-para-evoluir-no-desenvolvimento-de-software/)