DEV Community: Ana Carolina

Capítulo 1 Clean Code: Uma análise do livro por capítulo

Ana Carolina — Fri, 11 Oct 2024 12:57:57 +0000

Recentemente, por incentivo do meu chefe, comecei a ler o famoso livro Clean Code. Eu já tinha lido alguns capítulos no começo da carreira, mas acredito que relembrar vai ser essencial, ainda mais tendo passado por boa parte dos casos mostrados e entendendo na prática o que é um bom código.

O objetivo dessa escrita vai ser uma análise do meu ponto de vista, alguns tópicos também foram conversados com o chatGPT para que ele me ajudasse a destrinchar melhor, dividido por capítulos, esse método me ajuda a fixar o conteúdo, repassando os pontos marcados no livro e também pode ajudar outros desenvolvedores.

Capítulo 1

O capítulo 1, do mesmo nome do livro "Clean Code" basicamente faz um apanhado do que pode ser definido como um código limpo, trazendo definições, reflexões interessantes e pontos de vista de autores famosos que possuem uma base robusta pra dizer o que consideram ser um código limpo.

Pra começar, achei divertida a metáfora de um grego lavando um pergaminho com código, um trocadilho interessante pra começar a abordar o assunto.
O primeiro autor que é citado nesse capítulo é Kent Beck, que diz que o livro dele "is based on a rather fragile premise: that good coode matters…", após essa citação, o autor se mostra consternado com essa afirmação retrucando que acha uma das premissas mais robustas, e que Kent sabia disso. Nesse caso, levei um pouco menos ao pé da letra, é indiscutível que um bom código importa, talvez mais que tudo no desenvolvimento, mas talvez seja uma premissa frágil por ser tão facilmente subestimado, esquecido, no cotidiano é normal que desenvolvedores deixem de fazer um bom código devido a correria de uma entrega, ou a falta de importância do resto do time (e isso também é citado em algum outro momento do livro), e por mais que eu concorde que é essencial, infelizmente não da pra negar que é um aspecto extremamente frágil.

Ainda no tópico "Bad Code" o autor faz uma pergunta direta "Have you ever been significantly impeded by bad code?" pra apresentar o conceito de wading pra depois perguntar "why did you write it?", soltei um ar pelo nariz lendo essa pergunta porque acredito no motivo que descrevi acima, o que me faz sentir mal porque eu sou responsável pelo código que crio, amo o que faço e nada justifica a criação de um código ruim. E aí vem a parte onde ele apresenta possíveis argumentos pra criação de um código ruim.

O livro também conta com uma "solução" pra esse problema, falando que atitude é uma coisa que deve ser trabalhada também, como eu falei, desenvolvedores são responsáveis pelos códigos ruins que escrevem, e acho que a partir do momento que pessoas que querem fazer um bom trabalho entenderem isso (não é fácil), as tarefas no backlog podem esperar pra uma entrega de qualidade.

Uma coisa que me fez pensar muito nesse capítulo foi o paragráfo
A programmer without "code-sense" can look at a messy module and recognize the mess but will have no idea what to do about it. A programmer with "code-sense" will look at a messy module and see options and variations.

Particularmente, acho meio injusta essa afirmação, o que não muda a veracidade da mesma. Só que já experimentou a sensação de saber que tem algo ruim ali mas não ter conhecimento necessário pra melhorar sabe o quão agonizante é esse sentimento. Confesso que sinto uma certa inveja desse dom, porque também vejo pessoas que estudam pouco mas tem um senso de lógica fascinante pra lidar com esses momentos, e pra mim, por mais que estude muito e tente sempre melhorar e treinar minha lógica, ainda não é tão fácil.
Começando a espécie de "junção" de depoimentos de grandes autores da programação, são feitos alguns discursos interessantes definindo clean code.

Um deles, o criador do C++, Bjarne Stroustrup, fala duas coisas que achei bem importantes:

The logic should be straightforward to make it hard for bugs to hide
Clean code does one thing well

A primeira é óbvia, mas quando dita se mostra sensacional, código ruim é mais fácil de manter os bugs escondidos, e a segunda, é uma coisa que o livro cita bastante que é focar em uma coisa, esse é um conceito curioso porque até então eu não considerava que escrevia códigos ruins, mas sempre buscava tornar as coisas amarradinhas para que fosse de melhor entendimento, esse ponto me abriu os olhos para separações, principalmente depois da definição de que códigos ruins tentam fazer muita coisa, que possuem ambiguidade de propósito, e vamos citar isso melhor numa abordagem dos próximos capítulos. O autor também cita a palavra eficiência duas vezes, o que é irônico visto que duplicidade é fortemente repudiada na programação e no livro também.

Grady Booch, também deu seu depoimento dizendo que código limpo deve ser lido como uma prosa, achei bem fofo esse ponto de vista e uma verdade absurda. O que reforça que código limpo deve expor claramente os problemas que deseja resolver e também cita aquele momento de clímax onde as coisas começam a fazer sentido e sorri lendo porque essa é minha parte favorita da programação. Código bom não é especulativo, é auto descritivo.

Dave Thomas, ao qual tenho um certo carinho por conta do primeiro livro realmente técnico que li "O Programador Pragmático", comenta "It provides one way rather than many ways for doing one thing", o que reforça o ponto de focar bem em um só objetivo, além de citar testes, aqui acho que ele foi categórico porque tenho muito pra mim que bons códigos são testados, não sei se pensava que unitários e de aceitação, como Dave diz, mas como ele citou, acho interessante explicitar também. Nesse tópico, também é dito que existe uma diferença entre um código fácil de ler e um código fácil de mudar, e isso me fez pensar de novo sobre o modo que eu conduzo meu código.

Michael Feathers, autor do livro "Working Effectively With Legacy Code", trouxe que código limpo sempre parece ter sido escrito por alguém que se importa, e aqui, ele foi categórico! Citei o livro dele porque ele me ganhou demais nessa afirmação e adicionei na minha lista. Ao longo da minha trajetória, me deparei com vários tipos de código e INÚMERAS vezes percebi que a pessoa não se importava, isso é um pouco revoltante porque eu me importo e sei que isso sempre vai voltar pra mim de alguma forma, seja em refatoração ou atrapalhando meu cotidiano. A questão é que é muito perceptível quando as pessoas não se importam com o que estão fazendo e é perda de tempo se dedicar tanto a algo que não se importam o mínimo.

Ron Jeffries foi um dos que me fez parar, pensar e conversar com o ChatGPT sobre seu testemunho, num dos pontos que define um código limpo, ele citou que "Minimizes the number of entities such as classes, methods, functions and the like", essa frase me deixou num dilema pois como vimos, muitos autores (inclusive o próprio Ron) defendem que o código deve fazer apenas uma coisa, pegando o exemplo de uma função que faz apenas uma coisa, isso me obriga a criar outras funções que fazem outras "uma coisa só". Conversei com o ChatGPT sobre isso, trazendo esse questionamento, ao qual ele me respondeu que apesar de ser um ponto interessante, que Ron menciona isso e que o próprio livro posteriormente enfatiza o SRP (vou falar disso no capítulo de funções), parecendo contraditório. Mas que devemos considerar que a ideia é manter o código simples, coeso e fácil e que pra isso devemos ter equilíbrio, onde embora o número de declarações aumente, cada uma será mais simples, focada em uma só tarefa. De qualquer forma, acho que discordo desse ponto de Ron, apesar de entendê-lo.

Ward Cunningham trouxe uma frase muito interessante também "You can call it beatifull code when the code also makes it look like the language was made for the problem", com poucas palavras, pra mim ele matou a definição, pena que isso é díficil de ver no dia a dia.

Por último, como ponto importante, o livro mantinha uma preocupação na minha cabeça de ter um hype tremendo de limpar código mas não conseguir manter o código, sem querer, no primeiro capítulo, o autor me deu uma dica interessante, através do "Princípio dos Escoteiros", que diz que você deve deixar o lugar mais limpo do que encontrou, aplicar isso no código me fez conversar de novo com o ChatGPT sobre se fazer isso não estaria tirando o foco do meu desenvolvimento, mas novamente ele me respondeu que a resposta era o equilíbrio, que não precisam ser feitas grandes refatorações, mas que posso nomear melhor uma função, ou remover uma duplicação. Nessa dúvida me apressei em falar com ele desnecessariamente porque o próprio autor fala isso logo em seguida.

Como testes E2E podem nos surpreender

Ana Carolina — Thu, 29 Aug 2024 22:41:34 +0000

Recentemente, desenvolvi o hábito de ler pelo menos dois artigos cada noite antes de dormir para refletir mais sobre minha carreira. Ontem, o Medium sugeriu um artigo de uma grande empresa. O artigo falava sobre como a equipe implementou sua própria ferramenta de testes end-to-end dentro do projeto. Isso me lembrou de uma fase na minha carreira em que todos discutiam que deveríamos desenvolver nossas próprias tecnologias. Naquela época, eu era jovem e tola, mas aprendi que, às vezes, grandes empresas de tecnologia preferem controlar quais tecnologias usar, e isso faz sentido para mim. Está tudo bem.

No entanto, criar uma ferramenta E2E não me parece fácil. Trabalhei muito com o Cypress quando estava envolvida na equipe de Design System, e sempre gostei desse método de ver o que está sendo renderizado na página (eu sou front-end ne) e o que estamos testando, incluindo comportamentos, etc. Mas não posso negar que não é uma tecnologia simples.

De qualquer forma, estava pensando em como isso poderia ser um ótimo ponto para incluir no seu currículo. Em uma entrevista, você pode ser perguntado: “Qual é um dos maiores feitos da sua carreira?” e você poderia responder: “Ah, não é grande coisa, talvez quando eu trabalhei na xxx e implementamos nossa própria ferramenta para testar aplicações end-to-end…”

Fiquei muito interessado naquele artigo e o li com grande entusiasmo. Era um ótimo texto onde o autor discutia os desafios que os motivaram a não usar o Cypress e o Playwright (eu nunca tinha ouvido falar deste último antes, mas parece bastante semelhante ao Cypress com base na descrição dele). Ele mencionou quatro pontos, mas vou escrever sobre um deles:

Dificuldade em fazer chamadas para um endpoint de API alternativo sem implementar regras personalizadas de reescrita da camada de rede.

No projeto que eu trabalho atualmente, lido apenas com testes unitários, mas passei algum tempo resolvendo problemas e lendo a documentação do Cypress. Eu era estagiária naquela época, então aprendi muito com isso e estou quase certa de que o Cypress pode lidar com esse problema!

Então, comentei sobre isso no artigo, e acho que isso pode não ser amplamente conhecido. Veja, não acho que essa grande empresa não tenha pesquisado isso antes de começar a criar sua própria biblioteca com uma perspectiva revolucionária sobre testes end-to-end, mas isso me motivou a escrever sobre esses problemas e fornecer alguns exemplos básicos de como abordá-los (embora eu realmente não acredite que isso seja útil para eles, apenas para conhecimento geral).

Então, vamos ao problema: “Dificuldade em fazer chamadas para um endpoint de API alternativo sem implementar regras personalizadas de reescrita da camada de rede.” Neste caso, é importante notar que eles não disseram que é impossível, apenas que é difícil.

1. Interceptors

Com este código, estou interceptando solicitações para o endpoint especificado. Isso me permite simular uma resposta dentro do teste. Usar a propriedade “body” fornece os dados simulados, tornando a propriedade “fixture” opcional. As fixtures são úteis quando você deseja simular várias respostas ou configurar regras complexas na camada de rede. As propriedades “delay” e “throttleKbps” permitem simular condições de rede, como latência e limitações de largura de banda. Essa abordagem permite testar diferentes cenários sem modificar o endpoint real e possibilita aplicar várias condições de rede.

2. Configurações de Ambiente

Ok, isso pode ser mais difícil dependendo do projeto em que você está trabalhando, mas se você tiver essa opção, pode configurar diferentes ambientes para os testes e usar um arquivo .env para apontar as APIs para esses ambientes alternativos. Trabalhei em um repositório que tinha cinco ambientes, e um deles era dedicado exclusivamente a testes end-to-end. Essa configuração depende das necessidades e da robustez do seu projeto.

3. API Mockings

Talvez o ponto mais importante desta lista (embora eu realmente goste do primeiro) seja que você pode usar uma variedade de mocks de API para simular quaisquer respostas que desejar, sem precisar interagir com os endpoints reais. Existem inúmeras bibliotecas de mocking disponíveis; eu já usei a jackfranklin/test-data-bot, que não é a melhor, mas é uma opção para criar mocks baseados em respostas.

Novamente, estou quase certa de que essa grande empresa pesquisou essas soluções antes de afirmar que são difíceis e incompatíveis com seus problemas. No entanto, se você encontrar dificuldades ao fazer requisições para um endpoint de API alternativo porque acha que precisa implementar regras personalizadas na sua camada de rede, você pode usar interceptadores para simular respostas nos testes, redirecionar e manipular suas requisições de maneira simples. Você também pode usar configurações de ambiente para configurar diferentes ambientes, facilitando os testes em vários contextos. Além disso, você pode usar mocking de API, com ou sem uma biblioteca, para eliminar a necessidade de reescrever sua camada de rede!

Em alguns dias, escreverei mais sobre os outros pontos deste artigo…

Até mais!

How E2E tests could surprise us

Ana Carolina — Thu, 29 Aug 2024 22:38:33 +0000

Recently, I developed a habit of reading at least two articles each night before sleep to reflect more on my career. Yesterday, Medium suggested an article from a big company. It was about how the team implemented their own end-to-end tool within the project. This reminded me of a phase in my career when everyone argued that we should develop our own technologies. At that time, I was young and foolish, but I learned that sometimes big tech companies prefer to control which technologies to use, and that makes sense to me. That's okay.

However, creating an E2E tool doesn't seem easy to me. I worked extensively with Cypress when I was involved with the Design System team, and I always liked this method of seeing what is rendered on the page and what we are testing, including behaviors, etc. But I can't deny that it's not a simple technology.

Anyway, I was thinking about how this could be a great point to include on your resume. In an interview, you might be asked, "What is one of the biggest achievements in your career?" and you could answer, "Oh, not a big deal, maybe when I worked at xxx and we implemented our own tool to test end-to-end applications…"

I was very interested in that article and read it with great excitement. It was a great piece where the author discussed the challenges that motivated them not to use Cypress and Playwright (I had never heard of the latter before, but it seems quite similar to Cypress based on his description). He mentioned four points, but I will write about one of them:

Difficulty in making calls to an alternative API endpoint without implementing custom network layer API rewrite rules.

Today, I only work with unit tests in my current project, but I spent some time resolving issues and reading Cypress documentation. I was an intern at that time, so I learned a lot from it, and I'm almost sure that Cypress can handle this problem!

So, I commented on this in the article, and I think it might not be widely known. Look, I don't think this big company didn't research this before starting to create their own library with a revolutionary perspective on end-to-end testing, but this motivated me to write about these issues and provide some basic examples of how to address them (although I really don't believe it would be helpful to them, just for general knowledge).

So, let's go to the problem: "Difficulty in making calls to an alternative API endpoint without implementing custom network layer API rewrite rules."
In this case, it's important to note that they didn't say it's impossible, just that it's difficult.

1. Intercepts

With this code, I'm intercepting requests to the specified endpoint, this allows me to mock a response inside the test. Using the "body" property provides the mock data, making the "fixture" property optional, they are useful when you want to simulate variuos responses or configure complex custom rules at network layer, "delay" and "throttleKbps" allow you to simulate network conditions, such as latency and bandwitdh limitations. This approach lets you test different scenarious without modifying the actual endpoint and enables you to apply various network conditions.

2. Enviroments Settings

Okay, this can be more difficult depending on the project you are working on, but if you have this option, you can configure different enviroments for tests and using a .env file to point the APIs to these alternative enviroments. I worked in a repository that had five enviroments, and one of them was dedicated solely to end-to-end tests. This setup depends on the needs of your project.

3. APIs Mockings

Maybe the most important point on this list (though, I really like the first one, interceptors), is that you can use a variety of API mocks to simulate any responses you want, without needing to interact with the actual endpoints, these are a countless mocking libraries available, I've used jackfranklin/test-data-bot, it's not the best but it's one option for creating mocks based on responses.

Again, I'm almost sure that this big company researched these solutions before claiming that they are difficult and incompatible with their problems. However, if you encounter issues making requests to an alternative API endpoint because you think you need to implement custom rules in your network layer, you can use interceptors to simulate responses in tests, redirect and manipulate your requests in a simple way. You can also use environment settings to configure different environments, making it easier to test in various contexts. Additionally, you can use API mocking, with or without a library, to eliminate the need to rewrite your network layer!

In a few days, I will write more about the other points in this article…

Bye!

Quero contribuir com o Hacktoberfest mas sou iniciante em programação: o que posso fazer?

Ana Carolina — Fri, 16 Oct 2020 17:11:41 +0000

O HacktoberFest é um evento de desenvolvimento de código aberto que encoraja todo mundo a contribuir para a comunidade global através de Pull Requests feitos em repositórios/projetos do GitHub que contenham a tag "hacktoberfest"
O evento começou dia 1 de Outubro e os Pull Requests podem ser realizados a qualquer momento entre essa data até o dia 31 de Outubro.

O site diz que "se você é um desenvolvedor, estudante, anfitrião de evento ou uma companhia de qualquer tamanho, você pode ajudar", mas muitas pessoas ficam inibidas por acreditarem que é difícil contribuir já que não possuem conhecimento "suficiente" em programação para ajudar no crescimento desses repositórios.

Esse foi o meu caso, mas eu decidi não fazer disso um problema, eu entrei na comunidade do HacktoberFest no Discord (onde eu fui muito bem recebida por TODOS) e procurei por projetos com o mínimo de coisas em HTML, CSS ou Bootstrap onde eu pudesse fazer alguma diferença, já que estou aprimorando meus estudos front atualmente, não encontrei NADA...

Fiquei muito frustrada mas, passado alguns dias, eu decidi contatar algumas pessoas na comunidade do Discord, que postaram seus repositórios nomeados com coisas como "Bibliotecas para te ajudar em seus estudos", e me ocorreu que eu poderia fazer traduções dessas bibliotecas para o Português Brasileiro (é um fato que os programadores Brasileiros não possuem material de qualidade traduzido para a nossa linguagem).

Você pode imaginar minha felicidade quando eles disseram que eu podia fazer isso? A maioria concordou com essa ideia e me permitiu fazer as traduções nos repositórios, a partir disso fiz alguns Pull Requests e em uma conversa com um dos membros da comunidade, me foi sugerido tentar traduzir variáveis strings em alguns programas, ou em outra palavras criar a versão brasileira de um software específico.

Eu fiquei muito surpresa com essa sugestão, mas acabei aceitando porque achei que seria uma boa forma de contribuir e resolvi testar essa nova forma de contribuição com o próprio usuário que me sugeriu isso. Fiz as alterações no documento e ele não só aceitou meu Pull Request como me disse que me procuraria em breve para fazer a tradução de outros programas feitos por ele.

Depois disso, eu percebi como os issues (issues são como permissões para fazer alguma coisa naquele repositório) que eu abri anteriormente foram crescendo com muitas pessoas que queriam traduzir aquele repositório para seu idioma.

Ta, mas o que você está tentando passar através dessa história?

Você quer ajudar a comunidade global de código aberto? Então você pode! Não importa o seu nível de conhecimento, quando você decide ajudar, converse com a comunidade, contate amigos, explore sua habilidade ao máximo possível! Não há sensação melhor do que contribuir no projeto de alguém de alguma forma. Além de ser bom para os donos dos repositórios, também é vantajoso para você! Contribuições são uma atitude extremamente consideradas no mundo da programação!

Não se limite pensando que você não tem talento suficiente, tente o seu melhor e faça aquilo que você sabe. A comunidade do código aberto com certeza será receptiva e te ajudará o máximo que puder!

Precisa de ajuda com algum passo dessa jornada? Pode me chamar!

I want to contribute with Hacktoberfest but i'm a beginner in programming: what can i do?

Ana Carolina — Fri, 16 Oct 2020 17:07:43 +0000

The HacktoberFest is an open-source developer event where everyone is encouraged to contribute for the global community through Pull Requests made in any public repositories/projects that contains "hacktoberfest" label in GitHub.
The event started October 1 and the Pull Requests can be realized anytime between this date until October 31.

The event site says "if you're a developer, student, event host or an company of any size, you can help", but a lot people are inhibited because they believe it's hard to contribute since they don't have "enough" knowledge in programming to help in the growth in any repository.

That was my case, but I decided not to make this a problem. I entered in HacktoberFest community in Discord (where I was very well received by EVERYBODY) and I searched for projects with minimal HTML, CSS or Bootstrap things where I could make some difference, since I'm beginning in front-end and I was so sad because I didn't find ANYTHING for my profile...

I was very frustrated but, some days passed and I decided to contact some people in the Discord community again, that posted their repositories before with names like "Libraries to help you in your studies", and it occurred to me that I could make some translations in these libraries for Brazillian Portuguese (it's a fact that Brazillian programmers don't have enough quality material translated for our language to study).

Well, I got in contact with them and could you imagine my happiness when they said that I could do it? Most people agreed with this idea and allowed me to make these translations in the repos, so I made some Pull Requests and in a conversation with one of the members of the community, he suggested for me a first try to translate the strings variables in some softwares, in another words, he wants me to create a brazilian version of some specific software.

I was very surprised with this suggestion, but I've accepted because I think that was a nice form to contribute, and my test with this new mode was with their own repo. I made the translations in all front-end software and he not only accepted my Pull Request, but also said that he will look for me to make other translations in some softwares he needs.

After that, I realized how the issues (issues are like permissions to do something in some repo) that I had opened before were growing with a lot of people that wanted to translate that repository for their language.

Okay, but what message do you want to get across with this history?

Do you want to help the open-source global community? Then you can! No matter your knowledge level, when you decide to help, talk with the community, contact some friends, explore your skills the most you can! There is no better feeling than contributing to someone else’s project somehow.

Besides being good for repo owners, it's a big advantage for you too! Contributing is an extremely valued attitude in the programming world!

Don't limit yourself thinking you don't have enough talent, try your best and do whatever you know. I'm sure that the open-source community will be very welcoming and help you the most they can!

And I'll be too! If you want some help with this, send me a message and I'll do my best to help you!