Como se comunicar com um colega de trabalho que considera as estruturas um sucesso no desempenho

Como vender uma ideia como "devemos usar jQuery porque é altamente otimizado e compatível com vários navegadores" ou "estrutura de entidades é legal porque é elegante e cuida de nosso modelo automaticamente" quando a resposta comum é uma declaração abrangente como "jquery não tem bom desempenho "ou" entidades trazem 12 colunas para uma tabela quando precisamos apenas de 10 "?

Sou um cara pragmático que tende a confiar em axiomas que desenvolvi através da experiência (não é um problema de desempenho até que haja uma desaceleração visível). Não sei se existe uma "categoria" específica na qual o outro extremo se encaixa, enquanto tudo é um problema de desempenho até que se prove o contrário ... ou mesmo por onde começar a comunicação aqui.

Traga-lhes fatos concretos!

Por exemplo, existem benchmarks de desempenho para estruturas ORM e JS. Além disso, toda a estrutura e o ORM têm bons argumentos de venda em sua página inicial.

Depois de ler seu comentário, acredito que no seu caso o problema não é a tecnologia certa. São as pessoas que se recusam a aprender novas tecnologias.

Eu já enfrentei esse problema antes, pessoas querendo reinventar a roda. Normalmente, explico a eles que podemos melhorar e tornar o produto melhor se passarmos um tempo aperfeiçoando o que é importante, e não o que está por baixo. Além disso ... quero dizer, as estruturas existem por um MOTIVO, e o desempenho realmente não é tão problemático nos dias de hoje. A confiabilidade é mais importante e, se as estruturas tiverem boas críticas / classificações, provavelmente serão mais confiáveis ​​do que algo que qualquer um possa inventar em tempo real.

Todo mundo parece discordar do seu colega, mas acho que você deve levar a sério os argumentos dele por nenhuma outra razão senão entender o ponto de vista dele. Acredito firmemente nas estruturas quando você precisa delas ou quando elas realmente fornecem otimização, mas também acredito que o excesso de confiança em uma estrutura pode levar a um desenvolvimento fraco em alguns casos.

Eu acho que você deve abordar o problema menos do ponto de vista de que seu colega de trabalho está errado e mais do ponto de vista de que o uso das estruturas em que você está pensando melhorará o tempo de desenvolvimento, desempenho, manutenção etc.

Eu sempre tento me lembrar de usar a ferramenta certa para o trabalho certo. Eu não preciso de um trenó de 12 lb (jQuery) para martelar um prego para pendurar uma imagem (troca de imagem). Mas se eu me deparar com uma situação em que estou pendurando uma imagem que requer um pico de ferrovia para mantê-la na parede, é melhor ter esse trenó pronto.

ele está certo, tem sobrecarga

mas a suposição de que a sobrecarga de uma estrutura é mais do que uma solução codificada manualmente pode não estar correta e, mesmo que esteja correta, a sobrecarga pode não ser significativa.

proponha um teste:

• vocês dois escrevem algo realista, mas relativamente pequeno
• você usa jQuery (ou qualquer outra coisa) e ele não pode usar nada
• medir duas coisas:
  1. quanto tempo você leva para codificar a solução (assumindo que suas habilidades de codificação são equivalentes)
  2. quanto tempo leva para executar (ciclo de vida completo) cada solução

as chances são de que haja uma pequena sobrecarga na estrutura - muito pequena -, mas uma enorme diferença em quanto tempo leva para codificar [e depurar!] a solução

então seu amigo pode discutir com os fatos, e não com você

nota: esteja preparado para resistência contínua; muitas vezes, a reação às estruturas é apresentada em termos técnicos, mas na verdade é uma cortina de fumaça para "não inventado aqui" ou "não quero aprender outra ferramenta"

Lembre seu colega que reinventa a roda que o que ele está fazendo é uma variedade de Otimização prematura. Como ele pode saber que essas estruturas representam um impacto inaceitável no desempenho até que se demonstre que causam um problema. Enquanto isso, sua produtividade mútua certamente terá diminuído com todo o trabalho extra que você teve que fazer.

Que tal explicar o desempenho atingido no tempo de entrega do projeto quando você não usa algumas dessas enormes estruturas que economizam tempo e são testadas em batalha?

Uma opção seria dizer a ele que ele fica encarregado do ajuste de desempenho - se é possível mostrar que há um problema de desempenho! Ou, se você tiver os recursos, construa duas provas de conceitos: você constrói a sua com jQuery e tudo o mais que desejar. Ele pode construí-lo com seu próprio sistema super-rápido enrolado à mão. Não permita que isso continue por mais de alguns dias (é uma prova de conceito) e veja quem tem melhor desempenho no final.

E, é claro, como outros já mencionaram, obtenha alguns números concretos e perfis de desempenho para ambos os lados do argumento.

Primeiro, ele pode estar certo para sua situação específica.

Como parece que você está tendo problemas para que ele olhe para o seu ponto de vista, você precisa fazer um trabalho melhor para convencê-lo.

Vocês dois estão em dois pontos diferentes ao longo da linha entre "Build" e "Buy". Esta é uma linha bastante longa. À esquerda, em "Build", você tem a SpaceX, que teve que construir uma indústria inteira. À direita, no "Buy", você tem a terceirização completa de todas as funções de TI para IBM, HP e similares, e os negócios não fazem nenhuma codificação. No meio, com cerca de 2 mm de distância, vocês dois são. Vocês dois precisam convencer a gerência de que sua abordagem sobre "construir versus comprar" na estrutura e organização e tal - e com "comprar" quero dizer "não construído internamente" - é do interesse da empresa, por muito tempo. -prazo. O Twitter teria morrido se eles terceirizassem para a IBM. Eles rolaram os seus. Pense sobre isso.

De qualquer forma, a gerência precisa sair do campo de golfe e entrar lá e fazer o trabalho deles.

Bem, para o ORM, a resposta é "Somente se você escrever sua consulta dessa maneira, o mesmo pode ser dito para SQL". Como outros já disseram, fatos concretos são o que você precisa.

Além disso, faça perguntas específicas para descobrir o que ele diz - "Você pode me dar um exemplo de JQuery não executando porque essa não é a minha experiência".

A terceira opção, e um desenvolvedor antigo e sábio sugeriu isso para mim, apenas inclua a "coisa" de qualquer maneira (supondo que ela não tenha problemas).

Buscar aprovação apenas leva à resposta "não". Coloque-o lá, então você pode pedir que aponte para áreas específicas e peça que lhe digam qual é o problema.

"Ei, esse código EF, traz de volta apenas os 2 itens de dados necessários dessa tabela, qual é o problema" etc.

Obviamente, você precisa estar bastante confiante em si mesmo e na ferramenta que está usando antes de prosseguir com essa abordagem! :-)

Rejeitar bibliotecas como essa imediatamente é estúpido e às vezes arrogante. As horas de produto investidas nelas e o pensamento por trás delas tornam a rejeição delas simplesmente ridícula.

Pode ser que seu colega esteja certo, já que você precisa comparar e superar as demandas do software, que faz parte do design. Pode ser que uma solução ORM ou ActiveRecord seja um exagero ou, pelo contrário, que o software precise de uma solução realmente acoplada para o DB e o ORM simplesmente não será suficiente.

Levar essas coisas em consideração é importante sempre que você cria um software.

Para as bibliotecas do lado do cliente, devo dizer que é completamente estúpido, pois você sempre pode encontrar uma estrutura adequada às suas necessidades. E, como alguns disseram antes de mim, o que é melhor do que uma estrutura testada em batalha?

Deixe que ele elimine todos os problemas entre navegadores, ele entrará em contato com você de bom grado sobre como usar uma estrutura.

Btw, eu já tinha um chefe que não contava com frameworks. Eu apenas mostrei a ele como é fácil fazer solicitações de ajax em vez de copiar as funções repetidamente (o que foi uma Idéia idiota em primeiro lugar), bem, ele não sabia como codificar isso ..