A propriedade de código individual é importante? [fechadas]

Eu acredito que a posse de equipe é muito mais benéfica a longo prazo.

Você só precisa observar os dois cenários a seguir para entender por que a concentração de conhecimento em números mínimos de pessoas é menor que a ideal:

• O membro da equipe encontra um acidente infeliz
• O membro da equipe encontra melhor oportunidade de emprego

Só porque você não tem propriedade individual de seções de código, desde que você as escreveu, não significa que você ainda não terá os aspectos de "orgulho em sua criação", etc. Eu não acredito que ter equipe a propriedade diminuirá muito qualquer sentimento pessoal de propriedade do código escrito.

Por fim, a equipe é proprietária do código. Mas, por todas as razões mencionadas, designamos autores individuais para partes específicas do código. Cada autor é o principal responsável por sua parte do código e a responsabilidade secundária pelo código como um todo.

Se houver um problema com uma parte das superfícies de base de código, tento voltar para a pessoa que originalmente escreveu o código para uma correção. Naturalmente, nada impede que outros membros da equipe apliquem uma correção; Espera-se que todos os membros da equipe estejam familiarizados com o código de todos os outros. Mas nós sempre tentamos consertar o autor original primeiro. Afinal, eles escreveram o código; eles são o mais familiarizado com isso.

Eu trabalhei em ambientes de equipe que, porque as pessoas não sentiam um senso de propriedade naquilo que escreviam, não eram compelidas a escrever um código excelente, mas apenas o código médio.

Embora eu concorde com uma postura empresarial sobre razões para disseminar o conhecimento sobre o produto; a realidade é que um indivíduo concentrando seus esforços em uma determinada área de qualquer coisa, com o tempo, se tornará muito mais versado na área dada.

Ignorar isso é ignorar a ciência. Infelizmente, o cérebro é incapaz de reter tudo o que encontra. Ele lembra o que é válido e valioso em um determinado momento, e até mesmo esse armazenamento diminui com o tempo.

Eu tenderia a concordar com você que a propriedade de um módulo ou compartimento específico dentro da base de código maior geralmente produzirá melhores resultados. Alguém que sairia sem qualquer aviso impediria o sucesso? Certamente. Mas fingir que todos dentro da equipe devem ter a mesma quantidade de conhecimento com relação à base de código é ingênuo e não faz nada para melhorar o código; tenta proteger o código. Proteger o código é o papel do negócio por razões óbvias. Os esforços que uma empresa investirá para proteger o código podem se tornar prejudiciais da mesma forma.

Você não garante que todos os jogadores da sua equipe possam jogar quarterback? Eu diria que certificar-se de que o membro da equipe tenha uma participação na base de código é o mesmo que tentar fazer com que todos os jogadores da sua equipe joguem com o quarterback em um nível satisfatório ... isso não se soma. Você tem backups? Claro que você faz ... mas os membros da equipe devem ter uma identidade dentro da equipe. Acreditar que todos são iguais é pedir dor de um tipo diferente ...

Não sei se o código individual propriedade é uma boa ideia. Pelo menos não no sentido de que as pessoas possam dizer "Este é o meu código e eu farei o que eu quero com ele". Talvez seja melhor dizer que você deve ter um código individual gerentes : o código deve ser de propriedade da equipe, mas existe uma pessoa em quem a equipe delega responsabilidade e autoridade sobre ela.

A razão para isto é que, se é responsabilidade de todos, então não é responsabilidade de ninguém.

Eu defendo a propriedade da equipe sobre o indivíduo pelas seguintes razões:

• Codifique a consistência em todo o projeto
• Promove a discussão do código, o que sempre leva a soluções melhores e mais validadas
• Se um membro da equipe está doente (ou pior), uma seção inteira do código não está sujeita a atrasos
• Os membros da equipe podem trabalhar em todas as partes do projeto, o que serve para tornar a revisão de código incorporada no processo de desenvolvimento

A especialização é boa - para uma grande base de código, isso pode, a longo prazo, economizar bastante tempo de comunicação - mas a propriedade não é.

O que quero dizer é que a atitude deve ser que o time tem um bug, e ninguém deve dizer que "oh, só o X pode tocar nesse código, então não é problema meu". Se você faz parte da equipe, também é sua responsabilidade corrigir erros em toda a base de código, se puder, e fazê-lo corretamente. A pessoa X pode ser a melhor escolha para fazê-lo, mas qualquer pessoa deve fazê-lo se tiver que fazê-lo. Isso naturalmente requer que o código seja escrito de uma forma que permita e convide membros da equipe a trabalhar com ele. Ter um código deformado irá proibir isso, então busque um código simples e claro, já que isso permite que a maioria dos desenvolvedores trabalhe com ele. Você pode querer fazer uma revisão por pares para manter dessa forma.

Eu tenho que discordar de você: a propriedade da equipe de um codebase é uma opção muito melhor do que a propriedade individual.

A desvantagem óbvia para a propriedade individual é que, se algo acontecer a um funcionário (ser demitido, aposentar-se, adoecer, etc.), a menos que ele / ela tenha escrito realmente código limpo, um tempo para que alguém adote o código dessa pessoa, especialmente se eles também tiverem que gerenciar seu próprio código.

Eles também são ferramentas demais para facilitar a participação da equipe. Revisões de código, controle de origem - são coisas que estimulam o envolvimento da equipe em toda a base de código. Além disso, como você atribui uma parte específica de uma base de código a apenas uma pessoa? Você acabou de dizer que só essa pessoa pode modificar esse arquivo?

Por fim, acho que, se uma parte de uma base de código é quebrada, é muito fácil culpar a pessoa responsável por ela e isso só causa mais problemas.

Eu acho que você precisa de ambos, porque há uma tensão entre as duas abordagens.

Se, para qualquer parte do código, existe apenas uma pessoa que pode trabalhar nisso, isso é muito ruim a longo prazo para a empresa, especialmente se ela crescer, porque cada desenvolvedor se torna um ponto de falha. Por outro lado, a propriedade de código individual (esperançosamente) permite um tempo de entrega mais rápido, porque o desenvolvedor geralmente prefere essa abordagem (incentivo), porque o desenvolvedor conhece o código muito bem, etc ... Há também um problema de tempo: deve ser possível realocar os desenvolvedores em projetos específicos, dependendo das necessidades do negócio, mas se você fizer isso diariamente, isso é horrível (mesmo porque os desenvolvedores o odeiam, mas também porque o custo do switch é muito pesado e você passa a maior parte do tempo fazendo isso nada).

IMO, um papel de um gerente é encontrar um bom equilíbrio entre ambos. A revisão de código, os padrões de codificação, a padronização de um conjunto de ferramentas também devem ajudar a diminuir o problema da falha. Afinal, o principal ponto de código sustentável é abordar esse problema.

Acho que a propriedade coletiva de código é incomparavelmente melhor do que a propriedade individual de código.

Não me incomodo com o argumento do caminhão - em um modelo de propriedade individual, a perda de um proprietário é dispendiosa em termos do tempo necessário para que outra pessoa assuma o controle, mas o evento é raro o suficiente para que o custo amortizado é baixo.

Em vez disso, acho que a propriedade coletiva de código leva diretamente a um código de alta qualidade. Isto é por duas razões muito simples. Em primeiro lugar, porque a dolorosa verdade é que alguns de seus programadores não são tão bons quanto os outros, e se eles possuem código, esse código será ruim; dando aos seus melhores programadores acesso a ele, melhorá-lo. Em segundo lugar, revisão de código: se todos possuem o código, todos podem revisá-lo e melhorá-lo; até mesmo bons programadores escrevem códigos sub-par se deixados em seus próprios dispositivos.

Eu digo isso com base na experiência do meu projeto atual. Nosso objetivo é praticar a propriedade coletiva, mas há alguns pedaços do sistema que se tornaram especializados - eu e outro cara somos de fato donos do sistema de compilação, por exemplo, há um cara que está fazendo a maior parte do trabalho nos feeds de dados recebidos. , outro cara trabalhando na importação de imagens e assim por diante. Em várias dessas áreas (particularmente, tenho que confessar, na minha área!), A qualidade do código sofreu seriamente - há erros, equívocos, enganos e hacks que simplesmente não sobreviveriam à atenção de outras pessoas da equipe. / p>

Eu notei que você poderia obter alguns dos benefícios da propriedade coletiva de código, tendo a propriedade de código individual onde a propriedade de um determinado código se move entre diferentes programadores regularmente (digamos, a cada três meses ou a cada lançamento - talvez iteração?). Um equivalente de programação de rotação de culturas. Isso pode ser divertido. Eu não vou tentar por mim mesmo.

Eu não acho que a propriedade do código de equipe é tão importante quanto ter múltiplos colaboradores entenderem a arquitetura básica dos subsistemas predominantes.

Por exemplo, temos alguns caras em nossa equipe que fazem páginas administrativas para nossos produtos de servidor. Nós construímos um mecanismo de script customizado do lado do servidor para que pudéssemos chamar as funções C no servidor diretamente dos nossos scripts java ou html. Eu acho que é mais importante que nossos caras "web" entendam como usar este mecanismo oposto a ser co-proprietário dos aplicativos de páginas da web de cada um.

Acho que você assume a propriedade individual do código no momento em que o escreve e depois o entrega à equipe. Desta forma, todos assumem responsabilidade e contribuem. Todos devem corrigir uma falha de codificação que criaram. Junto com uma revisão de código, isso cria padrões mais altos. Ninguém quer o trabalho de limpar depois dos outros.

Pense mais responsabilidade e menos propriedade. Afinal, quem está escrevendo os cheques é o verdadeiro dono de qualquer maneira.

Jim, eu estou com você nesse 100%. Estou no meio da mesma batalha no meu local de trabalho - e é por isso que me deparei com a sua pergunta.

A maneira que eu vejo é: "quando todo mundo é dono, ninguém é dono disso".

Para mim, não há um fator mais importante para codificar a qualidade do que a propriedade e a responsabilidade.

Exemplo da vida real ilustra bem isso. qual você cuidaria melhor: seu gramado particular ou o parque da comunidade? Bastante óbvio.

Isso, a propósito, não precisa necessariamente ser trocado por "flexibilidade de equipe". Significa meramente que quando uma pessoa possui algo que ELE POSSA - e somente durante o dia.

Para mim, depende da dinâmica da sua equipe.

Por exemplo, se você tem uma equipe que não é unificada por padrões, revisão por pares, testes metódicos, ou se você tem uma equipe onde os níveis de competência variam muito entre os membros, pode ser bom buscar uma noção mais strong de propriedade de código com uma mentalidade modular mais caixa preta.

Faltando isso, por exemplo, sua interface cuidadosamente projetada conforme os princípios do SOLID pode ser rapidamente arruinada por alguém que nem sabe "SOLID" e quer adicionar novas funções ecléticas o tempo todo à interface para "conveniência ", por exemplo Este é, de longe, o pior.

Você também pode lidar com colegas de trabalho desleixados cuja idéia de consertar um bug é corrigir o sintoma sem entender o problema da raiz (ex: tentar responder a um relatório de falha simplesmente colocando soluções no código apenas para ocultar o erro e transferir os efeitos colaterais mortais para outra pessoa). Nesse caso, não é tão ruim quanto a sabotagem do design de interface e você pode proteger suas intenções com testes de unidade cuidadosamente construídos.

A solução ideal é fortalecer sua equipe até um ponto em que essa noção de autoria e propriedade não seja mais tão importante. A revisão por pares não se limita apenas a melhorar a qualidade do código, mas também a melhorar o trabalho em equipe. Padrões não são apenas consistência, eles melhoram o trabalho em equipe.

No entanto, há cenários em que a revisão por pares e a conformidade com todos em relação a um padrão é simplesmente impossível e trará muitos críticos inexperientes à mistura. Eu diria que muito se a propriedade do código ou da equipe tem uma prioridade mais strong será baseada na capacidade de sua equipe de realmente realizar uma revisão por pares efetiva e realmente deixar todos saindo como eles se beneficiaram dela (tanto em termos da própria revisão) , e se tornando mais próximos juntos em mentalidade e padrões como resultado). Em equipes grandes, soltas e / ou díspares, isso pode parecer sem esperança. Se o seu time pode funcionar como um "esquadrão" onde você mal sabe quem escreveu o quê, então a propriedade exclusiva começará a parecer uma noção tola.

Nesse tipo de cenários longe do ideal, essa noção de propriedade de código pode realmente ajudar. Ele está tentando compensar o pior cenário possível, mas pode ajudar se o trabalho em equipe for geralmente inútil para colocar uma cerca em torno do código de um autor. Nesse caso, está diminuindo o trabalho em equipe, mas isso pode ser melhor se o "trabalho em equipe" só levar a passos largos.