Escolha o esforço de design de código ou a preguiça no mundo do Banco

Trabalhei por dois anos em um grande banco de investimentos.

Fiz alguns projetos técnicos com o desejo de criar o código mais otimizado, respeitando os bons padrões de design adaptados, o princípio SOLID, a lei do deímetro e evitando todo tipo de código duplicado ...

Quando a entrega na produção => zero bugs, tudo aconteceu como esperado.

Mas a maioria dos desenvolvedores veio até mim para precisar que todo o meu código é muito complexo para a compreensão da leitura. Ouvi, por exemplo: "faça alguns se e instâncias de, esqueça o polimorfismo, para que seja muito fácil corrigir bugs de produção de emergência". Eu não preferi responder ......

Conhecer esses desenvolvedores não é nada curioso, recusar esforços para entender um bom design (por exemplo, 90% dos desenvolvedores não sabem o que é um Padrão de Estratégia e criam código de procedimento e nunca projetam porque desejam, eles disseram, simplicidade ), meus gerentes de projeto me disseram que eu realmente estou no caminho errado e sou idealista demais para o mundo do Banco.

O que você me aconselharia? Devo manter o desejo de um código realmente bom ou me adaptar à maioria dos desenvolvedores que, repito, não são realmente interessantes pelo código de design que está de acordo comigo, toda a beleza do nosso trabalho de desenvolvedor.

Ou, pelo contrário, eles deveriam aprender princípios e práticas recomendadas básicas de OO para se adaptarem ao meu código?

meus gerentes de projeto me disseram que eu realmente estou no caminho errado e sou idealista demais para o mundo do Banco.

GTFO!

Hora de sair e ter pena deles. Por que você deveria dar a mínima? Você sabe que isso lhes custará dinheiro a longo prazo com sua equipe incompetente. Este não é um jogo de discussão técnica. Isso é sobre política. Peça que eles treinem os outros desenvolvedores ou o GTFO! Se você não tem peso político suficiente, então o GTFO! Procure uma empresa com melhores práticas.

A única razão para ficar lá é uma compensação adequada para suas dores de cabeça. Então é melhor pagar bem acima da média ou GTFO! Duvido que você também possa crescer lá como desenvolvedor de software. O crescimento de nossa profissão é alcançado principalmente por trabalhar com pessoas que são melhores que você e que incentivam as melhores práticas. E quanto melhor você for, maior será o seu valor de mercado para as empresas que se importam.

Sim, eu sei que essa não é uma das minhas respostas habituais, mas realmente, se você não pode jogar o jogo político nesta empresa, a GTFO.

O que você me aconselharia? Devo manter o desejo de um código realmente bom ou me adaptar à maioria dos desenvolvedores que, repito, não são realmente interessantes pelo código de design que está de acordo comigo, toda a beleza do nosso trabalho de desenvolvedor.

Eu não trabalharia para uma empresa que deseja que eu forneça soluções abaixo do ideal. Eu quero esculpir meu nome no software. Eu quero me orgulhar disso. Não escrevo aplicativos procedurais em linguagens baseadas no paradigma OO. Eu acredito em software de alta qualidade e, se a empresa não acreditar, vou fazer o GTFO! Espero que você tenha o suficiente "foda-se dinheiro".

Local difícil. Eu acho que você pode seguir dois caminhos em paralelo, mantendo seu ponto de vista e mostrando vontade de comprometer:

• Isto é sobre dinheiro. Como qualquer trabalho de desenvolvedor, de fato, mas como você enfatiza o ambiente do banco, isso deve funcionar ainda melhor;). Mostre a eles que seu estilo economiza dinheiro. Encontre um exemplo de como uma alteração nos requisitos pode ser feita com muita facilidade devido ao seu design. Tente encontrar um pedaço de outro código (você precisa se certificar de que não fica muito agressivo aqui, mas, ei, é sobre comparar estilos de código), que é propenso a quebrar em breve, e mostre a eles como você não precisa se preocupe com esses problemas porque seu código é de melhor qualidade para começar.

• Isto é sobre dinheiro. E se o seu estilo de codificação realmente custar dinheiro? Pode ser que isso funcione se outras pessoas gastarem mais tempo tentando entender seu código do que o que está sendo salvo pelo design adequado. Você pode estar fazendo a coisa certa tecnicamente e ainda não contribuir positivamente para o esforço da equipe. Além disso, é possível exagerar no design do OOP. Estou com você do lado "o bom design é bonito", mas estou tentando conscientizá-lo aqui do ponto de vista deles e de como eles podem realmente estar certos da perspectiva deles. Paralelamente ao ponto anterior, tente encontrar um ponto em que você o exagerou. Isso dá a você espaço para manobrar: você pode dizer, ok, eu posso ser um pouco mais pragmático aqui e ali, mas veja, também existem lugares onde esse código é realmente melhor.

Mas a maioria dos desenvolvedores veio até mim para precisar que todo o meu código é muito complexo para a compreensão da leitura

Já lhe ocorreu que eles podem estar certos?

Eu trabalhei com alguém que se esforçou muito para escrever código que ele descreveu como elegante. Ele passou muito tempo censurando o trabalho de outras pessoas por não ser elegante. Quando for necessário manter o código, o código dele não é o código que eu escolheria para modificar. É tão preciso e exato que a mudança é profundamente carregada de perigos.

A palavra interessante que você menciona aqui é "complexa". Código que pode ser descrito como complexo raramente pode também ser descrito como particularmente bom.

Os fabricantes de móveis da era vitoriana (pelo menos aqueles cujo trabalho ainda hoje vemos) eram verdadeiros artesãos, o que eles fizeram foi funcional, bonito, bem trabalhado, projetado e construído para durar uma vida. No entanto, nos últimos 150 anos, o mundo mudou. Poucas pessoas estão dispostas a pagar por esse tipo de artesanato, quando alternativas mais baratas são mais comercialmente pragmáticas ao comprar uma mesa de jantar.

Muitos programadores querem ser os artesãos do passado, infelizmente, o comércio dita que isso não pode acontecer o tempo todo. Você tem uma escolha, adaptar ou sair. Existem empresas que querem artesãos, mas são superadas em número por aquelas que querem produtos que funcionam principalmente, baratos e agora.

A dica para mim de que você não é adequado para a maioria dos desenvolvimentos comerciais de software é o "Quando a entrega na produção => zero bugs". Nem a Nasa conseguiu isso com os ônibus espaciais.

Os únicos lugares em que sua atenção aos detalhes e, portanto, o custo inicial, provavelmente serão aceitáveis ​​são os sistemas de nível 1 de vida crítica - por exemplo, aviônicos / aeroespaciais, automotivo, militar e médico.

O problema é que você está trabalhando no lugar errado. Parece que você é um programador muito academicamente inclinado. Você não se sairá bem no ambiente em que se encontra e é bem provável que alguma desculpa seja inventada para se livrar de você e do seu código "muito complexo". Você pode receber tarefas indesejadas e / ou análises de desempenho ruins e até que você saia por conta própria ou que elas tenham uma trilha de papel com cobertura traseira suficiente para demiti-lo.

Eu recomendo que você encontre um lugar para trabalhar que valorize suas tendências acadêmicas. Eles estão lá fora. Você também encontrará alguns que estão em cima do muro entre pragmáticos e acadêmicos. Um trabalho como esse pode ser sua melhor opção, pois permitiria convidar um pouco de caos à sua abordagem, ajudando outros a refrear o deles.

Antes de tomar medidas drásticas como mudar de empregador, tentaria melhorar sua própria capacidade de explicar aos não programadores como os executivos por que sua maneira de codificar é melhor para a empresa e economizar tempo e dinheiro. Além disso, verifique se você não aplicou padrões de design apenas por motivos de design - você tem certeza de que também seguiu as regras do KISS e YAGNI? (Ok, padrão de estratégia e polimorfismo não são ciência do foguete, dê aos seus colegas algum tempo para se adaptarem e explique a eles por que você escolheu essa abordagem.)

Na minha empresa, realizamos uma série de workshops baseados no Clean Code Developer . O objetivo era criar um fórum fora do dia-a-dia, com seus prazos agitados e compromissos ruins, onde os desenvolvedores pudessem aprender sobre os princípios de design de software (como você mencionou), técnicas de programação etc. e refletir sobre seus projetos e seu próprio trabalho.

Exemplos da vida real de projetos reais também foram discutidos. O feedback dos participantes foi AFAIK muito positivo. É difícil medir um benefício real, no entanto.

A participação nesses workshops foi em parte no tempo patrocinado pela empresa, em parte no tempo livre dos participantes. Você não alcançará os colegas que não se importam com o aprendizado e simplesmente querem fazer o trabalho deles e ir para casa, mas para qualquer pessoa que tenha algum interesse em seu trabalho, isso pode ser interessante.

Antes de tudo, eu verificaria se o seu caminho é realmente melhor. O código orientado a objetos pode ser muito bom, mas também pode ser um pesadelo de efeitos colaterais ocultos e cada ação pode exigir várias classes diferentes.

Melhor ainda, vá para a InfoQ e assista à palestra de Rich Hickey sobre "Simple Made Easy"

Você vai ter que ceder um pouco se quiser continuar trabalhando lá sem lutas constantes. Um grupo de desenvolvedores que é totalmente processual não aceita polimorfismo imediatamente. Embora eles não consigam projetar de maneira OO, eles podem aprender com seu código. Eles podem perceber que alguns de vocês codificam é mais fácil de manter.

Como uma observação lateral, é necessário fazer perguntas durante o processo de entrevista para ver qual processo de desenvolvimento e metodologia de codificação é usada se você achar importante corresponder às suas preferências.

Emergências acontecem. Você não é perfeito e as mãos deles estragam seu código em algum momento. Isso, a menos que você nunca tire uma folga, o que, como o seu médico de família confirmará, não é bom para sua saúde. E leva a maiores chances de emitir código ruim.

Seu código pode ter uma qualidade mais alta (fato não comprovado), mas eles têm políticas . (com certeza)

Você foi avisado para seguir as políticas e será responsável por não segui-las. Em uma situação de emergência. Em um aplicativo bancário. Quero dizer, se seu objetivo está acabando mal e na prisão , posso descobrir muitas maneiras mais engraçadas e significativas de obter o mesmo resultado.

Vocês, colegas de cela, ficariam encantados em ouvi-lo divagando sobre a falta de curiosidade de seus ex-colegas de trabalho.

(então, novamente, sua empresa provavelmente não possui políticas internas contra o design de OO, mas o engenheiro desajeitado treinado por COBOL que tentará corrigir seu código vai compensar algo do nada e, IMHO, na pior das hipóteses, ele ' terá 40% de chance de marcar um acerto crítico)

Tente lembrar que a programação é considerada por alguns como um meio para um fim, e não por si mesma. Pense em todos os produtos e serviços que você usa: você gasta muito tempo pensando se o código abaixo é feito de forma elegante? Ou você simplesmente os aprecia como eles simplesmente funcionam? Encontre um setor ou causa de sua paixão, encontre uma organização com isso e ofereça soluções que incluem programação, mas não apenas isso. Os problemas podem ser resolvidos de maneira brilhante de diferentes maneiras.