Contratar profissionais para um time de desenvolvimento é uma tarefa e tanto. Afinal, assim como a  tecnologia evolui a todo momento, a necessidade constante de obter bons profissionais de software qualificados também não fica para trás. 

Você provavelmente já ouviu o ditado popular “a prática leva à perfeição”, certo? Essa é uma frase comum, que se encaixa em diferentes tipos de cenários — inclusive no mundo do desenvolvimento. Afinal, se você deseja saber como aprender a desenvolver software de qualidade, precisa estar preparado para muito treinamento.

Quando o assunto é desenvolvimento de software, todos os profissionais possuem opiniões muito fortes sobre quais métodos funcionam e quais são falhos. Porém, mesmo com essa divergência de ideias, uma coisa é certa: a metodologia agile se tornou a norma.

Software Quality Assessment (SQA) é o mais novo serviço da Codurance e o artigo de hoje vai te contar exatamente tudo o que você precisa saber sobre essa solução.

É inegável o poder que um software de qualidade e verdadeiramente bom possui nos mais variados segmentos.

Esta foi a pergunta que nos fizemos para preparar a palestra que compartilhamos com Scentmate™ by Firmenich no Retail & Logistics Forum do Digital Enterprise Show 2022 em Málaga.

A aprovação do seu caso de negócios de migração para a nuvem pode parecer uma longa maratona; morro acima, no escuro, numa tarde de domingo, na chuva.

Não existe uma resposta única que descreva a importância de se modernizar a tecnologia enquanto negócio, da mesma forma quando se trata de modernizar sistemas legado. Existem, entretanto, diversas razões que trazem sentido a essa prática.

Este artigo aborda diversas razões pelas quais as empresas devem, enquanto pensam em migrar seus sistemas, entender os benefícios de modernizar e evoluir suas aplicações para tecnologias mais modernas.

Modernização não é apenas um novo termo que está na moda. Trata-se de uma estratégia para assegurar que os negócios estão ocorrendo com alta performance e no topo do seu nicho de mercado, permitindo acompanhar mudanças de tendência e demandas dos clientes de forma rápida. Se considerarmos por exemplo, uma empresa como a Cazoo, é possível constatar que ela mudou completamente o mercado de carros usados no Reino Unido. Sim, grande parte disso foi gerado pelo serviço oferecido. O fator decisivo foi, entretanto, ter em seu núcleo uma estratégia que abraça práticas e tecnologias de engenharia moderna. Tudo isso ajudou a catapultar a empresa ao status de unicórnio em tempo recorde no Reino Unido. As empresas concorrentes, que já participavam do mercado a muito tempo, se viram em posição de desvantagem e com necessidade de recuperar o tempo perdido. Mas afinal, como é possível que as empresas já consolidadas consigam acompanhar o ritmo da tecnologia moderna?

Tradicionalmente, a tecnologia da informação, ou ‘TI’, era vista apenas como um centro de custos. No entanto, com a tecnologia tão permeada e onipresente em todos os aspectos do negócio nos dias de hoje, é preciso enxergá-la como o principal núcleo facilitador.

Existem vários indicadores que as empresas podem utilizar como guia enquanto avaliam se devem ou não começar uma jornada de modernização de software. Um indicador chave ocorre quando os sistemas ficam cada vez mais difíceis de se modificar e a tecnologia apresenta-se incapaz de acompanhar o ritmo dos negócios. Com o tempo isso se traduz em aumento nos tempos de resposta, o que significa que as soluções demoram cada vez mais a chegar nas mãos dos clientes finais. Como resultado, isso normalmente leva uma empresa a se tornar incapaz de acompanhar seus concorrentes e perder participação de mercado.

Como sabemos, a tecnologia evolui muito rapidamente e hoje é capaz de promover soluções que há 10 anos atrás simplesmente não eram possíveis. Por exemplo: os sistemas financeiros, em que a maioria da base instalada foi escrita 15 ou mais anos atrás. Naquela época os navegadores de internet não eram nem de perto tão poderosos e nem contavam com tantos recursos como hoje, resultando em várias aplicações desenvolvidas para desktop. Reforça-se o fato de que a computação em nuvem ainda não havia realmente decolado.

As aplicações desktop trouxeram alguns desafios com o tempo, como instalação, atualização e atendimento a muitas localizações geográficas.

Se avançarmos para os dias de hoje, os navegadores de internet estão muito mais maduros e servem de plataforma para construir aplicações poderosas, ricas em recursos e com elevada performance, algo impossível 15 anos atrás.

Objetivos de negócio da modernização

Para os negócios avançarem estrategicamente, é vital ser proativo ao invés de reativo quando se trata de tecnologia. Os sistemas devem receber constante cuidado e atenção, sendo capazes de evoluir constantemente para se manterem em linha com as demandas.

O acesso a novas tecnologias deve ser aproveitado. Isso significa que é importante revisar tudo que já foi feito, mesmo as aplicações que rodem razoavelmente bem, por que podem haver maneiras melhores de se fazer as coisas e libertar maior potencial. A resultante disso pode ser equacionada por uma maior velocidade de entrega ou melhores condições de operabilidade, que, por sua vez, aumentam seu custo-benefício, confiabilidade, segurança, performance e sustentabilidade.

No entanto, modernizar a tecnologia não é apenas adotar as melhores e mais recentes tecnologias. É vital entender primeiro as necessidades do negócio e depois avaliar quais tecnologias podem atendê-las melhor. A primeira etapa para qualquer projeto de modernização bem-sucedido é entender os objetivos e motivadores de negócios, por exemplo, os motivos para migrar para a nuvem durante a modernização da tecnologia. Tudo está relacionado a esses objetivos de negócios e ao que a empresa espera alcançar. O alinhamento do negócio é vital nesta fase, não apenas algo para esperar que aconteça, mas algo que seja estratégico para o negócio e alcance dos benefícios.

Benefícios como qualidade, tempo e custo podem ser alcançados, mas estão relacionados à qualidade das entregas. Se o tempo não for gasto focado em estabelecer metas boas e alcançáveis, há uma boa chance de fracasso. Na verdade, quase três quartos das organizações (74%) iniciaram um projeto de modernização do sistema legado, mas não conseguiram concluí-lo. Mas, se o seu software não for capaz de acompanhar o ritmo dos negócios, é um impedimento. Se a tecnologia está atrasando sua organização, isso pode significar que você não é capaz de escalar em termos de ofertas de serviços ou mesmo em novos mercados. É vital virar o jogo e remover a tecnologia como um bloqueador de qualquer crescimento organizacional. Muitas vezes, o único caminho a seguir é embarcar em um esforço de modernização de software.

Impacto da modernização nos negócios existentes

Ao embarcar em um esforço de modernização de software, as empresas também devem se precaver para não estrangular suas operações atuais. É preciso manter um nível mínimo de ‘luzes acesas’ - a tecnologia é aquilo que torna os negócios viáveis enquanto gera renda. A forma de abordagem e níveis de modernização devem ser objetos de muita atenção, propiciando que os negócios continuem a ocorrer enquanto são incrementalmente modernizados. Isso pode ser atingido ao destacar diferentes áreas nos sistemas, que terão abordagens específicas e individuais, onde gradualmente o trabalho poderá ser feito até que cada parte do sistema seja modernizada.

O impacto da Modernização nas pessoas e habilidades

Como parte de um esforço de modernização, deve-se levar em consideração a lei de Conway. No passado, em 1967, Melvin Conway introduziu a ideia de que os sistemas de uma organização deveriam tentar refletir uma estrutura similar à sua própria estrutura de comunicação. Esse aspecto possibilita sistemas pouco acoplados. Também há muita pesquisa acerca de composições de times, que sugerem que aqueles com maior índice de sucesso são constituídos por equipes multi-disciplinares, ou seja, com maior diversidade de habilidades e disciplinas. Idealmente, cada time deveria possuir todas as habilidades de que necessita, permitindo-o ser totalmente independente e desacoplado dos outros, tornando possível a atuação com maior autonomia e, finalmente, com maior velocidade.

Se imaginarmos uma empresa que deseja começar um esforço de modernização de software, envolvendo migrar para arquitetura de micro serviços, então, para que ela seja verdadeiramente bem sucedida, a organização deverá preparar equipes muito experientes e com grande conhecimento geral do sistema, para que estas estabeleçam propriedade sobre cada novo micro serviço criado. Para algumas organizações isso pode demonstrar o contraste sobre como seus times são constituídos atualmente. Novamente, um outro exemplo, se há um administrador de banco de dados (DBA) na organização, que dê suporte às bases instaladas em infraestrutura local, esse papel provavelmente precisará evoluir após uma migração para serviços de dados externos ou plataformas em nuvem. Rotinas de backup e otimizações passariam teoricamente a ser desempenhadas pelos provedores de serviço. Muitas organizações evoluíram papéis como o de DBA para atividades mais relacionadas a ciência de dados após essas migrações.

Portanto, como parte do esforço de modernização de software, é importante levar em consideração a topologia das equipes e o impacto nas definições atuais de cada papel.

Além disso, entender como o software será entregue ajudará a determinar funções e responsabilidades. A modernização envolve não apenas a adoção de novas tecnologias, mas também a avaliação e melhoria dos processos. Por exemplo, para muitas organizações, grande parte do esforço de modernização de software envolve a incorporação de mais automação e a adoção de padrões de engenharia maduros, como integração contínua e entrega contínua, para garantir um processo de implantação robusto e repetível para seu software. Isso pode, por exemplo, envolver a substituição de um conjunto de casos de teste executados manualmente por testes automatizados. Nesse caso, o papel desses testadores manuais pode evoluir.

Funcionários que trabalham para manter infraestruturas locais irão, provavelmente, precisar ser treinados novamente para adotar tecnologias de nuvem, que possivelmente envolverá atualização de habilidades, mudanças na estrutura organizacional, procedimentos de manutenção e responsabilidades futuras. Provedores de serviços de nuvem geralmente oferecem ajuda nesse processo, por exemplo, a AWS tem um modelo de responsabilidade. Isso ajuda a detalhar em que nível o negócio é responsável por governar e gerenciar o novo sistema de nuvem.

As empresas também precisam se preparar para mudanças no recrutamento e retenção. Existem comunidades diferentes para cada tecnologia. A maturidade de cada tecnologia vai determinar o tamanho de sua comunidade. Se é madura, ou evoluiu de forma rápida, haverá grande popularidade ao seu redor. Haverão muitas pessoas com as habilidades e vontade de trabalhar com essa tecnologia. No entanto, se a empresa trabalha com tecnologias ultrapassadas, haverá uma comunidade menor de pessoas dispostas a trabalhar com elas, dificultando a tarefa de recrutamento.

Mover para a nuvem e modernizar não se trata apenas de tecnologia. O conjunto de tarefas que as empresas precisam executar vão ser diferentes na nuvem, a automação e outros serviços irão alterar os processos adotados.

Quando é o momento certo para modernizar?

Como mencionado no início, não existe uma medida universal em se tratando de modernização de tecnologia. A resposta para essa pergunta depende do contexto e do apetite por riscos por parte da empresa, sendo que se a organização não for capaz de detalhar as diretivas de negócio, visão técnica e um mapa de objetivos, pode ser que ainda não seja o momento certo de começar. Nesse estágio, se a necessidade de empresa for de migrar rapidamente para a nuvem, uma estratégia comum seria focar apenas em ‘rehosting’ (mudar de servidor), ou ‘lift and shift’ - que permite iniciar a migração para a nuvem enquanto prepara-se para assumir mais riscos numa modernização completa. Essas estratégias mais completas estão detalhadas em Estratégias de migração de aplicativos - Os 3 R's.

Em um cenário ideal, os negócios evoluem gradualmente, ao invés de ter que modernizar - uma sutil mudança de direção ao invés de reversão total de sentido. Entretanto, ao negligenciar a visão técnica enquanto uma tecnologia funciona corretamente por 10/15 anos e não ter atenção ao tempo certo de modernizar ou evoluir, podem fazer sentir os efeitos de não o fazer. Esses efeitos podem ser, por exemplo, contratempos em produção, ou tempos extensos de entrega, indicando a decomposição arquitetural com o tempo. Se esses são os indicadores presentes na necessidade atual de modernização, o tempo ideal para isso já passou e a empresa já passa por desafios que afetam os negócios.

Os benefícios da modernização versus os desafios de não o fazer

O perigo de não se modernizar pode ser refletido na participação de mercado de uma empresa, e também na habilidade de reagir às demandas dos consumidores. Além disso, aumento de tempo de entrega, infelicidade das equipes e ocorrência de problemas nas atualizações - que compromete proporcionalmente a capacidade de entrega.

Isso leva de volta a maneira como os sistemas são suportados, e a habilidade de responder rapidamente às mudanças de mercado. Se a vantagem competitiva está diminuindo de velocidade, ou os sistemas deixaram de receber suporte pela comunidade, isso pode gerar problemas de segurança e perda da habilidade de atender às demandas dos clientes. Outro desafio é conter a infelicidade dos empregados, o ambiente de trabalho se torna desafiador.

Esses desafios podem ser invertidos para entender os benefícios da modernização. As empresas podem responder às mudanças rapidamente, permitindo que cresçam e evoluam junto com os negócios, à medida que se adaptam em diferentes direções para acompanhar as demandas dos consumidores.

As empresas podem então contar com maior disponibilidade de talento, facilidade de retenção e melhorias de performance, segurança e confiabilidade.

O potencial dos negócios pode ser libertado, e ao invés de gastar tempo com preocupações relacionadas a tecnologia, o tempo pode ser utilizado para adicionar valor ao negócio. Vamos pegar como exemplo empresas mais novas, como a Cazoo, mencionada acima. Problemas e oportunidades de negócios são respondidos mais rapidamente, pois a empresa pode se concentrar inteiramente em seus negócios, em vez de se preocupar com dívidas técnicas.

Os 3 R's

Em 2011, o Gartner cunhou a frase "os 5R's" para descrever diferentes estratégias de migração para a nuvem. Mais recentemente, isso evoluiu para os “7R’s” 

Na Codurance, sentimos que a grande maioria das migrações para a nuvem tende a adotar uma de apenas três dessas estratégias. Cada uma dessas estratégias apresenta um apetite de risco diferente para o negócio e se concentra em diferentes escalas de tempo e preparação do negócio.

Esses 3 Rs estão listados abaixo.

1. Rehosting 

Rehosting (geralmente mais comumente chamada de 'lift and shift') geralmente envolve a migração de aplicativos de software para a nuvem com muito pouca (ou nenhuma) alteração de arquitetura ou design sendo feita. Na verdade, passando de computação local, como máquinas virtuais, para máquinas virtuais hospedadas por um provedor de nuvem. A organização ainda mantém todo o software e serviços nessa máquina virtual da mesma forma que faziam anteriormente no local.

Essa estratégia geralmente é a melhor escolha quando uma organização tem pouco apetite por riscos. Ele permite que muitas operações e formas de trabalho continuem 'como estão' sem a necessidade de mudanças generalizadas. Veja, por exemplo, a situação de uma organização que precisa migrar a infraestrutura para a nuvem em um prazo apertado, imposta por restrições de negócios mais amplas. Rehosting permite uma mudança rápida para a nuvem, permitindo que o negócio continue. Embora essa estratégia não permita realmente que uma organização aproveite todo o poder de uma plataforma na nuvem, ela ainda traz benefícios, se os objetivos de negócios se alinharem, por exemplo, economia de custos no local com economia na nuvem. 

2. Replatforming 

Com que grau de 'Lift and shift' uma empresa se sente confortável?

Semelhante à rehospedagem, a replataforma é a mudança inicial para a nuvem, mas a mudança aqui é que uma organização está começando a fazer algumas alterações em seu cenário técnico, embora ainda não mude significativamente a arquitetura. Muitas vezes, isso envolve uma leve adoção de tecnologias nativas da nuvem na forma de serviços gerenciados. Portanto, os bancos de dados podem ser transferidos para o serviço gerenciado de banco de dados do provedor de nuvem ou um componente de agregação de log local pode ser substituído por um serviço gerenciado para análises e relatórios. Quando o apetite ao risco é um pouco maior, essa é a estratégia que as empresas tendem a adotar.

Muitos desses serviços gerenciados nativos da nuvem são inerentemente elásticos por design. Isso significa que, ao adotá-los, as organizações podem começar a colher alguns desses benefícios, como escalabilidade automática para lidar com picos e quedas no tráfego.

Ao decidir qual estratégia de migração para a nuvem adotar, há alguns fatores a serem considerados. Por exemplo, talvez sua organização precise obter os benefícios da nuvem em um período de tempo relativamente curto. Ou talvez os custos de manutenção precisem ser reduzidos. Nesse caso, rehosting ou replatform provavelmente seria a estratégia mais apropriada a seguir.

Adotar qualquer um dos dois primeiros R's - Replatforming ou Rehosting - permite que a organização veja os benefícios rapidamente. Já o 3º R -  Refactoring / Re-architecting  - conforme mencionado abaixo, é para empresas que possuem visão técnica de migração para nuvem. 

3. Refactoring / Re-architecting (e um pouco de recompra) 

'Como as empresas podem se beneficiar da migração de aplicativos legados para a nuvem' refere-se à importância de identificar o(s) impulsionador(es) de negócios por trás de uma migração para a nuvem. Esses direcionadores de negócios devem formar a base de uma visão técnica para garantir o alinhamento com as metas de negócios. Isso permite que as organizações especifiquem as qualidades que precisam que as arquiteturas técnicas exibam. Capturar essas qualidades na forma de métricas permite que mecanismos sejam implementados para garantir que uma arquitetura técnica atenda aos resultados pretendidos.

Uma abordagem de 'lift and shift', semelhante ao rehosting, muitas vezes oferece uma rota mais rápida para migrar para a nuvem e, portanto, permite uma rápida realização de valor como resultado, em algumas áreas. Por exemplo, reduzindo o custo de manutenção da infraestrutura.

No entanto, uma estratégia de rehosting geralmente não leva em consideração a evolução futura de uma organização e se o cenário tecnológico atual suporta isso.

É aqui que entra a estratégia de re-arquitetura. Isso geralmente é mais voltado para o futuro, garantindo que a plataforma de nuvem seja projetada de forma que possa suportar a evolução da organização sem a necessidade de redesenhos por atacado.

Re-arquitetar dessa maneira envolverá mudanças de tecnologia e sistemas durante esse processo. As questões que precisam ser enfocadas, é como isso parece no futuro, quais objetivos estão sendo alcançados? Por exemplo, se uma empresa deseja entrar em um novo mercado ou lançar várias novas linhas de serviço, elas dependem muito da estrutura e, portanto, precisam ser levadas em consideração na visão técnica dessa estratégia. A re-arquitetura é uma abordagem mais estratégica para obter vantagens competitivas.

No entanto, ter uma estratégia de re-arquitetura depende de ser um objetivo de toda a empresa. A migração para a nuvem dessa maneira não pode ser feita isoladamente e, muitas vezes, leva em consideração um propósito comercial. Qual é o propósito de estar na nuvem? E quais são os benefícios e mensuráveis que você deseja alcançar? Que serviços adicionais você espera alcançar? Visibilidade ou monitoramento, facilidade de adesão, grandes benefícios de dados. Todos esses benefícios dependem da mudança estratégica para a nuvem.

Também é importante entender como o negócio está se saindo tecnicamente. Se o local não estiver funcionando, a migração para a nuvem não será uma solução instantânea. Se a organização está lutando para entender bem como está gerenciando seu software local, é provável que isso também aconteça na nuvem. Neste ponto, é entender o roteiro em vez de fazer o movimento.

Atualizando com uma estratégia de re-arquitetura em grande escala

Se o roteiro técnico de um negócio estabelecido está apontando para uma re-arquitetura em larga escala, é um sinal de que algo deu errado. No cenário ideal, uma organização gostaria de expandir seus serviços e crescer gradativamente, evoluindo a plataforma. No entanto, nem sempre é esse o caso. Se as plataformas não mudaram ou evoluíram nos últimos 5 a 10 anos, elas geralmente não são adequadas para o propósito, interrompendo a possibilidade de respostas rápidas ao mercado.

Ao re-arquitetar, a organização deseja que o sistema faça algo que atualmente não pode fazer. Por exemplo, não pode criar uma boa auditoria? A empresa pode monitorar o desempenho ou a segurança?

Há uma etapa necessária para avaliar esses grandes sistemas, entender o mapeamento atual e avaliar os serviços atuais que a nuvem oferece. Nesse instante, os negócios podem concluir uma revisão bem arquitetada, que, do ponto de vista do aplicativo, analisa como a plataforma precisa ser reorganizada e entende como os requisitos atuais são mapeados para o sistema em nuvem. Sem mapear isso, é difícil ver todos os benefícios que podem ser alcançados usando provedores de nuvem.

Como a Recompra se encaixa nessa estratégia?

Os 6 R's originalmente cunhados mencionam a recompra como sua própria estratégia. No entanto, neste caso, ela foi adicionada com re-organização/re-arquitetura porque está dentro dos objetivos de negócios de longo prazo. Trata-se de mudar a forma como um negócio interage com uma ferramenta para economizar no esforço comercial, o que não traz valor de volta para o negócio. Não tem vantagem competitiva. Tomemos, por exemplo, o Salesforce, para uma organização, ao mudar para uma solução em nuvem ou SaaS, permite que o foco seja o valor comercial puro, em vez de aumentar o custo ou a dívida técnica em algo em que o negócio não está focado.

Qual estratégia é a certa para você?

Ao elaborar a estratégia certa para o seu negócio, é importante lembrar que o negócio não está preso a apenas uma dessas estratégias. Muitas vezes, a estratégia de rehosting pode atuar como um bom primeiro passo na jornada de adoção da nuvem muito mais ampla de uma organização. A estratégia de migração para a nuvem pode então ser expandida quando a empresa se sentir pronta, por exemplo, os aplicativos podem ser modernizados.

Saiba mais sobre o benefício da modernização de software como parte de uma estratégia de migração para a nuvem de negócios em: Compreendendo os benefícios de incorporar a modernização em uma estratégia de migração de aplicativos

Criando inovação na nuvem

O que significa inovação na nuvem? A inovação é geralmente definida como a introdução de algo novo - seja uma ideia, método ou processo. Aplicar isso ao contexto da computação em nuvem significa usar plataformas e serviços em nuvem para resolver desafios de negócios de novas e melhores maneiras, permitindo que eles se destaquem entre seus concorrentes.

Aproveitar a inovação na nuvem geralmente permite que as organizações entrem em novos mercados ou criem novas ofertas de linha de serviço. Além disso, essa inovação também pode ajudar a fornecer insights mais poderosos e significativos sobre o desempenho de uma organização e permitir que decisões baseadas em dados sejam tomadas. Tomemos, por exemplo, Aprendizado de Máquina - as organizações normalmente tinham que fazer grandes investimentos iniciais se quisessem adotá-lo, o que tornou a barreira de entrada muito alta e a adoção proibida para eles. Atualmente, a maioria das plataformas de nuvem fornece mecanismos em que o Aprendizado de Máquina é muito mais acessível. Como resultado, as organizações podem, por exemplo, oferecer soluções inovadoras para seus clientes que alavancam o aprendizado de máquina, sejam recomendações de produtos e experiências de usuário mais inteligentes e personalizadas ou geralmente construindo altos níveis de inteligência em seus sistemas.

A inovação usando a nuvem tornou-se mais acessível a empresas de todos os portes, e não apenas àquelas que têm acesso a grandes investimentos. A nuvem reduziu a barreira de entrada para organizações que adotam abordagens diferentes.

Os provedores de nuvem permitem que as empresas experimentem com custos muito mais baixos do que ter que construir e manter a infraestrutura subjacente no local. Freqüentemente, os provedores de nuvem oferecem um nível gratuito de avaliação inicial para acessar seus serviços. Isso dá às organizações a liberdade de experimentar com muito mais liberdade, sem a sobrecarga de custos. Isso desbloqueia a inovação.

Testar novos serviços em nuvem para oferecer serviços ou experiências novos ou inovadores ao cliente e oferece às organizações a chance de se diferenciar de seus concorrentes. Tomemos, por exemplo, novos métodos de pagamento. Se durante a jornada do cliente for bem-sucedida, ela permite que a empresa se destaque instantaneamente da multidão, pressionando a concorrência para alcançá-la. O baixo custo do teste permite que as empresas também parem de testar os serviços se eles não forem benéficos.

Serviços em nuvem para acelerar a inovação nos negócios

Entender como o uso da nuvem pode acelerar a inovação nos negócios é fundamental. Existem serviços de nuvem frequentemente negligenciados que podem ajudar a expandir os negócios, resolvendo problemas que anteriormente sobrecarregariam as equipes, impedindo-as de se concentrar em sua proposta de valor principal. Serviços gerenciados, por exemplo, tendem a ser inerentemente elásticos. Se tomarmos como exemplo um banco de dados, quando hospedado no local, é claro que é necessário manter esse banco de dados. Isso vem na forma de backups, planejamento de recuperação de desastres, provisionamento de recursos e assim por diante. Todas essas atividades exigem esforço e investimento de uma organização, mas não agregam valor diretamente, são mais atividades de suporte. Se uma organização mudar para um banco de dados de serviço gerenciado na nuvem, muitas dessas atividades são tratadas pelo provedor de nuvem e geralmente projetadas com escalabilidade em mente. Isso dá às organizações a capacidade de dimensionar seus serviços sem a sobrecarga adicional de gerenciamento da infraestrutura, como acontecia antes. Isso, por sua vez, permite que alcancem novos mercados e criem novas ofertas de serviços para seus clientes mais rapidamente do que antes.

Existem serviços cloud que do ponto de vista operacional podem otimizar o funcionamento do negócio, como ferramentas de gestão de custos que permitem gerir todos os serviços a partir de uma localização central. Ao combinar isso com boas práticas de gerenciamento de infraestrutura (como marcação apropriada de recursos), isso pode dar às organizações uma grande visão sobre seus custos de infraestrutura de nuvem e possivelmente oferecer soluções inovadoras.

Da mesma forma, a maioria das plataformas de nuvem oferece serviços de monitoramento de infraestrutura e serviços. Isso permite que as organizações tenham uma configuração de observabilidade abrangente para seus sistemas, permitindo que compreendam o estado desses sistemas a qualquer momento e, talvez mais importante, o motivo de estarem no estado em que estão. Esse tipo de prática pode não parecer muito empolgante, mas é extremamente importante. Feito corretamente, ele permite que as organizações resolvam proativamente quaisquer problemas nos sistemas de produção antes que eles afetem amplamente os clientes.

Blockchain está rapidamente se tornando uma tendência tecnológica na qual muitas organizações estão apostando firmemente ou querendo experimentar. Para as empresas que querem jogar neste espaço, os provedores de nuvem estão lançando serviços para permitir que as organizações integrem seus sistemas com o Blockchain. Fornecer as APIs para interagir com eles, em vez de fazer isso sozinhos. Isso está abrindo as portas para mais inovações, sendo capaz de resolver problemas do mundo real com tecnologia que não estava disponível anteriormente. Por exemplo, com o blockchain, estamos vendo as questões de propriedade da terra na África sendo ajudadas, usando o blockchain como uma forma de mostrar quem é dono de qual parte das terras.

Como impulsionar a inovação na nuvem

A possibilidade de inovação usando a nuvem é uma realidade, mas ser capaz de impulsioná-la como um negócio costuma ser o obstáculo que as empresas enfrentam.

Garantir que as equipes tenham espaço e tempo suficientes para inovar é vital. Se as equipes puderem gastar tempo procurando novas ferramentas, haverá a oportunidade de entender onde a inovação é possível. Freqüentemente, os negócios e, portanto, as equipes estão tão focados no curto prazo que geralmente há pouco ou nenhum tempo para entender como os problemas de negócios podem ser resolvidos de maneiras novas e diferentes ou se novas tecnologias abrem novas possibilidades e oportunidades. O Google, por exemplo, costumava ter tempo dedicado à inovação - conhecido como googles ‘20% do tempo’ era uma política de que 20% do tempo de um engenheiro poderia ser gasto em seus projetos pessoais, permitindo-lhes experimentar novos, criativos e ideias inovadoras, pesquisando novas tecnologias ou se aprimorando. Isso permitiu que novas ideias fossem apresentadas à empresa, à medida que as equipes investiam na pesquisa e no desenvolvimento para tornar a empresa melhor.

Ter uma visão técnica clara é vital para qualquer organização. Porém, muitas vezes muitos caem na armadilha de construir uma visão técnica que depois não é ajustada e evoluída ao longo do tempo. É importante traçar uma direção geral ou "Estrela do Norte" como parte de uma visão técnica, mas também é importante que ela seja constantemente avaliada para permitir mudanças na organização, mas também para acompanhar as mudanças na tecnologia. Sem isso, é possível definir uma 'grande visão' onde você perderá novas tecnologias. É assim que as empresas ficam presas e caem na armadilha de precisar embarcar em um esforço de modernização de software em larga escala. Ao revisar constantemente sua visão e roteiro de tecnologia, você pode garantir que ele esteja alinhado com as metas e necessidades de negócios.

Atualizar habilidades e criar processos adaptáveis - isso força as empresas a observar como fazem as coisas e entender a inovação e a eficiência. Além disso, fazer com que as pessoas olhem para a inovação em vez de combater incêndios - depois de migrar para a nuvem, o que você costumava fazer no local (gerenciamento de baixo nível) libera recursos para olhar para a inovação em vez de combater incêndios. Ao entender as funções das equipes e os padrões do que elas fazem, permite que os conjuntos de habilidades sejam movidos para onde se encaixam melhor. Por exemplo, alguém que anteriormente cuidava do banco de dados, como sua função muda quando você migra para a nuvem? Seria o ajuste certo para eles agora se concentrarem na ciência de dados?

Desafios comuns a serem evitados com a inovação em nuvem

Dan McKinley em 2015 falou sobre "Choosing Boring Technology", e como muitas vezes é uma estratégia muito menos arriscada do que adotar tecnologias mais novas, talvez menos maduras. Embora isso seja verdade, essa abordagem pode sufocar a inovação. O desafio que as organizações enfrentam é entender seu nível de risco e o quanto estão preparadas para investir em inovação. Algumas organizações optam por ser as primeiras a adotar novas tecnologias. Isso é bom, mas é importante tomar essa decisão, totalmente ciente dos riscos e compensações envolvidos. Por exemplo, tecnologias mais novas, por sua própria natureza, ainda não foram amplamente adotadas, então há menos exemplos de uso delas e, portanto, talvez não tão maduras ou "endurecidas pela batalha". Alguns casos de uso que você pode precisar podem não ser totalmente suportados ou a documentação pode ser muito leve.

Mudança para a nuvem

Mudar para a nuvem pode ser considerado uma mudança com os tempos. Mas, para qualquer empresa, entender por que você deve fazer uma mudança costuma ser a primeira pergunta que precisa ser respondida nesse processo ou estratégia.

A base de qualquer proposta de migração deve estar em como uma migração para a nuvem ajudaria a dar suporte aos objetivos de negócios. Por exemplo, escalabilidade, entrada em novos marcadores ou otimização de custos seriam apenas alguns motivos de negócios. Entender por que você está migrando para a nuvem e entender os problemas de negócios que está tentando resolver permite que você entenda se é a escolha certa para o seu negócio. Isso permite que você determine a estratégia de migração que deve adotar, bem como o que precisa medir ao longo do caminho.

Este artigo irá guiá-lo pelas etapas do que significa mudar para a nuvem para aplicativos legados e os benefícios que isso pode trazer para o seu negócio.

Concentrando-se primeiro no motivo pelo qual você se moveria, segue as declarações feitas acima. Entender a necessidade de mudança da empresa pode ajudar a definir benefícios claros e metas mensuráveis para a empresa.

Por que minha empresa precisaria migrar para a nuvem

A sobrecarga operacional de ter uma propriedade no local é um motivo popular para mudar para a nuvem. Manter a infraestrutura física no local exige muito esforço e investimento, atualizar patches de segurança e fornecer diferentes controles de acesso exige grandes despesas gerais. Se o seu negócio principal não envolve a prestação de serviços técnicos, o esforço necessário não agrega muito valor ao seu negócio. Quando isso excede os benefícios de ter uma propriedade local, a nuvem é uma opção viável. A remoção dessa sobrecarga libera as equipes para se concentrarem em problemas que agregam mais valor aos negócios. Por exemplo, deixar de gerenciar bancos de dados para incorporar a ciência de dados e obter insights significativos que podem ser realimentados no fluxo de valor.

O risco é outra área a ser considerada ao pensar na migração para a nuvem. Ao migrar para a nuvem, você está efetivamente transferindo um grau de risco para seu provedor de nuvem e é importante entender como isso se encaixa no seu apetite de risco geral e no processo de gerenciamento de risco. Por exemplo, o risco de gerenciamento de hardware e segurança pode não ser relevante para seus objetivos ou especificações de negócios do dia a dia, o que significa que o gerenciamento desse processo envolve a contratação de toda uma equipe ou especialistas. A transferência desse risco para os provedores de nuvem economiza o capital e o esforço de gerenciamento dessas equipes ou especialistas. Mudar para a nuvem pode ser o primeiro passo para gerenciar o risco, mas com o mesmo custo? A empresa também precisa reconsiderar a evolução das políticas atuais em relação à recuperação/backup de desastres, pois elas também mudarão quando você migrar para a nuvem.

Os benefícios de migrar para a nuvem

Depois de entender os motivadores de negócios para migrar para a nuvem, é importante entender as vantagens (ou desvantagens) adicionais. Os provedores de nuvem podem fornecer às empresas acesso a serviços que não possuem atualmente ou que seriam proibitivamente caros para configurar no local. As plataformas de nuvem oferecem acesso a esses serviços de maneira muito mais econômica, o que reduz a barreira de entrada e adoção. Tomemos, por exemplo, big data/análise de ciência de dados, que envolveria um investimento bastante grande, as empresas agora são capazes de alavancar serviços gerenciados em plataformas de nuvem. Os provedores de nuvem oferecem muitos níveis diferentes de uso, alguns até mesmo oferecendo algum tipo de nível gratuito. Isso torna incrivelmente barato para as organizações experimentar como novos serviços podem oferecer soluções inovadoras para seus problemas de negócios, sem o perigo de um compromisso de longo prazo no início.

Embora esses exemplos possam ou não ser relevantes para o seu negócio, algumas coisas são importantes a serem consideradas. A mudança para a nuvem sempre deve ser apoiada por um driver de negócios claro, ou seja, uma mudança para a nuvem deve ser uma resposta às necessidades de uma Organização. Por exemplo, pode ser uma necessidade de maior escalabilidade ou um desejo de reduzir custos operacionais. Uma migração para a nuvem não deve ser vista apenas por lentes técnicas. O motivo mais importante para mudar é que ele está alinhado com os objetivos de negócios. E esses objetivos de negócios geralmente são diferentes, dependendo da necessidade do negócio. Por exemplo:

Aplicativos - A adoção de serviços gerenciados pode ajudar as organizações a consolidar suas ferramentas técnicas. Por exemplo, em vez de ter ferramentas separadas de diferentes fornecedores para agregação de logs, alertas, painéis, etc., tudo isso pode ser reunido no mesmo provedor de nuvem.

Regulamentações - Dependendo do setor em que atua, as regulamentações podem ser caras e com altas restrições de tempo e prazos iminentes. Os provedores de nuvem criam patches e soluções para os regulamentos de sua infraestrutura, resolvendo os problemas sem que a empresa invista tempo.

Conjunto de habilidades - Os provedores de nuvem geralmente criam esquemas de treinamento e certificações, facilitando a contratação de funcionários com conhecimento existente dos sistemas. A infraestrutura local pode exigir um alto nível de treinamento para integrar alguém, enquanto a adoção da nuvem traz um nível de padronização em relação às habilidades.

Por que investir na migração para a nuvem?

Investir na migração para a nuvem precisa resolver os desafios que você enfrenta atualmente com seus aplicativos legados. O acesso a uma maior elasticidade de computação pode ser um fator importante na mudança para a nuvem. A elasticidade automatizada da infraestrutura e o poder de computação de um provedor de nuvem permitem que as organizações lidem com picos e quedas de tráfego em seus sistemas com relativa facilidade e de maneira altamente econômica. Tradicionalmente, as organizações precisariam investir tempo e dinheiro no planejamento e aquisição de hardware extra em preparação para os próximos picos de tráfego esperados (por exemplo, cargas de temporada como o Natal para varejistas on-line).

A comunicação de valor retornado ao negócio é determinada pelos desafios compreendidos neste primeiro ponto, por que o negócio mudou para a nuvem? Suponha que foi o custo, ao entender os custos de execução anteriores, permite definir métricas para quanto a infraestrutura de nuvem está custando agora. Nesse caso, você também pode mostrar a economia de custos ao entender o impacto nos negócios. Por exemplo, se o tempo de inatividade foi um grande problema, criando reclamações de clientes, você pode medir o tempo de inatividade, as reclamações de clientes e a carga de trabalho da equipe que lida com reclamações. Se os regulamentos foram o motivo para mudar para a nuvem, continuar trabalhando com seu provedor para entender quais patches foram implementados para ajudar a alinhar sua organização com esses requisitos pode ser comunicado à empresa e uma compreensão do esforço que teria sido necessário interno.

Então, para a questão de porquê você moveria aplicativos legados para a nuvem, em última análise, depende de seus objetivos de negócios por que seria uma boa ideia para seus negócios. Há benefícios em todos os desafios, mas não haverá benefícios se não houver desafios.

Continue sua jornada de migração para a nuvem entendendo qual estratégia é a certa para o seu negócio com: Estratégias de migração de aplicativos - Os 3 R's 

Você pode ter encontrado software que não é facilmente testável e, com isso, quero dizer software que não é testado desde o início. Você pode até ter tentado testá-lo, mas não conseguiu. Não se preocupe, o software em que o teste é uma reflexão tardia nunca será tão testável quanto o software projetado para ser testado desde o início.

Neste post, vou explorar como você pode abordar o teste de software onde o teste é uma reflexão tardia. Abordarei o contexto que você precisa coletar, um exemplo simples de Golden Master Testing e uma implementação não padronizada do padrão Golden Master.

Além disso, compartilharei com você um exemplo prático de como abordamos esse desafio com um de nossos clientes - e os resultados que conseguimos alcançar.

Por onde você começa ao trabalhar com código que não foi criado para ser testado?

Como consultoria de software, a Codurance trabalha com muitos clientes e códigos que estão em diferentes estágios ou estados. No cenário que vou compartilhar com vocês hoje, estávamos trabalhando com um cliente que tinha código de produção com pouco ou nenhum teste automatizado.

Em primeiro lugar, era importante concordarmos que uma “rede de segurança” deveria estar em vigor, onde um conjunto de testes automatizados poderia fornecer feedback sobre se as alterações no código de produção alteraram seu comportamento.

Receber esse tipo de feedback desde o início é importante, especialmente porque confiar em testes manuais resultará em feedback lento. Esse feedback lento pode não chegar a um desenvolvedor até horas, dias, semanas depois de fazer uma alteração.

Características comuns do código legado que dificultam o teste

O código de produção de nosso cliente tinha várias características que você pode esperar de um software escrito há alguns anos e que foi adicionando funcionalidades ao longo do tempo. Tudo isso é importante entender para apreciar melhor como tomamos decisões.

Aqui estão algumas dessas características e outros fatos pertinentes que ajudaram a moldar nossa solução.

Fortemente dependente de um banco de dados

A parte específica do código que estávamos testando dependia muito do banco de dados (DB). Com isso, quero dizer que ele é executado em um cronograma e consultará o banco de dados para ver se há entrada para processar. Nesse sentido, o banco de dados fornece a entrada para o código que queremos testar. E, claro, isso significa que precisávamos fornecer a entrada para o banco de dados, mas mais sobre isso depois.

Também é importante destacar que o design do sistema significa que o banco de dados é realmente parte integrante de como o código de produção é executado, controlando quais ramificações do código são executadas, por exemplo. Não vai demorar muito para fazer a conexão entre essa afirmação e o impacto em como o software é testado. Sim, de fato você está pensando que muitos dados precisarão ser colocados no banco de dados, antes de invocar o código de produção.

Em seguida, quero falar sobre a saída - usando o termo livremente. Digo isso porque o código de produção processa a entrada e grava os dados de volta no banco de dados, e aqui vou me referir a isso como “saída”, embora não seja, mas não quero ser pego em um debate filosófico sobre se isso é realmente "entrada" para o banco de dados. Portanto, para resumir o último ponto, o comportamento observável dessa parte do sistema é feito observando o efeito no banco de dados após a conclusão do código de produção.

Grande base de código que cresceu ao longo do tempo

O código é grande e foi adicionando funcionalidades ao longo do tempo. A redação é deliberada, pois o design não evoluiu necessariamente, mas um novo código foi adicionado e espalhado por todo o código existente. O que resta é grande e complexo, com algumas classes e métodos muito grandes.

Aqui, o tamanho do código é importante, pois mais código neste caso significava mais ramificações possíveis (execução de código, nada a ver com Git). E por causa do tamanho, você pode acabar fazendo uma alteração na linha 2.000 e impactar algo que acontece na linha 10.000.

O que tudo isso significa é que, como o código não foi projetado para ser testado quando foi criado, não poderíamos empregar facilmente as técnicas que usaríamos normalmente, pois isso provavelmente envolveria fazer alterações no código grande e complexo subjacente. Na verdade, fazer isso na ausência dessa “rede de segurança” tornaria essas mudanças potencialmente de alto risco, o que era extremamente indesejável nesse domínio específico.

Código antigo (que não envelheceu bem)

Outra parte importante do contexto é a idade do código. Todos nós sabemos que é incomum um software envelhecer como o vinho ou queijo, e quando nos referimos a “código legado”, não estamos elogiando o legado que foi deixado por pessoas antes de nós.

Como mencionado anteriormente, o código foi adicionado ao longo de muitos anos e o código pode conter ramificações mortas. Isso é extremamente importante, pois sustenta por que solicitamos dados da produção como entradas, além de obter especialistas de domínio para categorizar o comportamento e exemplos de origem que testaram esse comportamento.

O contexto e o ambiente são essenciais para permitir o teste no código legado

Talvez você já tenha percebido que essa não era uma situação para o teste padrão do Golden Master. Tivemos que trabalhar iterativamente em direção a uma solução, com base no levantamento do ambiente e na absorção de todo o contexto e fatos. Mas vamos primeiro fornecer uma atualização sobre os testes Golden Master.

O que fazer quando você não pode usar o teste Golden Master padrão

Antes de pular para a abordagem e nossa solução, pensei que valeria a pena uma pequena atualização sobre o Golden Master Testing, trabalhando com um exemplo simples.

Golden Master Testing - uma atualização rápida

Para aqueles de vocês mais familiarizados com a técnica Golden Master, você normalmente verá coisas como as abaixo na literatura:

Registre as saídas, para um conjunto de entradas fornecidas

Isso é muito simples e, se você mesmo os escreveu, provavelmente tinha um arquivo de texto com as entradas e um arquivo de texto com todas as saídas.

Onde sua entrada pode parecer:

1 Name: Sam, Age: 105
2 Name: Bob, Age: 34
3 Name: Linda, Age: 26

E a saída:

1 Can retire: true
2 Can retire: false
3 Can retire: false

É simples e cada linha corresponde a um único cenário. Por exemplo, quando o código de produção obtém Sam e ele tem 105 anos, podemos ver que o código de produção diz que ele pode se aposentar.

Todos nós amamos código simples e a simplicidade acima, mas não tivemos o luxo de escrever uma implementação tão simples. No entanto, queríamos avaliar se uma abordagem Golden Master realmente funcionaria e, mais importante, valeria o investimento.

No contexto de nosso cliente, essa abordagem era simples demais para funcionar. Em vez disso, tivemos que adotar uma abordagem personalizada que começou com testes manuais.

Comece experimentando um teste manual

Começamos a escrever um único teste escrito à mão. Você pode comparar isso com uma única linha do arquivo de texto mencionado acima, que geralmente se correlaciona com um único cenário. No entanto, ao contrário do exemplo simples descrito anteriormente, o nosso não era uma única linha. Para este cenário único, exigimos a configuração de várias tabelas no banco de dados, que deveriam ser inseridas em uma ordem específica, exigindo uma orquestração cuidadosa, dadas as restrições do banco de dados.

Isso equivalia a mergulharmos os pés na água e era necessário para obter feedback sobre nossa abordagem. Durante esse experimento, concluímos (entre outras coisas) que esses testes eram lentos para escrever e, por isso, decidimos explorar se havia uma maneira melhor.

Levantar hipóteses, identificar oportunidades e experimentar

Você pode ter ouvido conselhos como “você não deve automatizar imediatamente”, e este é um conselho sensato. Estávamos seguindo isso quando começamos a escrever os testes manualmente. Conforme mencionado anteriormente, havia várias tabelas que tínhamos que configurar antes de invocar o código de produção. Agora, identificamos que grandes partes dessa configuração podem ser determinadas desde a entrada até o código de produção.

Então nos perguntamos:

Podemos gerar testes, usando a entrada para a configuração necessária?

Se fôssemos capazes de fazer isso, economizaríamos o trabalho dispendioso de criar a configuração a partir das informações da entrada, repetidas vezes, para cada cenário. Nesse momento, imagine ler um pedaço de papel e inserir partes dessa informação digitalmente por meio de um computador. Foi assim que me senti.

Experimentamos e descobrimos que essa abordagem de criar automaticamente a configuração a partir da entrada é promissora. Então, apoiamos essa abordagem e continuamos nessa jornada.

Uma solução mais inteligente e automatizada

Escolhemos registrar o que o código de produção fez ao ver o efeito que teve no banco de dados. Em nosso contexto, o banco de dados é o núcleo, então isso era perfeitamente razoável.

O que isso significava era que executaríamos o código de produção com cada entrada e capturaríamos o que acontecia com o banco de dados (ou seja, os efeitos colaterais).

Exemplo prático de teste de código legado dependente de um banco de dados

Aqui, mostrarei o que fizemos para testar o código herdado capturando alterações no banco de dados.

O exemplo acima mostra uma visão muito simplificada de como o comportamento do código de produção é capturado e como os testes são gerados.

Vamos nos aprofundar um pouco mais em cada uma dessas etapas, para descrever com mais detalhes o que elas estão fazendo.

Configuração

Objetivo - configurar o “mundo” para que o código de produção seja executado conforme o esperado

Exemplos - inserir dados no banco de dados, provisionar um servidor FTP fictício

Invocar código de produção

Objetivo - acionar parte do código de produção, de maneira representativa de como ele é realmente usado na produção

Exemplos - invocar o método runSomething() na classe chamada TheLegacyCode

Registrar estado do banco de dados

Objetivo - identificar em quais tabelas foram gravadas e capturar o conteúdo dessas tabelas

Esta etapa é bastante específica e pode assumir várias formas. Forneci um exemplo concreto para simplificar.

Gerar estado de banco de dados gravado

Objetivo - armazenar o estado do banco de dados após invocar o código de produção. Isso forma a base das asserções que são usadas para verificar se o estado do banco de dados foi alterado quando os casos de teste são executados.

Gerar caso de teste

Objetivo - gerar um arquivo que represente um teste e tenha todas as informações necessárias para localizar a entrada e a saída esperada (para usar esse termo livremente) para um determinado cenário.

Código legado grande e complexo centrado em banco de dados pode ser testado

Antes de adicionarmos este conjunto de testes, muitos provavelmente disseram “este código não pode ser testado”, mas fornecemos uma maneira de provar que ele pode ser testado e fornecer opções às pessoas se elas se encontrarem em uma situação semelhante.

Descobrimos que a abordagem que adotamos tinha várias vantagens, incluindo:

Feedback mais rápido

Conforme declarado na literatura muitas vezes, obter feedback mais rapidamente é sempre desejável, e este conjunto de testes forneceu isso.

A economia de tempo é realmente surpreendente. Leva 2,5 horas para um testador manual executar 10 testes manuais, enquanto leva apenas um minuto para executar 10 versões automatizadas desses testes manuais. Você aprecia isso ainda mais quando entende que o Test Suite tem cerca de 1.000 testes e executar 1.000 testes manuais levaria 10,5 dias (para uma pessoa que trabalha 24 horas por dia), enquanto os testes automatizados serão concluídos em 1 hora e 40 minutos.

A economia de tempo é significativa, mas o teste automatizado também permite mais flexibilidade para os desenvolvedores executarem testes sob demanda sempre que quiserem. Infelizmente, você não pode fazer o mesmo com um testador manual, toque no teclado três vezes e eles aparecem.

Maior flexibilidade

Nossa abordagem específica de geração desses testes significava que poderíamos girar muito mais rápido do que criá-los manualmente. Por exemplo, se precisássemos testar em uma tabela anteriormente desconhecida, poderíamos configurá-la na ferramenta e, em seguida, gerar novamente todos os testes, onde agora a nova tabela é capturada no “estado do banco de dados gravado”. Isso foi muito útil, especialmente porque não tínhamos todo o conhecimento inicial e poderíamos expandir nossos testes à medida que nosso conhecimento aumentasse.

Oportunidade de introduzir a automação

Pode parecer que estou afirmando o óbvio, mas essa foi uma das primeiras instâncias em que esse código realmente teve algum tipo de teste automatizado. Em particular, esses testes foram direto ao cerne dessa parte do sistema e testaram a lógica central, algo que não havia acontecido antes.

Teste o código legado com mais confiança

Encontramos uma maneira de trabalhar iterativamente para estabelecer um conjunto de testes Golden Master como um meio de alterar o código subjacente com mais confiança e eliminar o medo que pode se formar. O cliente realmente comentou sobre como eles não têm mais o medo que já tiveram, e esse medo se dissipou.

Uma coisa importante a destacar é que, depois de estabelecer uma suíte Golden Master, você pode começar a modernizar a base de código herdada com confiança.

Ao começar a modernizar a base de código e adicionar testes mais abaixo na pirâmide (por exemplo, testes de unidade), você obterá um feedback mais rápido e se tornará menos dependente apenas dos testes Golden Master.

Como sempre, o contexto é importante e espero que você entenda que todas as técnicas têm um tempo e um lugar, e até mesmo como essas técnicas são aplicadas dependerá consideravelmente do contexto.

O compartilhamento de conhecimento é importante e adoraríamos ouvir suas experiências com o teste de código legado.

É fácil perceber os benefícios de migrar sua empresa para a nuvem; maior eficiência, escalabilidade e economia de custos mensurável.

Não é nenhuma surpresa que 60% das empresas concordam que sofrerão competitivamente se não modernizarem seu software. Na última década, o software tornou-se cada vez mais importante para as empresas no que diz respeito ao gerenciamento do dia-a-dia, mas você não pode confiar na mesma tecnologia de hoje.

À medida que as empresas crescem, seus sistemas e processos crescem com elas. Garantir que o software seja fácil de mudar para esse crescimento é um grande passo para a evolução futura. Frequentemente, os sistemas são continuamente construídos para esse crescimento, mas tornam-se difíceis de mudar e monolíticos.

Quando os negócios e a tecnologia estão alinhados, atingir as metas de negócios torna-se mais gerenciável. O conceito de alinhamento muitas vezes preenche a lacuna entre conhecimento, habilidades e comunicação. Assim, criando um ambiente onde todos trabalham para a estratégia do negócio. Muitas vezes negligenciado, esse alinhamento cria um ambiente de negócios onde todos trabalham para os mesmos objetivos, criando equipes mais eficientes trabalhando em direção a objetivos estratégicos de longo prazo e uma organização onde o desenvolvimento entende o contexto operacional do projeto, ajudando a identificar potenciais obstáculos desde o início.

Como isso pode ser feito?

Eliminando silos organizacionais e alinhando as equipes aos objetivos estratégicos de negócios

Embora as equipes focadas no lado tecnológico dos negócios tenham evoluído rapidamente nos últimos anos, a adoção da tecnologia nem sempre se traduziu em processos de negócios simplificados. Os silos em desenvolvimento geralmente são formados devido a objetivos técnicos estarem em primeiro plano, que nem sempre se alinham aos objetivos estratégicos mais amplos definidos nos negócios. Além disso, a falta de compartilhamento de informações entre as equipes prejudica a transparência, com os silos criando uma estrutura de definição de metas individuais em vez de trabalhar em direção aos objetivos organizacionais. Isso pode levar a uma falta de eficiência.

Quebrar silos geralmente inclui tomar medidas para mudar a atitude e a cultura dos funcionários. O ímpeto pode então ser criado por meio de uma mentalidade colaborativa em todos os departamentos. Essa mentalidade pode ser criada por:

• Compartilhamento de metas de negócios relacionadas ao esforço da equipe
• Projetando métricas compartilhadas
• Estabelecer transparência e melhor colaboração entre as equipes

Evolução empresarial impulsionada pela tecnologia

A evolução da tecnologia transformou a forma como os negócios são conduzidos nas últimas décadas. Com a tecnologia continuando a evoluir, é provável que mais inovações venham. As empresas que podem se adaptar rapidamente a novas ferramentas e tecnologias atenderão às necessidades de um mercado em constante mudança.

Linguagem onipresente

Linguagem onipresente é a prática de construir uma linguagem comum e rigorosa entre desenvolvedores e usuários. No âmbito do Domain Driven Design, esta linguagem existe dentro de um Bounded Context que faz parte de um Context Map mais amplo. Isso cria uma linguagem baseada em modelos dentro do negócio que é completa e compreensível, usando elementos simples que se combinam para expressar ideias complexas. Também ajuda com a sutil diferença dentro de diferentes Bounded Contexts, onde os mesmos termos podem ter significados diferentes. Prestar atenção em como descrevemos os conceitos ajuda a preencher a lacuna entre os vários silos da organização.

Colaboração mais próxima

Como mencionado anteriormente, a comunicação é a chave para alinhar os objetivos de negócios e tecnologia. Um fator significativo é criar uma colaboração e relacionamentos mais próximos entre os dois. A adoção de novas tecnologias e o desenvolvimento de roteiros tecnológicos precisam da adesão da alta administração. A primeira etapa é identificar as principais áreas do roteiro que se alinharão com as metas de negócios. Essas áreas podem ter prioridade e começar a educar os desenvolvedores sobre onde o esforço precisa ser concentrado. Uma colaboração mais próxima precisa ser contínua, garantindo que os esforços permaneçam focados nas metas de negócios e permitindo que as equipes de desenvolvimento obtenham feedback de qualidade mais rapidamente.

Feedback de qualidade mais rápido

Os ciclos de feedback são cruciais ao alinhar os objetivos de desenvolvimento aos da estratégia de negócios. Os engenheiros só podem se mover com segurança tão rápido quanto sua compreensão de como uma mudança afeta um sistema. Portanto, quanto mais longo o ciclo de feedback, mais tempo leva para corrigir um problema. O feedback atrasado também pode resultar em supercorreção com base no feedback anterior “obsoleto”. Obter feedback positivo e negativo sobre o processo de desenvolvimento de software permite que as equipes de desenvolvimento de software entendam o impacto que seu trabalho tem sobre os objetivos de negócios, permitindo que criem eficiência na direção certa.

Aproveitar a tecnologia deve ser simples. Como novas tecnologias surgem todos os dias, um diferencial de negócios hoje pode ser uma commodity amanhã. É essencial ter a capacidade de alavancar constantemente novas tecnologias para manter o foco no que é exclusivo do negócio. 

Quais técnicas existem para permitir que as empresas aproveitem a nova tecnologia?

Aqui estão alguns exemplos de como a nova tecnologia pode aprimorar os recursos de negócios:

• Usando a estratégia nativa da nuvem para aproveitar a capacidade de escalar e ser flexível
• A arquitetura sem servidor cria uma maneira de criar e executar aplicativos sem precisar gerenciar a infraestrutura
• A integração de terceiros permite a integração com tecnologias mais recentes sem ter que se preocupar com o tempo e custo de desenvolvimento
• Usar a conteinerização é uma alternativa à virtualização; ela evolui encapsulando ou compactando o código do software e todas as suas dependências para que possa ser executado de maneira uniforme e consistente em qualquer infraestrutura.
• Ter a capacidade de aumentar ou diminuir a capacidade (conhecido como dimensionamento elástico). Mais importante em ambientes de nuvem, quando é necessário atender a demandas crescentes quando necessário.
• Aproveitar o poder da automação aumenta a eficiência e alcança ou mantém uma vantagem competitiva por meio da redução de erros e despesas.
• Ao gerenciar e provisionar a infraestrutura como código em vez de processos manuais, você pode obter a vantagem de um tempo mais rápido de produção e comercialização, ajudando a empresa a ser a primeira em um cenário competitivo, com consistência aprimorada e menos configuração durante o rascunho.
• A utilização de bancos de dados gerenciados permite que a empresa se beneficie do monitoramento contínuo e do dimensionamento automatizado fornecidos pelo provedor de banco de dados
• Os frameworks modernos criam uma estrutura de suporte conceitual e tecnológico definida com módulos específicos que podem servir de base para o desenvolvimento de novos softwares

Como alavancar a tecnologia pode alcançar o sucesso nos negócios? - Os benefícios

Vantagem competitiva

Estamos no meio de uma revolução digital nas últimas décadas, e as empresas que a abraçaram totalmente foram algumas das que obtiveram um grande sucesso. A necessidade de acompanhar a revolução digital está diretamente ligada à complexidade e necessidade de velocidade do ambiente atual. As organizações que continuarem a adotar novas tecnologias se prepararão para melhor atender às necessidades de clientes e acionistas.

Michael Porter, da Harvard Business Review, diz que “a nova tecnologia muda a natureza da competição”, alterando a estrutura da indústria e, ao fazê-lo, alterando as regras da concorrência; criar vantagem competitiva ao oferecer às empresas novas maneiras de superar seus rivais; e gerando negócios totalmente novos, muitas vezes de dentro das operações existentes de uma empresa.

Redução de custos

O negócio é sobre o gerenciamento de custos. Muitas vezes, é um ato de equilíbrio delicado entre manter os custos baixos e maximizar os ganhos. A tecnologia desempenha um papel crucial no gerenciamento de custos por meio da melhoria da eficiência operacional: redução de perdas, menos erros e gastos aprimorados. Novos avanços tecnológicos apenas aumentaram essa eficiência operacional, permanecendo a chave para a redução de custos.

Os serviços de nuvem gerenciados ajudam a reduzir o custo do software, incluindo manutenção, migração, monitoramento e otimização. Isso permite que processos sejam aliviados, como backups em nuvem e manutenção de infraestrutura em nuvem, aliviando a carga de trabalho da equipe interna para se concentrar em tarefas mais críticas. 

Atualização tecnológica

Em vez de usar sistemas até que eles não possam mais funcionar com eficiência, as empresas podem optar por atualizar ou substituir a infraestrutura regularmente, esse processo é conhecido como "atualização de tecnologia".

A manutenção da infraestrutura legada pode ser cara, com tecnologia de data center desatualizada levando a desempenho lento, ineficiências e sobrecarga administrativa. Eficiência energética, taxas de falha e possíveis custos de tempo de inatividade são formas de justificar atualizações regulares de hardware.

Mitigação do fim de vida

Nem tudo foi construído para durar para sempre, e essa é frequentemente a realidade do software. A maioria das empresas procura substituir seus serviços de software regularmente quando, com o tempo, param de atender o cliente com eficiência, tornam-se lentas para mudar, param de receber atualizações do sistema ou perdem a garantia (conforme mencionado na atualização de tecnologia).

Quando os servidores param de emitir atualizações e patches, o software ou as plataformas se tornam mais vulneráveis a ameaças de segurança. E as ferramentas de terceiros geralmente não são compatíveis. Alguns dos perigos do fim da vida são os seguintes:

• Vulnerabilidades de segurança
• Incompatibilidade de software
• Problemas de conformidade
• Altos custos operacionais
• Baixo desempenho e confiabilidade

O resultado positivo é que, ao aproveitar a nova tecnologia, o fim da vida útil geralmente não é um problema, pois o software e as plataformas são atualizados ou substituídos antes desse estágio.

A inovação contínua só é possível quando suportada por um software bem desenhado e flexível. Para inovar, as empresas precisam ser capazes de experimentar. Portanto, para alcançar experimentos adequados à inovação, eles precisam ser relativamente fáceis de concluir a um custo baixo. Os sistemas devem ser inicialmente projetados para que os experimentos possam ser independentes e concluídos com o mínimo de impacto nos negócios como de costume.

As empresas precisam ter um software que permita a inovação para acompanhar as demandas dos consumidores e garantir que possam competir em um mercado exigente. O artigo a seguir destaca como uma empresa pode oferecer suporte à criação de software flexível e bem projetado, adequado para inovação, dividido em produto, processo e implementação.

Produto

Criando uma mentalidade de start-up para utilizar loops de feedback rápidos

Lean start-up é uma metodologia de desenvolvimento de negócios e produtos que visa encurtar os ciclos de desenvolvimento de produtos. Essa metodologia de negócios enfatiza o feedback do cliente sobre a intuição e a flexibilidade sobre o planejamento. Em uso, as empresas podem se recuperar de falhas com mais frequência do que durante as formas tradicionais de desenvolvimento de produtos, reduzindo o risco de mercado e evitando a necessidade de lançamentos de produtos caros e deficiências financeiras.

As empresas só podem se mover tão rápido quanto o software de qualidade pode ser entregue. Criar mudanças sustentáveis é fazer mudanças eficientes e mais seguras. Todos os pontos a seguir contribuem para otimizar a implementação de software para mudanças sustentáveis.

Criando Desenvolvimento de Software Sustentável

O que isso significa em termos empresariais? À medida que o ritmo da inovação aumenta nas empresas em todo o mundo, o tempo de vida esperado de aplicativos de software bem-sucedidos precisa aumentar com isso. A tecnologia e o software devem ser fáceis de mudar em ritmo paralelo à inovação. O desenvolvimento sustentável tem a ver com eficiência e equilíbrio entre as necessidades de curto e longo prazo.

Utilizando a arquitetura modular e alinhada com o negócio

A modularidade do software é a decomposição de um programa em programas menores com interfaces padronizadas. À medida que as empresas competem para entregar os valores mais críticos do cliente, mais rapidamente, criando uma arquitetura modular alinhada aos objetivos de negócio, as diferentes funções de software são divididas. Isso permite que módulos separados sejam desenvolvidos rapidamente sem ficarem presos em uma teia complexa de outras funções, permitindo que as equipes evitem obstáculos para aumentar a velocidade e a mutabilidade.

Este processo é sobre ser flexível, aprimorando o software existente para atender às necessidades do negócio de forma mais sustentável. Como resultado, as empresas podem trabalhar continuamente em novos recursos, mantendo a qualidade do software existente e sem colocar em risco a confiabilidade do produto.

Sem flexibilidade, o ritmo de desenvolvimento é mais lento, com mais bugs e problemas de teste. Isso cria projetos de hardware antigos e caros e de hardware em fim de vida, impactando a abordagem sustentável para o desenvolvimento de software.

Processos ágeis (práticas XP)

A programação extrema (XP) é uma das estruturas ágeis, sendo sua principal característica a ênfase nos aspectos técnicos do desenvolvimento de software. Introduzido por Ken Beck et al na década de 90, o objetivo é criar software de alta qualidade rapidamente, adaptável e, portanto, sustentável. XP é um dos métodos de engenharia de software mais populares dentro da metodologia Agile. Algumas das principais práticas desse método são:

#1 – Programação em Par

Programação em Par é quando dois (possivelmente mais) engenheiros trabalham lado a lado para desenvolver o código juntos. Essa prática visa otimizar a qualidade e promover a comunicação da equipe.

Leia mais para entender como a Programação em Par funciona: https://www.codurance.com/publications/should-i-use-pair-programming

#2 - Padrões de Codificação

Os projetos que carecem de um conjunto padrão de regras sofrem de falta de consistência e aumentam a probabilidade de problemas técnicos e defeitos. Dentro de qualquer projeto isso gera ineficiência, fazendo com que a implantação se torne insustentável.

Entenda mais sobre por que escrever um código de qualidade é importante: https://www.codurance.com/publications/2020/09/29/is-it-even-possible-to-deliver-software-compliant-fast-and-correctly/

#3 – Ritmo Sustentável

Um dos princípios fundamentais do Manifesto Ágil é respeitar o equilíbrio entre vida profissional e pessoal das equipes e incentivar o desenvolvimento sustentável, o que aumenta o moral e a qualidade do produto. O XP reforça esse valor para maximizar a eficácia da equipe.

#4 – Desenvolvimento dirigido por testes (TDD)

O XP afirma que os testes de unidade devem ser escritos antes do código, o que é uma prática com a qual muitas organizações não estão acostumadas. No entanto, o processo de TDD exige que os testes sejam escritos junto com o código de produção em um loop iterativo e restrito, garantindo que a alteração do código seja continuamente verificada por testes automatizados.

Saiba mais sobre TDD:

https://www.codurance.com/publications/2018/05/26/should-we-always-use-tdd-to-design

 https://www.codurance.com/publications/2015/05/12/does-tdd-lead-to-good-design

XP oferece práticas que podem beneficiar a maioria das equipes de software na criação de uma abordagem estruturada para a entrega de software. Cria uma cultura de eficiência e código bem elaborado que se adapta ao futuro.

Cultura DevOps de processos estáveis e repetíveis

A cultura DevOps abrange aspectos técnicos, comerciais e culturais do desenvolvimento. Criando:

Maior velocidade e qualidade dos lançamentos de produtos. A cultura DevOps acelera o lançamento do produto introduzindo entrega contínua, incentivando um feedback mais rápido e permitindo que os desenvolvedores corrijam bugs durante os estágios iniciais, permitindo que as equipes se concentrem na qualidade do software.

Resposta mais rápida às necessidades do negócio. As equipes podem reagir a solicitações de alteração mais rapidamente, adicionando novos recursos e atualizando os existentes.

Melhor ambiente de trabalho. Os princípios do DevOps levam a uma melhor comunicação entre os membros da equipe. Criando maior produtividade e agilidade, muitas vezes sendo considerados mais produtivos e com habilidades cruzadas.

Forte ênfase na qualidade do código

A qualidade do código costuma ser considerada um elemento abstrato que não afeta os resultados. No entanto, na realidade, uma codificação incorreta pode prejudicar o desempenho do produto, afetando negativamente a eficiência. Um impacto semelhante é criado com cantos de corte. Para que o código seja atualizado paralelamente à inovação, o código deve estar correto em primeira instância.

A manutenibilidade é uma das causas mais frequentes de falta de sustentabilidade ao trabalhar em código escrito por outros indivíduos. Para criar alterações e extensões, o código precisa ser adaptável e legível.

À medida que as empresas crescem, o software também e, dentro disso, o código associado. Se o código não for criado com qualidade para escalar, ele pode falhar catastroficamente nesses pontos de pressão, prejudicando os objetivos de negócios.

A capacidade de uma empresa de atingir seus objetivos geralmente está centrada na receita e no lucro, mas entender como os níveis de produtividade e a satisfação do funcionário se encaixam nisso pode ser a chave para o sucesso do negócio e geralmente depende em grande parte de sua cultura. Para começar a definir cultura e seu sucesso não deve ser confundido com outros aspectos de um benefício comercial, Horowiz define cultura como três coisas:

• O comportamento coletivo de todos na organização.
• O que as pessoas fazem quando não estão dando a elas uma direção.
• A maneira do Negócio fazer as coisas.

Portanto, a cultura é um reflexo do ambiente de trabalho e da liderança dentro dele.

Por que a cultura é importante para o desenvolvimento de software?

Uma cultura saudável reúne os desenvolvedores em torno de um objetivo comum, de criar código de alta qualidade, melhorando continuamente e aproveitando o processo. A cultura não é apenas fundamental para o alinhamento e eficácia do trabalho, mas para recrutar e reter talentos de alto nível.

A criação de uma boa cultura para as equipes de desenvolvimento de software pode ser alcançada por

• Proporcionando espaço para autonomia e domínio
• Criação de um senso de propósito
• Treinamento Contínuo
• Coaching e mentoria
• Comunidades internas de prática
• Engajamento com comunidades externas

Embora a cultura de uma empresa geralmente seja definida pelos comportamentos, as ações implementadas podem criar a trajetória para um ambiente de trabalho bem-sucedido.

Usando tecnologia moderna e atraente

Há duas seções para este ponto de ação, a primeira focando na progressão na carreira e na motivação dentro de uma equipe de desenvolvimento de software. O ritmo da inovação na indústria de software é exponencial e, para as empresas, o foco é obter vantagem competitiva por meio de conhecimento coletivo, experiência e criatividade. Portanto, a busca por atrair funcionários com um conjunto de habilidades modernas e inovadoras nunca foi tão importante. As equipes também são mais atraídas para trabalhar em novas técnicas e tecnologias modernas que têm uma vida útil mais longa, em vez de atualizar continuamente o software legado.

A segunda se enquadra na expectativa do negócio. Dar aos funcionários acesso às ferramentas e tecnologias de que precisam para realizar seu trabalho e deixá-los trabalhar da maneira que funcionar melhor para que sejam mais eficientes. Se os sistemas administrativos forem lentos e ineficientes, isso pode afetar a moral dos indivíduos. Sem as ferramentas para realizar tarefas administrativas com eficiência, isso afeta a produtividade em outros lugares.

Treinamento Contínuo 

É relatado que empresas com culturas de aprendizado contínuo têm uma produtividade 37% maior e 92% mais chances de inovar.

No entanto, esse caminho de cultura não é apenas fornecer oportunidades de aprendizado, mas criar uma verdadeira mudança, para permitir que a força de trabalho assuma todo o potencial que o treinamento tem a oferecer, para fornecer tempo e expectativas.

Focando, especialmente na cultura de aprendizagem contínua, um conjunto de valores e práticas que estimulam os indivíduos (e o negócio como um todo) a aumentar continuamente o conhecimento, a competência, o desempenho e a inovação. Isso é alcançado por meio do compromisso com a melhoria contínua e da promoção de uma cultura de inovação.

Coaching e mentoria 

Uma cultura de coaching e mentoria é um estilo de gerenciamento e trabalho em conjunto com o compromisso de fazer crescer o negócio e as pessoas no negócio. Abrange não apenas habilidade e desempenho, mas o desenvolvimento de cada indivíduo e sua carreira.

Pode ajudar as equipes a trabalhar juntas em direção a um objetivo comum, criando o hábito de desafiar um processo ou suposição. Também acelerando a transferência de conhecimento.

Ao criar essa cultura nas equipes de desenvolvimento de software, ela ajuda a reduzir a rotatividade de talentos, melhorando o envolvimento dos funcionários e o comprometimento com o trabalho para contribuir com o desempenho individual e da equipe.

Comunidades internas de prática (CoP)

Uma comunidade de prática é um grupo de pessoas que compartilham uma preocupação comum ou interesse em um tópico. Grupos se reúnem para cumprir objetivos individuais e de grupo.

Dentro das equipes de desenvolvimento de software, ao ter CoPs internas, pessoas que normalmente não colaborariam (se estiverem em equipes ou projetos diferentes) podem ser conectadas. Isso incentiva o compartilhamento de informações e experiências em todo o negócio. A coordenação entre todos os membros do negócio permite a resolução de problemas, a partilha de boas práticas e muitas vezes ajuda a remover quaisquer bloqueios no processo.

Essa comunicação aumenta o compartilhamento de conhecimento e ajuda a melhorar a cultura de coaching e mentoria.

Engajamento com comunidades externas

Grande parte de todas as técnicas citadas tem acesso ao conhecimento e aprendizado, o que continua com o engajamento com as comunidades externas. Muitas vezes, uma empresa não tem todas as respostas, e é por isso que incentivar o envolvimento fora da empresa apenas ajuda a aumentar o compartilhamento e o desenvolvimento do conhecimento. Ser capaz de conversar sobre problemas, objetivos de carreira ou novas tecnologias com novas pessoas aumenta a satisfação e melhora a taxa de retenção de funcionários. Também permite que funcionários experientes posicionem seu próprio conhecimento dentro da comunidade de software.

Comunicar-se externamente também aumenta a taxa de atração de novos talentos. 

Criar uma cultura de negócios na qual os funcionários se sintam felizes em trabalhar, não apenas ajuda na retenção, mas, como mencionado acima, oferece um espaço para trabalho eficaz, crescimento da produtividade e iniciativa para inovação. Portanto, a cultura se torna importante na modernização do software, pois é a chave para ajudar os desenvolvedores a trabalhar em direção a um código de maior qualidade e um ambiente de trabalho onde todos se esforçam para melhorar continuamente. Garantir que o software e os funcionários evoluam com o negócio, em vez de trabalhar como sempre funcionou.