DEV Community: Bea Lourenço

O que eu pude aprender lendo Clean Coder?

Bea Lourenço — Mon, 17 Mar 2025 18:31:57 +0000

Bom, o livro Clean Coder faz parte de uma coleção de livros do autor Robert C. Martin (nosso queridíssimo Uncle Bob) que busca orientar desenvolvedores sobre boas práticas relacionadas ao mundo do desenvolvimento de software.

Minha primeira experiência com o autor foi com o livro Clean Code, livro voltado principalmente a boas práticas ligadas ao código - como o uso estratégico de comentários, a importância dos testes, a relevância de bons nomes para funções e variáveis, dentre muitos outros conselhos interessantes.

Já no segundo livro que tive contato, o foco é em se tornar um bom desenvolvedor, sabendo os momentos de dizer sim e não, como assumir e arcar com as responsabilidades, como interagir bem com o time, se manter sempre atualizado e agregar valor à empresa.

Profissionalismo - em relação ao profissionalismo, algumas mensagens importantes, em minha humilde opinião são os seguintes:

Um bom profissional sabe como se portar no ambiente corporativo, de acordo com os códigos de conduta do lugar em que está;
Um bom profissional mantém seu time sempre a par do status do projeto, independente de qual seja;
Um bom profissional está sempre atento às demandas da empresa e do cliente;
Fugir dos pontos supracitados, o transforma num mal profissional.

Dizer sim - um bom profissional sabe os momentos certos para dizer sim, sem ceder à pressão ou influência de terceiros, que poderia influenciar negativamente no decorrer do projeto; mais profissionais dizem sim pra tudo e acabam não conseguindo arcar com suas responsabilidades e comprometimento.

Dizer não - seguindo a linha do sim, bons profissionais também sabem o momento certo para dizer não, para evitar contrair mais responsabilidades do que podem atender. Da mesma forma, dizer não para tudo, o torna um mau profissional.

Testes de aceite - os testes de aceite são necessários para garantir que o sistema cumpra com o desejado. O ideal é que seja escrito pelo QA e pelo Analista de negócios (para garantir que os caminhos felizes e tristes estão cobertos e garantir maior qualidade do software. Vale lembrar que um bom desenvolvedor testa seu código e o envia funcional para o QA).

Praticar - é certo que a prática leva a perfeição e algumas considerações trazidas pelo autor são: seu tempo de trabalho não deve ser seu tempo de prática. Todas as profissões demandam prática e isso não seria diferente no desenvolvimento. Uma recomendação interessante é escolher um algoritmo e desenvolver soluções para ele, até o domínio completo e também o pair programming.

Pressão - a pressão é algo presente no cotidiano de todas as pessoas, o ponto alto é a forma que se lida com essas pressões impostas, seja em relação ao tempo ou as maneiras que as demandas que devem ser entregues.

Estimativas - em relação às estimativas, o ponto mais legal abordado foi a forma que diferentes profissionais/setores enxergam as estimativas.
O pessoal da área de negócios entende as estimativas como algo já definido, ou seja, eles precisam de um prazo e acreditam que essa estimativa de prazo é 100% real e fidedigna. Em contrapartida, para os desenvolvedores, uma estimativa é uma ideia do tempo que pode levar para que uma tarefa seja executada, variando para mais ou para menos.
Existe um modelo de cálculo de estimativas sugerido no livro que pode ajudar a encontrar um valor médio aceitável para as estimativas.

Colaboração - é importante entender que existem diversas relações em que a colaboração é necessária: entre desenvolvedores e pessoas, clientes, empregadores e até mesmo (creio que principalmente) entre desenvolvedores, afinal, compartilhar conhecimento, escrever um código inteligível, trabalhar em conjunto para resolver problemas facilita e agiliza bastante o processo de desenvolvimento.

Times e projetos - em suma, é preferível construir um bom time, bem integrado e capacitado, que possa atuar em diversos projetos do que desmembrar, criar e recriar times todas as vezes que um novo projeto for aprovado.

Clean Code – Anotações interessantes sobre os capítulos de 12 à 14

Bea Lourenço — Sat, 04 May 2024 02:52:46 +0000

Capítulo 12 – Emergência
No capítulo 12, de acordo com Kent, o design de um sistema é considerado simples caso siga as seguintes regras:
• Passa por todos os testes;
• Não há duplicidade;
• Expressa a intenção do programador; e
• Minimiza o número de classes e métodos.

Também é dito que, havendo testes, somos impulsionados a manter nosso código limpo e podemos alcançar isso refatorando o código. Além disso, quanto mais claro o código for escrito pelo autor, menor será o tempo demandado para compreender o que ele deve fazer.

Capítulo 13 – Simultaneidade
O capítulo 13 começa citando alguns mitos sobre o uso de simultaneidade no desenvolvimento, sendo eles:
• Simultaneidade melhora performance;
• O design não muda ao escrever código simultâneo;
• Entender simultaneidade não é importante ao usar contêineres como Web ou EJB.
Também é mencionado algo mais fidedigno em relação a construção de softwares simultâneos:
• Simultaneidade incorre em alguma sobrecarga, tanto em performance quanto em código adicional;
• O uso correto de simultaneidade é complexo, mesmo em casos simples;
• Bugs de simultaneidade normalmente não se repetem, por isso comumente são ignorados;
• Simultaneidade geralmente demanda uma mudança significativa na estratégia de design.

Capítulo 14 – Refinamento sucessivo
O capítulo 14 começa dizendo que, para escrever um bom código limpo, primeiro é necessário escrever o código “sujo” e “limpá-lo”.
O autor sugere como alternativa interessante o TDD (Test-Driven Development), que torna impossível prosseguir com o desenvolvimento de código que causa danos ao sistema, já que a premissa é escrever primeiro um teste e passar por ele, antes de seguir com novos desenvolvimentos.

Observação sobre os capítulos 15 ao 17: São capítulos mais voltados a análise de algumas ferramentas e refatoração de classes levando em consideração conceitos abordados no livro, além de uma visão geral dos capítulos anteriores.

Clean Code – Anotações interessantes sobre os capítulos de 8 a 11

Bea Lourenço — Thu, 02 May 2024 02:24:36 +0000

Capítulo 8 - limites
No oitavo capítulo, falamos sobre os limites de um sistema e a importância de conhecê-los bem. Um ponto interessante a ser considerado é o uso do código de terceiros, como bibliotecas e APIs, pois nosso acesso, enquanto usuários, é limitado e precisamos controlar essas limitações, para não interferirem no sistema que está sendo desenvolvido; inclusive, testes são uma boa maneira de aprender sobre o código de terceiros, seus limites e ainda assim, manter testes coerentes ao projeto.

Capítulo 9 – testes unitários
No nono capítulo, o assunto tratado foi um dos mais interessantes: testes unitários. Confesso que é um tema que não domino e pude aprender bastante com este capítulo.
Gostaria de citar 3 leis do TDD (Test Driven Development) – fora a famigerada “primeiro escreva os testes, depois o código”.

• Primeira Lei: não escreva código até que tenha escrito um teste que falhe;
• Segunda Lei: não escrever mais do que um teste suficiente pra falhar e não compilar é considerado falha.
• Não escrever mais código do que o necessário para passar o teste que está falhando;
É importante manter os testes limpos e organizados, para garantir que o código se mantenha flexível.

Capítulo 10 – Classes
No capítulo 10, o tema classes é abordado e um dos pontos interessantes é a primeira regra sobre classes: elas devem ser pequenas. A segunda é que devem ser menores do que isso XD
Classes devem seguir o princípio de responsabilidade única (SRP) e devem também ser coesas.

Capítulo 11 – Sistemas
O capítulo 11 aborda alguns pontos sobre arquiteturas de sistema, mas em suma, sistemas no geral precisam ser considerados/construídos limpos. Uma arquitetura bagunçada pode impactar na lógica e na agilidade, facilitando o aparecimento de bugs.

Clean Code – Anotações interessantes sobre os capítulos de 4 a 7

Bea Lourenço — Wed, 03 Apr 2024 00:27:25 +0000

Oioi pessoal, tudo bem? Hoje eu trago alguns pontos que achei interessantes sobre o livro Clean Code.

Capítulo 4 – comentários

O quarto capítulo nos traz algumas boas práticas relacionadas ao uso de comentários. Em primeiro lugar, precisamos saber que comentários boa parte das vezes, são decorrentes da falha dos desenvolvedores, ao escrever o código, salvo casos em que são realmente necessários (como comentários legais) ou trazem algum benefício real.
Alguns tipos de comentário são: informativos, sobre algo que está acontecendo; explicação de intenção, sobre algo que se espera que aconteça em determinado bloco de código; aviso de consequências, caso o bloco de código seja alterado; comentários TODO, para documentar tarefas à fazer.
Além disso, há comentários que são maus, como comentários redundantes e comentários errôneos, comentários desconexos/distantes do código relacionado e comentários muito extensos, dificultando a compreensão do código.

Capítulo 5 – formatação

O quinto capítulo aborda a importância do código bem formatado, para facilitar a leitura e compreensão do que está escrito. É importante a definição de um padrão, que deverá ser seguido ao longo de todo código. Alguns pontos que achei relevantes, foram: evitar linhas muito extensas, para evitar o scroll para o lado, evitar tabulações estranhas, como espaçar tipagem e nome de atributos, organizar chaves e quebras de linhas, definir variáveis próximas ao seu lugar de uso.

Capítulo 6 – objetos e estruturas de dados

O sexto capítulo traz considerações interessantes sobre objetos e estruturas de dados. [...] Esconder a implementação é sobre abstrações. Objetos: “escondem” seus dados através de abstrações e expõem funções que operam aqueles dados escondidos; Estruturas de dados: expõem seus dados e não possuem funções significativas.
Além disso, também é citada a Lei de Demeter, comumente utilizada em desenvolvimento orientado a objeto, abordando o acoplamento fraco. Alguns pontos são levados em conta, sendo eles:
• Cada unidade deve possuir conhecimento limitado sobre as outras unidades;
• Cada unidade se relaciona apenas com seus “amigos”, nunca com “estranhos”;
• Apenas se relacionar com “amigos próximos”.
Em suma, objetos expõem comportamentos e escondem dados, facilitando a criação de novos objetos, sem alterar os comportamentos existentes. Isso também dificulta adicionar novos comportamentos a objetos existentes. Sendo assim, estruturas de dados são o oposto, expondo dados e não possuindo comportamentos significantes;

Capítulo 7 – tratamento de erros

No sétimo capítulo, são trazidas algumas considerações sobre o tratamento de erros. A responsabilidade do desenvolvedor é garantir que, caso ocorra, não seja algo fatal e o código faça o que precisa ser feito. A seguir, alguns pontos que achei interessantes deste capítulo: Escrever primeiro os try/catches, dar um contexto para as exceções, definir classes de exceção de acordo com as necessidades de chamada, definir um fluxo “padrão”, não retornar nulo.

Fonte

Link do e-book

Como é a Pós-Graduação EAD?

Bea Lourenço — Sat, 23 Mar 2024 12:06:28 +0000

Olá pessoal, tudo bom?

Trouxe meus centavos de contribuição sobre como é o estudo à distância. Ao longo da jornada acadêmica, estudei de forma presencial, aulas ao vivo através de plataformas de videochamada e, por fim, aulas 100% à distância.

Na instituição em que estudo, as aulas são disponibilizadas por partes no decorrer do curso e eu tenho duas atividades para composição de nota.

O conteúdo até agora foi bastante teórico e dependendo da matéria, existem algumas leituras obrigatórias (até então, foi bem tranquilo, apenas alguns artigos ou capítulos específicos de livros).

Em relação aos prós e contras...

Prós:

As aulas são fáceis de compreender, graças a explicação dos professores e ao material de apoio;
Posso estudar em qualquer lugar, em qualquer horário. Assim consigo escolher horários em que consigo me concentrar melhor e dar mais atenção para cada tópico;
Posso repetir as aulas quantas vezes forem necessárias;
Posso tirar dúvidas com professores, sobre a matéria;
Onde estudo, os temas das aulas são divididos em blocos menores, o que ajuda bastante na organização dos estudos.

Contras:

Demanda organização e disciplina. Da mesma forma que facilita a organização, pode acabar complicando devido a liberdade e flexibilidade de dias/horários e acaba gerando acúmulo de matéria pra estudar;
Pode ser complicado encontrar um lugar adequado/silencioso para estudar.

Eu costumo estudar fazendo anotações em formato de perguntas sobre a matéria e depois respondo, com base no material de apoio, revisando os vídeos de acordo com a necessidade e também tento "explicar" pra alguém o que estou estudando.

Até então, tem sido uma experiência bem proveitosa, consigo organizar meus estudos de acordo com a rotina de trabalho e demais tarefas. No início, fiquei um pouco apreensiva por ser algo novo, mas achei uma forma de estudo bem confortável e me adaptei super bem.

Meus insights lendo Clean Code

Bea Lourenço — Wed, 12 Jul 2023 22:31:19 +0000

Este é um artigo sobre o livro Clean Code - Robert C. Martin, em que pretendo trazer, de forma sucinta, anotações e comentários sobre o que aprendi com a leitura.

Logo no prefácio, é citada a metodologia 5S - até então, eu só conhecia o 5S utilizado em ambiente industrial, graças ao trabalho do meu pai - cujos conceitos são:

Seiri (ou utilização, em português);
Seiton (ou organização, em português);
Seiso (ou limpeza, em português);
Seiketsu (ou normalização);
Shutsuke (ou disciplina);

Já no primeiro capítulo (Clean Code) , o autor nos faz pensar sobre o que é o código limpo, como deve ser feito e sua função. Gosto bastante do trecho que diz que o código limpo pode ser lido, compreendido e alterado por um desenvolvedor diferente do autor. Além disso, o código deve possuir testes de unidade/unitários/de aceite, possuir nomes significativos e poucas dependências. Ademais, evitar duplicidade de código também é importantíssimo.

No segundo capítulo (Meaninful Names) , é abordada a importância de nomes bem definidos para classes, atributos, métodos e responder questionamentos importantes, como: "Por que existe?", "O que faz?" e "Como é usado?"; deve evitar desinformação; o nome de uma classe deve conter um substantivo e evitar verbos; em contrapartida, métodos devem possuir verbos em seu nome; manter um contexto significativo e evitar o excesso de informação gratuita.

O assunto tratado é função (Functions) e acredito que o principal ponto trazido é: funções devem fazer apenas uma coisa, fazê-la bem e apenas isso. Ademais, devem ser curtas, evitar misturar abstrações pois pode dificultar a leitura e compreensão do que é feito.

O quarto capítulo nos traz algumas boas práticas relacionadas ao uso de comentários. Em primeiro lugar, precisamos saber que comentários boa parte das vezes, são decorrentes da falha dos desenvolvedores, ao escrever o código, salvo casos em que são realmente necessários (como comentários legais) ou trazem algum benefício real.

Alguns tipos de comentário são: informativos, sobre algo que está acontecendo; explicação de intenção, sobre algo que se espera que aconteça em determinado bloco de código; aviso de consequências, caso o bloco de código seja alterado; comentários TODO, para documentar tarefas à fazer.

Além disso, há comentários que são maus, como comentários redundantes e comentários errôneos, comentários desconexos/distantes do código relacionado e comentários muito extensos, dificultando a compreensão do código.

O quinto capítulo aborda a importância do código bem formatado, para facilitar a leitura e compreensão do que está escrito. É importante a definição de um padrão, que deverá ser seguido ao longo de todo código. Alguns pontos que achei relevantes, foram: evitar linhas muito extensas, para evitar o scroll para o lado, evitar tabulações estranhas, como espaçar tipagem e nome de atributos, organizar chaves e quebras de linhas, definir variáveis próximas ao seu lugar de uso.

O sexto capítulo traz considerações interessantes sobre objetos e estruturas de dados. [...] Esconder a implementação é sobre abstrações. Objetos: “escondem” seus dados através de abstrações e expõem funções que operam aqueles dados escondidos; Estruturas de dados: expõem seus dados e não possuem funções significativas.

Além disso, também é citada a Lei de Demeter, comumente utilizada em desenvolvimento orientado a objeto, abordando o acoplamento fraco. Alguns pontos são levados em conta, sendo eles:

• Cada unidade deve possuir conhecimento limitado sobre as outras unidades;
• Cada unidade se relaciona apenas com seus “amigos”, nunca com “estranhos”;
• Apenas se relacionar com “amigos próximos”.

Em suma, objetos expõem comportamentos e escondem dados, facilitando a criação de novos objetos, sem alterar os comportamentos existentes. Isso também dificulta adicionar novos comportamentos a objetos existentes. Sendo assim, estruturas de dados são o oposto, expondo dados e não possuindo comportamentos significantes;

No sétimo capítulo, são trazidas algumas considerações sobre o tratamento de erros . A responsabilidade do desenvolvedor é garantir que, caso ocorra, não seja algo fatal e o código faça o que precisa ser feito. A seguir, alguns pontos que achei interessantes deste capítulo: Escrever primeiro os try/catches, dar um contexto para as exceções, definir classes de exceção de acordo com as necessidades de chamada, definir um fluxo “padrão”, não retornar nulo.

No oitavo capítulo, falamos sobre os limites de um sistema e a importância de conhecê-los bem . Um ponto interessante a ser considerado é o uso do código de terceiros, como bibliotecas e APIs, pois nosso acesso, enquanto usuários, é limitado e precisamos controlar essas limitações, para não interferirem no sistema que está sendo desenvolvido; inclusive, testes são uma boa maneira de aprender sobre o código de terceiros, seus limites e ainda assim, manter testes coerentes ao projeto.

No nono capítulo, o assunto tratado foi um dos mais interessantes: testes unitários . Confesso que é um tema que não domino e pude aprender bastante com este capítulo.
Gostaria de citar 3 leis do TDD (Test Driven Development) – fora a famigerada “primeiro escreva os testes, depois o código”.

No capítulo 10, o tema classes é abordado e um dos pontos interessantes é a primeira regra sobre classes: elas devem ser pequenas. A segunda é que devem ser menores do que isso XD
Classes devem seguir o princípio de responsabilidade única (SRP) e devem também ser coesas.

O capítulo 11 aborda alguns pontos sobre arquiteturas de sistema , mas em suma, sistemas no geral precisam ser considerados/construídos limpos. Uma arquitetura bagunçada pode impactar na lógica e na agilidade, facilitando o aparecimento de bugs.

Capítulo 12 – Emergência, de acordo com Kent, o design de um sistema é considerado simples caso siga as seguintes regras:
• Passa por todos os testes;
• Não há duplicidade;
• Expressa a intenção do programador; e
• Minimiza o número de classes e métodos.

O capítulo 13 começa citando alguns mitos sobre o uso de simultaneidade no desenvolvimento, sendo eles:

• Simultaneidade melhora performance;
• O design não muda ao escrever código simultâneo;
• Entender simultaneidade não é importante ao usar contêineres como Web ou EJB.
Também é mencionado algo mais fidedigno em relação a construção de softwares simultâneos:
• Simultaneidade incorre em alguma sobrecarga, tanto em performance quanto em código adicional;
• O uso correto de simultaneidade é complexo, mesmo em casos simples;
• Bugs de simultaneidade normalmente não se repetem, por isso comumente são ignorados;
• Simultaneidade geralmente demanda uma mudança significativa na estratégia de design.

Capítulo 14 – Refinamento sucessivo
O capítulo 14 começa dizendo que, para escrever um bom código limpo, primeiro é necessário escrever o código “sujo” e “limpá-lo”.

O autor sugere como alternativa interessante o TDD (Test-Driven Development), que torna impossível prosseguir com o desenvolvimento de código que causa danos ao sistema, já que a premissa é escrever primeiro um teste e passar por ele, antes de seguir com novos desenvolvimentos.

Fontes utilizadas:

Obrigada por ler até aqui!
Dúvidas, sugestões e comentários são sempre bem-vindos!

Dicas para personalizar seu GitHub

Bea Lourenço — Tue, 27 Jun 2023 22:35:52 +0000

Oioi besties, tudo bem?

Hoje trouxe algumas dicas para personalizar seu perfil no GitHub. É um post bem simples, mas com um conteúdo bem legal - e com um propósito pessoal: evoluir minha escrita, além de colaborar um pouquinho com a comunidade tech.

Bem, em primeiro lugar, você vai precisar de um github. Agora, o próximo passo é criar um repositório público, com o seu nome de usuário e um arquivo readme.md (pois isso garante que ele será exibido na página inicial do seu perfil. Bacana, né?)

O GitHub apresenta algumas dicas de como preencher o seu readme, dessa forma, você pode adicionar informações que considera relevante, como preferir.

A seguir, vou deixar alguns links que utilizei pra personalizar meu perfil. São alguns ícones simples, mas que achei que deram um "tchan" no perfil =)

Por fim, uma imagem meramente ilustrativa: