Fácil de manter a cultura corporativa em palavras. No entanto, apenas algumas empresas estão explorando ativamente os poucos recursos da cultura corporativa que têm um impacto significativo na produtividade - porque isso é o mais difícil.
Para as equipes de software, a propriedade do código é um preditor essencial do bem-estar da engenharia. Neste guia prático, analisaremos exatamente como você implementa esse princípio no trabalho diário de sua equipe de desenvolvimento, para que o bem-estar de sua base de código seja mantido por si só.
Tive a sorte de encontrar alguns dos melhores desenvolvedores do mundo - no Stepsize eu trabalho com eles todos os dias. E durante as discussões sobre como a dívida técnica é criada, com os principais desenvolvedores de empresas como Skyscanner, Spotify, Palantir e outros, uma pergunta é invariavelmente levantada: propriedade.
Nas equipes em rápida interação e em rápido desenvolvimento (ou seja, nas equipes modernas), onde os desenvolvedores podem se comprometer com qualquer parte da base de código, o código é facilmente confuso e se torna um monstro semelhante ao Frankenstein. E quando as coisas pioram o suficiente, alguém deve intervir, como o Capitão Marvel, e consertar tudo com uma grande refatoração.
Para evitar essa situação, as equipes de desenvolvimento tentam seguir uma das muitas ótimas dicas de Robert S. Martin ("Tio Bob"), ou seja, as " Regras dos escoteiros ": mantenha o código em melhores condições do que era antes de você . Aqui está uma extensão gratuita para o VSCode para ajudar você a tornar isso muito mais fácil .
No entanto, apesar do nível de habilidade e dos melhores incentivos dos desenvolvedores, parece que a lei imutável do desenvolvimento de software é que a dívida técnica se acumula - até que se torne demais, e então precisamos dedicar tempo para muitas refatorações . Relutamos em aceitar isso como parte do ciclo de vida de desenvolvimento de software.
Talvez tudo se deva a falta de disciplina?
Então eu pensei antes. E então eu conheci Gareth Vizaji , o arquiteto chefe do Snyk.io , e ele me bateu com a seguinte frase:
A propriedade é o principal indicador do bem-estar da engenharia.
O que ele quis dizer com isso? E como ele pôde fazer essa afirmação?
Há uma enorme quantidade de pesquisas mostrando que, quando os membros da equipe possuem os frutos de seu trabalho, prestam contas aos gerentes e assumem a responsabilidade pelo sucesso e pelo fracasso, todo tipo de coisa boa começa a acontecer.
Infelizmente, conseguir isso na prática não é fácil. Em parte porque, aparentemente, a produtividade da engenharia não pode ser medida e as práticas modernas de desenvolvimento podem ser vistas como encorajadoras à propriedade deficiente do código em qualquer circunstância. A verdade é que até agora tem sido incrivelmente difícil medir a propriedade corretamente nas equipes de desenvolvimento ... então nem sabíamos o quão "bom" esse indicador era.
Felizmente, pesquisas científicas recentes mostraram que a propriedade do código - a melhor medida indireta da vaga noção de "propriedade" nas equipes de desenvolvimento - pode ser medida pela atividade de confirmação do Git. E este é um maravilhoso indicador principal do bem-estar da sua base de código.
As partes da base de código nas quais muitos desenvolvedores fazem alterações ficam desordenadas ao longo do tempo e as que menos pessoas trabalham normalmente estão em melhores condições. Não aceite minha palavra - pessoas boas da Microsoft estudaram isso por seu próprio exemplo.
Fonte: Estudo da Microsoft
Quase consigo ouvir alguns de vocês gritando que não querem uma situação em que apenas um desenvolvedor é a única pessoa com permissão para tocar em qualquer parte do código - essa abordagem tem efeitos colaterais terríveis. Eu entendo você, e não é isso que oferecemos.
Ouça-me até o fim.
Existem várias formas de propriedade do código adequadas para diferentes circunstâncias.
Propriedade coletiva e falta de propriedade
Propriedade coletiva é a propriedade [...] na qual o código é de propriedade conjunta, mas as responsabilidades e os cronogramas são claramente definidos. Cada membro da equipe pode trabalhar em qualquer subsistema ou serviço, se necessário.
Não propriedade - uma [...] situação em que vários desenvolvedores fazem alterações no mesmo subsistema, mas a coordenação de ações, a responsabilidade pela qualidade ou a comunicação entre equipes são mínimas. Em tais sistemas, não se deve esperar um trabalho de alta qualidade.
Fonte: Estudo da Microsoft
Você pode continuar essa partição adicionando ao heap também o código sem proprietário e a propriedade exclusiva, mas não quero perder o principal, então aqui está um gráfico mostrando o espectro de formas de propriedade do código:
A propriedade coletiva deve ser sua escolha padrão e a forma de propriedade pela qual você deve se esforçar. Observe que isso não significa que apenas um desenvolvedor da sua equipe tenha permissão para alterar o código ou que qualquer modificação do código exija sua aprovação. Isso significa apenas que é completamente claro para todos da equipe com quem ele deve discutir qualquer dúvida que tenha e que o proprietário do código provavelmente irá lidar com a revisão do código (revisão de código). Isso permitirá que todos na equipe aprimorem os padrões de escrita de código e tomem consciência de como seu próprio código foi modificado.
O proprietário é responsável pelo estado de seu código, e os gerentes devem solicitar isso a ele. Isso não significa que ele precisa ser espancado por todos os erros que vazaram em seu código; isso significa que os proprietários estão autorizados a tomar decisões sobre a qualidade do código e a dívida técnica; eles serão responsabilizados por essas decisões com métricas de suporte adicionais, como atividades de coesão e repetição (rotatividade) (para obter mais detalhes, consulte nosso artigo sobre métricas técnicas de dívida ).
A falta de propriedade, ou propriedade fraca, é o oposto da propriedade coletiva e, na maioria dos casos, essa forma de propriedade deve ser evitada. Como já mencionado (e isso pode parecer óbvio) para arquivos como package.json não ter um proprietário claramente definido, é uma situação normal. Ir a extremos não é necessário.
Código órfão
O tipo mais desagradável de falta de propriedade, uma das arestas do espectro de formas de propriedade do código. Você definitivamente não precisa dessa forma de propriedade. Evite-o a todo custo ... a menos que seja, é claro, um código que você nunca mais toque. Mas esse código é muito raro.
O código é considerado sem dono se o desenvolvedor principal parar de fazer alterações na base de código. Talvez ele tenha deixado a organização, ou talvez tenha mudado de desenvolvedores para gerentes. De qualquer forma, você tem sérios problemas - e sua base de código também.
No entanto, existe uma solução. Você precisa converter o código-fonte em qualquer outra forma de propriedade mais adequada para ele. Para evitar a aparência de qualquer código sem dono em sua base de códigos, verifique se seus planos para o caso de demissão ou encaminhamento de casos incluem a introdução de novos proprietários do código no curso dos negócios de seu antigo proprietário. Você pode facilitar a tarefa atribuindo-os automaticamente para exibir solicitações pull para alterações de código. Na ausência de tal, você pode simplesmente designar os proprietários do código como achar melhor.
Independentemente de qual método você escolher, não deixe o código sem proprietário em sua base de código. Você nunca sabe o que vai acontecer com ele se você o deixar à mercê do destino.
Propriedade exclusiva (propriedade absoluta)
Esse é o outro extremo do espectro da propriedade do código. Com ele, tudo pode ser maravilhoso e muito difícil.
O código é considerado de propriedade exclusiva quando o proprietário é o único desenvolvedor que pode fazer ou aprovar alterações no código ou quando o proprietário é, em essência, a única pessoa que já fez alterações no código no passado.
Pequenas startups geralmente se deparam com práticas semelhantes em seu trabalho. Cada desenvolvedor, como regra, é responsável por todo o histórico de um único arquivo e espera-se que a propriedade desse arquivo seja mantida. Este não é o fim do mundo; afinal, as startups têm recursos limitados e você precisa fazer certos sacrifícios. Mas se um dia o desenvolvedor mover o barramento, essa parte do código ficará sem dono. Para tais situações, você deve ter um plano de backup.
Nas grandes organizações de engenharia, um baixo " fator de barramento " pode ser um problema real, especialmente quando se trata de partes críticas da base de códigos, a rotatividade de pessoal é alta e a dívida técnica recrutada pela empresa é muito grande. Por exemplo, se você deixar um desenvolvedor que atrapalhou todo o seu sistema de pagamento configurado manualmente, você terá uma enorme dor de cabeça - caso deseje alterar seu modelo de preços ou encontre um bug em sua base de códigos que faça com que você por muitos meses, eles receberam menos dinheiro de seus maiores clientes. Então, alguém precisará se reunir e tentar entender o código para fazer alterações, ou você terá que declarar falência técnica no seu sistema de pagamento e reescrevê-lo do zero (mas antes de fazer isso, leia isso ).
Não deixe que isso aconteça com você.
No entanto, há momentos em que a propriedade exclusiva do código é aceitável ou até recomendada. Você pode querer estabelecer essa forma de propriedade para aquelas partes da base de código cuja declaração "se essa parte quebrar, podemos desistir, porque a empresa não poderá pagar salários ou iremos para a cadeia".
Nesses casos, mesmo que você deseje disseminar conhecimento sobre a parte crítica do código entre vários desenvolvedores para manter um fator de barramento suficientemente alto, provavelmente também desejará estabelecer regras que proíbam a injeção de solicitações pull sem a aprovação do proprietário exclusivo do código correspondente.
Sumário
Busque a propriedade coletiva da grande maioria dos arquivos em sua base de código (50% a 90% da propriedade do código para qualquer arquivo) e seja mais disciplinado para aumentar a propriedade do código e reduzir a dívida técnica quando necessário.
Os benefícios são os seguintes:
- Padrões de escrita de código mais altos e com manutenção adequada. Em um grupo pequeno e bem informado, é mais fácil aderir a altos padrões. Isso se aplica não apenas aos desenvolvedores que modificam seu próprio código, mas também às revisões de código escritas por seus pares e afetam as partes que eles possuem.
- Facilitar a comunicação. Propriedade explícita e clara significa que todo desenvolvedor da equipe sabe quem responderá melhor à sua pergunta.
- Refatoração mais focada e eficaz. Se você decidir pagar parte da dívida técnica, desenvolvedores fortes que possuem o código apropriado são os mais adequados para este trabalho. Use propriedade, conectividade e métricas de atividade repetitivas para descrever áreas de preocupação em sua base de código. Seus desenvolvedores usarão sabiamente seu orçamento para dívidas técnicas e nunca mais perderão tempo pagando dívidas técnicas que não valem a pena.
- O fator de barramento nunca ficará fora de controle. Você pode usar a propriedade do código para organizar o compartilhamento de conhecimento em sua organização. Se o grau de propriedade for muito alto, designe outros desenvolvedores para revisar o código e as tarefas associadas à sua alteração. Você melhorará gradualmente seus indicadores de propriedade, o que levará a um aumento na qualidade do código e a uma redução na dívida técnica.
Como tudo que realmente vale a pena, criar uma cultura de engenharia de propriedade de código (e segui-la!) Leva tempo e esforço, mas será recompensado com juros. Esse fator afeta diretamente quase qualquer bem-estar de engenharia de KPI que você possa imaginar. Incorpore-o à cultura da sua empresa e, a longo prazo, se tornará sua enorme vantagem competitiva.