Alguma vez o fez à sua maneira? Houve alguma vez em que se utilizaram interfaces indiretas e de injecção e interfaces extra, e houve um desvio de última hora, e tudo foi tratado com suavidade e beleza, sem palavrões? Mesmo num trabalho anterior, se nunca conseguiste que esse código fosse cometido aqui?

Vou assumir que sim. Pratique contando ** essa** história. É específica e real. Não é “x pode acontecer” ou “y pode mudar” mas, “Era uma vez, eu fiz desta maneira e aqui está como funcionou”. Os gestores (falo como um) são desconfiados quanto a gastar dinheiro (e acredite, você escrever um código mais complicado que outros não conseguem entender num primeiro passe é gastar dinheiro) para o que poderia acontecer. Eles não querem financiar especulações que podem basear-se apenas na “aprendizagem do livro” e na última moda, de acordo com a Internet. Mas quando se baseia na sua experiência? É uma situação completamente diferente.

Não sou um grande fã de fábricas, fornecedores, injectores e afins. Geralmente são configurados para coisas que nunca irão realmente acontecer (mudar de MS SQL para Oracle) ou têm um pequeno impacto quando acontecem (mudar a pasta onde os ficheiros são guardados). Têm um lugar em arranjos que são altamente voláteis, nos quais você parece estar. Por isso precisa de mostrar que eles têm esse lugar. Parece vir de uma posição de: “Esta é a forma normal de fazer as coisas, e eu preciso de uma razão para não o fazer”. O seu gerente vem de: “Isto não é normal; o normal é simples e directo”. Dê-me uma boa razão para colocar mais uma camada no caminho". Trabalhem nessa razão. Trabalhar numa história de sucesso passada, onde essa camada extra poupou dias ou semanas de trabalho. Justifique a sua engenharia ou então é mesmo engenharia em demasia.

Esta citação de um dos vossos comentários preocupa-me:

Como engenheiro de software, torna-se para mim uma segunda natureza “fazer - fazer - aquilo que pode - não ter - ter uma boa razão na superfície”, como fazer interface com as incógnitas que mencionei. Ter de estar constantemente à beira de me explicar sobre assuntos profundamente técnicos (e por vezes muito opiniosos) drena-me.

• A equipa de programação especializada apresenta uma abordagem diferente à programação.
• É visto durante alguns anos, até uma década, como algo que deve ser usado universalmente, apesar de quaisquer desvantagens e limitações. Durante esta fase, basta dizer “Estou a aplicar a metodologia X” sem analisar se X é um benefício líquido.

• Está fora de moda, mas as suas ideias mais úteis permanecem como parte do kit de ferramentas de desenvolvimento de software, para serem retiradas e utilizadas sempre que tragam benefícios líquidos.

• Na minha opinião, tanto o TDD como os padrões de design estão a pairar em torno da divisão entre a segunda e terceira fases do ciclo de vida da metodologia de programação. Tenho a certeza que o TDD e muitos padrões de design terão uma vida longa e valiosa no kit de ferramentas, para serem utilizados sempre que ajudarem mais do que prejudicarem. Também penso que podem ainda estar a ser utilizados em excesso, por hábito e não por pensamento deliberado.

Deverá nunca aplicar um padrão de design porque é de segunda natureza, ou ter dificuldade em explicar a sua utilização. Em vez disso, antes de aplicar um padrão de desenho, pense nos seus custos e benefícios nesta situação específica. Se os seus benefícios compensam realmente os seus custos, deve saber exactamente porquê, pelo que a explicação do compromisso não o deve drenar. Se os seus benefícios não compensarem os seus custos, não o utilize. Mais uma vez, o seu próprio pensamento sobre o seu design deve prepará-lo para responder se lhe perguntarem porque não utilizou um padrão de design possivelmente aplicável.

Lembre-se que precisa de pensar sobre estas contrapartidas em termos da manutenção global do programa, e não apenas para que a sua peça funcione rapidamente. Muita indireção pode tornar mais difícil para futuros programadores descobrir o que realmente se está a passar.

Serei eu a única pessoa perplexa com a forma como no Local de Trabalho estamos a ver tanta concentração nas práticas de codificação em vez do verdadeiro conflito no local de trabalho? Por isso vou adoptar uma abordagem diferente.

Aqui estão os aspectos generalizados da vossa questão tal como a vejo:

1. Está num campo especializado que requer colaboração
2. Não existem procedimentos documentados que regulem a forma como este trabalho de colaboração deve ser feito
3. Há desacordo sobre a forma como este trabalho de colaboração deve ser feito
4. Um dos que discordam é o vosso gestor

Parece-me que o vosso grupo precisa de se reunir e acordar quais as normas e práticas que vão adoptar e adoptá-las globalmente, para o melhor e para o pior. Porque nada é pior para um produto do que uma equipa que está constantemente em desacordo, e nada é pior para a sua relação com a sua entidade patronal do que estar constantemente a discutir com ela.

Por isso, tente reunir a sua equipa para chegar a acordo sobre alguns padrões, e use essa reunião para defender o seu caso pelas práticas que está a utilizar. Se os conseguir, óptimo! Se não, então que assim seja. O teu trabalho não é escrever códigos bonitos. O seu trabalho é entregar um produto acabado. Se o seu empregador (tal como encarnado pelo seu manager) e uma pluralidade do seu grupo insiste que o faça de uma certa forma, então quem é você para os dissuadir?

Contudo, parece que a maioria da sua equipa concorda consigo, por isso deve tornar-se bastante evidente durante estas discussões que o seu manager é o mais estranho. Se esta pessoa ainda se recusar a mudar para o consenso da equipa, então essa é uma disfunção que não o podemos ajudar a resolver (a não ser recomendar-lhe que mude para uma equipa diferente).

Infelizmente, ele é o seu gerente e você não está a escrever o código da forma como ele quer que você o escreva. Se ele for gerente pode não estar a planear sair da empresa dentro de 2-3 anos, como a maioria dos programadores planeia fazer. Está a escrever um código que será mais difícil de corrigir para os seus substitutos, e é por isso que ele é duro consigo para o construir dessa forma.

Se me é permitido fazer aqui uma suposição, sabendo muito bem que eu poderia estar muito longe do alvo, para que está a escrever estas coisas? Eu ficaria bastante surpreendido se fosse algo mais do que aplicações LOB. Os padrões de design são provavelmente demasiado complicados para uma aplicação LOB que não precisa de ser particularmente complicada.

Nos meus 10 anos de desenvolvimento, uma verdadeira estratégia/modelo de fábrica só foi necessária três vezes, duas das quais foram criadas a partir de trabalhos:

• Numa aplicação que mostrava informação de produtos, em que alguns desses produtos eram essencialmente um monte de produtos mais pequenos numa caixa, utilizámos uma estratégia para determinar que fábrica era necessária para transformar a informação do produto (solicitada através de uma chave) numa visão. Não foi muito glorioso, mas fez o trabalho. Se me é permitido igualar a sua humilde visão sobre insectos, em todo o meu mandato nunca tivemos um único insecto! (um foi reportado depois de eu sair mas acabou por ser erro do utilizador :)).
• Numa aplicação que mostrava aos utilizadores onde ir para uma aula que eles frequentavam, utilizámos uma fábrica e abstracção para permitir uma rápida mudança entre uma API do Bing Maps API e a do Google Maps API. Isto porque ambos tinham um custo/benefício e a empresa não estava a fazer progressos determinando qual utilizar. Eventualmente ouvimos do nosso escritório em casa que já tínhamos uma chave API para uma delas e conseguimos rodar no último segundo para essa API, mesmo antes do lançamento.

E um terceiro é um projecto com o qual me estou a meter, que faz monitorização de servidores para servidores Windows:

• uso uma interface para a saída dos dados de monitorização e para os próprios monitores. Os monitores são altamente configuráveis (com base nas definições da aplicação). A implementação de saída varia dependendo se estou ou não a testar um novo monitor ou a ir para a implementação, de tal forma que a IOutputInterface tem ConsoleOutput e SqlOutput como implementações que podem variar.

Note que o meu projecto pessoal faz imediatamente um uso mais frequente de padrões e inversão de controlo (IoC) do que os meus projectos de trabalho.

Se eu puder dar-lhe algum conselho depois de tudo isto, que seja este: Um trabalho é um trabalho, e se você quiser fazer as coisas à sua maneira, então tente encontrar um meio de comunicação feliz. Os técnicos não costumam ficar muito tempo nos locais e não vale a pena discutir com a gerência sobre como isso é feito. Faça com que os seus projectos pessoais sejam uma pilha de padrões, tanto quanto você quiser.

Solução fácil: **

Solução difícil: em qualquer desacordo, ** metade da culpa é sua***.

Tire algum tempo, estude como funcionam as outras equipas, descubra onde está a descoordenação de obstáculos entre si e a outra parte. Fale com eles pessoalmente, cedo e frequentemente. Se fizer isto bem, ambos aprenderão a compreender as preocupações e credenciais da outra parte, e aprenderão a valorizá-lo pela sua contribuição, experiência e opiniões fortes. Aqui estão algumas áreas a considerar:

• produto de qualidade vs. tempo para comercializar
• bom produto vs. bom código
• código inteligente vs. código auto-explicativo
• cultura da empresa de cima para baixo vs. cultura da engenharia de baixo para cima

Se não funcionar bem, considere um outro papel na equipa, uma outra equipa* na empresa ou, finalmente, uma outra empresa*.

Se enfrentares estas pessoas de frente, enfrentarás a maior resistência, gafanhoto. Tenho sido mais eficaz a trazer mudanças quando atinjo estrategicamente os pontos de pressão correctos. É preciso ter muita paciência e ceder muito. Tenho primeiro de adaptar-me a eles antes de aplicar pressão nos pontos fracos.

Esvazia a tua mente, não tenhas forma. Sem forma, como a água. Se você colocar água num copo, ela se torna o copo… Agora, a água pode fluir ou pode colidir. - Bruce Lee

Ouça-os e faça muitas perguntas. Genuinely* ouvir alguém tira-lhe o desejo de resistir. Compreenda o que motiva o seu pensamento e depois fale a sua língua. Como as suas crenças são axiais, neste momento, é provável que ele espelhe a sua teimosia, desprezo e frustração. Uma vez que você é subordinado, é sua escolha não se juntar ao seu comprimento de onda e é sobre você que recai o ónus de construir a ponte.

Como você o vê, você se verá a si mesmo. À medida que o tratas, vais-te tratar a ti próprio. À medida que o vais vendo vais-te vendo a ti próprio. Nunca te esqueças disto, porque nele vais encontrar-te ou perder-te. - Helen Schucman

Um mestre de Kung Fu Wing Chun vai atrair o seu adversário e fechar a distância antes de procurar e atacar a linha central onde ele é mais vulnerável. Não discuta minúcias apenas para ganhar, encontre a linha central do maior problema e concentre-se na pressão lá.

Lido diariamente com engenheiros que se recusam a reequipar ou a aprender novos paradigmas de programação e já me foi dada alguma forma de argumento “Estou aqui desde os cartões perfurados” mais vezes do que posso contar. Estimo que perdi 80% das batalhas, mas esses 20%…woh…fiz muitas mudanças aconteceram. Posso parecer vago, mas faz alguma pesquisa no Google sobre algumas destas palavras-chave e vais perceber o que quero dizer.

Também, tenta entrar num novo projecto squirrel que podes fazer à tua maneira. Se realmente funcionar e poupar tempo ou dinheiro, as pessoas vão aparecer à sua maneira de pensar. Se não houver um novo projecto, crie um no seu tempo livre para resolver um ponto de dor que a empresa tem e ninguém está interessado em tirar o tempo para resolver.

O que devo fazer?

Na engenharia de software, o quão bem o código está escrito (ou sobre escrito) está sempre sujeito a algum nível de interpretação (opinião). Para mim, você está a dar os passos que eu daria na sua posição, mas em última análise é o seu gestor que precisa de ver a luz….continue a mostrá-la.

Eu continuaria, _ por mais doloroso que seja, a fazer exactamente o que você está a fazer e _ponha o retorno do investimento na utilização do padrão de design onde puder, sem fazer o seu gestor parecer muito.

Não mude o que está a fazer **a menos que se sinta em risco de pior do que uma reprimenda. Continue a mostrar-lhes os benefícios de usar o padrão, e eventualmente eles devem aparecer.

À medida que continua a luta, ** tente ganhar alguns outros aliados*** na equipa. Desta forma, não é a única voz que se ouve falar a favor do padrão.

A certa altura, porém, se recusarem que tenha de escolher se este ambiente é o mais adequado para si. Penso que ainda não estás lá, mas talvez tenhas de passar para um ambiente mais aceitável para as boas práticas de codificação.

Lembra-te, esta luta em que estás é uma maratona*. Se quiser mudar a cultura de codificação, cabe-lhe a si demonstrar o valor do padrão.

Em primeiro lugar, não podemos dizer, a partir da informação dada, quem tem razão. De facto, se eu fosse chamado para auditar o projecto, poderia ainda ter dificuldade em decidir quem tem razão, porque poderia estar a conceber com objectivos diferentes em mente. Mas o meu palpite é que o chefe conhece os objectivos melhor do que o senhor.

Em segundo lugar, a sua pergunta: “Como posso persuadir o meu chefe?” A resposta é: provavelmente não consegue. No final, ele é o patrão. A única vez que convenci o meu chefe a mudar as suas ideias sobre engenharia de software foi depois de termos passado um ano a remendar uma peça de software não fiável que estava escrita da forma que ele queria, e dissemos-lhe que não a podíamos tornar fiável a não ser concebendo-a de forma diferente.

Não sabemos quem está aqui de um ponto técnico de poucos - pode ser um gerente preso no passado, ou um novo empreendedor a acreditar cegamente em toda a propaganda.

Mas ele é o seu gerente, e você não lida com o gerente, você lida com a sua recusa em fazer o que você acha que é melhor, e insiste em fazer o que ele acha que é melhor. E esse é o estado normal das coisas, que é o seu manager que toma a decisão. É também o estado normal das coisas que ele tem a responsabilidade final pelo sucesso ou fracasso, e não você. Ele tem a autoridade. E ele tem razão, você não deve questionar a sua autoridade. Você pode questionar se ele está certo, mas não a sua autoridade. Então ou lida com isso ou muda para uma empresa que faz as coisas à sua maneira.

Entretanto, em vez de pensar que as coisas não correm como você quer, pense em como você produz o código de melhor qualidade que você pode dentro das suas limitações. Muitas coisas podem ser feitas de diferentes maneiras. Há “simples, mal concebido” e “simples, bem concebido”. Vá por este último.

A experiência permite avaliar se os benefícios do padrão de concepção são possíveis e prováveis no futuro. Se o supervisor conhece o modelo e continua a recusá-lo, provavelmente reconhece o caso quando aplica este ou outro modelo semelhante não compensa. Por vezes a experiência contradiz as regras ou é mais provável que elas interpretem.

Há uma opinião conhecida de que um código mais curto e mais simples é mais fácil de compreender e mais aberto a alterações significativas.

Sugiro a programação em pares e a revisão pelos pares. Isto irá ajudar os seus colegas de trabalho a compreender melhor o seu código, uma vez que precisa de explicar porquê e como como o faz e não depois.

Ou eles vão aprender consigo e ver porque é que é inteligente, ou você vai aprender que os melhores programadores escrevem código que outros podem manter.