Como explicar por que as escolhas de design são boas? [fechadas]

À medida que me tornei um desenvolvedor melhor, descobri que grande parte da minha habilidade de design vem mais da intuição do que da análise mecânica. Isso é ótimo. Isso permite que eu leia o código e sinta-o mais rápido. Isso me permite traduzir projetos entre idiomas e abstrações com muito mais facilidade. E isso me permite fazer as coisas mais rapidamente.

A desvantagem é que acho mais difícil explicar aos colegas de equipe (e pior, à gerência) por que um design específico é vantajoso; especialmente colegas de equipe que estão atrasados ​​nas melhores práticas. "Este design é mais testável!" ou "Você deve favorecer a composição sobre a herança". passam por cima de suas cabeças e me levam até a toca do coelho tentando localizar todos na última década dos avanços da engenharia de software.

É claro que vou melhorar com a prática, mas nesse meio tempo isso envolve muito tempo desperdiçado e / ou design inadequado (que levará ao desperdício de tempo corrigindo-o posteriormente). Como explicar melhor por que um determinado design é superior quando os benefícios não são completamente óbvios para o público?

Isso pode não responder diretamente à sua pergunta, mas pode levar você a uma direção interessante.

Eu acho que o que você precisa fazer está mais relacionado a vendê- los da ideia do que explicar a eles. Vendas significa entender qual é o problema do cliente e depois mostrar a eles como seu produto (ou método de desenvolvimento, qualquer que seja) os beneficiará . Cada pessoa tem necessidades diferentes; portanto, as coisas que beneficiam uma pessoa e as excitam podem muito bem deixar outra pessoa com frio.

Para o seu CEO, o tempo de colocação no mercado pode ser a chave; para o seu gerente, podem ser agendamentos mais previsíveis; para os colegas de programação, pode ser uma codificação mais rápida (ou para testes / documentação / depuração / o que for mais fácil) e para os clientes da empresa. pode ser ... ?

As vendas não acontecem automaticamente - você precisa fazer um esforço conjunto para entender o ponto de vista da outra pessoa e depois descobrir como mapear suas idéias no Happy Place ™. Uma vez que eles sabem como se beneficiarão pessoalmente dessa novidade, muitas vezes perguntam: "Quanto vai custar e em quanto tempo podemos fazê-lo?" Depois de ouvir essas palavras mágicas, você sabe que fez bem seu trabalho de vendas.

Eu realmente não tenho uma solução para sua pergunta, mas há algum tempo eu enfrentei exatamente o mesmo dilema e estava procurando responder exatamente a mesma pergunta.

Eu me encontrava de um lado da discussão e outra pessoa do outro lado, e mesmo que todas as fibras do meu corpo me dissessem que o design certo é X, eu não poderia apoiá-lo usando palavras.

Pior ainda é que, às vezes, eu aceitava o argumento e deixava a outra pessoa implementá-lo do seu jeito, apenas para ter seu design explodido na minha cara e então pensava: "Sim, este é um exemplo perfeito de por que não queria fazer dessa maneira. Se ao menos eu pudesse demonstrar esse código para eles naquela época ".

Bem, eu realmente nunca encontrei a resposta, mas há alguns dias atrás, enquanto eu estava folheando o Lean Software Development: An Agile Toolkit, Me deparei com algo interessante que pode sugerir que a resposta realmente não existe. Uma seção do livro estava falando sobre líderes em outros campos, especialmente em unidades de resposta a emergências e como esses líderes tomavam decisões. Quando há um incêndio, ou alguém está atirando em você, esses líderes nunca se sentam e discutem prós / contras com seus companheiros de equipe. Em vez disso, eles usam a intuição, que foi desenvolvida por meio de treinamento e experiência para ajudá-los a tomar decisões. O mesmo se aplica à nossa profissão: como você pode tomar uma decisão totalmente lógica diante de uma tonelada de incógnitas e variabilidade tão comuns no desenvolvimento de software? Os autores argumentam que, em vez de tentar justificar todas as decisões, os desenvolvedores devem ser incentivados a treinar e melhorar seus instintos, para, eventualmente, "saberem" o que fazer.

A única maneira que encontrei para superar esses argumentos é construir um histórico comprovado do meu trabalho. Mostrar aos gerentes e outras pessoas da minha equipe que as decisões de design que tomo no meu código resultam em um código mais fácil de manter, estender e mais confiável. Você faz isso repetidamente e as pessoas notam você. Nesse ponto, sua opinião, que só pode ser baseada em seu instinto, terá um peso muito maior do que hoje. Essa estratégia funcionou com mais de 90% da minha equipe, incluindo meu chefe. Infelizmente, você pode encontrar um ou dois caras completamente teimosos e se recusar a ver qualquer coisa do seu jeito. Nesse ponto, você tem poucas opções:

1. Você pode tentar obter uma classificação (acabei indo ao meu chefe e pedindo uma classificação porque estava cansada desses argumentos sem saída)
2. Você pode tentar fazer lobby para que a maioria da equipe o apoie.
3. Se o projeto puder pagar (ou seja, sem muita perda de produtividade), o que, na sua opinião, é uma má decisão, deixe a outra pessoa vencer a discussão. Uma de duas coisas acontecerá:
   • Em alguns casos (parte muito pequena), sua intuição estará errada e você acabará aprendendo alguma coisa. Bom para você.
   • Na maioria dos casos (novamente ... espero), você E a pessoa que defendia o design "ruim" perceberão exatamente por que ele é ruim; afinal, a retrospectiva é sempre 20/20. Felizmente, essa será uma lição para a pessoa de que possivelmente você sabe do que está falando e da próxima vez que ela pensar duas vezes discutindo o caso.

Bem, essa resposta não é tão específica de programação quanto você imagina. Você precisa devolvê-lo às coisas que eles entendem.

Se é algo como composição sobre herança, você provavelmente apenas tem que dizer que atualmente, talvez 90% dos desenvolvedores considerariam uma boa prática (um palpite, baseado em parte no fato de que 100% dos desenvolvedores concordam em quase nada), e você concorda e ficaria feliz em explicar o porquê.

Eu tento ser o mais honesto possível sobre o que é controverso e qual a porcentagem de desenvolvedores que concorda comigo.

Isso geralmente funciona melhor com o gerenciamento do que com os desenvolvedores, que provavelmente farão com que você explique se você está realmente defendendo um bom design e como você o conhece. Há algo louvável nisso, mas significa que você deve dedicar muito tempo. A menos que eles confiem em você o suficiente para aceitar sua palavra para essas coisas, pelo menos provisoriamente. No lado bom, eles podem convencê-lo de que você está errado, o que supera a dura e dura realidade, convencendo-o no caminho.

Para coisas como um design sendo mais testável, se eles não concordam que é mais testável, é praticamente o mesmo que no primeiro exemplo. Se eles não concordam que é desejável ser mais testável, você deve devolvê-lo às coisas que eles entendem. Provavelmente, isso seria gerenciamento, e você pode falar sobre custos mais baixos de desenvolvimento a longo prazo, menos controle de qualidade, processos mais previsíveis (já que é difícil prever a duração de ciclos repetidos de controle de qualidade) etc.

Acho que parte do problema é que você subestima o quão difícil é conseguir que uma equipe concorde com você em algo controverso, mesmo que você esteja correto (e, claro, talvez não esteja). A programação é em parte um exercício sociológico e talvez você precise agendar um horário para realmente descer por alguns desses buracos de coelho, pois um ótimo design que ninguém entende ou fica atrás raramente é um ótimo design na prática. Portanto, não pense nesse tempo desperdiçado, pense nele como uma parte necessária do sucesso do seu projeto. Mesmo que fosse muito mais fácil se você pudesse ignorá-lo.

Ser a única voz da mudança nunca é uma coisa fácil. O primeiro desafio é geralmente levar outras pessoas a bordo (espero que algumas pessoas na sua empresa tenham uma mente mais aberta do que as demais). Se você conseguir chamar a atenção de outros desenvolvedores / gerentes seniores para se juntar à sua cruzada, essas vozes combinadas serão cada vez mais difíceis para o resto ignorar.

Acho que uma boa maneira de explicar às pessoas é fornecendo exemplos concretos de erros passados ​​cometidos em projetos nos quais eles estiveram ativamente envolvidos (por exemplo, "Você já tentou depurar essa coisa? Tem sido assim há anos e ninguém sabe como consertá-lo.."). Melhor ainda, aplicar essas 'novas' idéias e princípios de design a um projeto pequeno / experimental e ser capaz de mostrar o quão bem-sucedido tem sido no final.

Dependendo das atitudes de outras pessoas em sua empresa, as mudanças podem ocorrer rapidamente ou pode ser como tentar nadar através de melaço. Alguns gerentes são completamente imóveis, a menos que tenham estatísticas / provas sólidas à sua frente, enquanto outros desejam manter o pensamento mais recente.

Pode ser necessário tentar táticas diferentes, dependendo de com quem você está lidando; Sugerir que dinheiro / tempo / esforço possa ser economizado e que a qualidade possa ser melhorada é uma boa maneira de chamar a atenção de gerentes não técnicos; e a promessa de testes automatizados fáceis atrai muitos desenvolvedores que normalmente não conseguem suportar passar dias executando as mesmas planilhas de teste repetidamente.

Depende da audiência! Como desenvolvedores, desenvolvemos uma intuição para códigos bons e ruins, e usamos termos emocionais vagos como "cheiro de código", "código feio", "solução bonita". Isso só funciona ao se comunicar com outros desenvolvedores com a mesma mentalidade. Tente explicar ao seu CEO não técnico que você deve investir x horas-homem para tornar algum código "mais bonito" e provavelmente irá falhar espetacularmente.

Você precisa ser capaz de defender que qualquer melhoria de design fornecida

• economizar dinheiro para a empresa
• ganhar dinheiro para a empresa

Por exemplo, qual é o caso de aderir ao princípio de responsabilidade única? Se cada classe tem uma única responsabilidade, fica muito mais fácil localizar e corrigir bugs, além de adicionar recursos e melhorias. Menos tempo corrigindo bugs e adicionando recursos = dinheiro economizado.