Affordance Coding e SOLID: a visão de um web developer

Você vai aprender um pouco sobre Affordance Coding e SOLID comigo, Caio, web developer do EBANX, do End User Squad. Meu papel? Garantir a qualidade técnica do nosso produto para os end users, e a estratégia de affordance coding é essencial para isto.

Você vai aprender um pouco sobre Affordance Coding e SOLID comigo, Caio, web developer do EBANX, do End User Squad. Meu papel? Garantir a qualidade técnica do nosso produto para os end users, e a estratégia de affordance coding é essencial para isto.

É interessante dizer que um dos objetivos do EBANX é atrair novos Merchants, que são sites internacionais parceiros, para quem o EBANX processa pagamentos. E não importa o tamanho do novo Merchant, a integração impacta sensivelmente nosso sistema – o processamento de pagamento online – gerando inputs que podem forçar a escalabilidade de nossa estrutura.

Como atrair Merchants é um dos nossos pilares de oportunidades (conforme a perspectiva da análise SWOT – metodologia para fazer um diagnóstico do negócio, e traçar estratégias com base em forças, fraquezas, oportunidades e ameaças), a tendência é que o volume de integrações seja cada vez maior.

Perspectiva de código

Em relação a este cenário, agora na perspectiva do código, devemos estar preparados para dar fluidez em nossa codificação quando for necessário aplicar o código de um novo Merchant que tenha particularidades. E se no momento de aplicar este novo código você perceber que está diante de um código não-SOLID (veja SOLID). Como você se sente?

Bom, eu comparo com a tentativa de beber café quente com uma xícara sem alça! A xícara sem alça resolveu o problema de conter o café, mas resolveu a necessidade de segurar? Não!

Ou seja, o design da alça da xícara não foi feito de maneira aleatória, apenas para enfeitar, ele tem uma função importante, que é garantir a praticidade e que o café será apreciado. (Agora você pode ir tomar um café, se bateu vontade!)

O significado de affordance para o mundo do design é isto: compreensão da usabilidade, de como manusear algo sem um “guia do usuário” por perto para descobrir. E convenhamos, a maioria das coisas que fazemos não tem um “guia”.

De volta ao mundo dos bits!

Sem usar um código SOLID assumimos alguns deveres extras que poderiam ser evitados. Ao aplicar SOLID podemos escrever o código de maneira mais lógica e significativa.

Quanto mais o código esteja de acordo com SOLID, mais perto estaremos de um “Affordance Coding” – uma engenharia de código que você pode apenas reutilizar fragmentos de código compreensíveis no caminho de acordo com o paradigma da sua linguagem de programação escolhida.

Embora o SOLID seja mais para a linguagem de programação de paradigma OOP, a ideia de Affordance Coding pode ser um propósito comum e é possível encontrar a melhor maneira em paradigma de linguagem de programação que está usando. Vamos iniciar uma estratégia de affordance coding?

Affordance Coding: O resultado da aplicação contínua de SOLID

Programadores devem estar sempre preparados para dar fluidez na codificação quando for necessário aplicar um código de terceiros que tenha particularidades. A aplicação de um código SOLID garante esta fluidez.

SOLID

O termo é um acrônimo para 5 princípios do design que tem o objetivo de tornar o design de software mais compreensível, flexível e fácil de manter.

Cada princípio tem uma definição bem clara, veja abaixo:

  • Single Responsibility

Este princípio diz que cada módulo, ou classe, deve ter responsabilidade sobre uma única parte das funcionalidades fornecidas pelo software, e essa responsabilidade deve ser totalmente encapsulada pela classe.

  • Open/Closed

O princípio de “open/closed” determina que “as entidades de software (classes, módulos, funções, etc.) devem estar abertas para extensão, mas fechadas para modificação”, ou seja, cada entidade pode permitir ser estendida, mas sem modificar o código fonte.

  • Liskov Substitution

Substituição de Liskov (LSP) é uma definição específica de uma relação de subtipagem, denominada (forte) subtipo de comportamento, que inicialmente foi introduzida por Barbara Liskov.

“Liskov Substitution” afirma que, em um programa de computador, se S é um subtipo de T, os objetos do tipo T podem ser substituídos por objetos do tipo S (ou seja, um objeto do tipo T pode ser substituído por qualquer objeto de um subtipo S) sem alterar nenhuma das propriedades desejáveis ​​de T (correção, tarefa executada, etc.).

  • Interface Segregation

Interface Segregation (ISP) afirma que nenhum cliente deve ser forçado a depender de métodos que não usa! Portanto, o ISP divide interfaces grandes em menores e mais específicas, para que os clientes só tenham que saber o que que lhes interessa.

O ISP destina-se a manter um sistema desacoplado e, portanto, mais fácil de refatorar, mudar e redistribuir.

  • Dependency Inversion

Refere-se a uma forma específica de módulos de software de dissociação. Ao seguir este princípio, os relacionamentos de dependência convencionais estabelecidos a partir de módulos de configuração de alto nível e de configuração para módulos de dependência de baixo nível são revertidos, tornando os módulos de alto nível independentes dos detalhes de implementação do módulo de baixo nível.

Checklist para iniciar uma estratégia de affordance coding

  1. Crie um git branch focado para code refactoring! Pode ser chamado de “filosofia SOLID” ou “Affordance Coding” mesmo;
  2. Pesquise e use as melhores práticas da linguagem que você está usando;
  3. Pull Request!

Qualquer coisa, me chama no Github.

Valeu!

Um comentário sobre “Affordance Coding e SOLID: a visão de um web developer”

  1. Não entendo de programação, mas vejo que estas soluções vêm para facilitar nosso acesso ao segmento bancário e trazem ideias de simplificação para um mundo menos complicado para nós leigos! Parabéns para o Caio e para o E.BANX!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *