Perché dovremmo (non) svilupparci su un server tramite RDP

Naviga le tue risposte
1

Ho un cliente che richiede che sviluppiamo la loro piccola applicazione web direttamente nel loro ambiente da RDP al server che ospiterà l'app. Hanno avuto un appaltatore per un po 'e ha funzionato "bene" per loro, quindi sono a loro agio con questo approccio. La principale preoccupazione del cliente a questo punto è tagliare i costi: hanno un budget molto limitato.

Il mio manager non sembra preoccuparsi o pensa che faccia la differenza. Tuttavia, non sono assolutamente d'accordo con quella pratica.

In quale modo posso convincere il cliente che è una cattiva pratica fare le cose in questo modo? Ho bisogno di usare la lingua "di gestione", non quella dello sviluppatore.

Posso pensare ad alcuni vantaggi dello sviluppo locale (come sviluppatore):

  1. Non possiamo garantire la qualità del codice nell'ambiente remoto (perché no?)
  2. La collaborazione interna al team aumenta l'efficienza (come?)
  3. Internamente, possiamo sfruttare meglio il controllo del codice sorgente (sebbene possa essere installato anche sul server)
  4. Internamente, possiamo seguire processi di controllo della qualità migliori
  5. Con RDP, solo uno sviluppatore può lavorare su un progetto alla volta
  6. Lo sviluppo a livello locale aumenta l'efficienza di uno sviluppatore (come? Forse perché è la loro zona di comfort? magari con più monitor? come va a vantaggio del cliente?)

Sfortunatamente, questi non si traducono necessariamente in apprezzamenti da parte del management (ad esempio dollari e centesimi)

Aiutatemi.

    
posta Alfero Chingono 11.04.2014 - 23:06
fonte

4 risposte

5

Stai cercando di usare un bulldozer per zappare un giardino. Smettila.

Il client & la tua gestione è soddisfatta del processo attuale (primitivo, semplice, pericoloso).

Questo processo funziona per una piccola app con un singolo sviluppatore affidabile.

Dato che stai apportando tutte le modifiche alla produzione, se introduci un bug è probabile che qualcuno lo individuerà rapidamente. Non tutte le aziende considerano un bug come catastrofico: si aspettano solo che tu lo aggiusti. Hanno anche un feedback immediato sul lavoro che stai facendo.

Questo tipo di cliente è relativamente poco sofisticato e potrebbe non apprezzare il valore che test, controllo del codice sorgente, collaborazione del team, QA, backup ecc. possono portare.

Fino a quando il cliente non è pronto ad avanzare, qualsiasi tentativo di portare "tutto ciò che è in testa" sarà ostacolato.

(Da un punto di vista tecnico, ovviamente sei assolutamente corretto. Dal punto di vista del business, tutta quella roba techno mumbo-jumbo sembra complicata e non visibilmente aggiunta alla linea di fondo)

    
risposta data 11.04.2014 - 23:39
fonte
5

Hai trovato la risposta che desideri e ora stai solo sollecitando la conferma. FERMA IT .

La domanda corretta non è "Perché non dovremmo ...." - piuttosto è "Dovremmo ..." Ricercare la domanda sottostante , non provare solo a supportare la risposta che desideri.

Ecco alcuni antipasti:

PRO

  • Minori costi (più thin client)
  • Maggiore flessibilità (qualsiasi macchina farà tutto il tempo necessario per supportare RDP)
  • Singolo ambiente prevedibile per la costruzione e lo sviluppo
  • Maggiore controllo sul codice; tutto rimane in un posto
  • Il codice non può "perdersi" sul laptop di qualcuno da qualche parte; la gestione sa sempre dove è l'ultima versione
  • Facile trasferimento della proprietà del progetto tra i programmatori; basta dare loro la nuova VM
  • e molto altro. Non sto cercando di provare ...

CON

  • Solo una copia = singolo punto di errore
  • Maggiore opportunità di esfiltrazione da segreto commerciale da parte di uno sviluppatore malevolo
  • Richiede una connessione Internet sempre attiva
  • L'ambiente di sviluppo è esasperante rispetto a un link a latenza elevata
  • A volte RDP "si intromette": i tasti vengono interpretati dal sistema operativo host, ad esempio
risposta data 12.04.2014 - 07:51
fonte
4

Ah, il cliente con un sito web di piccole dimensioni che non vuole pagare troppo.

Non puoi argomentare la tua strada è meglio quando il cliente ha la prova che l'altro sviluppatore è stato in grado di farlo funzionare. Fai sapere al cliente che il tuo gruppo non è abituato a lavorare in quel modo e se devi modificare drasticamente il tuo modo di lavorare, non puoi prevedere quanto sarai efficace. Da un punto di vista finanziario, il cliente non dovrebbe voler pagare per sperimentare e imparare sul suo tempo. Forse funzionerà, ma non può correre questo rischio. Non vuoi fare promesse che non puoi mantenere.

Da un punto di vista commerciale e tecnico questo è un cattivo cliente. Le restrizioni dell'ambiente di sviluppo sono una caratteristica che il cliente non vuole veramente pagare.

    
risposta data 14.04.2014 - 15:33
fonte
3

Una connessione RDP sarà più lenta su cui lavorare a causa della latenza. Digiterete una riga di codice e dovrete aspettare un po 'affinché venga visualizzata. Su una connessione veloce (LAN) questo probabilmente non sarà evidente, ma su una connessione lenta (come su un collegamento ADSL) questo sarà notevole, e (nella mia esperienza):

  1. Ti fa lavorare molto più lentamente (mentre aspetti che la tastiera e il puntatore del mouse rimangano al passo). Se fatturi per ora, potrebbe trattarsi di un problema con il tuo cliente.
  2. Fai impazzire lentamente (dopo un'ora di lavoro su RDP ho rinunciato e ho appena guidato l'altro ufficio).
risposta data 12.04.2014 - 07:07
fonte

Leggi altre domande sui tag

Proteggi le immagini in una pagina Web Test dell'unità di scrittura solo per le applicazioni che li richiedono [chiuso]