Come valutare le recensioni dei prezzi per incoraggiare un buon comportamento? [chiuso]

4

Lavoro per un'azienda che ha un'applicazione Internet .net ospitata con molti clienti. Questi clienti spesso desiderano scrivere personalizzazioni per la nostra applicazione. Abbiamo delle API da collegare all'app, ma le personalizzazioni sono scritte in .net. Si tratta di un ambiente di hosting condiviso e sicuro e dobbiamo codificare la revisione di queste personalizzazioni prima di poterle distribuire nel nostro datacenter per garantire che non degradino le prestazioni, danneggino i nostri server o aprano vulnerabilità di sicurezza. Facciamo pagare per queste recensioni del codice.

L'attuale modello di prezzo è semplicemente una funzione del numero di linee di codice. Penso che questa sia una cattiva idea per una serie di motivi, ma principalmente perché, se siamo interessati a verificare che il codice funzioni come previsto, dovremmo incentivare un codice buono, leggibile, non una compattazione.

Vorrei proporre un modello di determinazione del prezzo che incorpori alcuni o tutti i seguenti input:

  • Linee di codice
  • Complessità ciclomatica
  • Lunghezza della funzione media
  • numero di funzioni

Esistono altre metriche che dovrei includere o altre idee su come possiamo ragionevolmente creare prezzi per le revisioni del codice che incoraggiano un codice sicuro e comprensibile?

    
posta Chris Clark 02.02.2011 - 20:36
fonte

5 risposte

5

Francamente, penso che sia terribilmente coraggioso da parte tua offrire questa opzione in un ambiente di hosting condiviso . Ci sono anche database in uso che sono condivisi?

Se questa era una società per la quale ho lavorato, suggerirei di rottamare completamente la nozione di pagamento per riga o altra metrica e di sostituirla con commissioni forfettarie basate su quale funzionalità era in uso. Strutture di prezzo complesse sono un "odore aziendale" (se posso rubare un termine dalla programmazione).

    
risposta data 02.02.2011 - 21:03
fonte
3

La copertura del test sarebbe minima. Dovrebbe includere test progettati per cercare i problemi relativi alla sicurezza, agli arresti anomali e alle prestazioni del sito. Questo sarebbe in aggiunta ai criteri di valutazione del codice statico che hai citato.

Il tuo prezzo per questo livello di certificazione dovrebbe essere basato sui requisiti di personalizzazione dei clienti. È necessario preparare un piano di certificazione che delinei sia le valutazioni statiche che dinamiche che verranno eseguite.

    
risposta data 02.02.2011 - 20:56
fonte
3

La copertura del test potrebbe essere un'altra area che varrebbe la pena aggiungere, poiché ciò può aiutare quando vengono aggiunte nuove cose per garantire che le cose non siano interrotte.

L'utilizzo del modello di progettazione può essere un'altra idea per aiutare a rendere il codice più organizzato a volte, in quanto ci sono momenti in cui questo può essere molto utile per aiutare a rendere il codice comprensibile.

I test forniscono una documentazione iniziale di alcune delle funzionalità del codice che possono essere utili se qualcuno sta per scavare nel codice in un certo senso. Non sono sicuro di quanto approfondito nel codice che si desidera ottenere con le recensioni, ma l'idea per me sarebbe che i test potrebbero fornire un buon punto di partenza per entrare nel codice. Mentre questa è un'opinione un po 'ottimistica, a volte la vita può funzionare in questo modo.

    
risposta data 02.02.2011 - 20:49
fonte
1

GrandmasterB ha l'idea giusta: se inizi a negoziare con i clienti su LOC o con la funzione avg (che è solo LOC in un bel vestito), stai cercando dei guai. Cerca invece di fatturare per l'utilizzo di API / risorse, analisi di sicurezza e copertura dei test. Se, ad esempio, utilizzano un'API per eseguire un aggiornamento completo del database, le revisioni su base funzione / metodo dovrebbero essere più rigorose / costose di quanto se tutto ciò che stanno facendo sia estrarre i dati per una presentazione aggiuntiva.

Una revisione del codice di utilizzo dell'API di aggiornamento avrà

  • un componente significativo della recensione sulla sicurezza
  • una recensione approfondita sulla copertura dei test
  • un'attenta revisione standard del codice su base funzione / metodo

Al contrario, se tutto ciò che stanno facendo è recuperare informazioni per il loro livello di presentazione, la sicurezza e la revisione della copertura di prova possono essere significativamente limitate e meno costose. Non si è dopo tutto il loro dipartimento di QA. La tua preoccupazione è che non implementano nulla che possa avere un impatto sul tuo ambiente condiviso.

    
risposta data 02.02.2011 - 21:37
fonte
0

La tariffa oraria sembra equa (GrandmasterB). Un cliente potrebbe inviare il codice e potresti fornire un preventivo. Attraverso l'esperienza, dovresti essere in grado di determinare quanto tempo ci vorrà. Alcune metriche che hai menzionato potrebbero essere utilizzate come linee guida interne, ma non vuoi che i clienti pensino di poter "giocare" al sistema. Non paghi i tuoi programmatori per riga di codice?

Proprio come il servizio postale, puoi addebitare un extra per averlo fatto più velocemente.

La maggior parte dei fornitori di applicazioni scoraggia le personalizzazioni addebitando commissioni elevate. La tua azienda potrebbe vedere la possibilità di aggiungere il tuo codice come caratteristica principale della tua app / servizio. Ci sono più costi per lo sviluppo di questa applicazione rispetto alla semplice revisione del codice. Gli aggiornamenti devono essere molto disordinati e non hai modo di garantire che le personalizzazioni continueranno a funzionare. Spero che tu non inizi una tendenza;)

    
risposta data 03.02.2011 - 02:05
fonte

Leggi altre domande sui tag