Como você faz as pessoas valorizarem a abstração e a flexibilidade sobre "apenas fazer isso"?

Question

Às vezes, tenho dificuldades com outras pessoas que desejam resolver um problema quando desejam pular as interfaces oficiais e acessar diretamente os detalhes da implementação subjacentes.

Eles argumentam que isso permitirá que eles resolvam o problema mais rapidamente. Argumento que isso fará com que nossa arquitetura se torne mais fortemente acoplada e difícil de mudar à medida que novos requisitos surgem.

Aponto todo o trabalho que entrou no design atual e na filosofia do design e no valor da flexibilidade, o custo de tentar manter e alterar o código quebradiço, o valor do encapsulamento e do esconderijo de dados e arquiteturas em camadas e ser robusto essas pequenas alterações na especificação levam a pequenas alterações no código. E eles dizem "mas isso seria mais fácil".

Como você lida com essas pessoas?

Answer 1

Convencê -los de que levar atalhos é uma economia falsa.

Explique que o inicial codificação O esforço é inferior a 30% do esforço inicial de desenvolvimento e menos de 10% (na minha experiência) do esforço geral do projeto (incluindo manutenção).

Se eles permanecerem não convencidos e você tem autoridade para fazê -lo, diga -lhes para fazer o seu jeito. Se você não tem autoridade, não faça mais nada. Eventualmente, seu supervisor, se ela vale alguma coisa, reconhecerá isso e você estará na posição de autoridade.

Answer 2

Peça que eles trabalhem em algum código legado, corrigindo os bugs nele. É assim que a maioria das pessoas que eu conheço aprendeu essas lições realmente valiosas ... da maneira mais difícil.

Answer 3

"Mais fácil" quando? Agora, quando tudo não está em estado de fluxo? Ou daqui a três meses, quando os requisitos do cliente mudaram e eles têm uma 'solução' que não é mais uma solução?

Não sou muito por estrutura e regras por uma questão de estrutura e regras, mas é bom saber a) quem está dirigindo o barco b) quais são as regras e c) por que escolhemos fazê -lo dessa maneira.

Na minha loja, não gostamos de reescrever o código porque estragamos e codificamos um monte de coisas ou criamos uma 'solução' quebradiça para o problema. Tende a não ser mais difícil seguir a abordagem mais flexível, uma vez que as pessoas percebem que isso reduzirá as frustrações mais tarde quando as coisas forem de cabeça para baixo por várias mudanças de requisitos. Nós codificamos o 'longo transporte' não para 'precisam hoje', normalmente, então o design é feito por uma razão E o design é seguido pela mesma razão.

Passei uma semana da minha vida (7 dias consecutivos) reescrevendo um módulo porque estava no modo 'Get It Quick'. Sete dias de tempo cansativo, de 10 a 12 horas, fazendo da maneira certa, no final do jogo, quando eu poderia estar assistindo o Super Bowl. Aquele fedor. Eu aprendi uma lição lá. Pode ser que seus 'amigos' precisem experimentar esse tipo de abridor de olhos também.

Boa sorte!

Answer 4

Na verdade, eu odeio tomar a opinião dissidente sobre isso, mas ...

Para citar Van Halen (citando clichê): "Há um tempo e um lugar para tudo". Embora eu certamente não defenda mal escrever, às vezes, você precisa apenas fazê -lo e encontrar aquele meio feliz entre robusto/duradouro e hackeado/documentado. (A parte documentada é particularmente importante, em duas frentes: uma, que você indica claramente que o que quer que esteja fazendo está sendo feito simplesmente no interesse de fazê -lo e está pegando certos atalhos; e, dois, uma ideia aproximada Quanto à maneira mais correta de abordar o problema.

Como programadores, muitas vezes nos esforçamos para escrever o código perfeito (bem, alguns de nós) e, às vezes, perdemos de vista o quadro geral - há várias razões pelas quais pode ser bom (em um nível) jogar rápido e solto com o código, minimizando o impacto que terá no futuro.

Por favor, não use isso como justificativa - a regra 80/20 se aplica aqui, é claro. Na maioria das vezes, você deseja esmagar quaisquer atalhos nesse sentido; mas às vezes...

Answer 5

Mostre a eles! Deixe -os fazer um pequeno módulo em "Mas isso seria mais fácil". estilo enquanto você faz da maneira certa. Em seguida, peça que façam de 2 a 5 alterações nos requisitos (deve estar fazendo as alterações) e ter um concurso cronometrado na implementação das alterações. Pode levar um ou dois dias, mas eles conseguirão. Caso contrário, você terá a mesma discussão sobre todos os novos projetos ou tarefas.

Answer 6

Você poderia tentar uma analogia neles ....

As regras do xadrez são bem simples. Você pode ensiná -los a uma criança: "Os movimentos do cavalo como este", "o castelo se move como este", etc.

Se isso é tudo o que você sabe, você pode jogar um pouco de xadrez e provavelmente se divertir, mas alguém com um conhecimento mais profundo do jogo vai limpar a prancha com você sempre. Você será tão ruim que nem será mais divertido, porque você não terá idéia de como eles estão fazendo isso.

O mesmo princípio se aplica à programação. Conhecer a sintaxe do idioma e algumas estruturas de dados simples é suficiente para obter um programa de trabalho, mas você não terá muita sorte com um aplicativo em larga escala que precisa sobreviver a vários ciclos de liberação.

O xadrez definiu aberturas, estratégias de ataque, etc. Temos padrões de design.

Answer 7

A melhor coisa é provavelmente promovê -los à gerência, para que eles não possam causar tantos danos.

Answer 8

O problema é que a maioria das pessoas nem sabe sobre o design de software além dos conceitos mais básicos e do desenvolvimento de estilo de arrastar e soltar. Para todos os desenvolvedores que pesquisam e se educam sobre todos os melhores conceitos e tecnologias novos, há dez que vão para casa e não olham para um PC. Você tem que ensiná -los.

Answer 9

Eu projetei um sistema grande e complicado há cerca de cinco anos. Passei os cinco anos seguintes me injetando em todos os projetos que afetaram o sistema "meu" para impedir que os bárbaros resulçam na minha arquitetura. Enquanto eu aplicava uma pressão constante e implacável, consegui manter a arquitetura bastante limpa, mas estava travando uma batalha perdida. Aqui está o porquê:

1) A maioria das pessoas é julgada sobre se fizeram o trabalho hoje. Ninguém nunca foi repreendido porque eles cortaram uma esquina (ou dois) há três anos para obter um projeto a tempo. Por outro lado, muitas pessoas tenho foi repreendido por não obter projetos para fora da porta a tempo.

2) Você pode querer manter o sistema arrumado porque tem um senso de propriedade sobre o código, ou o aplicativo, ou os usuários, etc. Muitas pessoas não terão um senso de propriedade e, portanto, estão felizes em invadir algo Então eles podem ser feitos com isso. Você pode levar um cavalo à água, mas não pode fazê -lo se importar.

3) Se você Faz Convença todos a manter o código adequadamente, novas pessoas entrarão a bordo e precisam ser ensinadas a fazer as coisas certas. Portanto, mesmo se você for bem -sucedido, pode sentir que está falhando porque está sempre travando a mesma batalha contra novos oponentes.

4) Você pode realmente estar errado. Faria sentido financeiro para a Microsoft gastar o dobro de horas de programador tornando o MS-Paint robusto e sustentável? Às vezes, um sistema feio de hacked-together é bom o suficiente. A maioria dos bons programadores tem problemas para entender isso, mas isso geralmente ocorre porque são bons programadores.

5) Juro que há algumas pessoas que têm prazer perverso em invadir as coisas porque podem fazê -lo mais rapidamente, ou serão as únicas que o entendem, ou têm uma necessidade infantil de quebrar as regras. Você não pode argumentar com essas pessoas e quanto mais tempo gasta discutindo com elas, mais próximo o prazo do projeto chegar, o que o forçará a invadir algo juntos de qualquer maneira.

6) Há uma boa chance de você entender o sistema melhor do que eles. O que parece um hack feio para você pode parecer "pisar levemente" para uma pessoa que não está tão familiarizada com o sistema. Ou o esforço extra para tornar o código robusto protegerá o programador contra um problema que ele nunca teve antes e, portanto, não pode se divertir. Você não aprende a verificar os códigos de retorno até que algo dê errado porque você não Verifique um código de retorno. Nesse ponto, ele deixa de ser "trabalho extra" e começa a ser "trabalho necessário".

Se você tem uma equipe de desenvolvimento pequena e apertada, é possível. Mas quanto maior a organização, menor a probabilidade de você ter sucesso. Se você conseguir uma loja de TI de 250 pessoas para valorizar fazer as coisas em relação a fazer as coisas rapidamente, seus poderes de persuasão são lendários.

Answer 10

http://catb.org/jargon/html/l/lart.htmlScnr, etc. pp;)

Answer 11

Diga a eles para ler (não que nunca)) teoria do encapsulamento:http://www.edmundkirwan.com/