Como convencer Programação da equipe para deixar ir de Old Ways?

Question

Esta é mais uma questão de programação orientada a negócios que eu não consigo descobrir como resolver. Eu trabalho com uma equipe de programadores que têm vindo a trabalhar com BASIC há mais de 20 anos. I foi trazido para ajudar a escrever o mesmo software em .NET, apenas com atualizações e práticas modernas. O problema é que eu não consigo obter qualquer um dos outros membros da equipe 3 (todos os programadores BASIC, embora se faz .NET, bem como agora) para entender como fazer corretamente um banco de dados relacional. Aqui está a coisa eles não vão entender:

Nós temos basicamente uma transação que mantém o controle de informações tag de um cliente. Precisamos ser capazes de rastrear transações correntes e transações passadas. No sistema antigo, um banco de dados de arquivo simples foi usado que tinha uma tabela que continha registros com a transação corrente básica do cliente e outra transação que continha todas as transações anteriores do cliente junto com informações dinheiro importante. Para evitar redundância, eles iriam substituir a transação corrente com o Transações história (o arquivo de histórico foi atualizado primeiro, então o atual.) É totalmente desnecessário, pois você só precisa de uma tabela de transação, mas meu supervisor ou qualquer um dos meus outros dois co -trabalhadores não consigo entender isso. Como exatamente eu posso convencê-los a ver a tão leve que não terá que fazer quantidades ridículas de trabalho e acabar batendo o datatabse muitas vezes? Obrigado pela contribuição!

Answer 1

Em primeiro lugar devo admitir que não está absolutamente claro para mim a partir de sua descrição que as estruturas de dados e lógica flui nas estruturas existentes realmente são. Isto implica-me que talvez você não está fazendo-se claro para seus colegas de trabalho ou, então, uma das suas prioridades deve ser a de ser capaz explicar, verbalmente ou de preferência por escrito e diagramas, a situação atual e a proposta de substituição. Por favor, tome isso como uma observação ao invés de qualquer crítica da sua pergunta.

Em segundo lugar eu acho que é bastante notável que os programadores de 20 anos de experiência não compreendem bancos de dados relacionais e transações. arquivo simples codificação saiu do mainstream muito tempo atrás - eu segurei primeiro bancos de dados relacionais em um cenário de volta comercial em 1988 e eles eram muito comuns em meados dos anos 90. O setor eo tipo de produto que você está trabalhando? Parece possível para mim que você pode estar lidando com algum tipo de sistema 'incomum' incorporado ou de outra forma, caso em que você precisa fazer para se certificar de que você não tem algum tipo de problema de comunicação e você está com vista para um grande elefante que não tenha sido apontado para você - você não seria a primeira 'consultor' trazido para uma equipe que foi criado, de alguma maneira, não sendo alimentado as informações apropriadas. Que disse que tais lojas arcaicas ainda existem - um de meus clientes atuais interfaces de sistemas para um sistema baseado em arquivo simples codificado em COBOL, e sim, ele é o inferno para gerenciar; -)

Finalmente, se você está completamente certo de sua terra e você se depara com uma equipe que não vai levar em conta as suas recomendações - e código de demonstração é uma boa idéia se você pode poupar o tempo -então você provavelmente vai ter a aceitar a decisão graciosamente e mover um. -Me nesta posição que eu iria tentar abstrair a questão - podem as atualizações do banco de dados ser movido para procedimentos armazenados, por exemplo, para que o código para atualizar ambas as tabelas é no SP e podem ser modificados em uma data posterior para se deslocar para o esquema sem um mudança aplicação correspondente? Certifique-se de seus argumentos estão bem documentados e registrados para que você possa revê-las mais tarde deve surgir a oportunidade.

Você não será o primeiro codificador que teve para implementar uma solução sub-óptima por causa da política do escritório - usá-lo como uma experiência de aprendizagem para o seu próprio desenvolvimento pessoal sobre como lidar com tais situações e solidarizar-se com o que você vai receber o pagamento para o trabalho adicional. Muitas vezes o fator decisivo em tais argumentos não é a lógica, mas o "peso da reputação que você se trazer para a mesa - que parece ter sido trazido você não tem muito desse tipo de alavancagem com sua equipe, para que pode ter que trabalhar em ganhar uma reputação por exceling a implementar o que eles concordam em fazer antes de ter reputação suficiente em casos posteriores - você precisa ser modded-se primeiro

Answer 2

Às vezes, você não pode.

Se você ler alguns livros XP, eles costumam dizer que um de seus maiores obstáculos será convencer a sua equipe para abandonar o que sempre fizeram.

Geralmente eles vão recomendar deixar as pessoas que não conseguem se adaptar ir para outros projectos (Ou simplesmente deixá-los ir).

As revisões de código pode ajudar no seu caso. Obrigatórias revisões de código de cada linha de código não é inédito.

Answer 3

Às vezes o melhor argumento é um exemplo. Eu ia escrever um protótipo (ou uma substituição, se não muito trabalho). Com um exemplo para examinar será mais fácil para ver os prós e contras de um banco de dados relacional.

Como um aparte, bancos de dados de arquivos simples têm seus lugares uma vez que são muito mais fácil de "administrar" do que um banco de dados relacional verdadeiro. Mantenha a mente aberta. ; -)

Answer 4

Eu acho que você pode ter que dar o exemplo - quando as pessoas vêem que a maneira "nova" é menos trabalho eles vão adotá-lo (contanto que você não esfregue seus narizes nele)

.

Também gostaria de perguntar se o design antigo que realmente está causando um problema ou se é apenas esteticamente desagradável. É importante escolher suas batalhas - se o projeto antigo não está causando um problema de desempenho ou tornar o sistema difícil de manter você pode querer deixar o design antigo sozinho.

Finalmente, se você deixar o velho projeto no lugar, e tentar abstrair a interface entre o novo código e banco de dados antigo então se você convencer seus colegas de trabalho para melhorar o design mais tarde, você pode soltar o novo esquema no sem ter que mudar qualquer outra coisa.

Answer 5

É difícil extrair um lote inteiro, exceto frustração geral da pergunta original.

Sim, há uma série de técnicas e hábitos de longa temporizadores pegar ao longo do tempo que pode ser inútil e até mesmo caro, tendo em conta as mudanças tecnológicas. Algumas coisas que faziam sentido quando poder de processamento, memória e até mesmo disco foi caro pode ser tentativas tolas em otimização agora. Também é muito o caso que as pessoas acumulam maus hábitos e padrões de programação ruins ao longo do tempo.

Você tem que ter cuidado embora.

Às vezes, há boas razões para as coisas que esses veteranos fazer. Infelizmente, eles não podem sequer ser capaz de verbalizar o "porquê" -. Se eles ainda saber por que mais

Eu vejo um monte de este tipo de frustração quando novatos entram em uma loja de desenvolvimento de software corporativo. Pode ser ruim, mesmo quando o ambiente é toda a tecnologia e ferramentas bastante moderno. Se a maioria de sua experiência é, por escrito, desktop e web aplicações de pequena comunidade muito do que você "sabe" pode estar errado.

Muitas vezes, há requisitos para a transação no diário em um nível acima do que seu DBMS pode fazer. Muitas vezes pode ser necessário ir além semântica de transação DB, a fim de garantir a correção-seqüência de tempo, apenas uma única vez atualização, resiliancy, e não repúdio.

E isto nem sequer começar a abordar as questões envolvidas na empresa ou entre empresas escalabilidade. Quando você começa a aproximar-se de meio milhão de transações complexas um dia você vai achar que a tecnologia RDBMS falhar você. Como bancos de dados relacionais não são projetados para lidar com altos volumes de transação você deve muitas vezes romper com paradigmas convencionais de normalização e de atualização. técnicas de bloqueio convencional RDBMS pode destruir escalabilidade não importa o quanto de hardware que você jogue com o problema.

É fácil descartar tudo isso como stodginess ou errado de cabeça em geral - mesmo incompetência. Mas cuidado, porque este não é sempre o caso.

E a propósito: Existem outros modelos além do RDBMS, e a alternativa para um RDBMS não é necessariamente "flat files" - ao contrário da experiência de da maioria dos codificadores hoje. Há transacional hierárquica SGBDs que pode lidar com muito maior rendimento do que um RDBMS. IMS ainda está muito vivo em grandes lojas da IBM, por exemplo. Outros fornecedores oferecem software similar para diferentes plataformas.

É claro que em uma loja 4-homem talvez nada disso se aplica.

Answer 6

Inscreva-los para alguns treinamentos decentes e, em seguida, cabe a você para convencê-los de que, com as novas tecnologias é possível muito mais (ou pelo menos mais fácil!).

Mas eu acho que a coisa mais importante aqui é que profissionais, formadores certificados ensinar-lhes o básico primeiro. Eles serão mais impressionado com que, em vez de apenas um de seus colegas dizendo-lhes: "Ei, por que não usar essa"

post relacionado aqui .

Answer 7

O seguinte não podem ser aplicadas em situação yr, mas você faz muito pouca menção de detalhes técnicos, então eu pensei que eu iria falar dele ...

Às vezes, se os padrões de acesso são muito diferentes para os dados atuais do que para os dados históricos (Eu estou fazendo este exemplo, mas dizem que os dados atual é acessado 1000s de vezes por segundo, e acessa um pequeno subconjunto de colunas, e tudo se encaixa atuais de dados em menos de 1 GB, enquanto que, por exemplo, utiliza dados históricos 1000s de GBs, é acessado apenas 100s de vezes por dia, eo acesso é para todas as colunas),

então, o que seus colegas de trabalho estão fazendo faria todo o sentido, para otimização de desempenho. Ao separar os dados atuais (albiet redundante) você pode otimizar os índices e estruturas de dados na tabela, para os paterns acesso frequência mais alta que você não poderia fazer na tabela histórica.

Nem tudo o que é "academicamente", ou "tecnicamente" correta a partir de uma perspectiva puramente relacional faz sentido quando aplicado em uma situação prática real.