.
Annunci online

alessioricco
producer, consumer, crèpes
17 ottobre 2007
[codice] [tips] precalcolare fa bene alla salute
Supponiamo di avere una applicazione che abbia tre colonne, in una ho un elenco di regioni, se clicco su una regione nella seconda colonna ho un elenco di province e cliccando su una provincia ho l'elenco dei comuni di quella provincia.

Ovviamente regioni, province e comuni sono tutti nel loro bel database.

Ci sono tre strade:
La piu' ovvia è quella di fare tre pagine dinamiche che interrogano il db e chiedono di volta in volta l'elenco delle regioni, province e comuni in base ad un parametro di ingresso.

pro:
  • è semplice e naturale
  • permette di cambiare facilmente il template grafico
  • è veloce da scrivere e da manutenere
contro:
  • troppe interrogazioni al db per avere sempre gli stessi risultati

la seconda invece fa si che le pagine dei comuni e delle province siano tutte precalcolate. In genere questa è la fase successiva alla precedente, data la pagina che genera dinamicamente le province, mi creo le 100 e passa pagine statiche, una per provincia. Analogamente per i comuni.

pro:
  • non interrogo il db
  • la pagina viene restituita piu' velocemente
  • non ho parametri nelle pagine (riduco la possibilità di fare sql injection)
contro:
  • se uso dei template grafici che che cambiano spesso, questa soluzione non va bene
l'ultima strada è intermedia ed è valida quando il livello di presentazione del nostro sito è variabile e quindi non posso precalcolarmi la pagina. In pratica per non interrogare il db posso precalcolarmi l'elenco di comuni e province ad esempio sotto forma di files xml o binari (dipende un po' dall'algoritmo che voglio usare) e poi deserializzarli per applicarli al livello di presentazione.

pro:
  • non interrogo il db
  • posso continuare ad utilizzare il template engine

contro:

  • non è performante come la soluzione precedente

 


Tag inseriti dall'utente. Cliccando su uno dei tag, ti verranno proposti tutti i post del blog contenenti il tag. web code snippets

permalink | inviato da alessioricco il 17/10/2007 alle 17:49 | Leggi i commenti e commenta questo postcommenti (2) | Versione per la stampa
16 ottobre 2007
[codice] [tips] Gestione centralizzata dei parametri nelle URL
Anche se il termine globale e locale è usato in modo improprio, rende bene il concetto di parametri che vengono passati nelle URL e che vengono utilizzati in gran parte delle pagine della nostra applicazione e parametri che vengono utilizzati solo in poche (o addirittura una) pagine.

Una buona regola è quella di gestire i parametri utilizzando una sola funzione il cui codice è condiviso da tutta l'applicazione e che abbia come scopo, per ogni possibile parametro di ingresso ammissibile dall'applicazione, quello di:

  • verificare se il parametro esiste oppure no e impostare il relativo valore di default, se necessario
  • verificare se il tipo che ci aspettiamo dal parametro è quello giusto
  • accedere al dbms per prendere quelle informazioni che nel 90% dei casi dobbiamo andare a prendere ogni volta che quel parametro è settato.
i vantaggi di questa metodologia sono i seguenti:
  • si evitano inutili ripetizioni di codice e copia-incolla suscettibili di bug
  • si ha un unico punto centralizzato che gestisce i parametri di ingresso, cosa che rende estremamente piu' semplice e immediata la manutenzione del codice.
Lo svantaggio piu' evidente è che viene eseguito del codice anche quando non è necessario.

Tag inseriti dall'utente. Cliccando su uno dei tag, ti verranno proposti tutti i post del blog contenenti il tag. asp.net spaghetti code

permalink | inviato da alessioricco il 16/10/2007 alle 17:46 | Leggi i commenti e commenta questo postcommenti (0) | Versione per la stampa
TECNOLOGIE
15 ottobre 2007
[codice] [tips] Stessi parametri, stesso nome
http://sonounsito.com/index.php?idresource=10
http://sonounsito.com/show.php?resourceid=10

Questo è un esempio di "spaghetti code" piuttosto frequente. Il team di sviluppo si sente indipendente nella scelta del naming dei parametri della pagina e sceglie il primo nome che gli suona familiare. cosi' in una pagina il parametro si chiama idresource e nella successiva si chiama resourceid.

C'e' una grande chanche che chi ha sviluppato questo codice non abbia una gestione "centralizzata" dei parametri di ingresso e che quindi sia esposto piu' facilmente a questo tipo di problemi:
  • sql injection
  • parametri non tipati o tipati male
  • bug legati al fatto che un parametro non ha un nome univoco nell'ambito dell'applicazione.

Tag inseriti dall'utente. Cliccando su uno dei tag, ti verranno proposti tutti i post del blog contenenti il tag. bug spaghetti code

permalink | inviato da alessioricco il 15/10/2007 alle 17:35 | Leggi i commenti e commenta questo postcommenti (0) | Versione per la stampa
12 ottobre 2007
[codice] [BUG] Quando devi cambiare il codice al volo....
Prendiamo una funzione stupida come questa:
In pratica verifica che due stringhe siano uguali, assumendo che la prima stringa (x) inizi sempre per "00" e la seconda non debba mai iniziare per "00". Questo è quanto risultava infatti dalle specifiche.
Questo codice nasconde anche una insidia, infatti questo test funziona a meraviglia se x è stringa vuota, infatti ritornerà sempre false.

Public
Shared Function sameString(ByVal x As String, ByVal y As String) As Boolean
    Return x= "##" & y
End Function

Adesso, a circa 30 minuti prima della messa online dell'applicazione una telefonata ti fa capire che le specifiche sono diverse.. e che forse sarebbe meglio che il confronto tra le due stringhe fosse fatto da destra verso sinistra. La funzione, al volo viene riscritta ed ecco il patatrac!

Public Shared Function sameString(ByVal x As String, ByVal y As String) As Boolean
    Const CHARS As Integer =  <un numero, supponiamo 5>
    Dim yy As String = Right(y, CHARS)
    Dim xx As String = Right(x, yy.Length)
    Return xx = yy
End Function

Questa funzione è sbagliata! O meglio, questa funzione non fa quello che ci si aspetta debba fare perchè nel caso in cui x fosse stringa nulla, ritornerebbe true !

Prima di tutto alcune considerazioni:
1) ATTENTO ALLE PRECONDIZIONI IMPLICITE
La prima funzione ha un errore invisibile, ovvero le precondizioni della funzione sono implicite. anche se la stringa x è vuota la funzione è corretta. Questo assunto è corretto ma pericoloso, perchè basta che cambino le specifiche, modificando il codice della funzione la precondizione invisibile va a farsi benedire, perchè essendo sottointesa, è facile che te la dimentichi.

2) SCRIVI CODICE CHIARO E LEGGIBILE (e pure due commenti già che ci sei...)
Modificare il codice in corsa è il peggio che ti possa capitare, puoi anche lavorare dei mesi ad un progetto che c'e' sempre qualcosa che non è stato detto fino in fondo, qualcosa che tutti hanno dato per scontato e che nessuno ha esplicitato. C'e' sempre un problema che deve essere fissato poco prima o durante il rilascio. E' del tutto normale, purtroppo :(

3) QUATTRO OCCHI SONO MEGLIO DI DUE
Quando devi cambiare il codice al volo, non cambiarlo mai da solo. soprattutto se lo fai alle 2:30 del mattino. Trovati un collaboratore che possa rendersi conto delle modifiche che fai. Quattro occhi sono meglio di due e poi il tuo collaboratore potrebbe essere particolarmente motivato a pizzicarti in fallo. Sfrutta a tuo vantaggio questa cosa :)

4) DUE RIGHE IN MENO POSSONO SIGNIFICARE MOLTE ORE IN PIU'
Public
Shared Function sameString(ByVal x As String, ByVal y As String) As Boolean

    Const CHARS As Integer =  <un numero, supponiamo 5>

    ' Testa i parametri di ingresso
    if x.Length < CHARS then Return False
    if y.Length < CHARS then Return False

    Dim
 yy As String = Right(y, CHARS)
    Dim xx As String = Right(x, yy.Length)
    Return xx = yy
End
Function
 

Tag inseriti dall'utente. Cliccando su uno dei tag, ti verranno proposti tutti i post del blog contenenti il tag. bug asp.net vb.net debug

permalink | inviato da alessioricco il 12/10/2007 alle 16:41 | Leggi i commenti e commenta questo postcommenti (1) | Versione per la stampa
sfoglia