Você concluiu um curso, assistiu a uma série de vídeos no YouTube ou leu uma série de artigos sobre desenvolvimento para iOS e agora se sente pronto para escrever seu primeiro projeto favorito.

Em primeiro lugar, muito bem! Fantástico. Você é legal! 💪

Em segundo lugar, um projeto favorito é um impulso fantástico para suas habilidades. Quando você começa a fazer algo sozinho, sem seguir as instruções, você tem que gastar muito tempo e esforço, pesquisar muito no Google, ler muitas informações novas e tentar filtrá-las e encaixá-las com precisão no seu caso. Resumindo, já é uma tarefa real que vai te impulsionar cinco vezes.

No entanto, a maioria dos iniciantes ignora coisas importantes (não por iniciativa própria, mas sem compreender sua importância). Nos últimos seis meses, tenho estado ativamente mentoria e ajudar os recém-chegados com suas dúvidas e problemas, incluindo projetos favoritos.

Eu identifiquei os três principais pontos que você, como iniciante, deve incorporar em sua lista de itens essenciais, dominar, compreender e usar.

Nível de acesso

No início, quase ninguém presta atenção ao modificador private . Enquanto isso, todos podem explicar instantaneamente o SOLID se você acordá-los no meio da noite. Depois de ler vários artigos inteligentes, as pessoas tentam criar um monte de classes de acordo com a ideia de S (responsabilidade única).

E então, com a consciência tranquila, trocam a propriedade da class A da class B e vice-versa.

 class A { var someAValue: Int? } class B { let a = A() func foo() { a.someAValue = 1 } }

Em geral, se ainda não estiver claro, o plano é o seguinte: sempre escreva private em qualquer lugar e, quando o compilador reclamar, pense: é correto acessar essa propriedade ou função de fora? E se for — remova private .

Quando você pensar, guie-se com comparações do mundo real. Por exemplo, se a sua classe for uma loja, então a propriedade goods deverá obviamente ser acessível ao cliente externo. Mas o moneyInCashRegister claramente só pode ser alterado por um funcionário interno da loja.

Afinal, um cliente não deveria ter acesso à caixa registradora, mesmo com put , e muito menos fetch .

Alguém poderia argumentar: “Eu entendo perfeitamente quais propriedades podem ser tocadas e quais não podem, mesmo sem um modificador private ”. No entanto, escrever modificadores de nível de acesso faz parte do design. Tenho certeza de que você não criaria um projeto para uma casa com uma porta no terceiro andar que levasse para fora.

E então, lembre-se de não abri-lo. Afinal, é provável que outras pessoas também utilizem o seu código.

A propósito, existe uma situação semelhante com var e let . Novamente, sempre use let , a menos que tenha certeza imediata de que alterará o valor.

Simplicidade da Arquitetura

Tenho notado uma tendência em que os iniciantes tentam planejar tudo com antecedência. Embora isso seja louvável, os desenvolvedores muitas vezes cometem erros devido à falta de experiência. Eles pré-preparam gestores excessivamente complexos (geralmente copiados de StackOverflow ) com muitos métodos complicados, que eventualmente nunca usam. Como resultado, a quantidade e a complexidade do código aumentam.

Em vez do que parecia ser um serviço conveniente e pronto, nosso programador acabou tendo apenas problemas e mal-entendidos. O mesmo vale para a arquitetura.

Deixe-me fazer uma breve viagem pela história da programação para transmitir meu ponto de vista. No final da década de 1960, à medida que a popularidade da programação começou a crescer, o tamanho dos programas também aumentou. Como você pode entender, um tamanho de programa maior significa mais linhas de código, levando a uma maior complexidade e dificuldade de compreensão do programa.

Para resolver esse problema, surgiu a programação estruturada – funções e procedimentos que permitiam que os programas fossem divididos em partes menores e gerenciáveis. O código tornou-se modular, reutilizável e mais compreensível.

O advento da estruturação levou a um maior crescimento dos programas até que atingiram novamente os seus limites de tamanho e complexidade. Portanto, no final da década de 1970 e início da década de 1980, a abordagem de programação orientada a objetos foi formada. Esta solução permitiu a criação de sistemas flexíveis e escaláveis, dando resposta a tarefas cada vez mais complexas.

Na década seguinte, testemunhamos o boom dos jogos de computador. A reação às ações do usuário (cliques, pressionamentos) revelou-se crítica, levando ao surgimento da Programação Orientada a Eventos.

E para organizar código em aplicações web e desktop — quando os mesmos dados precisavam ser reorganizados a partir de diferentes perspectivas — surgiu o padrão MVC (ou seja, separar o modelo de sua representação visual).

Você compreendeu a ideia principal: surge um problema, -> surge uma solução. Problema -> Solução.

Então, por que os programadores iniciantes agora começam a aplicar soluções (arquiteturas) num momento em que os problemas ainda não surgiram? Os tutoriais sugerem imediatamente a escolha de pelo menos um MVP. As tarefas de teste para uma/duas telas sempre especificam NÃO usar MVC.

Durante as entrevistas, uma pessoa que escreveu alguns projetos favoritos com as mesmas uma/duas telas é questionada sobre os problemas do VIPER. Como ele poderia saber dos problemas se ainda não os encontrou?

As pessoas costumam falar sobre a conveniência da testabilidade no contexto da arquitetura, mas nunca escreveram testes. E se o fizeram, foi baseado apenas em algum tutorial, focando apenas em testes unitários, sem vinculá-los a uma aplicação real.

Eles podem explicar o esquema MVP em termos simples, mas muitas vezes ficam confusos quando se trata de protocolos com nomes semelhantes, como ViewInput e ViewOutput . No fundo, eles já veem tudo isso como uma sobrecarga 🙄🤯

Conclusão: não crie problemas para si mesmo. Não tenha vergonha do MVC. Quando seu controlador ficar muito grande ou você encontrar inconvenientes, você entenderá que é hora de procurar novas abordagens.

Simplicidade da IU

O desenvolvimento front-end é um paraíso de dopamina para iniciantes. Você escreve o código e vê imediatamente o resultado na tela — recebendo sua recompensa 🍭. É inegavelmente motivador. No entanto, há um outro lado desta moeda. Os iniciantes geralmente se esforçam para criar uma interface de usuário excessivamente complexa imediatamente.

Além disso, recursos complexos tendem a seguir uma interface de usuário complexa. Embora o SwiftUI simplifique a tarefa hoje, ainda é possível gastar muito tempo adicionando recursos sem fazer progresso real.

Aprendi desenvolvimento iOS em um curso onde formamos equipes e trabalhamos em um único projeto. Na minha equipe, um cara sugeriu iniciar o desenvolvimento do nosso aplicativo escolhendo fontes e cores para o modo escuro.

No geral, ele passou todo o curso nisso, e é importante notar que as fontes e cores ficaram fabulosas. No entanto, o cara escreveu aproximadamente zero linhas de código real durante todo esse tempo.

Sem dúvida, a beleza e a funcionalidade da sua aplicação são cruciais. Eventualmente, você terá que dedicar tempo a esse aspecto. É melhor começar com algo mais simples. Desenvolva um MVP (produto mínimo viável), concentre-se nos recursos mais críticos e lance a partir daí.

O Regra 80–20 aplica-se aqui — crie a base do aplicativo e depois adicione os extras. A abordagem oposta levará a lidar com nuances complexas e a lidar constantemente com uma funcionalidade principal que continua falhando.

Para os recém-chegados ao desenvolvimento móvel, existe o risco de adotar soluções complexas prematuramente. Embora as recompensas visuais do desenvolvimento front-end possam ser atraentes, começar com um simples MVP costuma ser mais sensato.

As tendências históricas sugerem que as soluções devem evoluir em resposta a desafios genuínos.

Compreender os princípios fundamentais e abordar os problemas do mundo real à medida que surgem é fundamental para um desenvolvimento eficaz.

Também publicado aqui