A resposta para isso é simples.
A consistência é de suma importância.
mas vem com uma ressalva ...
Você e seu colega de trabalho provavelmente estão obcecados com o tipo errado de consistência
As implementações são descartáveis. Eles podem ser completamente revisados com vários graus de facilidade, dependendo da qualidade e abrangência do conjunto de testes. Preocupando-se com coisas como "Isso deve ser uma propriedade?", "O código não deve usar o LINQ em vez de uma construção de nível inferior?" é de valor duvidoso. Sua variação é difícil de vincular qualquer medida ao valor da consistência no nível de implementação. Uma pergunta muito melhor para perguntar nesse nível é "Esse código funciona como anunciado?". A consistência de implementação de DR é onde as "mentes pequenas" colocam seu Hobgoblin.
Por que a consistência não é tão importante aqui? Implementações geralmente têm um pequeno número de colaboradores. A maioria dos métodos é escrita e nunca mais tocada. Do código restante, o número de métodos que tem dois contribuidores quase certamente é a maioria. Esse padrão continua ad infinitum . Neste contexto, a consistência não é tão importante. Se o prazo de validade do código for muito pequeno ( alguns anos ), os ganhos da consistência agressiva provavelmente não são fatores.
Isso não quer dizer que você deva ficar louco em suas implementações. Pelo contrário, é para dizer que um design simples, limpo e agradável terá ordens de grandeza mais valiosas para seu mantenedor futuro hipotético do que o método de consistência de placa de caldeira bobo por método. Isso nos leva ao ponto real ...
As APIs não são descartáveis.
Isso é tudo nível de código de APIs, serviços da Web, SDKs etc. Esses devem, devem, ser consistentes. Os ganhos de produtividade dessa variedade de consistência são enormes por vários motivos:
Testes de integração:
Se você mantiver sua API consistente, poderá criar conjuntos de testes de integração. Estes permitem que os desenvolvedores troquem livremente os detalhes da implementação e obtenham uma validação imediata. Quer trocar sua porcaria co-works para LINQ? Os testes de integração são executados? Também fornece validação quando se prepara para ir para a produção. Como os computadores são rápidos, um único laptop pode executar o trabalho de milhares de testadores que executam tarefas comuns. É o mesmo que aumentar consideravelmente o número de funcionários da sua organização.
Produtividade
Quando as APIs são consistentes, você pode adivinhar como usar uma API apenas seguindo o que aprendeu sobre outras partes da API. Isso ocorre porque a API oferece uma aparência "natural e consistente". Isso significa que seu cliente gasta menos tempo analisando a documentação. A integração é mais fácil e barata. Menos perguntas são feitas para as pessoas que desenvolveram a API. Consistência faz de todos um vencedor
Por que a consistência é importante nesse cenário? Porque as APIs têm o problema exatamente oposto das implementações. O número de pessoas que os utilizam é normalmente muito maior do que o número de pessoas que contribuem para suas implementações. Pequenos ganhos de pouca consistência são multiplicados e os custos de manutenção dessa consistência são amortizados.
Conclusão
A consistência é cara. Por sua vez, reduz a produtividade. Isso restringe os desenvolvedores e dificulta a vida deles. Ele coloca limitações nas maneiras como eles podem resolver um problema, às vezes, forçando-os a resolvê-lo de uma maneira não ideal. Isto é frequentemente por razões que eles não entendem, são mal concebidos, ou não estão a par (contratos, políticas organizacionais ou interorganizacionais maiores).
Raymond Hettinger fez alguns pontos excelentes em sua palestra sobre Pycon 2015 sobre o uso do guia de estilo PEP8 para equipes de programadores python. Ele mostrou que a obsessão pela consistência estilística em um pedaço de código fazia com que os revisores de código perdessem falhas sérias na lógica e no design. Sua hipótese pode ser resumida como encontrar inconsistências estilísticas é fácil; determinar a qualidade real de um pedaço de código é difícil
O ponto aqui é crítico. Identifique onde a consistência é importante e proteja-a agressivamente. Onde não é importante, não perca seu tempo. Se você não puder fornecer uma maneira objetiva de medir o valor da consistência (nos casos acima, "efetivo de funcionários", custo como uma função da produtividade) e você não pode demonstrar que os retornos são substanciais, então provavelmente você está fazendo um desserviço para sua organização.