Digamos que tenhamos um aplicativo winform com um evento buttonclick. O buttonclick lida com tudo, desde a configuração da interface do usuário até a chamada do banco de dados e manipulação de dados. Então você acaba com um método que é 100 de linhas de código longo. Fora do fato de que esse código não pode ser considerado testável por vários motivos, esse estilo de programação é frágil para mudar.
Eu posso falar sobre OO, Anti-padrões, etc. O problema é que qualquer tópico distinto que eu possa sonhar requer uma grande explicação para entender os benefícios potenciais.
Fora de encontrar um novo emprego ( lotes de empresas programam dessa forma), como posso ensinar a esses tipos de desenvolvedores como escrever um código melhor? Obviamente, não podemos sentar em torno de uma mesa redonda e discutir os prós e contras todos os dias devido a restrições de tempo e trabalho real que tem que ser feito. Embora o treinamento e o treinamento intenso sejam a única coisa em que posso pensar para corrigir esses problemas.
Para não dizer que escrevo código perfeito, certamente não o faço. Eu acredito que há certas melhores práticas que devem ser seguidas como regra geral. OO no contexto do .NET.
A desculpa mais comum que ouço é "não podemos escrever código rápido o suficiente se fizermos assim".
Encontre um paradigma adequado, como Model-View-Controller, e discuta-o especificamente.
Acho que você descobrirá que seus desenvolvedores verão imediatamente os benefícios de seguir um padrão arquitetônico predefinido. Você também estará falando sobre algo concreto, em vez de conceitos abstratos de torta-no-céu.
A ASP.NET MVC tem instruções completas de código em seu projeto de exemplo NerdDinner.
Isso vai exigir um investimento de tempo. Se as pessoas estão comprometidas com práticas como "programação de fita adesiva", evitando testes de unidade, escrevendo código de procedimento estático em uma linguagem OO, etc, os discursos sobre desacoplamento e teste de emendas não os influenciarão. Discursos sobre qualquer coisa provavelmente não os influenciarão.
Guarde para si mesmo, e faça as coisas do seu jeito, e então explique sua metodologia quando as perguntas inevitáveis começarem a aparecer como "por que você é capaz de absorver mudanças muito melhor do que o resto de nós?" ou "por que o seu defeito é menor do que o resto de nós?" Neste ponto, você terá o ouvido de alguém - seja desenvolvedores, se eles estiverem genuinamente engajados, mas céticos em relação a suas ideias ou gerentes, caso os desenvolvedores estejam com check-out.Para ser mais sucinto: falar é barato, mas os resultados não são. Obter os resultados e você será solicitado a falar. :)
Uma maneira de fazer com que os desenvolvedores juniores aprendam um paradigma é não permitir que eles toquem na arquitetura. Você cria a arquitetura e soletra as partes do código que elas gravarão. Certifique-se de que eles participam com todos os outros desenvolvedores e ver como tudo se encaixa enquanto eles escrevem o código. A cada semana faça uma revisão de código e dê um tapa nos pulsos para quebrar o padrão e assim por diante ... Essa é uma ótima maneira de aprender, e eles aprendem fazendo isso.
Com o tempo, eles aprenderão o modo de pensar necessário para projetar as coisas em si.
Outra maneira é dar a eles projetos onde a única maneira de resolver o problema é usar um determinado padrão. Quando eles tropeçarem, descobrirão o padrão e / ou verão sua sabedoria e uso.
Eu tentei sentar as pessoas para baixo e explicar a arquitetura para elas, e isso simplesmente passa por cima delas. Dê-lhes um projeto para usá-lo e eles ficarão muito mais fáceis.
IMHO, o melhor livro para criação ainda é o link . No entanto, é um livro para uma pessoa que já está tentando escrever um bom código. Para ensinar, você projeta, deixe-os implementar. Depois, com o tempo, inclua seus bons programadores um pouco mais no processo de design.
Além disso,
"we can't write code fast enough if we do it like that".
é a desculpa mais burra para o trabalho pobre. Por favor, explique ao agressor que é preciso mais tempo para depurar e manter um programa mal escrito do que para escrevê-lo corretamente para começar. Uma pessoa que diz tal coisa, obviamente, nunca teve que ver um pedaço de código através de desenvolvimento para produção para revisão ad infinitum.
Tags refactoring .net cowboy-coding