book

Engenharia de software na Google

by Titus Winters, Tom Manshreck, Hyrum Wright

April 2025

Intermediate to advanced

602 pages

20h 40m

Portuguese (Portugal, Brazil)

O'Reilly Media, Inc.

Audiobook available

Read now

Unlock full access

Programação ao longo do tempoA perspetiva da GoogleO que este livro não éObservações finaisConvenções utilizadas neste livroAprendizagem em linha da O'ReillyComo contactar-nosAgradecimentos
Tempo e mudançaLei de HyrumExemplo: Ordenação de HashPorque não tentas apenas "nada muda"?Escala e eficiênciaPolíticas que não têm escalaPolíticas com boa escalaExemplo: Atualização do compiladorDesloca-te para a esquerdaSoluções de compromisso e custosExemplo: MarcadoresInputs para a tomada de decisõesExemplo: Compilações distribuídasExemplifica: Decidir entre tempo e escalaRever decisões, cometer errosEngenharia de software versus programaçãoConclusãoTL;DRs
Ajuda-me a ocultar o meu códigoO mito do génioEsconder-se é considerado prejudicialDeteção precoceO fator autocarroRitmo de progressoEm suma, não te escondasO que importa é a equipaOs três pilares da interação socialPorque é que estes pilares são importantes?Humildade, respeito e confiança na práticaCultura Post-Mortem sem culpaSeres engraçadinhoConclusãoTL;DRs
Desafios à aprendizagemFilosofiaPrepara o terreno: Segurança psicológicaMentoriaSegurança psicológica em grandes gruposAumenta os teus conhecimentosFaz perguntasCompreende o contextoDimensionar as tuas perguntas: Pergunta à comunidadeConversas de grupoListas de correioYAQS: Plataforma de perguntas e respostasAumenta os teus conhecimentos: Tens sempre algo para ensinarHorário de expedientePalestras e aulas sobre tecnologiaDocumentaçãoCódigoAumentar o conhecimento da tua organizaçãoCultivar uma cultura de partilha de conhecimentosEstabelecimento de fontes de informação canónicasMantém-te informadoLegibilidade: Mentoria padronizada através da revisão do códigoO que é o processo de legibilidade?Porquê este processo?ConclusãoTL;DRs
O preconceito é o padrãoCompreender a necessidade de diversidadeDesenvolver a capacidade multiculturalTornar a diversidade acionávelRejeita abordagens singularesDesafia os processos estabelecidosValores versus resultadosMantém a curiosidade, avançaConclusãoTL;DRs
Gestores e responsáveis técnicos (e ambos)O Diretor de EngenhariaO líder técnicoO Gestor Principal TécnicoPassar de um papel de colaborador individual para um papel de liderançaA única coisa a temer é... bem, tudoLiderança ServidoraO Diretor de EngenhariaGerente é uma palavra de quatro letrasO Diretor de Engenharia de hojeAntipadrõesAntipadrão: Contrata pessoas que te empurramAntipadrão: Ignora os que têm baixo desempenhoAntipadrão: Ignora as questões humanasAntipadrão: Sê amigo de toda a genteAntipadrão: Compromete a barra de contrataçãoAntipadrão: Trata a tua equipa como criançasPadrões positivosPerde o EgoSê um Mestre ZenSê um catalisadorElimina os obstáculosSê um professor e um mentorDefine objetivos clarosSê honestoSegue a FelicidadeA pergunta inesperadaOutras dicas e truquesAs pessoas são como as plantasMotivação intrínseca versus motivação extrínsecaConclusãoTL;DRs
Toma sempre uma decisãoA parábola do aviãoIdentifica os óculosIdentifica as principais soluções de compromissoDecide e depois repeteVai sempre emboraA tua missão: Constrói uma equipa "Self-DrivingDividir o espaço do problemaEscala sempreO ciclo do sucessoImportante versus UrgenteAprende a largar bolasProteger a tua energiaConclusãoTL;DRs

Porque é que devemos medir a produtividade da engenharia?Triagem: Vale a pena medir?Seleção de métricas significativas com objectivos e sinaisObjetivosSinaisMétricasUtilizar dados para validar métricasTomar medidas e acompanhar os resultadosConclusãoTL;DRs
Porquê ter regras?Criar as regrasPrincípios orientadoresO guia de estiloMudar as regrasO processoOs árbitros de estiloExcepçõesOrientaçãoAplicar as regrasVerificadores de errosFormatadores de códigoConclusãoTL;DRs
Fluxo de revisão de códigoComo funciona a revisão de código no GoogleBenefícios da revisão do códigoCorreção do códigoCompreensão do códigoConsistência do códigoBenefícios psicológicos e culturaisPartilha de conhecimentosMelhores práticas de revisão de códigoSê educado e profissionalEscreve pequenas alteraçõesEscreve boas descrições de alteraçõesMantém os revisores no mínimoAutomatiza sempre que possívelTipos de revisões de códigoRevisões do código GreenfieldAlterações comportamentais, melhorias e optimizaçõesCorrecções de erros e reversõesRefatorações e alterações em grande escalaConclusãoTL;DRs
O que é que pode ser considerado documentação?Porque é que a documentação é necessária?A documentação é como o códigoConhece o teu públicoTipos de públicosTipos de documentaçãoDocumentação de referênciaDocumentos de designTutoriaisDocumentação concetualPáginas de destinoAnálises de documentaçãoFilosofia da documentaçãoQUEM, O QUÊ, QUANDO, ONDE e PORQUÊO início, o meio e o fimOs parâmetros de uma boa documentaçãoDocumentos obsoletosQuando é que precisas de redactores técnicos?ConclusãoTL;DRs
Por que escrevemos testes?A história do Google Web ServerTestes à velocidade do desenvolvimento modernoEscreve, executa, ReactBenefícios do teste de códigoConceber um conjunto de testesTamanho do testeÂmbito do testeA regra da BeyoncéUma nota sobre a cobertura de códigoTestes à escala da GoogleAs armadilhas de um grande conjunto de testesHistória dos testes na GoogleAulas de orientaçãoTeste certificadoTestes na casa de banhoTestar a cultura hojeOs limites dos testes automatizadosConclusãoTL;DRs
A importância da capacidade de manutençãoEvitar ensaios frágeisEsforça-te por fazer testes imutáveisTesta através de APIs públicasTesta o estado, não as interaçõesEscreve testes clarosTorna os teus testes completos e concisosTesta comportamentos, não métodosNão ponhas a lógica nos testesEscreve mensagens de falha clarasTestes e partilha de código: DAMP, não DRYValores partilhadosConfiguração partilhadaAjudantes partilhados e validaçãoDefinir a infraestrutura de testeConclusãoTL;DRs
O impacto das duplas de testes no desenvolvimento de softwareTesta as duplas no GoogleConceitos básicosUm exemplo de teste duploCosturasEstruturas de simulaçãoTécnicas de utilização de duplas de testeFingirAgarrarTeste de interaçãoImplementações reaisPrefere o realismo ao isolamentoComo decidir quando utilizar uma implementação realFingirPorque é que as falsificações são importantes?Quando é que as falsificações devem ser escritas?A Fidelidade das FalsificaçõesAs falsificações devem ser testadasO que fazer se um falso não estiver disponívelAgarrarOs perigos do uso excessivo de StubbingQuando é que o Stubbing é apropriado?Teste de interaçãoPrefere os testes de estado aos testes de interaçãoQuando é que os testes de interação são adequados?Melhores práticas para testes de interaçãoConclusãoTL;DRs
O que são testes maiores?FidelidadeLacunas comuns nos testes de unidadePor que não fazer testes maiores?Testes maiores no GoogleTestes maiores e tempoTestes maiores à escala da GoogleEstrutura de um grande testeO sistema em testeDados de testeVerificaçãoTipos de testes maioresTeste funcional de um ou mais binários em interaçãoTeste de navegadores e dispositivosTestes de desempenho, carga e stressTeste de configuração de implantaçãoTestes exploratóriosTestes de regressão A/BUATAnálise de Probers e CanáriosRecuperação de desastres e engenharia do caosAvaliação do utilizadorTestes grandes e o fluxo de trabalho do desenvolvedorCriação de testes de grande dimensãoExecutar testes grandesPossuir grandes ensaiosConclusãoTL;DRs
Porquê a depreciação?Porque é que a depreciação é tão difícil?Depreciação durante a conceçãoTipos de depreciaçãoDepreciação consultivaDepreciação obrigatóriaAvisos de depreciaçãoGerir o processo de depreciaçãoProprietários de processosMarcosFerramentas de depreciaçãoConclusãoTL;DRs
O que é o controlo de versões?Porque é que o controlo de versões é importante?VCS centralizado versus VCS distribuídoFonte da verdadeControlo de versões versus gestão de dependênciasGestão de sucursaisO trabalho em curso é semelhante a um ramoFiliais de desenvolvimentoLiberar filiaisControlo de versões na GoogleUma versãoCenário: Várias versões disponíveisA regra de "uma versão"(Quase) Nenhuma sucursal de longa duraçãoO que acontece com as ramificações de lançamento?MonoreposO futuro do controlo de versõesConclusãoTL;DRs
A interface de pesquisa de códigoComo é que os Googlers utilizam a pesquisa de códigos?Onde é que vais?O que é que queres?Como?Porquê?Quem e quando?Porquê uma ferramenta Web separada?EscalaConfiguração zero Vista de código globalEspecializaçãoIntegração com outras ferramentas de desenvolvimentoExposição da APIImpacto da escala na conceçãoLatência da consulta de pesquisaLatência do índiceImplementação do GoogleÍndice de pesquisaClassificaçãoSoluções de compromisso selecionadasCompleta: Repositório na cabeçaCompletude: Todos os resultados versus os mais relevantesCompletude: Cabeça versus ramificações versus todo o histórico versus espaços de trabalhoExpressividade: Token Versus Substring Versus RegexConclusãoTL;DRs
Objetivo de um sistema de construçãoO que acontece sem um sistema de construção?Mas tudo o que preciso é de um compilador!Scripts de shell para o resgate?Sistemas de construção modernosTudo se resume a dependênciasSistemas de construção baseados em tarefasSistemas de construção baseados em artefactosCompilações distribuídasTempo, escala, soluções de compromissoLidar com módulos e dependênciasUsando módulos refinados e a regra 1:1:1Minimizar a visibilidade do móduloGerir dependênciasConclusãoTL;DRs
Princípios das ferramentas de revisão de códigoFluxo de revisão de códigoNotificaçõesFase 1: Cria uma mudançaDifusãoResultados da análiseIntegração rigorosa de ferramentasEtapa 2: Reexame do pedidoFases 3 e 4: Compreender e comentar uma mudançaComentáriosCompreender o estado de uma mudançaEtapa 5: Aprovações de modificação (nota de uma modificação)Etapa 6: Comprometer-se com a mudançaApós a autorização: Acompanha o históricoConclusãoTL;DRs
Caraterísticas de uma análise estática eficazEscalabilidadeUsabilidadeLições importantes para que a análise estática funcioneConcentra-te na felicidade do programadorTornar a análise estática uma parte do fluxo de trabalho principal do desenvolvedorCapacita os utilizadores a contribuirTricorder: A plataforma de análise estática do GoogleFerramentas integradasCanais de feedback integradosSugestões de correçãoPersonalização por projetoPré-envioIntegração do compiladorAnálise durante a edição e navegação no códigoConclusãoTL;DRs
Porque é que a gestão de dependências é tão difícil?Requisitos conflitantes e dependências de diamanteImportação de dependênciasPromessas de compatibilidadeConsiderações sobre a importaçãoComo o Google lida com a importação de dependênciasGestão de dependências, em teoriaNada muda (também conhecido como o modelo de dependência estática)Versionamento semânticoModelos de distribuição agrupadosAo vivo no HeadAs limitações do SemVerO SemVer pode ter um excesso de tensãoA SemVer pode prometer demaisMotivaçõesSeleção da versão mínimaEntão, o SemVer funciona?Gestão de dependências com recursos infinitosExportação de dependênciasConclusãoTL;DRs
O que é uma mudança em grande escala?Quem lida com as LSC?Barreiras às alterações atómicasLimitações técnicasMesclar conflitosNão há cemitérios assombradosHeterogeneidadeTestesRevisão do códigoInfraestrutura LSCPolíticas e culturaPercebe a base de códigoGestão da mudançaTestesApoio linguísticoO processo LSCAutorizaçãoAltera a criaçãoFragmentação e envioLimpezaConclusãoTL;DRs
Conceitos CILoops de feedback rápidoAutomaçãoTestes contínuosDesafios da ICTeste herméticoCI na GoogleEstudo de caso da CI: Google TakeoutMas eu não posso pagar a CIConclusãoTL;DRs
Idiomas da Entrega Contínua no GoogleA velocidade é um desporto de equipa: Como dividir uma implantação em partes gerenciáveisAvaliação de alterações no isolamento: Caraterísticas de sinalizaçãoProcura o Agile: Configurar um comboio de lançamentoNenhum binário é perfeitoCumpre o teu prazo de lançamentoQualidade e foco no utilizador: Envia apenas o que é utilizadoMudar para a esquerda: tomar decisões baseadas em dados mais cedoMudar a cultura da equipa: Construir Disciplina na ImplantaçãoConclusãoTL;DRs
Domar o ambiente de computaçãoAutomatização do trabalhoContentorização e MultitenancyResumoEscrever software para computação geridaArquitetar para o fracassoLote versus doseamentoGerir o EstadoLigar a um serviçoCódigo únicoCaaS ao longo do tempo e à escalaContentores como uma abstraçãoUm serviço para governar todos elesConfiguração enviadaEscolher um serviço de computaçãoCentralização versus personalizaçãoNível de abstração: Sem servidorPúblico versus privadoConclusãoTL;DRs

Overview

Este trabalho foi traduzido com recurso a IA. Agradecemos o teu feedback e comentários: translation-feedback@oreilly.com

Atualmente, os engenheiros de software precisam de saber não só como programar eficazmente, mas também como desenvolver práticas de engenharia adequadas para tornar a sua base de código sustentável e saudável. Este livro enfatiza esta diferença entre programação e engenharia de software.

Como é que os engenheiros de software podem gerir uma base de código viva que evolui e responde às mudanças de requisitos e exigências ao longo da sua vida? Com base na sua experiência na Google, os engenheiros de software Titus Winters e Hyrum Wright, juntamente com o escritor técnico Tom Manshreck, apresentam um olhar franco e perspicaz sobre a forma como alguns dos melhores profissionais do mundo constroem e mantêm software. Este livro aborda a cultura, os processos e as ferramentas de engenharia exclusivos da Google e a forma como estes aspectos contribuem para a eficácia de uma organização de engenharia.

Explora três princípios fundamentais que as organizações de software devem ter em mente ao conceber, arquitetar, escrever e manter o código:

Como o tempo afecta a sustentabilidade do software e como tornar o teu código resiliente ao longo do tempo
Como a escala afeta a viabilidade das práticas de software dentro de uma organização de engenharia
Quais as soluções de compromisso que um engenheiro típico precisa de fazer ao avaliar as decisões de design e desenvolvimento