Boas Práticas

Boas práticas de programação para iniciantes

Quando estamos começando a lidar com linguagens de programação, ficamos mais preocupados em fazer nosso código funcionar do que qualquer outra coisa. Normalmente, a última coisa que prestamos atenção é se o código está legível e “bonito” se de ver… Porém, é importante começarmos a seguir algumas boas práticas de codificação desde o início. Isso irá lhe auxiliar a criar o hábito de escrever código de fácil entendimento e de manutenibilidade aprimorada. Às vezes, nós mesmos não conseguimos entender um código que fizemos a um tempo atrás.
Se você está iniciando agora, veja algumas dicas para colocar em prática.

Utilize nomes significativos

Quando escrevemos qualquer trecho de código que seja, é importante deixar claro o que é uma variável ou o que um método faz. Um dos pontos que precisamos seguir para atingirmos este objetivo é utilizarmos nomes significativos para as nossas estruturas de código. Evite nomear variáveis, métodos e classes com nomes que não tenham nada a ver com o contexto… O código deve ser simples e direto, deixando claro a sua intenção logo na primeira leitura.
Por exemplo: quando estamos iniciando nossos estudos em desenvolvimento e precisamos escrever uma estrutura de código que faça uma soma, geralmente escrevemos algo similar ao abaixo:

public int fazer_a_soma(int a, int b)
{
    return a + b;
}

Veja que temos alguns pontos que poderíamos melhorar, tornando nosso código mais legível: poderíamos simplificar o nome do método e darmos nomes mais claros para os nossos parâmetros… Nosso método, depois de corrigido (ou refatorado), poderia ficar da seguinte maneira:

public int somar(int numero1, int numero2)
{
    return numero1 + numero2;
}

Cuidado com os comentários!

Os comentários geralmente nos ajudam a explicar ou recordar de algo no código. Porém, comentários em excesso não é algo muito legal… Se você está tendo que explicar tudo que ocorre em seu código, é porque o código provavelmente está mal escrito ou bagunçado. Sendo assim, tente sempre restringir os comentários aos trechos onde realmente seja necessário. Trechos de código que sigam práticas como a utilização de nomes significativos geralmente auxiliam a restringir os comentários aos trechos onde os mesmos sejam de fato necessários.

Reaproveite o código

Se você está fazendo algo que já existe em mais de um lugar, é interessante pensar em uma forma de evitar essa duplicidade. Por isso, sempre pense em reaproveitamento de código, criando estruturas (como classes e métodos) mais abstratas e reaproveitáveis. Pensar em reaproveitamento de estruturas diminui o volume de código e torna o processo de manutenção centralizado e muito mais facilitado.

Idente seu código

A identação, que consiste nos tabs ou espaços agrupando os diferentes blocos de código, é algo essencial. Um trecho de código mal identado é terrivelmente difícil de ser lido. Por isso, atente-se sempre à identação dos trechos de código que você escrever. Lembre-se também que a maioria das IDEs e editores de texto modernos possuem atalhos que identam todo seu código de maneira rápida e automática, portanto: utilize este recurso sempre!
Veja abaixo um trecho de código com identação incorreta. Repare que o código é super complicado de ser lido, ainda mais por se tratar de um trecho de código com múltiplos blocos.

if(idade > 18) {
 System.out.println("Idade maior que 18");
} else if(idade == 18) {
System.out.println("Idade é igual a 18");
            } else { 
 System.out.println("Idade menor que 18");}

Veja agora o mesmo trecho de código corretamente identado. Veja que o código parece mais “fluído”, se tornando muito mais fácil de ser lido simplesmente por estar com a identação correta.

if(idade > 18) {
    System.out.println("Idade maior que 18");
} else if(idade == 18) {
    System.out.println("Idade é igual a 18");
} else {
    System.out.println("Idade menor que 18");
}

Mesmo sendo iniciante, é importante sempre estarmos atentos às possibilidades de como melhorar nosso código, pois isso é um ponto que o mercado em geral valoriza muito. Por mais que a maioria das empresas desejarem que seus softwares funcionem, elas também esperam que o código produzido apresente qualidade. Bons desenvolvedores estão atentos hoje às boas práticas de codificação.
Neste artigo, foram abordadas algumas práticas mais simples. Mas, caso queira se aprofundar ainda mais em pontos relacionados às boas práticas de código limpo, temos o artigo “Dicas para manter seu código limpo e legível” para que você possa melhorar cada vez mais a escrita de seus códigos.

Dicas para manter seu código limpo e legível

Atualmente, o mercado exige que os desenvolvedores não “programem” simplesmente. Muitas empresas desejam profissionais que possuem domínio de boas práticas e noções de arquitetura – o famoso “código limpo”. Muitas vezes, podemos até pensar: “não… as empresas desejam apenas que o software funcione”. A curto prazo pode até ser real esta afirmação, mas quando falamos sobre médio e longo prazo, que é quando certos problemas começam a aparecer, é que os débitos técnicos (os trechos de código que foram mal escritos ou funcionalidades que não foram implementadas da maneira correta) voltam para nos assombrar.

O famoso “código limpo” (ou “clean code”) é um estilo de desenvolvimento que tem como foco a escrita de código claro, conciso e de fácil manutenção posterior. Profissionais que se atentam a essas práticas costumam ser vistos de maneira diferente quando seu código é analisado em uma entrevista de emprego. Ter o código limpo e bem escrito facilita a leitura e é importante para o aumento da qualidade do software. Se você não se preocupa com isso, fatalmente, até mesmo em um curto prazo, você mesmo pode não entender seu próprio código! A situação piora ainda mais quando um desenvolvedor vai tentar entender o código de outra pessoa, ainda mais se for em uma empresa que tenha alta rotatividade na equipe (o que é uma situação bem comum nas empresas de software aqui no Brasil). As consequências desse tipo de situação são claras: perde-se muito tempo com a manutenção do software, gerando muitas vezes até mesmo situações de retrabalho.

A adoção de práticas de “clean code” acaba auxiliando a resolver estes pontos. Porém, ainda podemos obter outros benefícios através da adoção destas práticas: mais do que garantir a qualidade do código e do software, a adoção de práticas de “código limpo” trazem também maior produtividade, por consequência direta ao fato de que um software com qualidade exige menos processos de manutenção e, quando esta é necessária, o esforço a ser realizado acaba se tornando muito menor do que o usual.
Abaixo, descrevemos alguns tópicos comuns no que diz respeito ao “clean code”.

Escreva métodos curtos

Um método deve ser escrito de uma forma que qualquer pessoa que “bata o olho” entenda o que ele faz. Métodos demasiadamente extensos certamente não ajudam neste ponto. Alguns livros de arquitetura de software pregam que um método deve ter no máximo 15 linhas, embora até 25 linhas seja tolerável, caso seja muito necessário.

Utilize nomes de variáveis e métodos claros e bem definidos

Os nomes de variáveis e métodos devem ser precisos, claros e diretos, passando diretamente a ideia do que ele faz. Não tenha medo de escrever um nome grande caso seja necessário. Um nome bem descritivo irá possibilitar uma melhor compreensão e, posteriormente, uma melhor manutenção do código. Antes termos uma variável chamada valorTotalNotaFiscal do que valTot. A grande maioria das ferramentas de desenvolvimento hoje em dia oferecem a funcionalidade de autocomplete, o que invalida a justificativa de que “perdemos tempo ao digitar nomes de variáveis e métodos muito grandes” para não utilizarmos nomes mais diretos para nossas estruturas de código.
Vale lembrar que nomes de métodos sempre deve ter nomes de verbos, já que são criados para executar algum procedimento. No caso de classes, deve-se usar substantivos no singular.

Separação clara de responsabilidades entre métodos e classes (Single Responsability Principle – SRP)

Um método deve desempenhar apenas uma tarefa. O Single Responsability Principle, ou Princípio da Responsabilidade Única, é um de cinco princípios para utilização de boas práticas de codificação chamados S.O.L.I.D. Este princípio define que cada estrutura de código, seja uma classe ou um método, deve possuir apenas uma única responsabilidade, ou seja: cada estrutura deve fazer uma única coisa.
Tome cuidado também com a justificativa de uma classe. Os métodos existentes de uma classe devem estar alinhados com sua definição. Não adianta colocarmos um método chamado acelerar() dentro de uma classe chamada Mesa, sendo que quem acelera é um Carro.

Cuidado com a quantidade de parâmetros que os métodos recebem!

Quanto menos parâmetros um método receber, mais legível ele será. Sempre garanta que os parâmetros que um método recebe são de fato necessários. Quando uma quantidade muito grande de parâmetros for necessária, tente utilizar design patterns como o builder ou, pelo menos, agrupar esta quantidade de parâmetros em uma especificação de objeto a ser repassado como parâmetro único para o método.

Cuidado com o overpattern!

Design patterns são legais, desde que utilizados da maneira correta. Quando os design patterns são aplicados da maneira incorreta ou utilizados em conjunto de maneira complicada por pura “satisfação técnica pessoal”, estes acabam mais atrapalhando do que ajudando, já que a utilização de design patterns acaba por trazer uma certa complexidade ao código. Por isso, para evitarmos futuros débitos técnicos, é essencial que essa complexidade oriunda com a aplicação de um ou mais patterns seja devidamente justificada.

Para avaliar se você deve aplicar ou não um conjunto de design patterns, lembre-se sempre de um princípio chamado K.I.S.S. – Keep It Short and Simple, ou Mantenha Isso Pequeno e Simples (ainda existem algumas variações sob essa sigla). Sempre escreva suas estruturas de código da maneira mais direta e simples, aplicando simplesmente os patterns que são de fato necessários para a situação. Não crie débitos técnicos desnecessários por sofrer antecipadamente: escreva trechos de código claros e concisos que, quando necessário, possam ser modificados para estruturas e patterns mais complexos de maneira tranquila.

Entre um desenvolvedor que sai aplicando técnicas como DDD, CQRS, Event Sourcing e uma variedade de patterns gigantesca para um simples cadastro de uma entidade que nem tem relacionamentos e um desenvolvedor que utiliza patterns mais simples como o Repository e o Service Pattern, pode ter certeza que o mercado de maneira geral irá dar a preferência para o segundo desenvolvedor. E isso não o define com menos habilidades técnicas que o primeiro desenvolvedor – muito pelo contrário: o segundo desenvolvedor provavelmente possui um nível de maturidade maior que o permite calcular bem os benefícios de cada abordagem em diferentes situações.

Object Calisthenics em PHP – Parte 2

Este artigo é uma continuação do anterior. Para relembrarmos, abaixo a lista dos assuntos e em negrito os que serão abordados nesse artigo:

  1. Um nível de indentação por método
  2. Não use ELSE
  3. Envolva seus tipos primitivos
  4. Envolva suas collections em classes
  5. Uma chamada de método por linha
  6. Não abrevie
  7. Mantenha as classes pequenas
  8. Não tenha classes com mais de duas variáveis de instância

3. Envolva seus tipos primitivos

Podemos definir esse exercício para os tipos escalares em PHP que são: int, float, bool e string. “Envolver” vem de um significado da programação orientada a objetos, que quer dizer, colocar o tipo “envolta” de uma classe, a fim de trazer mais resultados e funcionalidades do que um tipo comum/escalar.

Essa técnica vêm de uma aplicação do DDD (Domain-Driven Design) chamada de Value Object, onde temos um objeto-valor pequeno, que irá cuidar de um tipo de dado específico. Como o PHP é fracamente tipado, a melhor aplicação será em passagens de parâmetros de métodos ou funções. Veja o código abaixo:

class Customer
{
    protected $name;
    protected $birthday;

    public function __construct(string $name, string $birthday)
    {
        // Validar aqui???
        $this->name = $name;
        $this->birthday = $birthday;
    }
}

Ambos parâmetros são validáveis e não é legal validarmos no construtor da classe, pelo fato de não podermos reaproveitar as validações. Já o fato de forçarmos os atributos como string na entrada, algo errado pode acontecer se o desenvolvedor que está usando a classe não souber, por exemplo, qual padrão de data utilizado para a entrada $birthday, o que pode gerar um problema lá na frente, possivelmente no banco de dados.

Abaixo um exemplo de bom e outro de mau uso da classe:

// Programador que conhece a classe
$customer = new Customer('John Doe', '1983-02-10');

// Programador que não conhece a classe
// pode gerar um 0000-00-00 no Database
$customer = new Customer('John Doe', '10/02/1983'); 

Poderíamos então usar duas classes que farão envolvimento no tipo string, por exemplo:

  • CustomerName: que cuidará de validação de nome de cliente, pode verificar tamanho, fazer trim, e até limpeza.
  • CustomerBithday: Mais importante que o nome, ela vai validar o formato da data ou até mesmo formatar a entrada como, por exemplo, converter 10/02/1983 para 1983-02-10, evitando assim um problema de inconsistência, lembrando que não precisa ser necessariamente uma classe e, seguindo o princípio de inversão de dependência, podemos facilmente trabalhar com interfaces seguindo estratégias.

Como ficaria após a implementação dessas classes:

class Customer
{
    protected $name;
    protected $birthday;

    public function __construct(CustomerName $name, CustomerBirthday $birthday)
    {
        $this->name = $name;
        $this->birthday = $birthday;
    }
}

Usando:

// Programador que conhece a classe
$customer = new Customer(
     new CustomerName('John Doe'), 
     new CustomerBirthday('1983-02-10')
);

// A data será formatada internamente
$customer = new Customer(
    new CustomerName('John Doe'), 
    new CustomerBirthday('10/02/1983')
);

Um possível problema dessa abordagem é que ela adiciona complexidade à base de código. Na tradução dos Object Calisthenics, é colocado que todos os tipos primitivos devem ser envolvidos em classes, porém, sabemos que em PHP isso pode se tornar improdutivo e desnecessário, portanto, analise o quanto aquela entrada ou tipo pode sofrer mudança, se precisa de validação, normalização etc, só aplique-o se tiver uma real justificativa.

4. Envolva suas collections em classes

Semelhante ao exercício anterior, devemos envolver nossas coleções. Isso significa que trabalhar com um CustomerList é melhor do que com um array, neste caso, o uso dará uma melhor flexibilidade para o tratamento da coleção.

Abaixo uma usabilidade com e outra sem coleção em classe:

// A lógica fica fora, o que pode trazer problemas futuros
foreach ($customers as $customer) {
    if ($customer->isGoldAccount()) {
        $customer->addBonus(new Money('R$ 50,00'));
    }
}

Nesse exemplo queremos adicionar um bônus aos clientes do tipo gold. $customers é um array e por isso para modificar a coleção, precisamos iterá-la com um foreach e ainda internamente verificar se o tipo do cliente é gold.

Se usarmos uma classe que envolve a coleção, ou seja, uma CustomerCollection ela poderá ter 2 métodos:

  • Para filtragem de tipos de clientes: filterGoldAccounts.
  • Para adicionar aos clientes o bônus: addBonus.

A usabilidade ficaria assim:

$customersCollection = new CustomersCollection; // Classe com Lazy Loading

// Filtramos os clientes de conta Gold
$goldCustomers = $customersCollection->filterGoldAccounts();

// Adicionamos pela collection o bonus de R$ 50,00
// filtrado pela classe de coleção
$goldCustomers->addBonus(new Money('R$ 50,00'));

// Por fim persistimos
$goldCustomers->persists();

Assim, temos coleções que são específicas e inteligentes o suficiente para melhorar a usabilidade e evitar erros de programação. No PHP temos um conjunto de classes padrão para lidar com listas, a SPL(Standard PHP Library) que tem uma sessão dedicada a iteradores.

5. Uma chamada de método por linha

Devemos sempre fazer uma chamada de método por linha, não se aplicando à bibliotecas que usam do padrão Method Chaining ou DSL(Domain Specific Language).

Para seguir esse exercício não devemos, por exemplo, ao desenvolver um conjunto de Models, relacioná-los com métodos em cadeia, isso pode ser uma péssima ideia, segue um exemplo:

$customer->getById(55988)
         ->getPurchase(18376)
         ->getProducts()
         ->filterById(234);

Queremos resgatar um produto do pedido de um cliente, pode-se parecer muito prático, porém, alguns problemas poderão ocorrer e é muito difícil testar um bloco desses. Como saber se getPurchase encontrou o pedido? E se não encontrou, o que acontece? Nesse caso, vem outra problemática: e se o pedido não contém itens ainda? E temos um retorno null, certamente teremos um erro de método não encontrado.

Por isso, para garantir que tudo ocorreu certo, podemos seguir a Lei de Demeter, ela diz que devemos somente conversar com classes próximas, então, criamos um método para conversar e filtrar o que precisamos, ao invés de percorrer pelos Models que estão distantes. Não focaremos na implementação, porém, o conceito de uso abaixo pode ilustrar essa aproximação:

// Resgatando o model isoladamente
$customer = $customerModel->getById(55988);

// Aproximação: método que pertence a Customer
// sua implementação cuidará de retornos nulls
$product = $customer->getPuchasedProduct(18376, 234);

O principal objetivo desse exercício é não sair percorrendo por objetos retornados em chamadas de métodos, usar chamadas de vários métodos em linha pode gerar muitos problemas de manutenção, dificuldade de entendimento e testes mal escritos. Costuma-se dizer que gera um código que “cheira mal”.

Conclusão

Esses exercícios são mais aprofundados e devem ser estudados com calma, não devemos seguí-los somente por que parece ser o certo, devemos entender a motivação por trás deles, lembrando que nenhuma dessas técnicas são balas de prata e vão servir para toda modelagem, o bom senso é a melhor direção.

Até o próximo artigo da série!

Object Calisthenics em PHP – Parte 1

O conceito de object calisthenic foi criado pelo desenvolvedor Jeff Bay, que teve a visão de que praticar código reutilizável, limpo e de boa leitura é uma prática que necessita de muito exercício, ou seja, muita prática e constante melhoria e evolução através de ações e práticas.

Ele é composto por nove exercícios que constituem a aplicação dos mesmos ao se escrever código em orientação a objetos.

Object vem da programação orientada a objetos, e calisthenics do termo grego, Kales, simplificando, seria a forma de se obter um físico ou, no caso, um resultado a partir da prática de exercícios que deixarão seu código em “forma”.

Ao todo são nove regras básicas, veja abaixo:

  1. Um nível de indentação por método;
  2. Não use ELSE;
  3. Envolva seus tipos primitivos;
  4. Envolva suas collections em classes;
  5. Uma chamada de método por linha;
  6. Não abrevie;
  7. Mantenha as classes pequenas;
  8. Não tenha classes com mais de duas variáveis de instancia;
  9. Sem getters e setters;

Veremos neste artigo as duas primeiras que são exercícios fortíssimos que fazem já muita diferença quando praticados.

1. Um nível de indentação por método

Como já especificado devemos internamente dentro de uma função usar somente um nível de indentação, quanto mais níveis de comandos de decisão ou estruturas de decisão, mais complexo o método fica, minando com a simplicidade do projeto.

Abaixo podemos ver um exemplo disso:

Código sem a regra de indentação:

class Customer
{
    public function getPromoCode(string $promoName)
    {
        // 1.
        if ($this->promoCode) {
            // 2.
            if (false === $this->promoCodeExpired()) {
                // 3.
                if ($this->promoName == $promoname) {
                    return $this->promoCode;
                } else {
                    throw new Exception('Promoção não existe mais');
                }
            } else {
                throw new Exception('Promoção Expirada');
            }      
        } else {
            throw new Exception('Cliente sem código de promoção');
        }
    }
}

Uma forma de “treinar” esse exercício é criando métodos protegidos auxiliares que tenham um motivo e reaproveitamento, atuando na facilitação da escrita e colocando os blocos dentro das funções de apoio.

Veja como resolvemos o problema acima:

class Customer
{
    public function getPromoCode(string $promoName)
    {
        if ($this->promoCode) {
            return $this->getValidPromoCode($promoName);
        } else {
            throw new Exception('Cliente sem código de promoção');
        }
    }

    protected function getValidPromoCode(string $promoName)
    {
        if (false === $this->promoCodeExpired()) {
            return $this->getPromoExists($promoName);
        } else {
            throw new Exception('Promoção Expirada');
        }    
    }

    protected function getPromoExists(string $promoName)
    {
        if ($this->promoName == $promoName) {
            return $this->promoCode;
        } else {
            throw new Exception('Promoção não existe mais');
        }
    }
}

2. Não use ELSE

Essa regra parece ser muito estranha, mas ela funciona muito bem com o conceito early return, que emprega o uso do “retorne seu valor o quanto antes”, ação que só é facilmente implementada dentro de funções, métodos ou loops.

A base deste exercício é sempre trabalhar com o return (ou continue), sabemos que ao cair em um return/continue o código abaixo não será executado o que ajuda na remoção dos “elses” ao inverter ou até modificar a validação antes usada.

Abaixo o código anterior com early return:

class Customer
{
    public function getPromoCode(string $promoName)
    {
        if ($this->promoCode) {
            return $this->getValidPromoCode($promoName);
        } 
        throw new Exception('Cliente sem código de promoção');
    }

    public function getValidPromoCode(string $promoName)
    {
        if (false === $this->promoCodeExpired()) {
            return $this->getPromoExists($promoName);
        }
        throw new Exception('Promoção Expirada'); 
    }

    public function getPromoExists(string $promoName)
    {
        if ($this->promoName == $promoName) {
            return $this->promoCode;
        }
        throw new Exception('Promoção não existe mais');
    }
}

Como trocamos os comandos de decisões para que fique um código limpo removemos os “else’s”, e simplificamos a lógica que passa a ser melhor compreendida e limpa, esse conceito também pode ser aplicador para loops, onde o intuito é usar o continue no lugar do “else”.

Vejamos abaixo um exemplo:

Antes:

// Exibir a lista de membros
// que pagaram a mensalidade
foreach ($members as $member) {
    if ($member->paid()) {
        $report[] = [$member->name => 'Paid'];
    } else {
        $report[] = [$member->name => 'Not Paid'];
    }
}

Depois:

// Sem Else
foreach ($members as $member) {
    if ($member->paid()) {
        $report[] = [$member->name => 'Paid'];
        continue;
    }
    $report[] = [$member->name => 'Not Paid'];
}

Ou até com um pouco mais de limpeza:

// Um pouco mais de limpeza
foreach ($members as $member) {
    $report[] = $member->paid() ? 
                    [$member->name => 'Paid'] : 
                    [$member->name => 'Not Paid'];
}

Conclusão

Veremos em breve as outras regras numa série de posts. O uso do object calisthenics trás muitos benefícios que em grande escala fazem uma grande diferença, comece esses exercícios e terá seu código elogiado e muito mais elegante.

Obviamente nem sempre é possível de imediato “atacar” seu código com os calisthenics, mas com refatorações isso começa a ficar natural e quanto mais prática mais natural fica a aplicação desses exercícios.

Espero que tenham gostado e nos vemos nos próximos posts. Bons estudos!

Práticas que todo desenvolvedor que não trabalha em uma equipe deveria seguir

A demanda de projetos na área de desenvolvimento nunca esteve tão aquecida como atualmente. Inclusive, escrevemos aqui no blog sobre o mercado de desenvolvimento web, vale muito a leitura.

Nesse mercado tão aquecido o número de programadores freelancers ou que trabalham sozinhos está cada dia maior. Em grandes projetos, mesmo os programadores freelancers que trabalham remotamente, possuem a possibilidade de participar de uma equipe, porém, na maioria dos pequenos e médios projetos isso nem sempre é possível. Muitos freelancers ou até profissionais fixos trabalham apenas em “EUQUIPE”, como brincávamos na faculdade referindo ao trabalho “solitário”.

Trabalhar sozinho em um projeto pode ser algo extremamente legal e prazeroso, porém, muito tempo trabalhando sozinho pode trazer alguns “prejuízos” para carreira de um desenvolvedor se ele não tomar alguns cuidados.

Falta de revisão de código

Quando um projeto de software está sendo desenvolvido em uma equipe é normal que vários programadores trabalhem sobre o mesmo trecho de código em momentos diferentes por necessidades próprias do projeto. Em uma equipe ideal, quando um programador mais experiente encontra um trecho de código que ele não acha legal, normalmente tende a conversar com quem escreveu para dar dicas sobre uma melhor maneira de desenvolver aquele trecho.

Em outros projetos quando um código é commitado, o próprio pessoal da equipe passa no código por conta própria para verificar se existe algum trecho a ser melhorado e, utilizando serviços como GitHub, levantam uma discussão sobre as decisões tomadas.

Dependendo da metodologia usada no projeto é possível que seja utilizada a prática de programação em par, onde dois desenvolvedores trabalham juntos com objetivo de escrever um código com mais qualidade.

Essas práticas podem aumentar a qualidade do código do desenvolvedor, pois ele aprende a pensar de vários pontos de vista na hora de resolver um determinado problema, além da experiência natural que ele ganha de trabalhar com outros profissionais.

Quando o desenvolvedor trabalha sozinho, normalmente não é possível ter esse feedback natural do código. Além disso, ele não tem a possibilidade de analisar o código de outros desenvolvedores. O problema disso é que ele pode escrever um código ruim por não conhecer as práticas corretas ou até mesmo escrever código com qualidade extremamente baixa por falta de tempo e, como ninguém vai ler aquele código, isso acaba virando um padrão para ele, o que também é um grave problema.

Problema na escolha das tecnologias

Quando estamos em uma equipe normalmente existem vários tipos de desenvolvedores envolvidos. Existem aqueles “hipsters” que gostam de coisas diferentes, querem usar aquele banco dados que ninguém conhece, aquela lib beta e outras coisas do tipo. Existem também aqueles que estão sempre ligados às novidades, porém, são um pouco mais conservadores, além, claro, daqueles que são extremamente conservadores. Quando todos esses perfis se misturam a escolha das tecnologias tende a se equilibrar e chegar a um meio termo bacana.

O problema é quando uma única pessoa vai fazer a escolha das tecnologias de um projeto. Se for alguém extremamente hipster pode acabar escolhendo recursos que no andamento do projeto causem algum problema de compatibilidade ou que seja necessário desenvolver algo do zero e que já existe pronto em outras tecnologias. Ao contrário, se o desenvolvedor for conservador, ele pode acabar ficando anos em um mesmo conjunto tecnologias por comodidade, o que geralmente é mais comum de acontecer. O problema é que o desenvolvedor pode acabar “parando no tempo”.

Habilidade de trabalhar em equipe

Trabalhar em equipe requer além de skills de desenvolvimento de software. Pessoas geralmente pensam de modo diferente, pode ser difícil para muita gente aceitar as opiniões alheias sobre os seus trabalhos. Existem também as dificuldades de comunicação, empatia e outras habilidades necessárias para trabalhar em equipe.

Trabalhando isolado o desenvolvedor tende a perder um pouco essas habilidades. Existem também aqueles desenvolvedores que nunca trabalharam em equipe, esses podem não ter a chance de desenvolver essas habilidades.

O que podemos fazer para evitar esses problemas

Nesse ponto do artigo se você for um desenvolvedor carreira solo deve estar pensando em abrir um site de emprego e procurar uma equipe para trabalhar o mais rápido possível, porém, existem muitas coisas que podemos fazer para evitar tais problemas, o primeiro é ter ciência deles. Existem algumas práticas que podem nos ajudar a desenvolver as habilidades descritas acima mesmo trabalhando sozinhos.

Na verdade, a maioria das práticas expostas abaixo deveriam ser seguidas por todos os desenvolvedores, mas para quem trabalha sozinho elas são quase obrigatórias na minha opinião.

Participar da comunidade

Uma das coisas mais incríveis da área de desenvolvimento de software são as comunidades. Enquanto em muitas outras áreas os profissionais estão preocupados em esconder o modo como fazem determinado processo, nas comunidades de desenvolvimento estão sempre procurando dividir as experiências e entender como os problemas diários estão sendo resolvidos.

Para quem trabalha sozinho a comunidade pode evitar que se fique isolado do mercado. É possível absorver diversos comportamentos que você teria com a sua equipe de projeto, substituindo pela interação com o pessoal da comunidade.

Contato diário

Geralmente, assim como uma equipe de trabalho, o pessoal da comunidade está em contato quase todo dia. Existem membros mais ativos e outros menos, porém, se acompanhar o histórico, com certeza todo dia terá algo para ler. Cada comunidade tem um modo de se comunicar, mas os principais escolhidos são:

  • Slack
  • Telegram
  • Grupos no Facebook
  • Fóruns

Geralmente nesses grupos muitos desenvolvedores tiram dúvidas desde coisas mais simples até decisões complexas de projeto. Outras pessoas postam artigos que escrevem e que acham importante compartilhar. Existem também oportunidades de trabalho para freelancers e emprego fixo, além de convites para meetups e outros eventos.

Os grupos de comunidade podem ser uma grande oportunidade para tirar dúvidas, porém, muito além disso, existe a possibilidade de ajudar outras pessoas. Um dos melhores modos de aprender algo é ensinando, digo isso por experiência própria. Quando precisar explicar algo para alguém você precisará pensar sobre aquilo, pesquisará tudo para dar uma resposta correta. Outra grande oportunidade é compartilhar conteúdo, se tiver tempo escreva artigos e tutoriais. Isso vai aumentar o seu nível de conhecimento e, com certeza, também vai construir uma imagem sua na comunidade. Inclusive, caso queira ser um autor do nosso blog basta entrar em contato.

Eventos

Os eventos de comunidade são algo muito legal! Geralmente eles possuem palestras, coffee breaks e até happy hour. Neles é possível aprender novos recursos nas palestras, ver o que o pessoal está utilizando, conhecer novas pessoas, além da oportunidade de uma conversa mais descontraída.

Participar de projetos Open-source

Projetos open-source são uma ótima oportunidade para programadores trabalharem em equipe. Apesar de não ser exatamente do mesmo modo que uma equipe de trabalho convencional, esses projetos permitem você desenvolver algumas habilidades importantes para qualquer programador.

Analisar código de outros programadores

Para trabalhar em projetos open-source precisará entender e alterar código de várias pessoas diferentes. Com isso, terá a oportunidade ler código de diversos programadores diferentes, ganhando bastante experiência e repleto repertório de soluções.

Revisão do seu código

Ao enviar uma requisição de mudança para um projeto open-source, o código que escreveu ou modificou provavelmente passará por outros programadores, para só então depois ser aceito, com isso você terá o feedback deles.

Ajuda na documentação

Projetos open-source geralmente precisam de ajuda em outros aspectos que não estão ligados à programação em si. Um dos trabalhos mais importantes é a documentação. Caso ainda não se sinta seguro para realizar alterações no código, pode se oferecer para ajudar na criação da documentação ou até mesmo na tradução para português. Trabalhando nisso, automaticamente estará estudando sobre a ferramenta que se tem interesse.

Oferecer qualquer tipo de ajuda

Tanto nas comunidades, quanto em projetos open-source, sempre existe algum tipo de trabalho a ser feito. Seja em divulgação e organização de eventos, ajudando outras pessoas ou qualquer coisa do tipo, isso ajuda muito no engajamento com a comunidade.

Estar sempre aberto a novas tecnologias

Como falado no começo do artigo não precisa ser aquele desenvolvedor que pega qualquer tecnologia nova e já quer aplicar em projetos reais, mas também não precisa ser aquele que fica anos e anos usando a mesma coisa. Nossa área é muito rápida, dominar uma tecnologia hoje pode não significar nada daqui 3 anos.

Nesse ponto estar ligado nas comunidades, eventos, projetos open-source nos ajudam a saber que existem coisas novas, o quanto elas já estão sendo usadas e se realmente vale a pena colocar em seus projetos.

Investir em qualificação

As mudanças nas ferramentas fazem nossa área ser extremante volátil. Já falei isso no parágrafo acima e ao escolhermos essa área já estávamos cientes disso. É extremamente importante, além de todas as práticas faladas nesse artigo, investir constantemente em treinamentos.

Gosto muito da ideia pensar em treinamentos como curadoria de conteúdo. Hoje em dia existe muito conteúdo sobre tudo o se que possa imaginar. Na nossa área também é assim, existem ótimos artigos, podemos ter acesso a eles sem nenhum custo, porém, muitas vezes somos bombardeados por conteúdo e ficamos perdidos sobre qual caminho seguir. É exatamente nesse ponto que entram os treinamentos.

Nossos cursos aqui do TreinaWeb, além do fato dos instrutores possuírem grande experiência de mercado, outra grande vantagem é o planejamento do conteúdo. A grade é pensada da melhor forma possível para você entender um determinado conteúdo de forma gradual. O ambiente virtual e a metodologia são propícios para o ensino de tecnologia, além do suporte que permite tirar suas dúvidas sobre o conteúdo de forma rápida e dedicada. Isso garante um aprendizado muito rápido de novas tecnologias, permite se aprofundar nas que já conhecemos e os certificados possuem reconhecimento do mercado.

Conclusão

É extremamente importante se manter dentro das práticas de mercado e obter feedback sobre o nosso trabalho. As ideias acima podem muito lhe ajudar nesse ponto. Fique à vontade para nos contar nos comentários quais práticas você utiliza no dia a dia para manter a sua carreira e seu trabalho em alto nível.

JUNTE-SE A MAIS DE 150.000 PROGRAMADORES