Você já teve que codificar “mal” para sua equipe? [duplicado]

15

Eu tenho estado na constante estrada de aprender novos conceitos em OOP, Design de Software, Arquitetura, etc. Mas há momentos em que você está em uma equipe onde esses conceitos são estranhos para eles e eles não têm tempo ou a mesma vontade de aprender como você.

O problema é que se você projetar seu código da maneira "certa", as pessoas que codificam com classes 2kLOC não o entenderão. Você sacrificaria bons princípios de codificação para apoiar sua equipe? Que tal um cenário em que esse será um acordo de longo prazo?

    
por Jonn 23.09.2010 / 15:34
fonte

2 respostas

14

Bem-vindo ao mundo real.

Trabalhei com centenas de desenvolvedores diferentes em todo o mundo, em startups e grandes empresas. A grande maioria deles não entende conceitos avançados e não o fará no futuro. É muito complicado dominar alguma coisa, a menos que você passe mais de uma década nesse campo específico. Muito poucos são capazes de fazer isso.

É por isso que estou muito chateado quando um dos meus desenvolvedores é muito "CV" e tento implementar padrões de design que não fazem nada melhor, mas permitem que ele coloque algo novo em seu currículo (ou o título "Arquiteto"). enquanto o resto da equipe está lutando para entender e manter o código HIS.

É por isso que eu acho que um bom desenvolvedor não é o tecnicamente melhor, mas o mais pragmático do pacote:

An excellent developer try to convert a functionnality the business ask by maximizing the ROI.

IMHO, manter as coisas simples, é o caminho a percorrer. Se você quiser fazer o material "certo", faça em casa. Seu chefe está pensando em outra coisa sua.

    
por 23.09.2010 / 15:46
fonte
5

Acho que há uma diferença entre o que você está se referindo e a dívida técnica .

A dívida técnica é quando você faz deliberadamente uma implementação rápida e hacky com o total conhecimento de que precisará alterar o design em um estágio posterior. Semelhante à dívida financeira, isso pode ser benéfico para um projeto, mas você precisa estar ciente disso e eliminá-lo em um estágio posterior.

Em termos de deliberadamente não usar certos recursos de linguagem - também estive nessa situação. Lembro-me de uma vez ter implementado delegados anônimos logo após o C # 2.0 ser lançado, e alguns meses depois vi alguém simplesmente ter excluído meu delegado e substituído por um método normal. Eles simplesmente não entendiam o código: - (

Dito isto, nem sempre é uma coisa ruim. Vamos simplificar .

    
por 23.09.2010 / 15:49
fonte

Tags