Come comunicare con un collega che considera le strutture un successo in termini di prestazioni

Dai loro fatti concreti!

Per esempio ci sono benchmark delle prestazioni per i framework ORM e JS. Inoltre, tutti i framework e gli ORM hanno buoni argomenti di vendita nella loro homepage.

Dopo aver letto il tuo commento, credo che nel tuo caso il problema non sia la tecnologia giusta Sono le persone che si rifiutano di imparare nuove tecnologie.

Ho affrontato questo problema prima, le persone che vogliono reinventare la ruota. Di solito spiego loro che possiamo rendere il prodotto migliore e più lucido se passiamo il tempo a perfezionare ciò che è importante, e non ciò che sta sotto. Inoltre ... voglio dire che i framework sono lì per una REASON, e le prestazioni in realtà non sono tanto un problema in questi giorni. L'affidabilità è più importante, e se i framework hanno buone recensioni / valutazioni, probabilmente sono più affidabili di qualcosa che chiunque potrebbe inventare al volo.

Tutti sembrano non essere d'accordo con il collega, ma penso che dovresti prendere sul serio i suoi argomenti se non altro per capire il suo punto di vista. Credo fermamente nei framework quando ne hai bisogno o quando effettivamente forniscono l'ottimizzazione, ma credo anche che l'eccessiva dipendenza da un framework possa portare a uno sviluppo debole in alcuni casi.

Penso che dovresti affrontare il problema meno da un punto di vista che il tuo collega è sbagliato e più dal punto di vista che l'utilizzo dei framework a cui stai pensando migliorerà i tempi di sviluppo, le prestazioni, la manutenzione, ecc.

Cerco sempre di ricordare di usare lo strumento giusto per il lavoro giusto. Non ho bisogno di una slitta da 12 libbre (jQuery) per martellare in un'unghia per appendere un'immagine (scambio di immagini). Ma se mi imbatto in una situazione in cui appendo un'immagine che richiede un picco ferroviario per tenerlo sul muro, è meglio che la slitta sia pronta per andare.

ha ragione, c'è un sovraccarico

ma l'ipotesi che il sovraccarico di un framework sia più di una soluzione codificata a mano potrebbe non essere corretto, e anche se è corretto, il sovraccarico potrebbe non essere significativo.

proponi un test:

• entrambi scrivete qualcosa di realistico ma relativamente piccolo
• usi jQuery (o qualsiasi altra cosa) e può usare niente
• misura due cose:
  1. quanto tempo ci vuole per codificare la soluzione (supponendo che le tue capacità di codifica siano equivalenti)
  2. quanto tempo è necessario per eseguire (ciclo di vita completo) ogni soluzione

è probabile che ci sarà un piccolo sovraccarico con il framework - molto piccolo - ma una enorme differenza in quanto tempo ci vuole per codificare [e debugare!] soluzione

allora il tuo amico può discutere con i fatti, invece che con te

nota: preparatevi per la resistenza continua; molte volte il respingimento contro le strutture è espresso in termini tecnici, ma in realtà è una cortina fumogena per "non inventato qui" o "Non voglio imparare un altro strumento"

Ricorda al tuo collega che reinventa le ruote che ciò che sta facendo è una varietà di ottimizzazione prematura. Come fa a sapere che questi quadri rappresentano un colpo di performance inaccettabile fino a quando non è stato dimostrato che causano un problema. Nel frattempo, la tua reciproca produttività sarà sicuramente diminuita con tutto il lavoro extra che hai dovuto fare.

Che ne pensi di spiegare la performance colpita dal tempo di consegna del progetto quando non utilizzi alcuni di questi enormi framework di risparmio di tempo e testati in battaglia?

Un'opzione potrebbe essere quella di dirgli che si occuperà della messa a punto delle prestazioni - se può essere mostrato c'è un problema di prestazioni! Oppure, se hai le risorse, crea due Proof-of-concept: costruisci il tuo con jQuery e tutto il resto che vuoi. Può costruirlo con il suo sistema super-veloce arrotolato a mano. Non permettere a questo di andare avanti per più di un paio di giorni (è un proof-of-concept) e vedere chi ha prestazioni migliori alla fine.

E, naturalmente, come altri hanno già detto, prendi alcuni numeri e profili prestazionali per entrambi i lati dell'argomento.

In primo luogo, potrebbe avere ragione per la tua situazione specifica.

Dal momento che sembra che tu abbia problemi a fargli vedere il tuo punto di vista, devi fare un lavoro migliore convincendolo.

Voi due siete su due punti diversi lungo la linea tra "Build" e "Buy". Questa è una linea piuttosto lunga. A sinistra, in "Build" c'è SpaceX, che ha dovuto costruire un intero settore. A destra, nel campo "Acquista" si ha l'esternalizzazione completa di tutte le funzioni IT a IBM, HP e simili, e l'azienda non esegue alcuna codifica. Nel mezzo, a circa 2 mm di distanza, siete voi due. Entrambi avete bisogno di convincere il management che il vostro approccio su "build vs buy" sul framework e orm e simili - e con "buy" intendo "non costruito in-house" - è nel migliore interesse dell'azienda, a lungo -termine. Twitter sarebbe morto se si fossero esternalizzati a IBM. Loro rotolarono da soli. Pensaci.

In ogni caso, la direzione deve scendere dal campo da golf e entrare e fare il proprio lavoro.

Bene per l'ORM la risposta è "Solo se si scrive la query in questo modo, lo stesso di cui si può dire per SQL". Come altri hanno già detto, i fatti concreti sono ciò di cui hai bisogno.

Inoltre, fai domande specifiche per approfondire ciò che dice: "Puoi darmi un esempio di JQuery che non funziona, perché non è la mia esperienza".

La terza opzione, e un vecchio sviluppatore saggia mi ha suggerito questo, ma includi comunque la "cosa" (supponendo che non abbia problemi).

La ricerca dell'approvazione porta solo alla risposta "no". Portalo lì, quindi puoi chiedere loro di indicare aree specifiche e chiedere loro di dirti qual è il problema.

"Ehi, questo codice EF riporta solo i 2 dati necessari da quella tabella, qual è il problema" ecc.

Ovviamente, devi essere abbastanza sicuro di te stesso e dello strumento che stai utilizzando prima di procedere con questo approccio! : -)

Il rifiuto delle biblioteche come quello è semplicemente stupido e talvolta arrogante. Le ore di prodotto investite in queste e il pensiero dietro di loro rende il loro rifiuto semplicemente ridicolo.

Può essere che il tuo collega abbia ragione, dal momento che devi confrontare e superare le richieste del software, che è parte del design. Può essere che una soluzione ORM o ActiveRecord sia solo troppo di un overkill o al contrario, che il software abbia bisogno di una soluzione realmente accoppiata per DB e ORM semplicemente non lo taglierà.

Prendere in considerazione queste cose è importante ogni volta che si progetta un software.

Per le librerie lato client dovrei dire che è semplicemente stupido dal momento che è sempre possibile trovare una struttura adatta alle proprie esigenze. E come alcuni hanno detto prima di me, cosa c'è di meglio di un framework testato in battaglia?

Lascialo prendere da tutte le questioni del cross-browser, verrà da te volentieri su come utilizzare un framework.

A proposito, avevo un capo una volta che non contava sui framework. Gli ho appena mostrato quanto sia facile fare richieste di jax invece di copiare le funzioni più e più volte (che era un'Idea stupida in primo luogo), beh lui non sapeva come codificare così ..