Porque só entregar desafios não nos torna bons candidatos a desenvolvedores

Viralizou no Linkedin alguns meses atrás o post de uma tech lead que desabafava sobre o método de seleção de desenvolvedores do seu time, baseado em uma dessas plataformas famosinhas de desafios de código.

No post ela destacava como os recém-contratados não sabiam escrever código limpo, com design pattern, pois a única coisa que essas plataformas exigem é a resposta certa a um desafio.

Como você chegou nessa resposta, não importa para a plataforma, pois a única coisa que ela faz é validar o seu código com um “Assert” num arquivo de teste.

Com base nisso, eu gostaria de propor um desafio para todos nós que estudamos por meio de bootcamps e plataformas de código padronizadas. Por que não ir além, e de fato aplicar os preceitos da linguagem que estudamos nas nossas respostas, em vez de apenas fazer os testes para passar?

Raciocínio lógico não é tudo em programação, pois a gente programa para outras pessoas. Nosso código, portanto, deve ser legível, fácil de manter e de alterar quando preciso. Nem sempre sempre seremos nós mesmos quem cuidará de manter nosso "legado" em um projeto. 

Em um mercado que está cada vez mais imerso em metodologias ágeis de entrega contínua, saber fazer um código escalável e flexível a implementações novas em cada sprint é fundamental - muito mais fundamental do que apenas escrever um código que implementa uma feature simples.

Não precisamos aplicar os preceitos descritos por Uncle Bob em qualquer situação. Afinal, às vezes é só um código simples de “Hello World” e não seria de fato preciso fazer várias abstrações, complicando ainda mais o problema.

Feita essa ressalva, vou usar um desafio da Dio como exemplo. É um desafio, aliás, possível de resolver com um simples System.out.println(), concatenando variáveis que vieram do .split() de uma string padronizada. Duas linhas resolvem o código, é fato.

Mas… o desafio foi proposto em um bootcamp e vem logo em seguida à apresentação de uma série de aulas sobre Orientação a Objetos, o coração da linguagem Java.

Então, não valeria a pena se desafiar a utilizar o que você aprendeu no curso, em vez de apenas retornar o resultado esperado?

Em programação, existem diversas maneiras de se chegar ao resultado desejado. Então existe uma série de possibilidades diferentes para um mesmo código. E isso é muito legal!

Mas vou postar abaixo uma das várias possíveis soluções, que utilizam os conceitos de Orientação a Objetos do Java e de organização de código, como por exemplo:

• Princípio da responsabilidade única para métodos e classes;
• Abstração de um objeto da vida real para uma Classe;
• Acesso público x privado (encapsulamento);
• Sobrescrita de método;
• Tratamento de exceções;

E você poderia ir muito além, utilizando Enum, validação completa de dados, tipagens mais apropriadas etc etc etc. O céu é o limite!

Em vez de mostrar para o recrutador que você sabe chegar na resposta certa, mostre que você também sabe utilizar os conceitos da linguagem e que se preocupa com a legibilidade e manutenção do seu código para o futuro - ou seja, que está pronto para o trabalho em equipe e entregas contínuas!

/*
Desafio
O seu amigo quer verificar quais os imóveis estão disponíveis em uma certa corretora na região onde ele mora. A corretora disponibilizou uma API para ele, mas como ele não entende nada de programação, pediu a sua ajuda. Para deixar tudo bonitinho, você resolveu criar um aplicativo para seu querido amigo, mas quando foi olhar a API retornava os dados de uma forma esquisita, separado por barras. Ajude seu amigo deixando a informação mais amigável possível.


Entrada
A entrada será a classificação do imóvel, o valor do aluguel dele e se ele está disponível no momento.


Saída
A saída deverá ser as informações da entrada, porém de uma forma mais amigável. (sem as aspas)


Entrada                      | Saída
Casa/1900/Disponivel         | "Imovel: Casa R$1900 Disponivel" 
Apartamento/850/Indisponivel | "Imovel: Apartamento R$850 Indisponivel"

*/


import java.util.Scanner; 
  
public class Main {
  public static void main(String[] args) {
      Scanner leitor = new Scanner(System.in);
      String frase = leitor.next();

      try{
        String teste[] = separarDados(frase);
        Imovel imovel = new Imovel(teste[0], teste[1], teste[2]);
        System.out.println(imovel);
      } catch (ArrayIndexOutOfBoundsException err) {
        System.out.println("Erro: os dados inseridos são inválidos");
      }
  }


  /*
  Se as regras de separação mudassem no futuro, poderíamos apenas alterar o método responsável por essa tarefa, 
  facilitando legibilidade e manutenção (responsabilidade única)
  */
  public static String[] separarDados(String frase){
    return frase.split("/");
  }


  /*
  Nos desafios, temos apenas um arquivo, o main, para resolver os problemas. Mas, na vida real, teríamos de separar
  nossas classes em módulos apropriados para melhor manutenção
  No mundo do desenvolvimento back-end, esta classe seria a representacao de uma entidade no banco de dados
  */
  public static class Imovel{
    private String tipo; //poderia ser Enum
    private Integer valor; //na vida real seria um numérico decimal
    private String disponibilidade; //poderia ser Boolean


    public Imovel(String tipo, String valor, String disponibilidade){
      this.tipo = tipo;
      this.valor = Integer.parseInt(valor); // poderia criar um método com tratamento de erros
      this.disponibilidade = disponibilidade;
    }
    
    public String getTipo(){
      return this.tipo;
    }      
    
    public Integer getValor(){
      return this.valor;
    } 


    public String getDisponibilidade(){
      return this.disponibilidade;
    } 


    @Override
    public String toString(){
      return "Imovel: " + this.tipo + " R$" + this.valor + " " + this.disponibilidade;
    }
    
  }
}