Quando um desenvolvedor aborda um problema, ele geralmente tem um objetivo claro. Corrija esse bug, crie esse componente, refatore esta implementação. Somos muito orientados por objetivos por natureza. Temos um objetivo que precisamos alcançar e temos que tentar todas as técnicas que aprendemos para atingir esse alvo. Mas algo que eu sinto que é menos discutido é a mentalidade de um desenvolvedor: a forma pensamos, em vez de o que pensamos, para resolver um problema de codificação.
Quero compartilhar algumas idéias sobre duas mentalidades específicas que percebi que tenho oscilado entre durante a maior parte da minha carreira. Mas aqui está a parte engraçada … raramente percebi quando estava alternando entre eles. Olhando para trás, se eu tivesse percebido esse paradigma, poderia ter sido capaz de economizar horas pensando nas soluções perfeitas para os problemas.
Para se ter uma ideia dos diferentes estágios de desenvolvimento de software, vou dar um pouco de história ao projeto em que estou trabalhando. Posteriormente, examinaremos as duas mentalidades do programador mais de perto. Por fim, apresentarei algumas dicas sobre como utilizar as duas abordagens e como ser mais cuidadoso no processo.
Minha jornada recente
Agora mesmo , minha equipe está em um ponto interessante em nossa longa jornada. Desde junho 2019, estamos migrando o aplicativo da web de pedidos de comida Just Eat Takeaway.com para uma pilha moderna de Next.js, React e Redux Saga. Durante o ano passado, nossa equipe cresceu a ponto de se tornar benéfico dividi-la em equipes menores com um conjunto de responsabilidades mais especializado.
Começamos criando as páginas de menu e checkout do site. Isso incluiu os elementos do cabeçalho, incluindo pesquisa de local e login da conta, e também o menu, carrinho e o mecanismo de envio de pedido.
Ao longo dos próximos 1,5 anos, mudei da equipe responsável pelo menu e experiência de checkout para a página de lista de restaurantes, onde o usuário escolhe de qual estabelecimento deseja fazer o pedido. Nosso principal desafio para esta página foi implementar os vários filtros e mecanismos de classificação. Depois de terminar a página da lista de restaurantes, passei para a equipe que cuida do desenvolvimento dos componentes comuns de todo o site (cabeçalho, rodapé, login da conta, etc).
Cada equipe foi responsável por construir as páginas do zero. Durante este período eu estava principalmente no que comecei a chamar de arquiteto mentalidade.
Depois que o aplicativo começou a ser concluído, não estávamos construindo tantos novos recursos e mecanismos, e as convenções eram principalmente estabilizado. Em vez disso, estávamos seguindo o que já estava em vigor. Deliberamos e concordamos em seguir as convenções de codificação que estabelecemos juntos. Você pode pensar nisso como construir em cima de o que já era lá. Essa é a outra mentalidade, que eu chamo de mentalidade adaptador .
Duas mentalidades
Depois de muito tempo deliberando, acho que os melhores rótulos para essas duas mentalidades são o arquiteto e o adaptador. Nenhuma mentalidade é melhor que a outra. Os dois funcionam juntos como yin e yang. Ambas as mentalidades são utilizadas por desenvolvedores de todos os níveis de experiência. O truque é estar ciente de quando é melhor ter uma mentalidade em detrimento da outra.
Vamos começar.
Caminho do Arquiteto
Ao construir um aplicativo do zero, podemos assumir o seguinte:
- Se um novo recurso precisa ser implementado, não há código existente que você possa reuso. Você terá que escrever sozinho.
- As decisões arquitetônicas terão muito peso. Você apresentará novas convenções.
- Você tenha alguma flexibilidade para introduzir pacotes, plug-ins ou software dos quais a infraestrutura do seu aplicativo dependerá.
Na mentalidade do arquiteto, você não vai procurar em seu aplicativo uma implementação anterior porque não haverá uma. Estar na mentalidade de arquiteto significa saber que o caminho à sua frente será explorar novas ideias e projetar uma solução que atualmente não existe.
É quando começamos a sacar os marcadores de apagamento a seco e chegar ao quadro branco. Você estará pesando as decisões de uma implementação possível com outra. Isso significa pensar sobre o futuro do software – uma abordagem agora pode ser referenciada até que um dia seja predominante em todos os lugares em seu aplicativo e cada vez mais difícil de substituir.
Caminho do Adaptador
A mentalidade do adaptador entra em ação quando você está trabalhando em um aplicativo mais maduro. As convenções de código estão em vigor, a documentação foi escrita e reescrita e você compartilha um determinado padrão de qualidade entre os membros da equipe.
Quando mudamos da necessidade de construir algo novo para estender o que já está lá, entramos na mentalidade do adaptador. Isso nos permite manter as convenções para certos padrões em mente. Eles podem ser tão pequenos quanto preferir Booleano (foo) em vez de !! foo ou nomeando seus criadores de ação redux no passado, como orderSubmitted , preferênciaSalvo , etc.
Nesta mentalidade, nós ‘ Estamos mais focados em usar o que já existe, em vez de construir algo completamente novo ou adotar uma nova abordagem. Estamos seguindo padrões que foram definidos por desenvolvedores anteriores.
Tudo isso com a suposição saudável de que você e sua equipe pensou estrategicamente sobre como construir seu aplicativo. Boas decisões arquitetônicas foram tomadas para permitir que seu software seja ampliado e escalonado. Parte de seguir o padrão do adaptador inclui determinar se uma implementação existente deve ser reutilizada ou se uma solução melhor e mais reutilizável é necessária.
Imagine ingressar em um grande projeto que está ativo há mais de 2 anos. Conforme o aplicativo está sendo construído, a equipe está adicionando modelos, esquemas, contratos, constantes, utilitários, seletores, etc. para implementar funcionalidades. Essas várias funções dependerão e serão utilizadas em todo o aplicativo. Como um novo desenvolvedor, você pode presumir que deve seguir as convenções que foram estabelecidas para você. Isso o coloca na mentalidade do adaptador.
Notícias Relacionadas
Tecnologia em Disputa
Caso X: Virar o jogo e enfrentar as big techs
Documento assinado por intelectuais – como Piketty, Mazzucato e Morozov – apoia a posição do Brasil contra a intransigência de Elon Musk. Em todo mundo, governos já sinalizam: corporações-plataformas são riscos às democracias, se não reguladas
Tecnologia em Disputa
Telas, déficit cognitivo e crise da educação
Estudos mostram: celulares podem afetar a concentração, a saúde mental e o aprendizado de crianças e adolescentes. Porém, normaliza-se o “inovacionismo” nas escolas, sem reflexão crítica – e o Estado é moroso em promover este debate
Uma mentalidade é melhor do que a outro?
Você pode ser rápido em pensar que queremos seguir a mentalidade do arquiteto mais da vez, mas não é o caso. Para construir um software de forma eficiente, um desenvolvedor deve alternar entre as duas mentalidades, dependendo da tarefa em mãos.
Colocar um novo desenvolvedor na mentalidade do arquiteto pode ser um método eficaz para encontrar melhores maneiras de fazer algo, seja no processo de desenvolvimento ou no próprio código. Por outro lado, um desenvolvedor sênior com a tarefa de trabalhar na base de código existente também pode ajudar a reconhecer as tendências na forma como o aplicativo está sendo construído.
Alternando entre as duas mentalidades
Uma abordagem não é melhor que a outra. Na verdade, como desenvolvedores de software, precisamos lidar adequadamente com ambas as abordagens. Claro, um novo desenvolvedor provavelmente estará na mentalidade do adaptador na maior parte do tempo enquanto aprende uma base de código e como estender o que já está lá. Mas os desenvolvedores seniores podem se beneficiar muito com o domínio dessa mentalidade. Um desenvolvedor que não reconhece que pode reutilizar uma implementação anterior vai acabar fazendo o dobro do trabalho – primeiro escrevendo desnecessariamente sua própria implementação e novamente quando um colega aponta que essa lógica já existe no aplicativo e eles têm que remover o que eles escreveram.
Digamos que você tenha assumido a tarefa de restaurar as preferências do usuário de cookies ou armazenamento local após atualizar a página . Suponha que você tenha pouco conhecimento sobre este tópico e que o aplicativo tenha amadurecido decentemente. Um desenvolvedor inteligente primeiro pesquisará quais mecanismos já existem e podem ser reutilizados. Você pergunta a alguns colegas que podem saber e, em seguida, analisa o código e testa a cadeia de eventos para o fluxo específico. Estas são etapas que realizamos enquanto estamos na mentalidade do adaptador.
Então, vamos assumir outro cenário onde você precisa solicitar certos dados do usuário de uma API separada. Você percebe que não há nenhuma solicitação GET feita para esta API que também requer autenticação, nenhuma das quais foi implementada ainda. Agora você deve considerar como estender a lógica existente ou se precisa implementar esses mecanismos do zero. Este é o momento em que mudamos para a mentalidade do arquiteto. Em seguida, temos que começar a pensar sobre as etapas arquitetônicas para criar algo novo, em vez de simplesmente usar e aprimorar o que já está lá.
Algumas dicas
Agora que nós entendo as duas mentalidades e a relação entre elas, tenho algumas dicas sobre a melhor forma de colocar nosso conhecimento em prática.
Esteja atento à maneira como você está pensando ao trabalhar em uma tarefa
Muitas vezes nos encontramos tão focados em encontrar uma solução que não paramos para considerar como estamos abordando o problema. É preciso prática para diminuir o zoom por um momento e pensar: “ Estou fazendo isso da maneira certa? Verifiquei na base de código uma implementação semelhante que pode ser reutilizada? Ou estou apenas programando no piloto automático? ”Fazer a si mesmo esses tipos de perguntas o ajudará a refletir sobre sua própria abordagem – algo que encorajo todos a fazer , não apenas desenvolvedores.
Se você descobrir que cometeu um erro porque você não estava com a mentalidade certa, não se preocupe
Minha inspiração para este artigo veio de ter ficado preso na mentalidade do adaptador por um ou dois dias. Continuei procurando uma maneira existente de resolver meu problema. Continuei tentando olhar para as implementações anteriores de diferentes perspectivas, mas não consegui chegar a uma solução confortável. Eu estava começando a agonizar sobre quanto tempo estava demorando, como não conseguia fazer o aplicativo se comportar da maneira que eu queria; Comecei a avaliar a quantidade de progresso que fiz.
Então uma lâmpada ? acendeu na minha cabeça. Eu estava tentando estender o que existia atualmente na base de código. Só depois de muitos exemplos de tentativa e erro é que percebi que estava abordando o problema com a mentalidade errada. Eu precisava abordar o problema com a mentalidade do arquiteto. Eu tinha feito minha pesquisa e testes e determinado que a solução não existia na base de código. Eu mesmo teria que construí-lo.
Essa percepção tardia acontece com mais frequência do que você imagina. Não se culpe se demorou um pouco para fazer a conexão como eu fiz. Tudo isso faz parte do crescimento como desenvolvedor. O importante é que você observe esses momentos de sua carreira e aprenda com eles.
Reflita sobre o seu processo
Quando comecei a trabalhar no JET, a colega compartilhou sua abordagem diária e semanal para fazer as coisas. Ele disse que tem uma “postura pessoal” todas as manhãs quando examina sua lista de ToDos e decide as prioridades. No final da semana, ele reserva algumas horas para refletir sobre a semana anterior, respondendo a perguntas como:
- O que foi bem? O que não correu tão bem?
- Quais atividades estão lhe dando energia e quais estão tirando energia de você?
- Mantém bons hábitos? Você desenvolveu algum ruim? Como você pode corrigi-los?
- Você tem alguma ideia durante a semana em que deseja se concentrar na semana que se aproxima?
Fazer esses tipos de perguntas e refletir ativamente sobre seus próprios processos é uma virada de jogo. Isso o ajudará a estar mais atento sobre como você trabalha e viver o seu dia, em vez de ficar no piloto automático e verificar os ToDos sem pensar muito em por que está fazendo isso ou se há um melhor maneira.
Agradeço como esses conceitos são refletidos no scrum. Como praticante de scrum e ágil, você participará de cerimônias como Retrospectivas, onde a equipe refletirá sobre o sprint anterior e fará perguntas semelhantes às mencionadas acima. Dedicar tempo para refletir sobre como você se sentiu em relação ao dia / semana / sprint anterior é uma tática engenhosa para dar uma olhada honesta em como você ou sua equipe trabalham.
Conclusão
Às vezes, parece que você deve saber todas as respostas sobre sua base de código. Caímos nesse padrão de pensamento em que precisamos trabalhar o mais rápido possível, nos comparando com nossos colegas e nos esquecendo de refletir sobre o que realmente estamos fazendo. Trabalhar dessa forma aumentará o estresse e pode levar ao esgotamento.
É por isso que é importante pense em como você pensa . Quando você estiver planejando como lidar com uma tarefa de codificação, pergunte-se “ Qual mentalidade eu preciso ter agora? Qual abordagem provavelmente me levará a uma solução de alta qualidade? ”
O desenvolvimento de software envolve tentativa e erro. É sempre cognitivamente exigente. Precisamos cuidar de nossa mente e corpo se quisermos ser eficazes no trabalho e em nossa vida diária. Reserve um tempo para recuar e refletir sobre como – ao invés do que – você acha que o levará a algumas realizações esclarecedoras sobre o seu próprio processo.
Este artigo foi publicado originalmente no blog Just Eat Takeaway-Tech medium . Você pode lê-lo aqui.
Com mais 580,000 restaurantes conectados, Just Eat Takeaway.com é um mercado líder de entrega de alimentos online que oferece aos consumidores uma ampla variedade de opções. Junte-se ao fundador e CEO, Jitse Groen, em TNW 2021 para um bate-papo ao lado da lareira sobre como o ecossistema holandês e de tecnologia evoluiu, lições aprendidas ao longo do caminho e o que vem por aí para o gigante da entrega de comida.
