Come comunicare con un collega che considera i framework un successo nelle prestazioni

Come si può vendere un'idea come "dovremmo usare jQuery perché è altamente ottimizzato e compatibile con più browser" o "il framework di entità è bello perché è pulito e si prende cura del nostro modello automagicamente" quando la risposta comune è una dichiarazione coperta come "jquery non funziona bene "o" le entità portano 12 colonne in una tabella quando abbiamo bisogno solo di 10 "?

Sono un ragazzo pragmatico che tende a fidarsi degli assiomi che ho sviluppato attraverso l'esperienza (non è un problema di prestazioni fino a quando non c'è un rallentamento visibile). Non so se esiste una "categoria" specifica in cui si inserisce l'altro estremo, mentre tutto è un problema di prestazioni fino a prova contraria ... o anche da dove iniziare la comunicazione qui.

Porta loro fatti concreti!

Ad esempio, ci sono benchmark di performance per i framework ORM e JS. Inoltre, framework e 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 apprendere nuove tecnologie.

Ho affrontato questo problema prima, le persone che volevano 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 un MOTIVO, e le prestazioni non sono un grosso problema al giorno d'oggi. L'affidabilità è più importante e se i framework hanno buone recensioni / valutazioni allora sono probabilmente 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 le sue argomentazioni se non altro per capire il suo punto di vista. Sono fermamente convinto dei framework quando ne hai bisogno o quando forniscono effettivamente 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 dal punto di vista del fatto che il tuo collega ha torto 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 tenere a mente l'uso dello strumento giusto per il lavoro giusto. Non ho bisogno di una slitta da 12 libbre (jQuery) per martellare un chiodo per appendere un'immagine (scambio di immagini). Ma se mi imbatto in una situazione in cui sto appendendo un'immagine che richiede un picco di ferrovia per tenerlo sul muro, è meglio che quella slitta sia pronta per partire.

ha ragione, c'è un sovraccarico

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

proporre un test:

• entrambi scrivete qualcosa di realistico ma relativamente piccolo
• usi jQuery (o qualunque altra cosa) e lui non può usare nulla
• misurare due cose:
  1. quanto tempo impieghi entrambi a codificare la soluzione (supponendo che le tue capacità di codifica siano equivalenti)
  2. quanto tempo impiega per eseguire (ciclo di vita completo) ogni soluzione

è probabile che ci sarà un piccolo overhead con il framework - molto piccolo - ma un'enorme differenza nel tempo impiegato per codificare [ed eseguire il debug!] la soluzione

allora il tuo amico può discutere con i fatti, anziché con te

nota: essere preparati per la resistenza continua; molte volte il respingimento dei framework è definito in termini tecnici, ma in realtà è una cortina di fumo per "non inventato qui" o "Non voglio imparare un altro strumento"

Ricorda al tuo collega che reinventa la ruota che ciò che sta facendo è una varietà di ottimizzazione precoce. Come può sapere che questi framework rappresentano un inaccettabile successo prestazionale fino a quando non viene dimostrato che causano un problema. Nel frattempo, la tua produttività reciproca sarà sicuramente diminuita con tutto il lavoro extra che hai dovuto fare.

Che ne dite di spiegare il successo delle prestazioni ai tempi di consegna del progetto quando non utilizzate alcuni di questi enormi framework risparmiati in tempo e testati in battaglia?

Un'opzione sarebbe quella di dirgli che deve essere responsabile del tuning 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 desideri. Può costruirlo con il suo sistema superveloce arrotolato a mano. Non permettere che ciò continui per più di un paio di giorni (è una prova di concetto) e vedi chi alla fine ha prestazioni migliori.

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

In primo luogo, potrebbe essere giusto per la tua situazione specifica.

Dal momento che sembra che tu abbia problemi a convincerlo a guardare il tuo punto di vista, devi fare un lavoro migliore per convincerlo.

Voi due siete su due punti diversi lungo la linea tra "Build" e "Buy". Questa è una linea piuttosto lunga. A sinistra, in "Build" hai SpaceX, che ha dovuto costruire un intero settore. A destra, nella sezione "Acquista" hai l'outsourcing completo di tutte le funzioni IT a IBM, HP e simili, e l'azienda non codifica affatto. 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" nel framework e orm e cose del genere - e con "buy" intendo "non costruito internamente" - è nel migliore interesse dell'azienda, a lungo -termine. Twitter sarebbe morto se si fosse affidato in outsourcing a IBM. Hanno rotolato il loro. Pensaci.

In entrambi i casi, la direzione deve scendere dal campo da golf, entrare e svolgere il proprio lavoro.

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

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

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

Cercare l'approvazione porta solo alla risposta "no". Fallo entrare, quindi puoi chiedere loro di indicare aree specifiche e chiedere loro di dirti qual è il problema.

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

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

Ben rifiutare le biblioteche come quelle fuori mano è stupido e talvolta arrogante. Le ore di prodotto investite in questi e il pensiero dietro di loro rende il rifiuto semplicemente ridicolo.

Può essere che il tuo collega abbia ragione, dato che devi confrontare e superare le esigenze del software, che fa parte del progetto. Può darsi che una soluzione ORM o ActiveRecord sia troppo esagerata o al contrario, che il software abbia bisogno di una soluzione realmente accoppiata per il DB e ORM non la taglierà.

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

Per le librerie lato client dovrei dire che è semplicemente stupido poiché puoi sempre trovare un framework adatto alle tue esigenze. E come alcuni hanno detto prima di me, cosa c'è di meglio di un framework testato in battaglia?

Lascia che si occupi di tutti i problemi del cross-browser, verrà da te volentieri riguardo a come usare un framework.

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