Juliana Ribeiro

O Google é uma empresa multinacional de serviços online e software dos Estados Unidos. Principal subsidiária da Alphabet, ela hospeda e desenvolve uma série de serviços e produtos baseados na internet e gera lucro, principalmente, por meio da publicidade pelo AdWords. A empresa foi fundada por Larry Page e Sergey Brin em 4 de setembro de 1998, a missão declarada da empresa desde o início foi “Organizar a informação mundial e torná-la universalmente acessível e útil”.

Com o rápido crescimento da empresa, muitas práticas foram adotadas para o desenvolvimento de software. Este resumo irá falar sobre tais práticas com base no artigo de Fergus Henderson “Software Engineering at Google”.

Desenvolvimento de Software

• The Source Repository

A maior parte do código do Google é armazenada em um único repositório de código-fonte unificado e é acessível a todos os engenheiros de software do Google. Existem algumas exceções notáveis, particularmente os dois grandes projetos de código aberto Chrome e Android, que usam repositórios separados de código aberto. O acesso de gravação ao repositório é controlado: apenas os proprietários listados de cada subárvore do repositório podem aprovar alterações nessa subárvore. Culturalmente, os engenheiros são incentivados a consertar qualquer coisa que vejam que esteja quebrada e saibam como consertar, independentemente dos limites do projeto.

• The Build System

O Google usa um sistema de compilação distribuído conhecido como Blaze, que é responsável por compilar e vincular software e para executar testes.

Os programadores escrevem arquivos “BUILD” que o Blaze usa para determinar como construir seu software. Entidades de compilação, como bibliotecas, programas e testes, são declaradas usando especificações de compilação declarativas. Isso possibilita a construção rápida de programas extremamente grandes ou a execução de milhares de testes em paralelo. A seguir algumas vantagens do sistema:

1. Etapas de construção individuais devem ser “herméticas”: elas dependem apenas de suas entradas declaradas.
2. As etapas de construção individuais são determinísticas. Como consequência, o sistema de compilação pode armazenar em cache os resultados da compilação.
3. O sistema de compilação é confiável.
4. Os resultados da compilação são armazenados em cache “na nuvem”. 
5. Reconstruções incrementais são rápidas.
6. Pré-enviar cheques.

• Code Review

Quando o autor de uma alteração inicia uma revisão de código, os revisores são notificados por e-mail, com um link para a página da ferramenta de revisão da Web dessa alteração. As notificações por email são enviadas quando os revisores enviam seus comentários de revisão. Todas as alterações no repositório principal do código-fonte devem ser revisadas por pelo menos um outro engenheiro.

• Testing

O teste unitário é fortemente incentivado e amplamente praticado no Google. Espera-se que todo o código usado na produção tenha testes de unidade, e a ferramenta de revisão de código destaca-se, se os arquivos de origem foram adicionados sem os testes correspondentes. Espera-se que as equipes produzam uma tabela ou gráfico mostrando como as principais métricas, principalmente latência e taxa de erro, variam com a taxa de solicitações recebidas.

• Bug tracking

O Google usa um sistema de rastreamento de bugs chamado Buganizer para rastrear problemas: bugs, solicitações de recursos, problemas de clientes e processos (como lançamentos ou esforços de limpeza).

É comum (embora não universal) que as equipes do Google verifiquem regularmente os problemas em aberto em seus componentes, priorizando-os e, quando apropriado, atribuindo-os a engenheiros específicos. Algumas equipes têm um indivíduo específico responsável pela triagem de bugs, outras fazem a triagem de bugs em suas reuniões regulares de equipe.

• Programming languages

As linguagens de programação oficialmente aprovadas no Google: C + +, Java, Python, Go ou JavaScript. O google possui guias de estilo para cada idioma, para garantir que o código em toda a empresa seja escrito com estilo, layout, convenções de nomenclatura semelhantes, etc.

Treinamento  de legibilidade : Engenheiros experientes treinam outros engenheiros em como escrever código legível e idiomático em um idioma específico.

• Debugging and Profiling tools

Os servidores do Google estão vinculados a bibliotecas que fornecem várias ferramentas para depurar servidores em execução.

Existem também interfaces da web para depuração que permitem examinar RPCs de entrada e saída (incluindo tempo, taxas de erro, limitação de taxa, etc.), alterar valores de sinalizadores de linha de comando (por exemplo, para aumentar a verbosidade de log para um módulo específico), consumo de recursos, criação de perfil , e mais. Essas ferramentas aumentam muito a facilidade geral de depuração a ponto de ser raro iniciar um depurador tradicional,como o gdb.

• Release engineering

Os lançamentos são feitos com frequência para a maioria dos softwares. Lançamentos semanais ou quinzenais são um objetivo comum, e algumas equipes até lançam diariamente. Isso é possível automatizando a maioria das tarefas normais de engenharia de lançamento.

• Launch approval

O lançamento de qualquer alteração visível ao usuário ou alteração significativa no projeto requer aprovações de várias pessoas fora da equipe principal de engenharia que implementa a alteração. Além disso, aprovações são necessárias para garantir que o código esteja em conformidade com os requisitos legais, requisitos de privacidade, requisitos de segurança, requisitos de confiabilidade , requisitos de negócios, e etc.

• Post-mortems

Sempre que houver uma interrupção significativa de qualquer um de nossos sistemas de produção, ou contratempo semelhante, as pessoas envolvidas são obrigadas a redigir um documento post-mortem. Este documento descreve o incidente, incluindo título, resumo, impacto, cronograma, causa(s) raiz, o que funcionou/o que não funcionou e itens de ação. Com isso, o foco está nos problemas e como evitá-los no futuro, não nas pessoas ou na atribuição de culpa.

• Frequent rewrites

A maioria dos softwares do Google é reescrito a cada poucos anos.  Reescrever o código elimina toda a complexidade acumulada desnecessária que estava abordando requisitos que não são mais tão importantes. Reescrever o código é uma forma de transferir conhecimento e um senso de propriedade para os membros mais novos da equipe. Reescritas frequentes também incentivam a mobilidade de engenheiros entre diferentes projetos, o que ajuda a estimular a polinização cruzada de ideias e ajudam a garantir que o código seja escrito usando tecnologia e metodologia modernas.

Gerenciamento de Projetos

Os engenheiros podem gastar até 20% de seu tempo trabalhando em qualquer projeto de sua escolha, sem precisar da aprovação de seu gerente ou de qualquer outra pessoa. Isso permite que qualquer pessoa com uma boa ideia, mesmo que seja uma ideia que outros não reconheceriam imediatamente como valendo a pena, tenha tempo suficiente para desenvolver um protótipo, demonstração ou apresentação para mostrar o valor de sua ideia.

• Objectives and Key Results (OKRs)

Indivíduos e equipes do Google precisam documentar explicitamente suas metas e avaliar seu progresso em relação a elas. As equipes definem objetivos trimestrais e anuais, com resultados-chave mensuráveis que mostram o progresso em direção a esses objetivos.

No final de cada trimestre, o progresso em direção aos principais resultados mensuráveis é registrado e cada objetivo recebe uma pontuação de 0,0 (sem progresso) a 1,0 (100% de conclusão). Os resultados não são usados diretamente como entrada para a avaliação de desempenho de um indivíduo.

• Project approval

Embora exista um processo bem definido para aprovações de lançamento, o Google não possui um processo bem definido para aprovação ou cancelamento de projetos.

Isso ocorre porque a abordagem não é uniforme em toda a empresa. Os gerentes em todos os níveis são responsáveis pelos projetos em que suas equipes trabalham e exercem sua discrição como acharem melhor.

• Corporate reorganizations

Uma decisão executiva é tomada para cancelar um grande projeto e, então, os muitos engenheiros que estavam trabalhando nesse projeto podem ter que encontrar novos projetos em novas equipes. No caso de desfragmentação, também podem ter a opção de permanecer na mesma equipe e projeto, movendo-se para um local diferente.

Gestão de pessoas

• Engineering Manager

Engenheiro de Software, podem gerenciar pessoas, mas Gerentes de Engenharia sempre gerenciam pessoas. Há uma distinção entre liderança técnica e gestão de pessoas.

Gerentes de Engenharia não necessariamente lideram projetos; os projetos são liderados por um líder técnico,que pode ser um gerente de engenharia, mas geralmente é um engenheiro de software.

• Research Scientist

Os cientistas de pesquisa do Google geralmente trabalham ao lado de engenheiros de software, as mesmas equipes e trabalhando nos mesmos produtos ou na mesma pesquisa. Essa prática de incorporar a pesquisa na engenharia contribui muito para a facilidade com que novas pesquisas podem ser incorporadas ao transporte de produtos.

• Product Manager

Os Gerentes de Produto são responsáveis pelo gerenciamento de um produto.

• Program Manager / Technical Program Manager

Os gerentes de programa têm uma função amplamente semelhante ao gerente de produto, mas em vez de gerenciar um produto, eles gerenciam projetos, processos ou operações (por exemplo, coleta de dados).

Instalações

O Google é famoso por suas instalações divertidas, com recursos como escorregadores, piscinas de bolinhas e salas de jogos. Isso ajuda a atrair e reter bons talentos.

Treinamento

Novos Googlers (“Nooglers”) têm um curso de treinamento inicial obrigatório. O Google oferece aos funcionários uma variedade de cursos de treinamento on-line e presenciais.  O Google também oferece suporte para estudar em instituições externas.

Transferências

As transferências entre diferentes partes da empresa são incentivadas, para ajudar a disseminar conhecimento e tecnologia por toda a organização e melhorar a comunicação entre organizações.

Avaliação de desempenho e recompensas

O feedback é fortemente encorajado no Google. Os engenheiros podem dar um feedback positivo explícito uns aos outros por meio de “bônus de pares” e “kudos”.

Qualquer funcionário pode nomear qualquer outro funcionário para um “bônus de pares” – um bônus em dinheiro de US$ 100 – até duas vezes por ano. Os funcionários também podem dar “kudos”, declarações formalizadas de elogio que fornecem reconhecimento social explícito pelo bom trabalho, mas sem recompensa.

Referências

1. Henderson, Fergus. Software Engineering at Google. 31 de janeiro de 2017
2. Google Imagens
3. https://www.infoq.com/br/news/2019/10/google-software-engineering/