Qual è la pessimizzazione più ridicola che hai visto? [chiuso]

Sappiamo tutti che l'ottimizzazione prematura è la radice di tutti i mali perché porta a codice illeggibile / non realizzabile. Ancora peggio è la pessimizzazione, quando qualcuno implementa una "ottimizzazione" perché pensa che sarà più veloce, ma finisce per essere più lento, oltre ad essere buggy, non mantenibile, ecc. Qual è l'esempio più ridicolo di questo che hai visto ?

In un vecchio progetto abbiamo ereditato alcuni programmatori di sistemi embedded (altrimenti eccellenti) che avevano una vasta esperienza con Z-8000.

Il nostro nuovo ambiente era Sparc Solaris a 32 bit.

Uno dei ragazzi è andato e ha cambiato tutti gli interi in pantaloncini per accelerare il nostro codice, dal momento che prendere 16 bit dalla RAM era più veloce che afferrare 32 bit.

Ho dovuto scrivere un programma dimostrativo per dimostrare che acquisire valori a 32 bit su un sistema a 32 bit era più veloce che ottenere valori a 16 bit e spiegare che per ottenere un valore a 16 bit la CPU doveva fare una larghezza di 32 bit accesso alla memoria e quindi mascherare o spostare i bit non necessari per il valore a 16 bit.

Penso che la frase "l'ottimizzazione prematura è la radice di tutti i mali" è molto, molto usata. Per molti progetti, è diventata una scusa per non tenere conto delle prestazioni fino a tardi in un progetto.

Questa frase è spesso una stampella per le persone per evitare il lavoro. Vedo questa frase usata quando le persone dovrebbero davvero dire "Accidenti, non ci abbiamo pensato prima e non abbiamo tempo di affrontarlo ora".

Ho visto molti più "ridicoli" esempi di problemi di prestazioni stupide rispetto agli esempi di problemi introdotti a causa della "pessimizzazione"

• Leggere la stessa chiave di registro migliaia (o decine di migliaia) di volte durante l'avvio del programma.
• Caricamento della stessa DLL centinaia o migliaia di volte
• Sprecare mega byte di memoria mantenendo inutili percorsi completi di file
• Non organizzare le strutture dei dati in modo che occupino molta più memoria del necessario
• Dimensionamento di tutte le stringhe che memorizzano nomi di file o percorsi su MAX_PATH
• Polling gratuito per cose che hanno eventi, callback o altri meccanismi di notifica

Quello che penso sia un'affermazione migliore è questa: "l'ottimizzazione senza misurazione e comprensione non è affatto ottimizzazione, è solo un cambiamento casuale".

Il lavoro con buone prestazioni richiede tempo, spesso più che lo sviluppo della funzione o del componente stesso.

I database sono il terreno di gioco della pessimizzazione.

I preferiti includono:

• Dividi una tabella in multipli (per intervallo di date, intervallo alfabetico, ecc.) Perché è "troppo grande".
• Creare una tabella di archivio per i record ritirati, ma continuare a UNION con la tabella di produzione.
• Duplica interi database per (divisione / cliente / prodotto / ecc.)
• Resistere ad aggiungere colonne a un indice perché lo rende troppo grande.
• Crea molte tabelle di riepilogo perché il ricalcolo dai dati non elaborati è troppo lento.
• Crea colonne con sottocampi per risparmiare spazio.
• Denormalizza in campi come un array.

È fuori dalla mia testa.

Penso che non esista una regola assoluta: alcune cose sono ottimizzate al meglio in anticipo, altre no.

Ad esempio, ho lavorato in un'azienda in cui abbiamo ricevuto pacchetti di dati dai satelliti. Ogni pacchetto costava un sacco di soldi, quindi tutti i dati erano altamente ottimizzati (cioè imballati). Ad esempio, latitudine / longitudine non sono state inviate come valori assoluti (float), ma come offset relativi all'angolo "nord-ovest" di una zona "corrente". Abbiamo dovuto decomprimere tutti i dati prima che potessero essere utilizzati. Ma penso che questa non sia pessimizzazione, è un'ottimizzazione intelligente per ridurre i costi di comunicazione.

D'altra parte, i nostri architetti del software hanno deciso che i dati decompressi dovrebbero essere formattati in un documento XML molto leggibile e archiviati nel nostro database come tali (invece di avere ogni campo memorizzato in una colonna corrispondente). La loro idea era che "XML è il futuro", "lo spazio su disco è economico" e "il processore è economico", quindi non è stato necessario ottimizzare nulla. Il risultato è stato che i nostri pacchetti da 16 byte sono stati trasformati in documenti da 2kB archiviati in una colonna e per query anche semplici abbiamo dovuto caricare in memoria megabyte di documenti XML! Abbiamo ricevuto oltre 50 pacchetti al secondo, quindi puoi immaginare quanto sia diventata orribile la performance (BTW, la società è fallita).

Quindi, di nuovo, non esiste una regola assoluta. Sì, a volte l'ottimizzazione troppo presto è un errore. Ma a volte il motto "CPU / spazio su disco / memoria è economico" è la vera radice di tutti i mali.

Oh buon Dio, penso di averli visti tutti. Il più delle volte è uno sforzo per risolvere i problemi di prestazioni di qualcuno che è troppo dannatamente pigro per risolvere il problema fino alla CAUSA di quei problemi di prestazioni o persino ricercare se esiste effettivamente un problema di prestazioni. In molti di questi casi mi chiedo se non è solo il caso di quella persona che vuole provare una particolare tecnologia e cerca disperatamente un chiodo che si adatti al suo nuovo martello lucido.

Ecco un esempio recente:

Data Architect mi viene in mente con una proposta elaborata di partizionare verticalmente una tabella di chiavi in ​​un'applicazione abbastanza grande e complessa. Vuole sapere quale tipo di sforzo di sviluppo sarebbe necessario per adeguarsi al cambiamento. La conversazione è andata così:

Io: perché lo stai prendendo in considerazione? Qual è il problema che stai cercando di risolvere?

Lui: la tabella X è troppo ampia, la stiamo partizionando per motivi di prestazioni.

Io: cosa ti fa pensare che sia troppo largo?

Lui: Il consulente ha detto che ci sono troppe colonne per avere in una tabella.

Io: E questo sta influenzando le prestazioni?

Lui: Sì, gli utenti hanno segnalato rallentamenti intermittenti nel modulo XYZ dell'applicazione.

Io: come fai a sapere che la larghezza della tabella è la fonte del problema?

Lui: Questa è la tabella delle chiavi utilizzata dal modulo XYZ, ed è come 200 colonne. Deve essere il problema.

Io (Spiegazione): Ma il modulo XYZ in particolare usa la maggior parte delle colonne in quella tabella e le colonne che utilizza sono imprevedibili perché l'utente configura l'app per mostrare i dati che vogliono visualizzare da quella tabella. È probabile che il 95% delle volte finiremmo per unire tutti i tavoli insieme, il che danneggerebbe le prestazioni.

Lui: Il consulente ha detto che è troppo ampio e dobbiamo cambiarlo.

Io: chi è questo consulente? Non sapevo che avessimo assunto un consulente, né avevano parlato con il team di sviluppo.

Lui: Beh, non li abbiamo ancora assunti. Questo fa parte di una proposta che hanno offerto, ma hanno insistito sulla necessità di riprogettare questo database.

Io: Uh eh. Quindi il consulente che vende servizi di riprogettazione del database pensa che abbiamo bisogno di una riprogettazione del database ....

La conversazione è andata avanti all'infinito. Successivamente, ho dato un'altra occhiata al tavolo in questione e ho determinato che probabilmente poteva essere ristretto con una semplice normalizzazione senza la necessità di strategie di partizionamento esotiche. Questo, ovviamente, si è rivelato essere un punto controverso una volta che ho esaminato i problemi di prestazioni (precedentemente non segnalati) e li ho rintracciati fino a due fattori:

1. Indici mancanti su alcune colonne chiave.
2. Alcuni analisti di dati non autorizzati che bloccavano periodicamente le tabelle delle chiavi (inclusa quella "troppo ampia") interrogando il database di produzione direttamente con MSAccess.

Ovviamente l'architetto sta ancora spingendo per un partizionamento verticale del tavolo aggrappato al meta-problema "troppo ampio". Ha anche rafforzato il suo caso ricevendo una proposta da un altro consulente di database che è stato in grado di determinare che avevamo bisogno di importanti modifiche di progettazione al database senza guardare l'app o eseguire alcuna analisi delle prestazioni.

Ho visto persone che usano alphadrive-7 per incubare totalmente CHX-LT. Questa è una pratica non comune. La pratica più comune è inizializzare il trasformatore ZT in modo da ridurre la bufferizzazione (a causa della maggiore resistenza al sovraccarico netto) e creare bytegrafazioni in stile java.

Totalmente pessimista!

Niente di sconvolgente, lo ammetto, ma ho catturato persone che usano StringBuffer per concatenare le stringhe al di fuori di un loop in Java. Era qualcosa di semplice come girare

String msg = "Count = " + count + " of " + total + ".";

in

StringBuffer sb = new StringBuffer("Count = ");
sb.append(count);
sb.append(" of ");
sb.append(total);
sb.append(".");
String msg = sb.toString();

Una volta era una pratica abbastanza comune usare la tecnica in un ciclo, perché era misurabilmente più veloce. Il fatto è che StringBuffer è sincronizzato, quindi in realtà c'è un sovraccarico extra se stai concatenando solo alcune stringhe. (Per non parlare del fatto che la differenza è assolutamente banale su questa scala.) Altri due punti su questa pratica:

1. StringBuilder non è sincronizzato, quindi dovrebbe essere preferito su StringBuffer nei casi in cui il codice non può essere chiamato da più thread.
2. I moderni compilatori Java trasformeranno la concatenazione di stringhe leggibile in bytecode ottimizzato per te quando è appropriato comunque.

Una volta ho visto un database MSSQL che utilizzava una tabella 'Root'. La tabella principale aveva quattro colonne: GUID (uniqueidentifier), ID (int), LastModDate (datetime) e CreateDate (datetime). Tutte le tabelle nel database erano con chiave esterna per la tabella principale. Ogni volta che una nuova riga è stata creata in qualsiasi tabella nel db, dovevi usare un paio di procedure memorizzate per inserire una voce nella tabella principale prima di poter arrivare alla tabella effettiva a cui tieni (piuttosto che al database che fa il lavoro per tu con pochi grilletti grilletti semplici).

Questo ha creato un casino di inutili sentite e mal di testa, ha richiesto qualsiasi cosa scritta sopra per usare sprocs (ed eliminare le mie speranze di presentare LINQ all'azienda. Era possibile ma non valeva la pena il mal di testa), e per finire non ha fatto Non riesco nemmeno a fare quello che doveva fare.

Lo sviluppatore che ha scelto questo percorso lo ha difeso supponendo che questo abbia risparmiato tonnellate di spazio perché non stavamo usando le Guide sui tavoli stessi (ma ... non è un GUID generato nella tabella Root per ogni riga che facciamo?) , in qualche modo ha migliorato le prestazioni e ha reso "facile" il controllo delle modifiche al database.

Oh, e il diagramma del database sembrava un ragno mutante dall'inferno.

Che ne dici di POBI - la pessimizzazione ovviamente per intento?

Il mio collega negli anni '90 era stanco di essere preso a calci nel culo dal CEO solo perché il CEO ha trascorso il primo giorno di ogni versione del software ERP (personalizzato) per individuare i problemi di prestazioni nelle nuove funzionalità. Anche se le nuove funzionalità scricchiolavano gigabyte e rendevano possibile l'impossibile, trovava sempre qualche dettaglio, o persino un problema apparentemente importante, su cui lamentarsi. Credeva di sapere molto sulla programmazione e ha preso a calci i calci nel culo del programmatore.

A causa della natura incompetente delle critiche (era un CEO, non un ragazzo IT), il mio collega non è mai riuscito a farlo bene. Se non si riscontra un problema di prestazioni, non è possibile eliminarlo ...

Fino a una versione, ha inserito molte nuove chiamate di funzione Delay (200) (era Delphi) nel nuovo codice. Ci vollero solo 20 minuti dopo il via libera, e gli fu ordinato di presentarsi nell'ufficio del CEO per recuperare di persona gli insulti in ritardo.

L'unica cosa insolita finora era che i miei colleghi erano muti quando tornava, sorrideva, scherzava, usciva per un paio di BigMac mentre normalmente prendeva a calci i tavoli, si incendiava con il CEO e la compagnia e passava il resto della giornata a morire .

Naturalmente, il mio collega ora si riposava per uno o due giorni alla sua scrivania, migliorando le sue abilità di mira in Quake - poi il secondo o il terzo giorno cancellò le chiamate di ritardo, ricostruì e rilasciò una "patch di emergenza" di cui spargeva la voce che aveva trascorso 2 giorni e 1 notte per riparare i buchi delle prestazioni.

Questa è stata la prima (e unica) volta in cui l'amministratore delegato malvagio ha detto "ottimo lavoro!" a lui. Questo è tutto ciò che conta, giusto?

Questa era la vera POBI.

Ma è anche una sorta di ottimizzazione dei processi sociali, quindi va bene al 100%.

Penso.

"Indipendenza dal database". Ciò significava che non c'erano processi, trigger, ecc. Memorizzati, nemmeno chiavi esterne.

var stringBuilder = new StringBuilder();
stringBuilder.Append(myObj.a + myObj.b + myObj.c + myObj.d);
string cat = stringBuilder.ToString();

Il miglior uso di StringBuilder che abbia mai visto.

Usare una regex per dividere una stringa quando è sufficiente un semplice string.split

Conosco molto tardi questa discussione, ma l'ho visto di recente:

bool isFinished = GetIsFinished();

switch (isFinished)
{
    case true:
        DoFinish();
        break;

    case false:
        DoNextStep();
        break;

    default:
        DoNextStep();
}

Sai, nel caso in cui un booleano avesse dei valori extra ...

Il peggior esempio che mi viene in mente è un database interno della mia azienda contenente informazioni su tutti i dipendenti. Riceve un aggiornamento notturno da HR e ha un servizio web ASP.NET in cima. Molte altre app usano il servizio web per popolare cose come i campi di ricerca / discesa.

Il pessimismo è che lo sviluppatore ha ritenuto che le chiamate ripetute al servizio Web sarebbero state troppo lente per eseguire query SQL ripetute. Quindi cosa ha fatto? L'evento di avvio dell'applicazione legge nell'intero database e lo converte in oggetti in memoria, archiviati indefinitamente fino a quando il pool di app non viene riciclato. Questo codice era così lento che il caricamento in meno di 2000 dipendenti avrebbe richiesto 15 minuti. Se inavvertitamente hai riciclato il pool di app durante il giorno, potrebbero essere necessari almeno 30 minuti, poiché ogni richiesta del servizio Web avvierebbe più ricariche simultanee. Per questo motivo, i nuovi assunti non appariranno nel database il primo giorno in cui il loro account è stato creato e quindi non sarebbero in grado di accedere alla maggior parte delle app interne nei loro primi due giorni, facendo girare i pollici.

Il secondo livello di pessimismo è che il responsabile dello sviluppo non vuole toccarlo per paura di rompere le applicazioni dipendenti, ma tuttavia continuiamo ad avere sporadiche interruzioni a livello aziendale di applicazioni critiche a causa della cattiva progettazione di un componente così semplice.

Nessuno sembra aver menzionato l'ordinamento, quindi lo farò.

Diverse volte, ho scoperto che qualcuno aveva realizzato manualmente uno bolle, perché la situazione "non richiedeva" una chiamata all'algoritmo quicksort "troppo elaborato" che già esisteva. Lo sviluppatore è stato soddisfatto quando il suo bolle d'aria fatto a mano ha funzionato abbastanza bene sulle dieci file di dati che stanno usando per i test. Non è andato altrettanto bene dopo che il cliente ha aggiunto un paio di migliaia di righe.

Una volta ho lavorato su un'app che era piena di codice come questo:

 1 tuple *FindTuple( DataSet *set, int target ) {
 2     tuple *found = null;
 3     tuple *curr = GetFirstTupleOfSet(set);
 4     while (curr) {
 5         if (curr->id == target)
 6             found = curr;
 7         curr = GetNextTuple(curr);
 8     }
 9     return found;
10 }

Semplicemente rimuovendo found, tornando nullalla fine e cambiando la sesta riga in:

            return curr;

Raddoppiato le prestazioni dell'app.

Una volta ho dovuto tentare di modificare il codice che includeva queste gemme nella classe Costanti

public static String COMMA_DELIMINATOR=",";
public static String COMMA_SPACE_DELIMINATOR=", ";
public static String COLIN_DELIMINATOR=":";

Ognuno di questi è stato utilizzato più volte nel resto dell'applicazione per scopi diversi. COMMA_DELIMINATOR ha disseminato il codice di oltre 200 utilizzi in 8 pacchetti diversi.

Il grande numero uno di sempre in cui mi imbatto di volta in volta nel software interno:

Non utilizzare le funzionalità del DBMS per motivi di "portabilità" perché "potremmo voler passare a un altro fornitore in un secondo momento".

Leggi le mie labbra. Per qualsiasi lavoro interno: NON SARÀ ACCADUTO!

Avevo un collega che stava cercando di battere in astuzia l'ottimizzatore del nostro compilatore C e il codice di riscrittura di routine che solo lui poteva leggere. Uno dei suoi trucchi preferiti stava cambiando un metodo leggibile come (inventando un po 'di codice):

int some_method(int input1, int input2) {
    int x;
    if (input1 == -1) {
        return 0;
    }
    if (input1 == input2) {
        return input1;
    }
    ... a long expression here ...
    return x;
}

in questo:

int some_method() {
    return (input == -1) ? 0 : (input1 == input2) ? input 1 :
           ... a long expression ...
           ... a long expression ...
           ... a long expression ...
}

Cioè, la prima riga di un metodo leggibile una volta diventerebbe " return" e tutte le altre logiche verrebbero sostituite da espressioni ternarie profondamente annidate. Quando si tenta di discutere su come ciò non sia realizzabile, si indica che l'output dell'assemblaggio del suo metodo è stato di tre o quattro istruzioni di assemblaggio più brevi. Non era necessariamente più veloce, ma era sempre un po 'piccolo po 'più breve. Si trattava di un sistema incorporato in cui l'utilizzo della memoria occasionalmente contava, ma c'erano ottimizzazioni molto più semplici che avrebbero potuto essere fatte di così che avrebbe lasciato il codice leggibile.

Quindi, dopo questo, per qualche motivo ha deciso che ptr->structElementera troppo illeggibile, quindi ha iniziato a cambiarli tutti nella (*ptr).structElementteoria che era più leggibile e anche più veloce.

Trasformare il codice leggibile in codice illeggibile per un miglioramento massimo dell'1% e talvolta un codice più lento.

In uno dei miei primi lavori come sviluppatore a pieno titolo, ho assunto un progetto per un programma che soffriva di problemi di ridimensionamento. Funzionerebbe ragionevolmente bene su insiemi di dati di piccole dimensioni, ma si bloccherebbe completamente quando vengono fornite grandi quantità di dati.

Mentre mi immergevo, ho scoperto che il programmatore originale ha cercato di velocizzare le cose parallelizzando l'analisi, lanciando un nuovo thread per ogni ulteriore fonte di dati. Tuttavia, aveva commesso un errore nel fatto che tutti i thread richiedevano una risorsa condivisa, su cui si stavano bloccando. Ovviamente, tutti i vantaggi della concorrenza sono scomparsi. Inoltre ha bloccato la maggior parte dei sistemi per avviare oltre 100 thread solo per bloccare tutti tranne uno. La mia potente macchina per gli sviluppatori è stata un'eccezione in quanto ha sfornato un set di dati di 150 fonti in circa 6 ore.

Quindi, per risolverlo, ho rimosso i componenti multi-threading e pulito l'I / O. Senza altre modifiche, il tempo di esecuzione sul set di dati di 150 origini è sceso sotto i 10 minuti sulla mia macchina e da infinito a meno di mezz'ora sulla macchina media dell'azienda.

Suppongo di poter offrire questo gioiello:

unsigned long isqrt(unsigned long value)
{
    unsigned long tmp = 1, root = 0;
    #define ISQRT_INNER(shift) \
    { \
        if (value >= (tmp = ((root << 1) + (1 << (shift))) << (shift))) \
        { \
            root += 1 << shift; \
            value -= tmp; \
        } \
    }

    // Find out how many bytes our value uses
    // so we don't do any uneeded work.
    if (value & 0xffff0000)
    {
        if ((value & 0xff000000) == 0)
            tmp = 3;
        else
            tmp = 4;
    }
    else if (value & 0x0000ff00)
        tmp = 2;

    switch (tmp)
    {
        case 4:
            ISQRT_INNER(15);
            ISQRT_INNER(14);
            ISQRT_INNER(13);
            ISQRT_INNER(12);
        case 3:
            ISQRT_INNER(11);
            ISQRT_INNER(10);
            ISQRT_INNER( 9);
            ISQRT_INNER( 8);
        case 2:
            ISQRT_INNER( 7);
            ISQRT_INNER( 6);
            ISQRT_INNER( 5);
            ISQRT_INNER( 4);
        case 1:
            ISQRT_INNER( 3);
            ISQRT_INNER( 2);
            ISQRT_INNER( 1);
            ISQRT_INNER( 0);
    }
#undef ISQRT_INNER
    return root;
}

Dato che la radice quadrata è stata calcolata in un luogo molto sensibile, ho avuto il compito di cercare un modo per renderlo più veloce. Questo piccolo refactoring ha ridotto i tempi di esecuzione di un terzo (per la combinazione di hardware e compilatore utilizzati, YMMV):

unsigned long isqrt(unsigned long value)
{
    unsigned long tmp = 1, root = 0;
    #define ISQRT_INNER(shift) \
    { \
        if (value >= (tmp = ((root << 1) + (1 << (shift))) << (shift))) \
        { \
            root += 1 << shift; \
            value -= tmp; \
        } \
    }

    ISQRT_INNER (15);
    ISQRT_INNER (14);
    ISQRT_INNER (13);
    ISQRT_INNER (12);
    ISQRT_INNER (11);
    ISQRT_INNER (10);
    ISQRT_INNER ( 9);
    ISQRT_INNER ( 8);
    ISQRT_INNER ( 7);
    ISQRT_INNER ( 6);
    ISQRT_INNER ( 5);
    ISQRT_INNER ( 4);
    ISQRT_INNER ( 3);
    ISQRT_INNER ( 2);
    ISQRT_INNER ( 1);
    ISQRT_INNER ( 0);

#undef ISQRT_INNER
    return root;
}

Naturalmente ci sono entrambi modi più veloci E migliori per farlo, ma penso che sia un esempio piuttosto chiaro di pessimizzazione.

Modifica: vieni a pensarci bene, il ciclo srotolato era in realtà anche una pessimizzazione ordinata. Scavando attraverso il controllo della versione, posso presentare anche la seconda fase del refactoring, che ha funzionato anche meglio di quanto sopra:

unsigned long isqrt(unsigned long value)
{
    unsigned long tmp = 1 << 30, root = 0;

    while (tmp != 0)
    {
        if (value >= root + tmp) {
            value -= root + tmp;
            root += tmp << 1;
        }
        root >>= 1;
        tmp >>= 2;
    }

    return root;
}

Questo è esattamente lo stesso algoritmo, anche se un'implementazione leggermente diversa, quindi suppongo che si qualifichi.

Questo potrebbe essere ad un livello superiore a quello che stavi cercando, ma risolverlo (se ti è permesso) comporta anche un livello più alto di dolore:

Insistere a portata di mano lanciando un Object Relationship Manager / Data Access Layer invece di utilizzare una delle librerie consolidate, testate e mature là fuori (anche dopo che ti sono state segnalate).

Tutti i vincoli di chiave esterna sono stati rimossi da un database, perché altrimenti ci sarebbero così tanti errori.

Questo non corrisponde esattamente alla domanda, ma la citerò comunque una storia di ammonimento. Stavo lavorando su un'app distribuita che funzionava lentamente e sono volata a Washington per partecipare a una riunione principalmente volta a risolvere il problema. Il responsabile del progetto ha iniziato a delineare una nuova architettura volta a risolvere il ritardo. Mi sono offerto volontario di aver preso alcune misurazioni durante il fine settimana che hanno isolato il collo di bottiglia in un unico metodo. Si è scoperto che mancava un record in una ricerca locale, causando l'applicazione per passare a un server remoto su ogni transazione. Aggiungendo il record all'archivio locale, il ritardo è stato eliminato - problema risolto. Nota che la ri-architettura non avrebbe risolto il problema.

Verifica prima di OGNI operazione javascript se esiste l'oggetto su cui stai operando.

if (myObj) { //or its evil cousin, if (myObj != null) {
    label.text = myObj.value; 
    // we know label exists because it has already been 
    // checked in a big if block somewhere at the top
}

Il mio problema con questo tipo di codice è che nessuno sembra preoccuparsene se non esistesse? Non fare niente? Non dare il feedback all'utente?

Sono d'accordo che gli Object expectederrori sono fastidiosi, ma questa non è la soluzione migliore per questo.

Che ne dici dell'estremismo YAGNI. È una forma di pessimizzazione prematura. Sembra che ogni volta che applichi YAGNI, finisci per averne bisogno, con il risultato di 10 volte lo sforzo di aggiungerlo rispetto a quando lo avessi aggiunto all'inizio. Se crei un programma di successo, allora hai delle probabilità che LO STAI BISOGNO. Se sei abituato a creare programmi la cui vita si esaurisce rapidamente, allora continua a praticare YAGNI perché allora suppongo YAGNI.

Non esattamente un'ottimizzazione prematura - ma certamente fuorviata - questo è stato letto sul sito web della BBC, da un articolo che parla di Windows 7.

Curran ha affermato che il team di Microsoft Windows ha studiato attentamente ogni aspetto del sistema operativo per apportare miglioramenti. "Siamo stati in grado di eliminare 400 millisecondi dal tempo di spegnimento tagliando leggermente la musica di arresto del file WAV.

Ora, non ho ancora provato Windows 7, quindi potrei sbagliarmi, ma sono disposto a scommettere che ci sono altri problemi che sono più importanti di quanto tempo ci vuole per spegnere. Dopotutto, una volta visualizzato il messaggio "Spegnimento di Windows", il monitor si spegne e me ne vado: come mi avvantaggiano quei 400 millisecondi?

Qualcuno nel mio dipartimento una volta ha scritto una classe di stringhe. Un'interfaccia simile CString, ma senza la dipendenza di Windows.

Una "ottimizzazione" che hanno fatto è stata quella di non allocare più memoria del necessario. Apparentemente non si rende conto che la ragione per cui classi come std::stringallocare memoria in eccesso è tale che una sequenza di +=operazioni può essere eseguita in tempo O (n).

Invece, ogni singola +=chiamata ha forzato una riallocazione, che ha trasformato gli accodamenti ripetuti in un algoritmo O (n²) di Schlemiel il Pittore .

Un mio ex collaboratore (un soab , in realtà) è stato assegnato a costruire un nuovo modulo per il nostro ERP Java che avrebbe dovuto raccogliere e analizzare i dati dei clienti (settore della vendita al dettaglio). Decise di dividere OGNI campo Calendario / Datetime nei suoi componenti (secondi, minuti, ore, giorno, mese, anno, giorno della settimana, bimester, trimestre (!)) Perché "come altrimenti avrei cercato" ogni lunedì "?"

Senza offesa per nessuno, ma ho appena valutato un incarico (Java) che ha avuto questo

import java.lang.*;