DEV Community: Lucca Mabel

The Universe of Exceptions in Dart: An Uncomplicated Guide

Lucca Mabel — Thu, 07 Dec 2023 21:08:43 +0000

Developing in Dart is an exciting journey full of challenges, and one of the crucial aspects of this journey is exception handling. In this article, we'll dive head first into these topics, demystifying exception handling to make it more accessible for our end users.

The importance of implementing exception handling is to be able to deal with situations that we cannot always predict, so that our users are not impacted. From this we were able to build more robust applications, capable of dealing with unexpected situations effectively.

Success Only Programming

A common approach in the world of programming is to program a solution targeting only the path that works, where everything always works out. However, by thinking only about success, we end up not preparing our application to deal with real-world situations, where things may not work the way we expect. By neglecting these problems, we end up with a highly unpredictable and low-quality application.

It is important to think beyond the success story, and prepare the system for extraordinary, exceptional situations.

Let's understand the difference between Errors and Exceptions

In the Dart documentation, we can understand in more depth about Error Handling and some definitions that we will cover now, but in order to be objective:

Exceptions

Situations that can be anticipated and that the software must be prepared to deal with.

Errors

Situations that should not occur and that the developer should have avoided.

Try On-Catch-Finally: Dealing with the Unexpected

Now, how can we anticipate and deal with exceptional situations? Within Dart, and many other programming languages, we have a code structure precisely designed to help us deal with this: Try On-Catch-Finally.

Try

Try is used when we have a block of code that we know can cause a failure. So, we wrap the code with the Try structure, so that it can be properly handled.

In the example below, we can see that the toInt() method was structured with only the happy path in mind, however, if an error occurs, the system will simply ‘crash’.

void main() => print(toInt("5"));

int toInt(String value) {
   return int.parse(value); //Works perfectly
}

void main() => print(toInt("not a number"));

int toInt(String value) {
   return int.parse(value); //Uncaught Error: FormatException: not a number
}

How can we prepare the system to deal with this situation?

Using the Try structure.

void main() {
   try {
     print(toInt("not a number"));
   } // we'll need to complete this with 'catch', 'on' or 'finally'
}

int toInt(String value) {
   return int.parse(value);
}

On

Now that we purposely caused an exception, and started the process of handling it so that our user is not impacted, let's understand how to handle it when we know exactly the exception that will be thrown.

We know that if we pass a String “not a number”, the toInt() method will throw a FormatException. To be able to catch this exception, we will use the on structure.

on is ideal for use in situations where we know which exception can be triggered or when we want to define special treatment for a certain type of exception.

void main() {
   try {
     print(toInt("not a number"));
   } on FormatException {
     print("The value is not a valid number.");
   }
}

int toInt(String value) {
   return int.parse(value);
}

Catch

Using catch is another way to capture an exception.

Catching an exception means that it will not be propagated further. It is an opportunity to address it so that the user understands what went wrong.

void main() {
   try {
     print(toInt("not a number"));
   } on FormatException catch (e) {
     print(e.toString());
   }
}

int toInt(String value) {
   return int.parse(value);
}

catch provides the parameter e which is equivalent to error or exception. With it, we have access to the triggered object that can help us understand what went wrong.

💡 If the captured object is a FormatException, ‘e’ is of type FormatException.

It is important to highlight that in Dart, anything can be thrown as an exception, so it is important to know how they work in order to handle them in the best possible way.

Finally

finally is a clause that guarantees that a given piece of code is executed regardless of whether an exception is triggered or not. If an exception is thrown, it is only triggered after.

void main() {
  try {
    print(toInt("not a number")); // 1º
  } on FormatException catch (e) {
    print(e.toString()); // 2º
  } finally {
    print("we reached the end"); // 3º
  }
}

int toInt(String value) {
  return int.parse(value);
}

we reached the end
Uncaught Error: FormatException: not a number

Throwing Exceptions with Throw

A very common situation is when we try to indicate the success or failure of an operation using booleans, or returning some value that represents success or error. But in cases like this, when an error is returned, finding its exact source can be like looking for a needle in a haystack.

Below, we can see that the toInt() method does not give us any information if something exceptional happens.

For example, I created the rule that the passed String cannot be empty. However, the only way I can check is if the toInt() method returns 0.

This ends up being a problem when I inform, for example, toInt("0"). How do I know when the result returned is a success or error 0?

void main() {
    print(toInt("0")); // return 0 - success
    print(toInt("")); // return 0 - error
}

int toInt(String value) {
   if (value.isEmpty) return 0; // <- indicates an error

   return int.parse(value); // <- indicates success
}

To facilitate this process, let's understand the concept of throwing exceptions with throw. This practice will help us improve the clarity of our codes and also provide a clear path to understanding and solving problems, without the uncertainty of abstract values.

void main() {
   try {
     print(toInt(""));
   } on Exception catch (e) {
     print(e.toString());
   }
}

int toInt(String value) {
   if (value.isEmpty) {
     throw Exception("The provided value is empty.");
   }

   return int.parse(value);
}

With the adjustment we made above, we can validate within the method itself that the String passed cannot be empty, and if it is, an exception will be thrown informing the user that the rule was not met. Otherwise, the method continues normally.

It is also important to take into account that int.parse(value) can still trigger any type of exception. Therefore, we have our try {} on Exception catch (e) {} structure in the main method.

Creating Custom Exceptions

To further improve the clarity of our code, and the projects we work on in our daily lives, we can create customized exceptions.

I will create an exception for each rule:

The value provided can't be empty;
The value provided can't be negative.

class InformedValueIsEmptyException implements Exception {
   @override
   String toString() => 'The provided value is empty.';
}

class InformedValueIsUnderLimitException implements Exception {
   String value;

   InformedValueIsUnderLimitException({required this.value});

   @override
   String toString() => "The provided value can't be less than 0. You entered '$value'.";
}

By organizing our toInt() method with the appropriate exceptions being referenced, we can clearly see the possible situations we have and how we can handle them clearly.

int toInt(String value) {
   if (value.isEmpty) throw InformedValueIsEmptyException();

   int result = int.parse(value);

   if (result < 0) throw InformedValueIsUnderLimitException(value: value);

   return result;
}

Properties for Exceptions

Sometimes, as an exception, it is necessary to provide the user with information that may be useful so that they can have a better understanding of the problem. For example, in the exception below, we make it clear to the user that the value x they provided don't satisfy our rule that this value can't be negative.

💡 To identify the necessary parameters, think about how to clearly communicate the information to the user.

class InformedValueIsUnderLimitException implements Exception {
String value;

InformedValueIsUnderLimitException({required this.value});

@override
String toString() => "The provided value can't be less than 0. You entered '$value'.";
}

Saving in memory

Throughout this article, we explored the world of exception handling in Dart. Understanding how to implement exception handling strengthens our applications, preparing them to effectively deal with unexpected situations.

When programming, it's common to only focus on everything working perfectly. It's important not to neglect preparing for real-world situations. The best possible approach involves thinking beyond the success case, preparing the system to deal with exceptional situations.

Dart's Try On-Catch-Finally structure is a powerful tool for dealing with the unexpected. Using try to wrap blocks of code that may fail, on to catch specific exceptions, catch to handle exceptions and finally to guarantee code execution, even after an exception occurs.

We learned about throwing exceptions with throw, abandoning the common practice of indicating success or failure using booleans or special values. We also created custom exceptions, such as InformedValueIsEmptyException and InformedValueIsUnderLimitException, that helped provide clarity about the problems we encountered, making our code easier to understand and maintain.

In short, by adopting good exception handling practices and creating custom exceptions, we increase the quality of our code, promoting more robust, secure and understandable applications.

💡 This article was produced based on notes from my studies on the Alura course Dart: Dealing with Exceptions and Null Safety.

From Chaos to Consistency: How I Improved My Productivity

Lucca Mabel — Thu, 09 Nov 2023 17:27:45 +0000

For a while, I was looking for ways to improve my productivity. It's a topic that has always fascinated me because the idea of doing more with less effort is very appealing. However, the ideal vision of "being productive" often led me astray. The process of trying to do more, deliver more, be aware of everything, multitask, be a reference, study everything, and know everything became quite exhausting.

This approach ended up yielding results opposite to what I was aiming for. I wanted to do more with less effort, but I ended up in a cycle of doing much more and using up all my energy to keep up.

When I began to realize this was happening, after bouts of anxiety from feeling like I wasn't delivering enough and having no energy left for anything in my life, I decided to reevaluate my concepts about "what it means to be productive."

In the past, I used about eight different software applications to organize things like notes, calendars, studies, routines, habits. I must admit it was quite chaotic. Another thing I noticed that disrupted my routine was the lack of a strategic schedule.

I knew what I needed to do during the week, but I didn't know which days to do what. Did something have a deadline? I didn't know. Did something have priority? I didn't know. Furthermore, I had a smartphone addiction and didn't stick to my chaotic routine's schedule. All of this led to information overload, workflow congestion, fatigue, lack of maintainability, and an ever-increasing list of tasks because almost nothing got done in line.

What I Decided to Change and Believe Has Improved My Productivity and Energy Levels

First, I sat down and put on paper what I wanted to adjust. For me, the things that became a priority were:

Learning
Nutrition
Physical activity
Sleep
Personal projects
Free time

After defining these priorities, the next step, which was organizing a routine, became much easier. For my routine, I established rules. These rules help me set boundaries for what is feasible and what is not, to maintain a level of consistency in my day, and not overexert myself. Some of these rules include:

Wake-up time: Allow space for a morning routine that prepares me for the day (e.g., waking up, showering, walking the dog, having breakfast, ...).
Study time: Allocate one hour of study every workday.
Planning the workday: Allocate the first 30 minutes of work to define priorities for the day and review what was done the previous day.
Off-duty time: Allow space for personal projects, physical activity, therapy, or free time (especially on weekends).
Bedtime: Allow space for a nighttime routine that helps me rest for the next day (e.g., setting the alarm, meditating, reading, ...).

After I started incorporating these rules into my routine, I felt it became much easier to get through the day. However, some other things have also helped me maintain this consistency. Remember when I mentioned using eight apps and being addicted to my smartphone? Well, I decided to be a bit more radical about addressing this issue.

First and foremost, I cleaned up my smartphone. I deleted all the apps I didn't use, removed all non-essential app notifications, deleted social media apps, and set up "Focus" modes. Focus is an Apple feature that allows the phone to behave differently based on specific rules. In my case, I set Focus modes for Study, Work, Exercise, and Sleep. Each one has its specific rules, but the idea is that my phone doesn't remind me of its existence during these times when I need to focus my energy on something else.

Once the Focus modes were set up, I went on to clean up and redefine my entire workflow and establish my routine once and for all, following the rules and focusing on my current goals. I now use only four apps to manage my overall routine:

Cron: A calendar with a practical and clean interface. I use it to create and check fixed appointments (e.g., study time, regular meetings, time to work on side projects, physical activity time, meal prep for the week, ...).
NotePlan + Session: A powerful note-taking app aimed at helping with daily organization, creating time blocks, and tracking activity progress, combined with a Pomodoro technique software that allows note-taking at the end of each session and setting focus goals. I use this combination to manage my workdays. These are apps I was able to access through a Setapp subscription, and they have definitely made a difference in this process.
Notion: A highly versatile note-taking tool that allows documenting various things in various ways. I use it to store all kinds of information and to manage Is It Safe?, a project I've been leading for almost two years.

How Has This Helped Me?

I started this process seven months ago, taking it one step at a time and maintaining the determination to be consistent, even if I can't always follow the routine to the letter. I have been trying to do my best.

However, now I feel more energized during the day, I can see progress in my health and eating habits. I no longer have the constant need to check my phone or social media. I've started to read more, and, more importantly, I don't feel exhausted when the day is over.

What has helped me the most in this process is having a set bedtime and waking time and effectively using my calendar to keep my commitments recorded, preventing me from wasting energy every day wondering "What do I have to do today?"

This post isn't a set of rules or a one-size-fits-all guide. It's simply an account of what went very wrong for me and what has been working so far. I believe that over the long term, more solid changes will be visible as I adjust to these new habits I've created. However, regardless of the process you use, it's essential to keep two things in mind: consistency is key, and take your bedtime seriously.

Entendendo Algoritmos: Recursão

Lucca Mabel — Fri, 20 Oct 2023 21:16:51 +0000

Ao longo da minha leitura do Entendendo Algoritmos, eu tenho revisitado muitos conceitos e técnicas que eu já havia me esquecido que existiam e algumas que eu nunca consegui entender (até agora haha). Dentro desse post (e em mais alguns outros q vão vir ao longo da minha leitura) eu vou trazer esses conceitos sob uma análise de estudos pessoais.

O que é 'Recursão'?

Imagine que você chegou na academia e tava tão empolgado com o treino que colocou sua carteira no primeiro armário vazio que você achou. Quando acabou o treino, você não consegue mais lembrar em qual armário você guardou suas coisas então, vai abrindo um de cada vez até você encontrar.

Recursão começa por aí, executar uma função de forma repetida até encontrar o resultado correto.

Mas... isso também não seria um loop?

Sim, um loop pode ser uma alternativa para resolver tipos de situações como essa. Inclusive, há casos em que loops são mais benéficos pois, recursão não trás nenhum bônus em termos de desempenho.

E por mais não-atrativo que eu esteja fazendo recursão parecer, ela tem uma qualidade sem igual: Objetividade.

Mas, resumindo:

Recursão é quando uma função chama a si mesma.

Como estruturar uma recursão?

Ao estruturar uma recursão, temos duas sub-estruturas:

- Caso recursivo: Quando a função chama ela mesma.

Ex: Abrir um armário de cada vez, de forma contínua.

- Caso-base: Quando a função não chama ela mesma, evitando um loop infinito.

Ex: Parar de abrir os armários quando encontrar a carteira.

Como assim um loop infinito? Pse, quando mal implementado, pode acontecer de uma função recursiva ficar chamando ela de novo e de novo para sempre. E como não queremos isso, vamos entender como estruturar uma.

Esse é um exemplo de loop infinito. Presta atenção em como os números continuam reduzindo para sempre.

#MinhaPrimeiraRecursão

Vamos exemplificar recursão ao calcular o fatorial (!) de um número (num).

num = 3, portanto 3! = 3 x 2 x 1 => 6.

Problema: Descobrir o fatorial de um número.

Solução: Multiplicar esse número por: ele mesmo - 1, até ele ser igual a 1.

Caso recursivo: Multiplicar esse número por: ele mesmo - 1.
Caso-base: até ele ser igual a 1.

Isso em código fica assim:

Pilha e o lado sombrio da recursão

Recursão é estruturada em cima de pilhas, assim como muitas coisas no seu computador. E, o que é uma pilha?

Pilha é uma estrutura de dados onde o último dado inserido, é o primeiro a sair. Por exemplo, você tem uma pilha de livros para ler, quando for iniciar a leitura, você pega o livro que está no topo, e assim sucessivamente até a pilha não existir mais. Para entender mais sobre pilhas, aqui tem um material massa!

Contudo, ainda que recursão traga a magia da Objetividade tem a desvantagem de que você pode acabar sobrecarregando a sua pilha (da uma olhada nesse artigo para entender porque isso acontece), como no exemplo abaixo:

Mas, não precisa temer. Tem sempre outras duas alternativas:

Voltar para o bom e velho loop;
Utilizar Recursão de Cauda.

Recursão de Cauda

Se você utiliza dart, já vou deixar adiantado que isso não vai dar certo e aqui e aqui também vão ter descritivos melhores das informações referentes à isso.

Mas, caso você utilize uma linguagem que tenha suporte para Recursão de Cauda, ou curiosidade em como funciona, vamos aos trabalhos.

O que diferencia a recursão de cauda da recursão normal é que a primeira utiliza menos memória durante o processo de empilhamento, fazendo com que ela seja mais rápida.

Comparando de forma prática, ao calcular 5!, que é igual a 120, vemos uma diferença importante entre a recursão simples e a recursão de cauda. Na recursão comum, são necessárias 120 variáveis para rastrear as chamadas. Porém, na recursão de cauda, isso não é preciso, uma vez que a chamada recursiva é a última operação executada pela função. Isso simplifica o processo e economiza recursos, tornando o código mais eficiente.

E ainda que dart não tenha a otimização de recursão em cauda, ainda sim temos o exemplo abaixo de como ela seria estruturada.

Resumão

Recursão é quando uma função chama a si mesma;
Recursão é uma boa alternativa para loops quando você está buscando mais objetividade;
Às vezes pode acontecer de sua pilha ficar muito grande quando utilizar recursão;
Você pode contornar o problema da pilha grande com loops ou com recursão de cauda.

Referências

Notas de Aula – Algoritmos e Programação de Computadores
Recursão de cauda para iniciantes

Entendendo Algoritmos: Ordenação por Seleção

Lucca Mabel — Wed, 18 Oct 2023 19:54:12 +0000

Ao longo da minha leitura do Entendendo Algoritmos, eu tenho revisitado muitos conceitos e técnicas que eu já havia me esquecido que existiam e algumas que eu nunca consegui entender (até agora haha). Dentro desse post (e em mais alguns outros q vão vir ao longo da minha leitura) eu vou trazer esses conceitos sob uma análise de estudos pessoais.

O que eu preciso saber sobre 'memória'?

Bem... o mais simples de tudo é que a memória armazena informações. Mas, como ela faz isso?

Imagine que você quer ir no cinema assistir o último lançamento. Ao comprar seu ingresso, tem uma seleção de assentos disponíveis para você escolher. Você seleciona o seu, finaliza a compra e recebe o código do seu assento.

A memória funciona da mesma maneira! Você precisa armazenar algo, dentre os espaços disponíveis um é selecionado e você recebe um código falando qual espaço foi o escolhido.

O código retornado é chamado de endereço.

O espaço escolhido é chamado de slot.

Arrays x Listas Encadeadas

Agora que entendemos 'memória' vamos nos aprofundar um pouco em 'Listas'.

Simplificando, 'Listas' é quando você precisa armazenar mais de um elemento na memória. Por exemplo, ao invés de você ir só ao cinema, vai você e mais 3 amigos. Um único assento já não dá para todo mundo, vão precisar de mais!

Mas, qual tipo de 'Lista' eu escolho? Um Array ou uma Lista Encadeada?

Bem... depende de qual problema você quer resolver.

Vamos entender melhor!

Arrays

Quando utilizamos um array, significa que colocamos todas as nossas informações em slots um do lado do outro (contiguamente). Como se no cinema, sentasse você e seus amigos na mesma fileira, um do lado do outro.

Mas isso acaba virando um problema quando aparece mais 2 amigos de surpresa e não tem mais espaço na fileira. Então, se ainda quiserem ficar todos juntos, todo mundo vai ter que mudar de lugar. E, isso demora.

Mas tem duas formas de resolver esse problema. O primeiro é comprando ingressos a mais (reservando locais extras na memória). Mas, caso ninguém extra apareça, vai ser um disperdício. Ou pior, se aparecer mais gente do que você havia antecipado. Vai ter que mover todo mundo de novo.

E a outra maneira é sentar em locais separados um dos outros. Assim todo mundo consegue ver o filme, sem precisar ficar movendo de fileira caso mais alguém apareça. Portanto, fazer uso de uma lista encadeada.

Listas encadeadas

As listas encadeadas podem estar em qualquer lugar da memória. Cada um dos itens armazena o local do item seguinte e dessa forma, eles estão conectados em cadeia.

Com elas, você não precisa ficar movendo seus itens caso precise armazenar mais coisas do que havia previsto.

Observações importantes

Listas encadeadas são boas quando:

Você quer ler todos os itens da sua lista;
Você quer priorizar inserção/deleção do que leitura;
Você precisa inserir algo no meio da lista.

Arrays são bons quando:

Você quer acessar itens aleatórios da sua lista;
Você quer priorizar leitura do que inserção.

Ordenação por seleção

Vamos para a prática!

Imagine que você tem uma lista de livros, e você categorizou eles com notas de 0 à 10. Você gostaria de ordenar essa lista do seu livro favorito, para o menos favorito.

Uma forma de fazer isso é pegando seu livro mais bem avaliado e colocando em uma outra lista. E fazendo isso até sua primeira lista não ter mais itens. No final, você vai ter uma lista ordenada pelo critério que você queria.

O tempo para isso ser executado é de O(n²).

A ordenação por seleção vai resolver o seu problema, mas ele não é um algoritmo rápido.

Como implementar?

Referências

Entendendo Algoritmos: Introdução a Algoritmos

Lucca Mabel — Thu, 05 Oct 2023 20:57:11 +0000

Ao longo da minha leitura do Entendendo Algoritmos, eu tenho revisitado muitos conceitos e técnicas que eu já havia me esquecido que existiam e algumas que eu nunca consegui entender (até agora haha). Dentro desse post (e em mais alguns outros q vão vir ao longo da minha leitura) eu vou trazer esses conceitos sob uma análise de estudos pessoais.

O que é um algoritmo?

O mais simples possível é que:

"Um algoritmo é um conjunto de instruções que realizam uma tarefa."

Os algortmos são utilizados para facilitar o processo de resolver um problema.

Dado que, em um contexto de programação, um problema pode se repetir várias vezes em diferentes partes do seu sistema (ou da sua jornada técnica), ter uma solução (ou um meio para chegar na sua solução) já pré-definido aceleraria e facilitaria mais o processo, correto?

Bem, é ai que os algoritmos entram. Contudo, eles não se limitam à isso.

"Cada trecho de código poderia ser chamado de um algoritmo."

Porquê algoritmos são importantes?

Antes de partirmos para a prática, vamos entender porque é importante entendermos como os algoritmos funcionam.

Vamos imaginar um problema onde eu precise verificar se (a + b) é par.

Com certeza, deve ter várias maneiras de implementar uma solução para esse problema. Mas como eu sei se uma solução é melhor que outra?

Ainda que ambas retornem o resultado correto, uma pode ser mais rápida, a outra pode gastar menos memória.

A partir do estudo de algoritmos, podemos aprender diversas técnicas de análise que nos permitam comparar soluções e definir qual delas faz mais sentido para resolver o problema.

Ex: Ao precisar verificar se (a +b) é par. Se eu adicionar que preciso do resultado em até 2ms. De todos as soluções existentes, quais delas ainda solucionaria o meu problema?

Por isso é importante nos aprofundarmos além do que o algoritmo faz, e levar em conta também, como ele funciona.

Solucionando problemas com Algoritmos

Agora sim, vamos para prática! O primeiro algoritmo que vamos dar uma analisada é o de Pesquisa Binária. Ele facilita o processo de busca em listas ordenadas.

Pesquisa Binária

Vamos introduzir com um exemplo que o livro trás:

Você está procurando um nome (Mabel) em uma agenda com 100 contatos. Você poderia começar da letra A e ir descendo até chegar na letra M. Mas, é mais provável que você comece ali pela metade da lista, porquê é mais perto de onde a letra M fica.

Bem.. vamos destrinchar:

Problema: Achar um nome na minha agenda de contatos.

Solução: Começar da metade da lista para achar o resultado mais rápido.

Isso tem nome e é Pesquisa Binária.

"Pesquisa Binária é um algoritmo de busca que recebe uma lista ordenada de elementos e retorna a localização do item que você está buscando, caso ele esteja na lista."

Então...

Ex: Se entre 1 e 10, eu quero saber onde está o número 5, ele vai me retornar a posição dele da lista. E se eu quiser saber onde está o número 21, ele não vai me retornar nada.

Porquê Pesquisa Binária e não Pesquisa Simples?

Lembra do exemplo das diversas soluções para verificar se (a + b) é par? Então, mesmo conceito. Ao comparar ambas, a Pesquisa Binária vai resolver meu problema da agenda de contatos muito mais rápido.

Mas... como eu sei que isso é verdade?

Na Pesquisa Simples, o que pode acontecer é:

Ex 1: Eu querer o nome Aaron e o algoritmo ir la num pulo e me devolver que é o primeiro contato da lista.

Ex 2: Eu querer o nome Zakarias, o último contato.

E é ai (Ex 2) que as coisas complicam...

Na Pesquisa Simples, meu algoritmo vai ir la, de um em um, até o fim da lista para poder me falar, que Zakarias ta lá na última posição, levando mais tempo.

Já na Pesquisa Binária, começando pelo meio, se o nosso chute não for a resposta, é só verificar se ta mais para cima ou para baixo, eliminar a outra metade e partir do meio novamente.

Ex: Eu ainda quero o contato de Zakarias (100). Se começarmos do contato 50, vemos que o 100 ta mais pra cima. Então agora, eu busco entre 50 e 100, e minha nova metade é 75. E assim sucessivamente até que o resultado seja exibido.

Então, enquanto na Pesquisa Simples, foi preciso 99 etapas. Na Pesquisa Binária, foi preciso somente 7. Uma baita diferença né?!

Obs: O número de etapas de uma Pesquisa Simples é igual ao tamanho da lista (n). Enquanto o número de etapas de uma Pesquisa Binária é log2(n).

Como implementar um algoritmo de Pesquisa Binária?

O exemplo abaixo foi originalmente implementado no livro. A única coisa alterada é a sintaxe, pois abaixo está em #Dart.

Best practices for refactoring legacy code to make it more maintainable and easier to work with

Lucca Mabel — Wed, 12 Apr 2023 20:14:57 +0000

It is quite common for us developers, especially those newer to the field, to have an idea that when entering a new company, a new project, they will come across clean, well-organized, well-structured, and easy-to-navigate and maintain code (or maybe just me in my naivety haha).

With the emphasis on using the best practices in the tech market, every agile development process adopted by many companies, numerous materials on how to write quality code available, it is common to think that the scenario of the previous paragraph is the reality. However, it's not. It's much more common to find a scenario of outaded code, with outdated dependencies, outdated stack, difficult-to-read code, and confusing architecture (maybe not so chaotic haha but you get it...).

So, considering all this, what to do in the face of this chaos? How to work with legacy code? How to know where to modify? How to know if the system won't break?

These are great questions, and I hope to address them well in this article by bringing points from my personal experiences and lessons learned from the book Working Effectively With Legacy Code.

What is 'Legacy Code'?

Let's start by identifying our problem, understanding what legacy code is, and some reasons why it is generated.

We can think of legacy code as messy, unreadable, difficult to make changes to, and hard to find code. But this type of code takes time to become what we call legacy, right?

It starts off beautiful, clean, and harmonious, until someone, for example, starts implementing duplicated methods in several classes, uses abstract names for variables, implements giant methods that do many things, forgets to implement a test, doesn't perform periodic refactorings, and submits a pull request for all of this, which is approved without scrutiny for reasons X, Y, or Z. Afterwards, the person who implemented all of this leaves the team or changes projects/companies and didn't leave any documentation behind.

However, despite all of this being true, the book "Working Effectively With Legacy Code" brings a perspective that legacy code is basically code without tests. So, no. It doesn't take a lot of time to call any code legacy, you can write legacy code right now.

But why are tests so important in a software? The importance of implementing unit tests.

I think now the path we are following is a little clearer... so let's go.

Why refactor?

To understand the importance of refactoring, it's also important to understand the importance and cost of code rewriting.

I understand the problems that arise from working with legacy code. It's not a productive flow, it's not easy to find anything, you never know if you changes one thing it will break the entire system, requirements are confusing to understand, and often support is limited.

So, for these reasons, I know we think it will be easier to simply rewrite the entire system to make it clean and harmonious again. However, it's often more costly and something the company isn't willing to do at the moment. Therefore, it's important to know when to rewrite and when to refactor.

Things you should never do, Part I

Getting straight to the point...

So, why refactor?

It will take less time, and therefore, less cost. The idea in this scenario is not an extensive refactoring, it's more like "adjusting as you go".

If you're going to implement something in a method, it already helps a lot to take extra time to refactor the method you're working on and make the necessary adjustments. But, it doesn't mean you need to allocate more time to refactor the whole class, for example. Do you understand what I mean?

Nevertheless, it's important to have refactoring as a constant practice and do it whenever possible.

When to refactor?

Before starting the refactoring process, it's important to have in mind the current behavior and the expected behavior of the feature that you're going to implement/modify.

This can be easily verified with tests. But sometimes they don't exist within the system we're working on. Therefore, in order to evaluate the risks we will face when performing the refactoring process, it's important to have very clear:

The changes that will be made
How it will be verified that they were made correctly
How it will be verified that, by making the changes, nothing will break

After evaluating these cases, it's noticeable that refactoring is not always simple, and that's why many people say "if it's working, don't touch it."

But, as tempting as it may be to avoid everything, software problems will only increase over time and come back worse. And without practice, it becomes increasingly difficult to make necessary changes.

Software Evolution and the Importance of Refactoring

How to refactor?

The book presents two approaches to making changes in the system: Edit and Pray and Cover and Modify.

Edit and Pray

This practice is the most common. You try to understand the code that will be changed, are careful with the modifications, make them, and when finished, run the system to verify if what was modified is visible and try a bit more to check if nothing broke.

It's modifying with hope and faith that everything will work out and using extra time to confirm that everything really did work out.

Cover and Modify

On the other hand, this practice brings more security when making modifications. The idea is to have confidence in the changes and to know for sure that nothing will break.

For this, it is important to check if what you are looking to modify is covered by tests, so that it is possible to guarantee that the modification works as expected and does not have any other effect. With tests, it is much easier to make changes carefully and assertively.

How to test?

The book presents The Legacy Code Change Algorithm, which provides a structure for making functional changes that add value through testing.

Identify the points of change

Locate the areas where you need to implement changes.

Find the test points

Identify where you need to implement tests for the changes you will make.

Separate dependencies

Perhaps this part is where you will encounter the most difficulty. There are some techniques to perform this separation, but I won't go into it at the moment. However, I believe that this material can provide a good starting point.

Write tests

Separate the test cases and write them to cover as many scenarios as possible.

Make modifications and refactor

The book recommends using TDD for making changes in legacy code. It is a way of validating your code as you go along with the implementation. A good recommendation on how to start this practice is How I managed to start practicing TDD.

Conclusion

In summary, legacy code is a combination of situations that happen in a developer's daily life, but it's basically code without tests.

In this scenario, it is important to know when to refactor and when to rewrite code. And when refactoring, be aware of the current state of the functionality and the expected state, as well as prepare for verification scenarios to ensure that the changes were made correctly.

It's also important to know when to perform refactorings; they do not need to be extensive, but they need to be constant. When left aside, the problems arising from it will only increase over time, and you will lose the practice of solving them.

Additionally, it is important to verify if the code you want to modify has test coverage before starting a refactoring process. Only in this way, it's possible to ensure that nothing beyond the expected will be changed, and the system will work as expected.

If there isn't test coverage in the system or the piece of code you want to modify, it's possible to implement them by following The Legacy Code Change Algorithm.

References

Working Effectively With Legacy Code
Working Effectively With Legacy Code - Book Review
Clean Code: A Handbook of Agile Software Craftsmanship
Software Evolution and the Importance of Refactoring
Things you should never do, Part I
Breaking Dependencies
How I managed to start practicing TDD

Evolução de Software e a Importância da Refatoração

Lucca Mabel — Mon, 26 Dec 2022 19:33:53 +0000

Evolução de Software

O que é Evolução de Software?

Evolução de Software é o processo de desenvolvimento, modificações e atualizações que o software sofre ao longo do tempo.

A importância da Evolução de Software

Com o passar do tempo, a complexidade de um software aumenta e junto com ela, o seu tamanho também. Ou seja, mais código para realizar manutenção e maior dificuldade de encontrar e solucionar bugs.

O envelhecimento de um software é inevitável, portanto é preciso que os conceitos da evolução de software estejam presentes em seu processo de desenvolvimento.

Como prevenir futuros problemas?

Algumas maneiras de prevenir os problemas que o tempo de vida de um software pode trazer são:

Transparência:

Manter todas as partes envolvidas no software cientes do escopo, propósito e regras de negócio do sistema em desenvolvimento. Inclusive de possíveis modificações ao passar do tempo.
Realizar abstrações:

Sempre que possível, realizar abstrações para agilizar o desenvolvimento e diminuir repetição de código
Modularização:

Dividir o sistema em módulos para facilitar a manutenção ao longo do tempo. Além de facilitar detecção de erros, realização de testes e permitir o desenvolvimento independente dos módulos
Amputação:

Em casos extremos, quando algo está apresentando muitos problemas e não é possível resolver, talvez seja melhor analisar a possibilidade de remover a feature por completo

Manutenção x Desenvolvimento

A partir disso, é importante abrir espaço entre, ou durante, as etapas de desenvolvimento para realizar manutenção do software para que, no futuro, não ocorram problemas decorrentes disso.

Para realizar as devidas manutenções, é preciso passar por algumas etapas para entender o propósito das mesmas.

É preciso, primeiramente, de um conhecimento profundo da estrutura do sistema, ou da funcionalidade em questão, isso podemos adquirir a partir de documentações muito bem escritas ou designando esta tarefa para a pessoa que mais teve contato com a funcionalidade.

Também é bastante importante entender e levantar o impacto que mexer nessa funcionalidade pode causar. Por isso reforço a importância da documentação, que é possível evitar novos erros a partir do histórico de problemas antigos.

Em sequência, é necessário realizar as estimativas de custo ou de tempo que essa manutenção pode causar para que ela seja devidamente incluída dentro da sprint e, por fim, documentar todas as mudanças realizadas.

Problemas que a falta de manutenção pode causar:

É importante destacarmos que a manutenção é extremamente importante para garantir a Manutenibilidade do software, que é a facilidade com que é possivel modificar o sistema.

Quando não há manutenção, ou há manutenção ruim, pode coasionar em perda de tempo para desenvolver novas funcionalidades, um cliente insatisfeito, redução na qualidade do produto e até mesmo insatisfação do próprio time de desenvolvimento pois irá gerar dificuldade para corrigir o problema futuramente e novamente.

Coisas que podem afetar a manutenibilidade do sistema:

Por si só a evolução do software é dificil de se manter por muitos anos e isso deve ser levado em consideração. São muitos processos, classes, linhas de código e a complexidade aumenta com o passar do tempo. Isso impacta diretamente na manutenilibidade. Por isso é fundamental estabelecer padrões referentes a linguagem de programação, realizar testes e versionar o código.

Assim como, é dificil documentar todas as alterações e processos de forma que todos os desenvolvedores estejam 100% cientes de tudo.

E por fim, a visão que algumas pessoas tem de que manutenção é sinônimo de um trabalho ruim. O que não é verdade! Código cresce com o passar do tempo, a complexidade aumenta e a manutenção é fundamental para que o software continue vivo e funcionando da maneira esperada. É preciso haver, ou criar, espaço para aprimorar a manutenibilidade.

Refatoração

Dentro da engenharia de software, temos muitas formas de realizar a manutenção do código. Diversos conceitos, ferramentas e metodologias, contudo, hoje vamos focar na Refatoração.

O que é refatoração?

Refatoração é o processo de alterar um sistema afim que seu comportamento não seja modificado, mas sua estrutura interna seja melhorada. O objetivo por trás disso é reduzir a complexidade e tornar o software mais compreensível, basicamente é melhorar a qualidade do software.

Quando podemos refatorar?

Alguns momentos ideiais para realizar a refatoração de um código, são quando:

Houver tempo entre as etapas de desenvolvimento
Durante a etapa de Code Review (seja ao enviar o MR ou na revisão que fazemos enquanto desenvolvemos)

Quando não refatorar?

Quando está muito perto do prazo final de entrega
Quando o código tá muito confuso (neste caso é recomendado a reescrita total)
Quando o código apresenta muitos bugs
Depois

O “Consertar Depois”

Sempre que possível, refatore e aprimore o código no momento que você identificar algum indicativo que é preciso. Pois, muito provavelmente, se você deixar para depois, as chances de retomar para refatorar são menores.

Poque não deixar para “depois”?

Perda de contexto e confiaça

Quanto mais você estiver removido do ponto em que o código foi escrito, menos você o entende. E se você não consegue lembrar todos os casos de uso, não tem mais a mesma confiança em alterar por medo de quebrar a funcionalidade. Portanto o risco de quebrar não "vale” o benefício da melhoria.
Normalização

Quanto mais você convive com algo, mais acostumado você está com isso e cada vez menos é uma prioridade.
Maior Prioridade

Sempre há uma coisa nova que queremos construir ou melhorar. Eventualmente, o que antes era um problema, acaba virando o normal e outra coisa ganha prioridade.
Agora você está confiando naquele código

Mesmo sabendo que o código é ruim, ainda sim é preciso implementar coisas novas. Isso acaba criando um ciclo onde tudo que vem de novo, acaba ficando dependente daquele código ruim e acaba ficando mais dificil de realizar manutenção.

Como identificar se o código precisa de refatoração?

Uma forma de identificar se um código precisa de refatoração a partir da presença de “Bad Smells”.

O que é Bad Smell?

Bad Smell é basicamente algumas más práticas de desenvolvimento que podem ser aprimorados com refatoração.

Classe Deus

A classe Deus é uma classe que realiza muitas coisas dentro do sistema. Ela pode ter muitos atributos, muitas funções e muitas responsabilidades.

Como resolver?

Dividir em classes menores
Criar subclasses que se relacionem melhor com a classe principal
Verificar se os atributos e métodos são todos necesários

Método Deus

São métodos extensos que centralizam toda funcionalidade de uma classe. Altamente dificeis de manter e de entender.

Como resolver?

Dividir o método em outros menores
Verificar a possibilidade de transformá-lo em uma classe

Funcionalidade Invejosa

Parte de uma classe que só utiliza atributos e métodos de outra classe específica.

Como resolver?

Verificar a possibilidade de mover os atributos e métodos em questão entre as classes
Verificar se vale a pena juntar as classes em uma, ou utilizar conceitos de sub-classes para dividir melhor as responsabilidades

Comentários

Comentários não é necessariamente algo ruim. Eles podem ser utilizados para auxiliar na compreensão do código, contudo, se for em excesso pode atrapalhar a legibilidade do mesmo.

Como resolver?

Remover comentários desnecessários
Simplifique o código (Se algo está muito complexo à nível de necessitar de um texto para compreender, a melhor abordagem é simplificar o código ao invés de escrever um texto explicando o mesmo)

Mudanças Divergentes

Quando uma classe muda frequentemente de forma com razões distintas.

Por exemplo: Uma classe que originalmente estava responsável por controlar a página de login, foi alterada e agora o novo escopo dela é controlar a página de cadastro, e foi alterada novamente e agora ela é responsável por controlar o fluxo de onBoarding.

Como resolver?

Dividir a classe: Cada mudança de escopo deve ficar em uma classe separada

Shotgun Surgery

Quando ao alterar uma classe, é necessário alterar várias outras.

Como resolver?

Reorganizar as responsabilidades e divisões das classes afetadas e verificar a possibilidade de junção de classes ou mover os métodos e atributos para se enquadrar melhor ao escopo

Classe Reclusa

Uma classe que herda atributos e métodos de outra classe, mas não utiliza para nada.

Como resolver?

Reformular a hierarquia das classes em questão

Lista de Parâmetro muito Grande

Uma classe com parâmetros em abundância.

Como resolver?

Verificar a possibilidade de remodelar o algoritmo a fim de que não seja preciso parametros em excesso para que a feature funcione de maneira apropriada

Anti-Patterns

Algumas más práticas que vão de encontro à boas práticas de desenvolvimento.

Blind Faith: Não checar a correção de um bug
Boat Anchor: Parte do sistema sem uso
Lava Flow: Código ruim colocado em constante mudança sem ser refatorado
Gold Hammer: Tecnologia familiar aplicada em todos os problemas
Cult Programming: Utilizar padrões sem saber o motivo
Lasagna Code: Código com muitas camadas desnecessárias
Spaghetti Code: Estruturas de código pouco compreensíveis

Como planejar a manutenção?

Uma sugestão para melhor planejar a manutenção do software é, além de aplicar os conceitos mencionados atenriormente quando necessário, também alinhar um período de manutenção dentro da sprint.

Uma sugestão seria a equipe não passar imediatamente para a próxima feature, mas sim ter um tempo de melhoria para que o que for entregue, tenha menos chances de apresentar problemas e aumente a manutenibilidade do software.

É claro, que não é preciso alocar esse tempo entre cada sprint. Mas é importante ter essa possibilidade analisada e manter uma certa periodicidade para as necessidades referentes à manutenção do sistema.

Como aumentar a periodicidade da necessidade de manutenção?

Algumas formas de aumentar a periodicidade é basicamente tentar se manter fiel aos conceitos de código limpo, planejar bem, entender o problema que você quer resolver e testar bem a solução implementada.

Definir Metas Claras

Tenha em mente, de forma clara e visível, as metas que o código quer resolver. Isso é fundamental em situações onde é preciso decidir como adicionar uma feature nova ou se deve ser aceita uma mudança de escopo.

Defina as Restrições

Também tenha em mente quais problemas seu código não resolve. Restringir o escopo é importante e é uma forma de te forçar a focar exclusivamente no problema.

Dizer Não

Sempre vai ter algo novo e importante para ser implementado. A importância de dizer não, quando couber, garante que o software não cresça de forma descontrolada.

Elimine Resíduos

Sempre que possível, remova quaisquer recursos não utilizados e código morto.

Minimize Dependências

Ser exigente ao adicionar dependências, considerar prós e contras. Pois dependências podem quebrar, desaparecer, se tornar um risco de segurança. Se a funcionalidade for crucial para o produto, vale a pena avaliar se não é melhor implementar você mesmo.

Conclusão

Para resumir, evolução de software é algo que tem que ser olhado com atenção para que o sistema tenha possibilidade de crescer junto com o tempo. Para isso, é importante garantir a manutenibilidade do sistema com manutenção periódica, que deve ser planejada e não ser feita somente quando a situação ta critica.

Uma forma de fazer a manutenção é através da refatoração, que melhora o código internamente, sem afetar a funcionalidade para o usuário final. Para identificar se há necessidade de refatoração, é importante se atentar à presença de “Bad Smells”.

E para aumentar o período em que uma manutenção deve ser feita, é preciso se manter fiel aos conceitos de código limpo, planejar bem, entender o problema que você quer resolver e testar bem a solução implementada.

Referências

Stop lying to yourself – you will never “fix it later”
Best practices for building scalable Flutter applications
Your Code Doesn't Have to Be a Mess
Lean software development
Keep it Simple, Over Time

Mudanças que podem ser feitas para tornar aplicativos de celular um ambiente seguro para pessoas LGBTQ+

Lucca Mabel — Wed, 23 Feb 2022 02:47:01 +0000

Há um tempo, eu estava em busca de algumas aplicações que são inclusivas para com a comunidade LGBTQ+, no entanto, depois de muita busca, eu obtive muito poucos resultados. Como membro da comunidade, isso me deixou muito triste e como desenvolvedora, abriu um espaço para que eu falasse sobre isso e talvez mobilizar alguém a acatar mudanças para que suas futuras aplicações sejam mais inclusivas e tenham em vista o conforto e segurança do usuário.
Portanto, dentro de experiência pessoais e pesquisas sobre o assunto, vamos falar um pouco sobre algumas mudanças que podem ser feitas para garantir essa inclusividade.

Diversidade de gênero

Uma situação que eu vejo com frequência é a pouca diversidade de gênero quando o usuário está fazendo o cadastro e o gênero é requerido para finalizar, ou até mesmo, nenhum campo de gênero (como por exemplo, substituí-lo por um campo de sexo biológico). Se um campo de gênero é realmente necessário para o cadastro do usuário na sua aplicação, então é importante que o usuário se sinta representado pela disponibilidade de gêneros que a aplicação está fornecendo.

Foram pouquíssimas aplicações que eu utilizei em que era disponibilizado mais que 2 gêneros (Homem, Mulher), menos ainda que eu vi que era disponibilizado mais de 3 alternativas (Homem, Mulher, Prefiro não dizer/Outro). E ai, encontramos 2 problemas: o primeiro é a pouca diversidade de gêneros, que estamos discutindo agora. O segundo é sobre a alternativa “prefiro não dizer”. Não vou generalizar em dizer que todes querem expor o gênero que se identificam, mas muita gente quer e muita gente não tem a oportunidade. Em complemento, quanto a opção de “Outro”, é possível ver que tem um espaço para a pessoa colocar como ela se identifica, no entanto, a minha experiência pessoal é que, ainda que essa alternativa esteja lá, eu não me sinto representada.

É importante fazer com que o usuário se sinta contemplado, seguro e confortável. Isso melhora a experiência que ele vai ter durante o uso da aplicação, pois a aplicação foi feita pensando nele, também.

Atualmente, a Comissão dos Direitos Humanos reconhece 31 diferentes tipos de gênero. Portanto, não assuma o gênero do seu usuário, é muito provável que você vai errar. Ao invés disso, disponibilize uma quantidade maior de gêneros para o seu usuário, deixe que ele se auto-declare como ele se sentir melhor.

Pronomes

Se a diversidade de gênero é pouco explorada, a utilização de pronomes diversos muito mais. Assim como você não deve assumir o gênero do seu usuário, também não deve assumir os pronomes dele.

Nem sempre pronomes estão presentes dentro de uma aplicação, mas sempre que são, a linguagem é voltada para o masculino (predominantemente) ou feminino, poucas foram as vezes que eu presenciei o uso de linguagem neutra dentro de alguma aplicação, muito menos foram às vezes em que eu presenciei o uso correto da linguagem neutra, acredito que é possível que eu nunca tinha visto na verdade.

Portanto, se sua aplicação possuir diálogos com o usuário ou fizer uso de pronomes em seus textos, o ideal é deixar o usuário escolher o pronome em que quer ser tratado e adaptar os diálogos e textos, de forma correta, para que o usuário se sinta respeitado, confortável e tenha uma boa experiência de uso.

Diversidade de Orientações Sexuais

Assim como os tópicos anteriores, a pouca diversidade de orientações sexuais dentro das aplicações é muito presente. Apesar de que poucas aplicações fazem o requerimento desse dado, as poucas que fazem, possuem uma limitação enorme de alternativas para seus usuários. A maioria das vezes, dentro de onde eu tive acesso, as alternativas variam entre Heterossexual ou Homossexual e Heterossexual, Gay ou Lésbica e isso deixa uma lacuna enorme para as pessoas que se identificam com uma sexualidade diferente dessas.

A comunidade possui tanta diversidade que a sigla possui uma sigla. Limitando alternativas de sexualidade, gênero e pronome vai somente causar desconforto para os usuários fora das alternativas presentes.

Diversidade de Formação de Família

Em aplicativos que solicitam informações sobre os pais do usuário, é importante levar em consideração que existem diversas formas de se construir uma família. Colocar um campo com o label “Mãe” e outro com o label “Pai”, está longe de se adequar as diversas famílias atuais.

As famílias podem ser constituídas por duas pessoas de mesmo gênero, de gêneros diferentes, com somente 1 responsável legal, com mais de 2 responsáveis legais. Portanto, modificar a forma que esses dados são capturados é essencial.

Desenvolva apps voltado para comunidade

Mesmo que não seja membro da comunidade, com certeza você possui alguma pessoa a sua volta que é. A falta de conteúdo e tecnologia voltada para comunidade LGBTQ+ é enorme. Apesar de avanços significativos que aconteceram nos últimos tempos, ainda é importante que os avanços continuem vindo e mais conteúdo e tecnologia seja produzido. Seja para informar, alertar, entreter, protejer, fazer uma diferença.

Conclusão

Para tornar seu aplicativo um ambiente seguro para pessoas LGBTQ+, é preciso considerar essas pessoas durante o processo de desenvolvimento. É preciso analisar os casos e respeitar eles para promover segurança, acolhimento, representatividade e individualidade para elas.

8 projetos iniciantes para aprender Flutter e expandir seu portfólio

Lucca Mabel — Wed, 23 Feb 2022 02:45:10 +0000

Flutter é um framework open source de desenvolvimento criado pelo Google, que possibilita a criação de aplicativos para múltiplas plataformas com um único código. Por conta de sua possibilidade multi-plataforma, acessibilidade e facilidade de aprendizado, Flutter tem se tornado bastante popular no mundo do desenvolvimento. Tendo isso, e a diminuição de custo, em vista, muitas empresas estão buscando iniciar projetos em Flutter ou migrar os já existentes. Pensando na grande comunidade crescente do Flutter, esse artigo foi feito com a ideia de trazer 8 apps de nível introdutório/iniciante para começar sua jornada com o framework.

1. Calculadora

Um app de calculadora básico é o projeto perfeito para iniciar sua jornada com Flutter. O app em si, não precisa ter layouts ou widgets complexos (a menos que queira), basta somente um display para mostrar o caminho e resultado das operações, botões para os números e para os tipos de operação.

2. Login UI

Seguindo a linha de uma jornada de aprendizagem introdutória, uma tela de Login é fundamental. É o tipo de feature que é necessária na maioria dos projetos Flutter, portanto, é fundamental tê-la em seu currículo. Além de que, não é uma feature complexa de ser realizada.

3. Pedra, Papel e Tesoura

Um joguinho de pedra, papel e tesoura pode ser um app de treinamento perfeito para começar a aprofundar suas habilidades de lógica em Dart. Além de ser um diferencial para seu portfólio, pode ser o inicio para aplicações com conceitos um pouco mais complexos.

4. Jogo da velha

O app do jogo da velha é um clássico para quem está aprendendo quase qualquer linguagem de programação/framework do zero. Isso porque: ele cumpre bem seu papel. O jogo da velha possibilita aprofundar mais na parte lógica da aplicação, fazer uso de widgets mais complexos e modificar o estado e layout das telas com mais propriedade.

5. Pomodoro Timer

A ideia do pomodoro timer é fortalecer o uso de lógica e inicializar a utilização de widgets mais complexos e pacotes. Se você não conhece um pomodoro timer, ele funciona assim (de forma padrão): O usuário define uma quantidade de ciclos em que o timer vai rodar, um ciclo é composto por: período de trabalho (25 minutos) e período de descanso (5 minutos), começando pelo período de trabalho. Assim que um ciclo acaba, outro, automaticamente, começa. Isso perdura até que todos os ciclos tenham sido realizados.

6. ToDo List

Um app de ToDo List é clássico na vida de todo desenvolvedor mobile (ou pelo menos de muitos rsrs) com ele é possível agregar outros conceitos da programação para dentro da estrutura do seu app, por exemplo: arquitetar seu app de forma orientada à objetos (OO), que é um conceito essencial para se trabalhar com desenvolvimento de software. Além de poder agregar mais complexidade e domínio ao seu código, podendo fazer uso de um banco local, construtores de lista, construtores de grid e gerenciadores de estado.

7. Clone de Algum App Existente

Talvez um dos projetos introdutórios mais comuns que eu observo são clones de outros apps. E é super válido! Dessa forma é possível explorar conceitos de UI que talvez não tenham sido explorados em projetos prévios e fortalecer os que você já tem, além possibilidade de entrar em contato com arquiteturas e fluxos de lógica diferentes.

8. Portfólio

Depois de desenvolver todos, ou alguns desses, projetos, é importante mostrar para o mundo o que você produziu. E que melhor forma de fazer isso do que construindo a plataforma que você vai exibi-los? Um outro motivo que torna o Flutter tão prático é que com todos os conhecimentos adquiridos no processo de desenvolvimento desses projetos (graças ao Flutter Web), você pode utilizar-los para construir seu site sem nenhuma complicação. Além disso, pode facilmente, com algumas linhas de comando, hospeda-lo no firebase gratuitamente e conectar ao domínio que você quiser.

Conclusão

Tendo isso em vista, realizando, pelo menos alguns, projetos eu tenho certeza que seus conhecimentos em Flutter vão alavancar de forma rápida. E logo você será capaz de desenvolver layouts e aplicações mais complexas. Não existe melhor forma de aprender do que praticando a todo momento.