* Código proprietário * sistema: é uma maneira eficiente? [fechadas]

Como muitas dessas perguntas, acho que a resposta é:

Depende

Existem razões para acreditar que assumir a posição de que todo programador deve conhecer todas as linhas de código é equivocado.

Se assumirmos por um momento que alguém com um profundo entendimento de um trecho de código fará alterações 5 vezes mais rápidas do que alguém que não o conhece (e não um salto gigante de fé em minha experiência) e é preciso com cerca de um mês de experiência em codificação para obter uma boa compreensão de um módulo de tamanho significativo (também não razoável), então podemos executar alguns números (completamente falsos e fictícios):

• Programador A: tem uma compreensão profunda
• Programador B: nenhum

Digamos que o programador A tenha 1 unidade de trabalho por dia. Em 4 semanas de 5 dias úteis, ele pode obter 20 unidades de trabalho.

Então, o programador B, começando com 0,2 unidades de trabalho por dia e terminando com 0,96 unidades de trabalho em seu 20º dia (no 21º dia eles são tão bons quanto o programador A), realizará 11,6 unidades de trabalho no mesmo período de 20 dias. Durante esse mês, o programador B atingiu 58% de eficiência em comparação com o programador A. No entanto, agora você tem outro programador que conhece esse módulo, bem como o primeiro.

Claro, em um projeto de tamanho decente, você pode ter ... 50 módulos? Então, se familiarizar com todos eles leva cerca de 4 anos, e isso significa que o programador de aprendizado está, em média, trabalhando com eficiência de 58% comparado ao programador A ... hmmm.

Então, considere este cenário: os mesmos programadores, o mesmo projeto (A sabe tudo, e B não sabe nada disso.) Digamos que haja 250 dias úteis no ano. Vamos supor que a carga de trabalho é distribuída aleatoriamente nos 50 módulos. Se dividirmos os dois programadores uniformemente, A e B receberão 5 dias úteis em cada módulo. A pode fazer 5 unidades de trabalho em cada módulo, mas B só recebe, de acordo com minha pequena simulação do Excel, 1.4 unidades de trabalho feitas em cada módulo. Total (A + B) é 6,4 unidades de trabalho por módulo. Isso porque B passa a maior parte do tempo sem nenhuma habilidade com o módulo em que está trabalhando.

Nesta situação, é melhor ter B focado em um subconjunto menor de módulos. Se B foca em apenas 25 módulos, eles recebem 10 dias em cada, totalizando 3,8 unidades de trabalho em cada. O programador A poderia então gastar 7 dias cada nos 25 módulos em que B não está trabalhando, e 3 dias cada trabalhando nos mesmos módulos B. A produtividade total varia de 6,8 a 7 unidades por módulo, com média de 6,9, e isso é significativamente maior do que as 6,4 unidades por módulo que fizemos quando A e B espalharam o trabalho uniformemente.

À medida que reduzimos o escopo dos módulos em que o B trabalha, obtemos ainda mais eficiência (até certo ponto).

Treinamento

Eu também argumentaria que alguém que não sabe tanto sobre um módulo irá interromper a pessoa que faz muito mais do que alguém com mais experiência. Então, esses números acima não levam em conta que quanto mais tempo B gasta em código que eles não entendem, mais tempo de A eles ocupam fazendo perguntas, e algumas vezes A tem que ajudar a consertar ou solucionar o que B fez. Treinar alguém é uma atividade demorada.

Solução ideal

É por isso que acho que a solução ideal deve ser baseada em perguntas como:

• Qual é o tamanho do seu time? Faz sentido ter todo mundo treinado em todas as partes, ou se temos uma equipe de 10 pessoas, podemos apenas garantir que cada módulo seja conhecido por pelo menos 3 pessoas? (Com 10 programadores e 50 módulos, cada programador precisa conhecer 15 módulos para obter uma cobertura de 3x.)
• Como está sua rotatividade de funcionários? Se você está entregando os funcionários em média a cada três anos, e leva mais tempo do que isso para realmente conhecer todos os cantos do sistema, eles não estarão por perto o tempo suficiente para que o treinamento se pague de volta.
• Você realmente precisa de um especialista para diagnosticar um problema? Muitas pessoas usam a desculpa, "e se essa pessoa sair de férias", mas eu fui chamado várias vezes para diagnosticar um problema em um sistema que eu não tive nenhuma experiência. Pode ser verdade que a pessoa experiente poderia encontrá-lo muito mais rápido, mas isso não significa que você não pode viver sem eles por uma semana ou duas. Poucos sistemas de software são tão importantes que o problema precisa ser diagnosticado em 1 hora em vez de 5 horas ou o mundo terminará. Você tem que pesar esses riscos.

É por isso que penso "depende". Você não quer dividir 20 módulos entre dois programadores no meio (10 cada), porque então você não tem flexibilidade, mas você também não quer cruzar train 10 programadores em todos os 50 módulos porque você perde muito eficiência e você não precisa de muita redundância.

É uma ideia terrível . Pode ser mais rápido a curto prazo, mas encoraja códigos difíceis de entender, já que apenas o programador que os escreveu é responsável por mantê-los. Quando alguém sai da empresa ou sai de férias, todo o plano se estraga. Também torna muito difícil alocar cargas de trabalho; o que acontece quando dois bugs urgentes aparecem com o código que um codificador "possui"?

Você deve codificar como uma equipe . Naturalmente, as pessoas receberão tarefas e se concentrarão em determinadas áreas, mas compartilhar a carga de trabalho e trabalhar juntas devem ser encorajadas, e não desencorajadas.

Depende de qual é o domínio do problema.

Se for algo geral (ou seja, ações simples do CRUD, etc), então eu concordo com o Tom Squires (qualquer um deve poder trabalhar nele e editá-lo).

No entanto ...

Se a solução em questão exigir conhecimento de domínio (muito tempo foi investido no passado ou muita pesquisa precisa ser feita antes da implementação, pois isso é algo que você listaria em um requisito de trabalho como conhecimento especializado que nem todos no projeto têm), então um proprietário deve definitivamente ser atribuído a essa parte do código. Dito isto, qualquer um deve ser capaz de modificá-lo conforme necessário, mas deve sempre ser revisado pela pessoa que possui essa área do projeto.

Você não quer ter toda a sua equipe (ou um número de pessoas na equipe) pesquisando e aprendendo o mesmo assunto (ciclos desperdiçados). Designe um dono, mas faça com que ele documente seus aprendizados e projetos, e talvez faça com que eles conduzam sessões de treinamento informais (ou formais, não importa) sobre a tecnologia.

Esta é uma ideia horrível . Eu trabalhei em uma empresa que usou essa abordagem e é praticamente uma receita para montes de dívida técnica . A conclusão é que duas cabeças quase sempre são melhores que uma. Por quê? Porque a menos que você seja um idiota, você sabe que não é um programador perfeito e não vai pegar todos os erros que cometer. É por isso que você precisa de uma equipe - mais olhos olhando o mesmo código de diferentes perspectivas.

Tudo se resume a uma coisa: disciplina . Quantos programadores solitários você conhece que são verdadeiramente disciplinados em seu estilo de codificação? Quando você não codifica com disciplina, você toma atalhos (porque você vai "consertar depois") e a manutenção do código sofre. Todos sabemos que "depois" nunca chega. Fato : é mais difícil aceitar atalhos quando você é imediatamente responsável por seus colegas em uma equipe. Por quê? Porque suas decisões serão questionadas e é sempre mais difícil justificar os atalhos. Resultado final? Você produz um código melhor e mais sustentável que também é mais robusto.

A vantagem é que nem todo mundo precisa pesquisar e entender tudo. A desvantagem é que isso torna cada pessoa necessária para sua própria área de código, e ninguém mais sabe como mantê-la.

Um compromisso seria ter pelo menos dois proprietários para cada área de código. Então alguém pode sair de férias, aceitar um novo emprego ou se aposentar, e ainda há alguém que conhece o código (e pode treinar a nova segunda pessoa). Nem todo mundo precisa aprender tudo, o que é um pouco mais eficiente.

Não tenha as mesmas 2 (ou 3) pessoas trabalhando juntas o tempo todo. Alterne os pares para diferentes áreas, para que o conhecimento também seja compartilhado inadvertidamente ao trabalhar com uma pessoa diferente em uma área de programa relacionada.

Sim, é um pouco mais eficiente no curto prazo. E aí termina os benefícios. Isso nem chega perto de compensar o custo.

O que acontece quando ele está de férias, ou inesperadamente doente, ou sai, ou é atropelado pelo ônibus proverbial? O que acontece quando você deseja flexibilizar recursos para obter um trabalho mais rápido do que outro? Quão eficazes podem ser as revisões de código? Como pode um gerente, especialmente um que não está no código-base, saber se o desenvolvedor está trabalhando duro ou puxando a lã sobre os olhos? Quem vai notar se a dívida técnica começa a subir?

Na minha experiência, pessoas que gostam de trabalhar assim são, na melhor das hipóteses, caçadoras de glória, preguiçosas na pior das hipóteses. Eles gostam de ser a única pessoa a quem você pode ir com um determinado problema e eles gostam que o código deles permaneça privado. E muitas vezes gostam de codificar rapidamente, sem levar em conta a legibilidade.

Isso não quer dizer que, em uma equipe de 50 desenvolvedores, todos devem conhecer todo o código, mas uma equipe de 5-7 deve possuir um módulo grande o suficiente para manter essas pessoas trabalhando. Nenhum indivíduo deve possuir nada.

Há pelo menos três questões que as outras respostas apontam; mas eu gostaria de tentar tratar os dois juntos. As duas questões são:

• especialização : Alguém na equipe possui conhecimento detalhado sobre um determinado campo; este conhecimento é independente da implementação específica desse domínio no projeto
• liderança : Embora o trabalho de construir o projeto possa ser compartilhado entre muitos desenvolvedores; o roteiro, bem como decisões imediatas sobre detalhes importantes da implementação estão nas mãos de um membro específico da equipe ou apenas de alguns membros da equipe.
• código sem ego : A maneira específica como o projeto é implementado não depende dos estilos de código, práticas ou conhecimento de qualquer desenvolvedor específico da equipe; e pela aderência estrita a um estilo de codificação bem conhecido ou a uma especificação bem mantida, qualquer novo membro da equipe tem uma chance igual de entender o como e o porquê do projeto como os desenvolvedores experientes.

Quando o assunto é puramente especializado, o sucesso do projeto pode depender de um alto nível de conhecimento sobre o domínio; mas não depende do conhecimento de um especialista específico desse domínio. Os especialistas, embora talvez raros e valiosos, ainda são essencialmente intercambiáveis; Um contador contábil experiente é tão útil para um projeto de software de planejamento tributário como outro, do ponto de vista de seu conhecimento de domínio. A questão passa a ser a de quão bem o especialista é capaz de transferir seu conhecimento para o projeto.

Quando o tópico é puramente de liderança, o sucesso do projeto depende principalmente da consistência e percepção das decisões tomadas pelo líder do projeto; Embora tenhamos a tendência de favorecer leads de projeto que tenham experiência no domínio ou que sejam comprovados como líderes de projeto, isso às vezes é secundário ao papel. O "líder" pode mudar de um dia para o outro se as decisões tomadas forem consistentes de um caso para o próximo e cada decisão for executada rapidamente pela equipe. Se isso está funcionando direito; muitas decisões não precisam ser "feitas" pelo líder do projeto porque a equipe já entende quais decisões serão tomadas.

Eu não acho que a questão seja realmente sobre código sem ego, mas é difícil falar sobre a propriedade do código sem também discutir o quão importante é esse problema. Manter um projeto é provavelmente a maior parte do ciclo de desenvolvimento. A maneira de entender esse problema é imaginar o que aconteceria se alguns dos desenvolvedores tivessem que deixá-lo imediatamente. O que aconteceria se a equipe inteira tivesse que ser substituída? Se o projeto tiver dúvidas, pois depende de alguns participantes importantes, você corre um grande risco de falha. Mesmo que você nunca perca um único membro da equipe, o simples fato de que um ou alguns desenvolvedores são necessários para avançar o projeto significa que você pode não estar trabalhando da maneira mais eficiente possível se mais desenvolvedores estivessem envolvidos.

A propriedade de código tende a impedir a refatoração, criar gargalos de desenvolvimento e causar problemas de ego quando o código tem problemas que devem ser resolvidos.

Eu recomendo consultoria com autores de código antes de mudar, mesmo que o código padrão esteja bem documentado, testado, testado e testado para tornar isso redundante, ainda não faz mal ter outra opinião.

Isso é ruim por muitas razões, eu trabalhei em uma loja onde eles tentavam mudar isso para algo mais razoável e era feio.

As razões pelas quais isso é ruim:

• Se o dono do código tirar férias e aparecer algum bug grande em suas coisas, será muito difícil e demorado tentar aprender o código E consertar o bug
• Se o dono do código deixar a empresa, seus projetos serão gravemente recuados, já que todo o patrimônio e o conhecimento tribal acabaram de sair pela porta
• A documentação é ruim. Se eu sou a única pessoa a codificar, por que eu documentaria isso? Relacionado é o problema que qualquer documentação que é forçada a ser criada provavelmente também será ruim porque ninguém saberá o suficiente sobre o código para realmente dizer se a documentação está completa ou precisa.
• As guerras sagradas do Code podem ser acionadas facilmente quando todos têm seu próprio sandbox, já que outros mencionaram que isso pode ser realmente estúpido muito rapidamente. Onde isso é um problema é quando duas pessoas têm que trabalhar juntas, nenhuma delas está acostumada a comprometer qualquer coisa.
• Por causa do ponto acima, as habilidades de trabalho em equipe nunca se formam - as pessoas nunca têm que trabalhar com os outros.
• Os feudos podem se formar facilmente, pequenos reinos feitos de bolsões de lixo que não compram nada à empresa. Você não sabe que isso está acontecendo até que seja tarde demais, porque o módulo ou a ferramenta X é de responsabilidade de Bob, e ai de você que deve perguntar sobre o que Bob está fazendo em seu código.
• Revisões de código e revisões de colegas sofrem, pois ninguém sabe nada sobre o código. Se você não souber o código, não poderá identificar os lugares que não estão certos e limitar-se a comentar apenas sobre formatação de texto e convenções de nomenclatura.
• E se você trabalha para mim ... a empresa possui o código, não você. Temos orgulho no que fazemos e no que fazemos e no que escrevemos, mas é uma coisa de grupo, como quando seu time vence uma partida difícil. Qualquer funcionário que trabalhe para a empresa possui o mesmo código e, no decorrer de seu trabalho, pode editá-lo de qualquer forma que queira para realizar seu trabalho, que é encaminhar os objetivos da empresa.

Os maiores são os problemas pessoais e a documentação. Essa pessoa vai sair algum dia, e garoto você estará empurrando o cronograma para a esquerda por algumas semanas.

• Corrija qualquer defeito nessa área
• Adicione novos recursos ou aprimoramentos menores ou moderados

Cada pessoa tende a saber um pouco mais sobre algumas coisas do que outras, então, para os problemas difíceis, dois ou três podem se unir, ou o especialista em fatos pode aceitar isso. Eu trabalhei em grupos onde este era o caso e funcionou muito bem. Não só não havia nenhum dos contras listados acima, o pessoal era muito mais previsível, uma vez que não estávamos procurando especialistas.

A propriedade de código de propriedade exclusiva é que o "proprietário do código" pode fazer coisas mais rapidamente do que outras, mas isso só vale se todos forem "proprietários de código" em projetos que não se sobrepõem. Em outras palavras, se as pessoas girarem em torno da vantagem do "único dono do código" desaparecerá.

Veja Número do caminhão também conhecido como Fator de ônibus

bus factor (also known as truck factor, or bus/truck number) is a measurement of the concentration of information in individual team members. The bus factor is the total number of key developers who would need to be incapacitated (as by getting hit by a bus/truck) to send the project into such disarray that it would not be able to proceed; the project would retain information (such as source code) with which no remaining team member is familiar. A high bus factor means that many developers would need to be removed before the project would necessarily fail.

"Getting hit by a bus" could take many different forms. This could be a person taking a new job, having a baby, changing their lifestyle or life status, or literally getting hit by a bus: the effect would be the same...

Como acontece com muitas coisas, é um grande "depende". Se for estrito "ninguém mais pode trabalhar no código", provavelmente está chegando ao fim. Se for "o proprietário deve fazer uma revisão de código antes de aceitar uma alteração", ele é bom, dependendo de quão disposto o proprietário aceitar alterações externas.

A desvantagem é grave; o "número do caminhão" do seu time praticamente se torna 1.

Para revisar, o "número do caminhão" é definido simplesmente como "quantos membros da equipe, no pior caso, podem ser atingidos por um caminhão antes que o conhecimento necessário para executar alguma tarefa crítica seja perdido para a equipe." p>

É natural, e um pouco encorajado, que os desenvolvedores se concentrem em sub-disciplinas; se todos tivessem que saber tudo que tinha a ver com o projeto, nada seria feito porque todos estariam aprendendo o que todo mundo fez, por que funciona e como pode ser mudado sem quebrá-lo. Além disso, se os desenvolvedores estiverem fazendo coisas diferentes em áreas diferentes, é menos provável que as alterações colidam. Portanto, geralmente é bom ter dois ou três desenvolvedores ou pares de desenvolvedores que trabalham principalmente em um subsistema específico do projeto e o conhecem bem.

No entanto, se apenas uma pessoa supostamente tocar uma determinada linha de código, quando esse sujeito sair, será demitido, sair de férias ou acabar no hospital, e essa linha de código será demonstrada como a causa de um bug que deve ser corrigido, alguém tem que entrar e entender o código. Se ninguém mais além do cara que o escreveu já viu, levará algum tempo para chegar a um nível de entendimento que permita ao desenvolvedor fazer a mudança que corrige o bug sem fazer mais. O TDD pode ajudar, mas apenas informando ao desenvolvedor que ele fez a alteração "errada"; novamente, o desenvolvedor deve entender quais testes estão exercendo o código para garantir que os testes em falha não estejam tentando fazer as afirmações erradas.

Eu não levo isso ao extremo, mas prefiro responsabilidade de código . Você escreve código quebrado, você deve consertá-lo. Isso pode ser feito no nível individual, de par ou de equipe. Isso evita que você passe a sua bagunça para outra pessoa para limpá-la. Isso vale para mudanças também.

Problemas de carga de trabalho e agendamento irão sobrescrever isso. Seria insensato evitar consertar um problema grave porque o culpado está em férias de duas semanas.

O objetivo não é fazer com que seu time jogue "o jogo da culpa" ou levar as contagens de bugs longe demais (eles não são todos iguais, de qualquer maneira). Baseie-se em quem verificou o código ou peça a um supervisor para tomar a decisão e atribuí-lo a alguém, em vez de passar por todas as partes de cada linha de código.

Os melhores programadores provavelmente acabam corrigindo muito o código de outras pessoas, independentemente de como você o atribui.