Tempo di sviluppo: sql nel codice UI vs modello di dominio con datamapper

3

In primo luogo, mi dispiace per i miei ragazzi inglesi.

Attualmente questo è il mio primo lavoro di programmazione. Sono etichettato come il programmatore più incompetente della mia azienda perché misura le prestazioni e la produttività del programmatore dalla velocità con cui è possibile ottenere le cose. Non sono sicuro se sono lento o meno, perché cerco sempre di testare manualmente il mio codice prima di inviarlo, e sono abbastanza sicuro che la maggior parte dei programmatori qui non testano il loro codice nel modo in cui collaudo il mio. Non faccio test automatici perché ammetto che il concetto è ancora complesso per me. Poiché il nostro software non è ancora utilizzato dall'utente, non sappiamo quale programmatore ha il maggior numero di bug. E anche il sistema è solo per uso interno, quindi non abbiamo una scadenza rigorosa. Il tempo di spedizione non è così importante.

Non abbiamo best practice, test automatizzati, revisioni del codice e standard di codifica qui in azienda, quindi in pratica sei da solo, basta che il codice funzioni e sia corretto. Quasi tutti i programmatori qui sono freschi dal college. Anche io sono un neolaureato.

Penso che il motivo per cui sono veloci è perché fanno tutta la logica di business in sql. Quindi Fondamentalmente hanno tutto il codice UI e il codice Sql in un file .aspx proprio come il codice qui sotto

Patial class InvoiceView : Page
{
    protected void button_click(object sender, Eventargs a)
    {
     string sql = "Select * from some blah blah blah";
     DataTable tab = .....some Ado.net code here.
     Gridview.DataSouce = Tab;
     Gridview.DataBind();
    }
}

Prima di ottenere il mio primo lavoro (anche se questo è il mio primo lavoro), non codifico più questo tipo di solito uso un oggetto personalizzato proprio come il codice qui sotto.

Public class Invoice
{
     public int InvoiceNo {get;set;}
     Public DateTime PaidDate {get;set;}
     Public List<Item> Items {get;set;}
     public decimal Amount {
     get
        {
         decimal amount = 0;
         foreach(var i in Items)
         {
            amount = amount + i.TotalPrice;
         }
         return amount;
        }
    }
}

dopodiché creerò una classe DataMapper, e sono abbastanza sicuro che questo sia il motivo per cui sono lento, perché devo mappare manualmente la tabella delle righe agli oggetti e testare il datamapper. Quindi in pratica il loro non è un ORM o un micro ORM. Il nostro database non ha integralità referenziale e le tabelle cambiano sempre. Quindi pensavo che gli ORM non fossero l'ideale per questo progetto.

La persona che mi ha etichettato come la più lenta è in realtà un programmatore junior, proprio come il resto. Ha 2 anni di esperienza davanti a noi, ecco perché è il nostro immediato superiore. A volte penso sempre che la ragione per cui ha detto questo è perché è ancora un junior e non ha esperienza quando si tratta di gestire una squadra di programmatori.

Sono fiducioso di poter fare tutto il lavoro che mi daranno.

Ecco la mia domanda.

  1. Devo usare DataTable e inserirlo in gridview proprio come fa il resto del mio team?

  2. Quando utilizzare DataTable al posto di oggetti personalizzati o classi di dominio?

  3. Attualmente conosco solo due pattern di accesso ai dati, ActiveRecord e DataMapper. Come si chiama lo schema utilizzato dal mio team?

  4. Come posso programmare più velocemente?

Grazie ragazzi, mi dispiace per il mio inglese.

    
posta Ruby 26.03.2015 - 05:38
fonte

3 risposte

2

Test automatici

Investire il tempo nei test automatici. Ti pagherà molto rapidamente.

L'idea di base è che se esegui solo test manuali, non sarai in grado di gestire il numero sempre crescente di test. Non è raro che anche un'applicazione relativamente piccola abbia migliaia di test, senza contare i test di integrazione, di sistema, funzionali, di carico e di altro tipo. Se questa applicazione viene consegnata ogni giorno, questo significa che dovrai eseguire migliaia di test a mano, ogni giorno. Se ti bastano più di 8 ore per eseguirle tutte, non avrai più tempo per fare altro.

Perché eseguire quelle migliaia di test in primo luogo?

Principalmente per evitare regressioni. Quando scrivi nuovo codice, non importa quanto hai pensato alle conseguenze del cambiamento, può (e spesso lo farà) rompere qualcos'altro, da qualche altra parte. Se l'architettura e il design sono buoni, questo accadrà raramente e interesserà solo alcune classi per lo più correlate. Se l'architettura e il design non sono così buoni, puoi effettivamente modificare qualcosa in un unico punto e vedere le funzioni che sembrano un'interruzione completamente indipendente.

Codice

Se sei convinto che il tuo codice sia buono e il codice del tuo collega sia meno buono, il tempo necessario per fornire le funzionalità non dovrebbe essere un problema. Una volta che il prodotto inizia ad essere utilizzato dai clienti, segnaleranno bug. Se il tuo codice è facile da mantenere e ha meno bug, i tuoi colleghi passeranno la maggior parte del tempo a correggere i bug, mentre tu, d'altro canto, fornirai funzionalità, ottenendo un punteggio migliore sulla metrica utilizzata nella tua azienda.

Potrebbe essere (anche se non è chiaro dalla tua domanda, non credo sia il caso) che il codice del tuo collega sia valido, e il tuo 'è troppo architettato. In questo caso, infatti, stai spendendo più tempo del necessario scrivendo un codice che non è necessario. Il fatto che il tuo codice venga esaminato dai tuoi colleghi potrebbe darti un'immagine migliore. Se attraverso la revisione, ottengono semplicemente di ridurlo e mantenerlo gestibile, c'è effettivamente un problema.

Strumenti

Assicurati di conoscere i tuoi strumenti. IDE, checker statici, generatori di codice, qualunque cosa. Ad esempio, la tua classe Invoice , a parte la proprietà Amount , potrebbe essere stata scritta automaticamente da un generatore di codice. Questo potrebbe non fare un'enorme differenza per una singola classe, ma se ne hai a dozzine, contenenti dozzine di proprietà, i generatori di codice potrebbero avere un impatto.

    
risposta data 26.03.2015 - 08:52
fonte
1
  1. Devo usare DataTable e inserirlo in gridview proprio come fa il resto del mio team?

Inferno no. Questo è solo brutto codice. È un codice ok per progetti molto piccoli e non complicati che non cambieranno e ha uno schema di database che cambierà raramente se non mai. O per veloci progetti one-off. Altrimenti questa è una cattiva pratica del codice e tornerà indietro e ti morderà nel culo più tardi.

  1. Quando utilizzare DataTable anziché oggetti personalizzati o classi di dominio?

Mai. O bene, come detto prima. Per progetti straordinari molto piccoli. Anche se poi preferisco rimanere il più lontano possibile da DataTable e usare Dapper o Massive o qualcosa di simile a non dover scrivere codice contro DataTable.

  1. Attualmente conosco solo due pattern di accesso ai dati, ActiveRecord e DataMapper. Come si chiama lo schema utilizzato dal mio team?

"Maintenence hell":)

  1. Come posso programmare più velocemente?

Da quello che stai dicendo, non sei tu che dovresti codificare più velocemente, è il tuo team che dovrebbe programmare più lentamente. La codifica veloce è buona, ma la codifica corretta è migliore. Se si codifica correttamente, aderendo alle migliori pratiche e facendo test automatici e così via, si otterrà più velocemente a lungo termine riducendo al minimo gli incubi di manutenzione e avendo un sistema più stabile che sarà più facile da cambiare in seguito. Andare veloce è buono, ma non se vai veloce e poi finisci con un sistema che non puoi aggiungere nuove funzionalità o mantenere. Vai il più velocemente possibile senza tagliare gli angoli. Con il tempo e l'esperienza, troverai il ritmo giusto in cui puoi fornire il codice corretto abbastanza velocemente.

    
risposta data 26.03.2015 - 10:14
fonte
0

Sarò leggermente contrario ai consigli di "mantieni la codifica buono / lento" e "trova un nuovo lavoro" che riceverai nelle altre risposte, nel caso in cui nessuna di queste opzioni sia desiderabile per te .

Ecco la triste verità: a volte è meglio scrivere codice scadente conforme allo stile della squadra piuttosto che scrivere un buon codice che vada contro il limite. Tuttavia, dovrai passare un po 'di tempo a coprire il tuo retroterra e la tua reputazione dall'inevitabile numero di bug e problemi di manutenzione che insorgono quando alcuni altri sviluppatori junior vanno e cambia lo schema del database e le tue app si rompono.

Lo stile del tuo team è di avere molte app Web Form che hanno un sacco di sql in eventi di click del pulsante e collegamenti GridView, senza molti pezzi di "middle-tier" come le classi e le strutture di dati riutilizzabili. Ciò rende quasi impossibile fare un test unitario, tuttavia ciò non significa che non sia possibile testare affatto. Quello che devi fare è concentrarti su come fare i test di integrazione dell'interfaccia utente codificati per il tuo lavoro.

Consiglio vivamente il test dell'interfaccia utente Canopy pacchetto Nuget ( PM > Installa- Copertura del pacchetto ). È uno strumento di test dell'interfaccia utente basato su F #, ma non lasciare che F # ti spaventi, è molto facile imparare le basi su come eseguire i test, e usa selettori in stile CSS, che probabilmente già conosci (o può imparare facilmente).

Se fossi in te, eseguirò questo tipo di flusso di lavoro per quando hai bisogno di codificare velocemente una nuova app (sciatta) Web Form:

1) Vai avanti e cablare la tua app Web Form il più velocemente possibile, utilizzando lo sporco stile sql-in-button-evento utilizzato dalle università. Dì quello che vuoi, è IS veloce / facile scrivere app con quello stile (la manutenzione a lungo termine è un incubo, ma questa è la cultura che il tuo team ha selezionato!)

2) Scrivi uno script SQL per popolare il tuo database di test con un insieme di valori noti

3) Scrivi i test Canopy / Other UI per eseguire l'app in base ai requisiti (inserisci il valore X nella pagina Y e visualizza il risultato Z). Verranno verificati tutti i valori calcolati che vengono visualizzati sullo schermo, oltre a garantire che non si ottengano schermi gialli di morte. Potresti anche fare cose come avere pagine 'test' nascoste che non fanno altro che controllare le tabelle del database per gli schemi previsti e generare errori se cambiano abbastanza da rompere la tua app.

4) Se necessario, scrivi uno script sql finale per verificare i valori del database non controllati dai test dell'interfaccia utente.

Ora puoi eseguire questi test periodicamente, e se ci sono errori che vengono fuori perché Steve the Intern ha cambiato lo schema di una tabella senza dirlo al team, quindi il suo CRYSTAL CLEAR che l'ha fatto, e non è colpa del tuo web app. Nell'ambiente in cui ti trovi, coprire il tuo culo sarà di fondamentale importanza. Il team ti vede già lento e ci vorrà molto tempo prima che cambi opinione, quindi dovrai codificarti velocemente prima di poter ottenere il loro rispetto / fiducia.

    
risposta data 26.03.2015 - 13:34
fonte