Se on melkein takuun arvoinen. Aloittelijoista asiantuntijat , arkkitehtuurista ASM: iin ja kaiken optimoinnista koneen suorituskyvystä kehittäjän suorituskykyyn, on todennäköistä, että sinä ja tiimisi oikosuljet omia tavoitteitasi.

Mitä? Minä? Minun tiimi?

Se on melko raskas syytös tasolle. Anna minun selittää.

Optimointi ei ole pyhä graali, mutta sen saaminen voi olla yhtä vaikeaa. Haluan jakaa kanssasi muutaman yksinkertaisen vinkin (ja vuoren sudenkuoppia), jotka auttavat muuttamaan tiimisi kokemuksen itsesabotaatista harmonian, tyydytyksen, tasapainon ja lopulta optimoinnin kokemukseksi.

Mikä on ennenaikainen optimointi?

Ennenaikainen optimointi yrittää optimoida suorituskyvyn:

1. Kun koodataan ensin algoritmi
2. Ennen kuin vertailuarvot vahvistavat sinun
3. Ennen profiloimista tarkkoja kohtia, joissa on järkevää vaivautua optimointiin
4. Alemmalla tasolla kuin projektisi sanelee

Olen optimisti, Optimus.

Ainakin aion teeskennellä olevani optimistinen kirjoittaessani tätä artikkelia. Voit puolestasi teeskennellä, että nimesi on Optimus, joten tämä puhuu sinulle suoremmin.

Teknillisenä ihmisenä luultavasti joskus ihmettelet, kuinka se voisi olla $year ja silti kaikesta edistyksestämme huolimatta se on jotenkin hyväksyttävä standardi $task olla niin ärsyttävän aikaa vievää. Haluat olla laiha. Tehokas. Mahtava. Joku pitää Rockstar-ohjelmoijista, joita nämä työhakemukset kiihottavat, mutta johtajana. Joten kun tiimisi kirjoittaa koodia, kannusta heitä tekemään se oikein ensimmäisellä kerralla (vaikka 'oikea' onkin hyvin suhteellinen termi, tässä). He tietävät, että tämä on älykäs kooderi ja myös niiden tapa, joiden ei tarvitse tuhlata aikaa myöhemmin.

Minusta tuntuu että. Perfekcionismin voima on joskus vahva myös minussa. Haluat joukkueesi käyttämään vähän nyt aikaa säästää a paljon aikaa myöhemmin, koska jokainen on lyönyt osuutensa'Paska koodi, jonka muut ihmiset kirjoittivat (mitä helvettiä he ajattelivat?).'Se on lyhyesti SCOPWWHWTT, koska tiedän, että pidät lausumattomista lyhenteistä.

Tiedän myös, ettet halua joukkueesi koodin olevan itsellesi tai kenellekään muulle.

Katsotaan siis, mitä voidaan tehdä ohjataaksesi tiimiäsi oikeaan suuntaan.

Mitä optimointiin: Tervetuloa tähän olemiseen

Ensinnäkin, kun ajattelemme ohjelman optimointia, oletamme usein heti, että puhumme esitys . Jopa että on jo epämääräisempi kuin miltä se saattaa tuntua (nopeus? muistin käyttö? jne.), joten lopetetaan siellä.

Tehdään se tasaiseksi lisää epäselvä! Aivan aluksi.

Seumaverkko-aivoni haluavat luoda järjestystä aina kun se on mahdollista, joten minun on otettava jokainen unssi optimismia, jotta voin ajatella, mitä aion sanoa, hyvä asia .

Siellä on yksinkertainen (suorituskyvyn) optimoinnin sääntö Älä tee sitä . Tämä kuulostaa melko helppolta jäykästi, mutta kaikki eivät ole sen kanssa samaa mieltä. En myöskään ole täysin samaa mieltä. Jotkut ihmiset yksinkertaisesti kirjoittavat paremman koodin portista kuin toiset. Toivottavasti jokaiselle henkilölle koodin laatu, jonka he kirjoittavat upouuteen projektiin, paranee yleensä ajan myötä. Mutta tiedän, että monien ohjelmoijien kohdalla näin ei ole, koska mitä enemmän he tietävät, sitä enemmän tapoja kiusata optimoida ennenaikaisesti.

Monille ohjelmoijille ... mitä enemmän he tietävät, sitä enemmän tapoja kiusata optimoida ennenaikaisesti.

Siis tämä Älä tee sitä ei voi olla tarkka tiede, vaan se on tarkoitettu vain torjumaan tyypillisen teknikon sisäistä halua ratkaista pulma. Loppujen lopuksi tämä houkuttelee monia ohjelmoijia alukseen. Ymmärrän tuon. Mutta pyydä heitä Tallenna se , vastustaa kiusausta. Jos joku tarvitsee palapelin ratkaisemisen juuri nyt , voi aina pistäytyä sunnuntai-lehden Sudokussa, noutaa Mensa-kirjan tai mennä koodi golfia keinotekoisen ongelman kanssa. Mutta jätä se pois reposta oikeaan aikaan. Melkein aina tämä on viisaampi tie kuin ennakkooptimointi.

Muista, että tämä käytäntö on tarpeeksi kuuluisa, jotta ihmiset kysyvät ennenaikainen optimointi on kaiken pahan perusta . (En menisi aivan niin pitkälle, mutta olen samaa mieltä mielipiteen kanssa.)

En sano, että meidän pitäisi valita aivojen kuollein tapa, jonka voimme ajatella kaikilla suunnittelutasoilla. Ei tietenkään. Mutta sen sijaan, että valitsemme älykkäimmän näköisen, voimme ota huomioon muut arvot :

1. Helpoin selittää uudelle vuokralle
2. Todennäköisimmin läpäisee kaikkein kokeneimman kehittäjän koodiarvostelun
3. Ylläpitävin
4. Nopein kirjoittaa
5. Helpoin testata
6. Kannettavin
7. jne.

Mutta tässä ongelma osoittautuu vaikeaksi. Kyse ei ole vain välttämällä nopeuden optimointia , koodin koko, muistin jalanjälki, joustavuus tai tulevaisuuden kestävyys. Kyse on tasapainosta ja siitä, onko tekemäsi todella arvojesi ja tavoitteidesi mukaista. Se on täysin kontekstuaalinen, ja joskus jopa mahdotonta mitata objektiivisesti.

Se on taidetta. (C.f. Tietokoneohjelmoinnin taide .)

Miksi tämä on hyvä asia? Koska elämä on tällaista. Se on sotkuista. Ohjelmointikeskeiset aivomme haluavat joskus luoda järjestystä kaaokseen niin pahasti, että lopulta moninkertaistamme kaaoksen. Se on kuin paradoksi yrittää pakottaa joku rakastamaan sinua. Jos luulet onnistuneen siinä, se ei ole enää rakkautta; sillä välin sinua syytetään panttivankien ottamisesta, tarvitset todennäköisesti enemmän rakkautta kuin koskaan, ja tämän metaforan on täytynyt olla yksi hankalimmista, mitä olisin voinut valita.

Joka tapauksessa, jos luulet löytäneesi täydellisen järjestelmän johonkin, no ... nauti illuusiosta, kun se kestää. Se on ok, epäonnistumiset ovat upeita mahdollisuuksia oppia.

Pidä UX mielessä

Tutkitaan, miten käyttökokemus sopii näiden mahdollisten prioriteettien joukkoon. Loppujen lopuksi jopa haluaminen, että joku toimii hyvin, on jossain määrin UX: ää.

Jos työskentelet käyttöliittymän kanssa, riippumatta siitä, mitä kehyksiä tai kieltä koodi käyttää, siellä on tietty määrä kattilaa ja toistoa. Se voi olla ehdottomasti arvokasta ohjelmoijan ajan ja koodin selkeyden kannalta yrittää vähentää sitä. Auttaakseni painopisteiden tasapainottamisen taidetta haluan jakaa pari tarinaa.

Yhdessä työpaikassa yritys, jonka palveluksessa työskentelin, käytti suljetun lähdekoodin yritysjärjestelmää, joka perustui mielipiteelliseen tekniikkapinoon. Itse asiassa se oli niin mielipide, että myyjä, joka myi sen meille, kieltäytyi tekemästä käyttöliittymän mukautuksia, jotka eivät sopineet pinon mielipiteisiin, koska se oli niin tuskallista heidän kehittäjilleen. En ole koskaan käyttänyt heidän pinoaan, joten en tuomitse heitä tästä, mutta tosiasia oli, että tämä 'hyvä ohjelmoijalle, huono käyttäjälle' -vaihto oli niin työtovereilleni hankala tietyissä yhteyksissä, että päädyin kirjoittamaan kolmannen osapuolen lisäosan, joka otti uudelleen käyttöön järjestelmän käyttöliittymän tämän osan. (Se oli valtava tuottavuuden parantaja. Työtoverini rakastivat sitä! Yli vuosikymmenen kuluttua se on edelleen säästää siellä kaikki aikaa ja turhautumista.)

En sano, että mielipide on sinänsä ongelma; vain siitä, että liikaa siitä tuli ongelma tapauksessamme. Vastaesimerkkinä yksi Ruby on Railsin suurimmista vetoista on juuri se On mielipide, etupään ekosysteemissä, jossa huimausta voi helposti saada liian monista vaihtoehdoista. (Anna minulle mielipiteitä, kunnes saan selville omani!)

Sitä vastoin saatat olla kiusaus kruunaa UX kaiken kuninkaaksi projektissasi. Arvoinen tavoite, mutta anna minun kertoa toinen tarinani.

Muutama vuosi edellä mainitun projektin onnistumisen jälkeen yksi kollegoistani tuli luokseni pyytämään minua optimoimaan UX automatisoimalla tietty joskus syntynyt sotkuinen tosielämän skenaario, jotta se voitaisiin ratkaista yhdellä napsautuksella. Aloin analysoida, oliko edes mahdollista suunnitella algoritmi, jolla ei olisi vääriä positiivisia tai negatiivisia tilanteita skenaarion monien ja outojen reunatapausten vuoksi. Mitä enemmän puhuin siitä työtoverini kanssa, sitä enemmän tajusin, että vaatimukset eivät yksinkertaisesti tule maksamaan. Skenaario tuli esiin vain silloin tällöin - sanotaan kuukausittain - ja yhden henkilön ratkaiseminen kesti muutaman minuutin. Jopa jos voisimme automatisoida sen onnistuneesti ilman virheitä. Tarvitaan vuosisatoja, ennen kuin vaadittu kehitys- ja ylläpitoaika maksetaan työtovereideni säästämän ajan suhteen. Minussa olevalla ihmisten miellyttäjällä oli vaikea hetki sanoa 'ei', mutta minun piti keskeyttää keskustelu.

Joten anna tietokoneen tehdä kaikkensa auttaakseen käyttäjää, mutta vain järkevässä määrin. Mistä tiedät kuitenkin, missä määrin se on?

Haluan käyttää lähestymistapaa UX: n profilointiin kuten kehittäjät profiloivat koodinsa . Ota selvää käyttäjiltäsi, missä he viettävät eniten aikaa napsauttamalla tai kirjoittamalla samaa uudelleen ja uudelleen, ja katso, voitko optimoida nämä vuorovaikutukset. Voiko koodisi tehdä joitain koulutettuja arvauksia siitä, mitä he todennäköisesti syöttävät, ja tehdä siitä oletusarvoisen? Tiettyjen kiellettyjen asiayhteyksien lisäksi (ei napsautuksella tapahtuvaa EULA-vahvistusta?), Tämä voi todella vaikuttaa käyttäjien tuottavuuteen ja onnellisuuteen. Suorita käytävän käytettävyyden testaus, jos voit. Joskus sinulla voi olla vaikeuksia selittää, mistä tietokoneilla on helppo auttaa ja mikä ei ... mutta kaiken kaikkiaan tällä arvolla on todennäköisesti melko suuri merkitys käyttäjillesi.

Ennenaikaisen optimoinnin välttäminen: milloin ja miten optimoida

Oletamme nyt nimenomaisesti, että etsimme muita konteksteja optimoimalla jokin näkökohta koneen raakaa suorituskykyä muulle artikkelille. Ehdotettu lähestymistapa koskee myös muita tavoitteita, kuten joustavuutta, mutta jokaisella kohteella on omat valintansa; pääasia on optimointi ennenaikaisesti mitä tahansa epäonnistuu todennäköisesti.

Joten mitä suorituskyvyn suhteen on noudatettava? Kaivetaan sisään.

Tämä ei ole ruohonjuuritason aloite, se on Triple-Eh

TL; DR on: Neulo alas ylhäältä . Korkeamman tason optimoinnit voidaan tehdä aikaisemmin projektissa, ja alemman tason optimoinnit tulisi jättää myöhempää käyttöä varten. Se on kaikki mitä tarvitset saadaksesi suurimman osan ennenaikaisen optimoinnin merkityksestä; tekemällä asioita tässä järjestyksessä on suuri todennäköisyys tuhlata tiimisi aikaa ja olla tehottomia. Loppujen lopuksi et kirjoita koko projektia konekoodiksi alusta alkaen, vai mitä? Joten meidän AAA toimintatapa on optimoida tässä järjestyksessä:

1. Arkkitehtuuri
2. Algoritmit
3. Kokoaminen

Yleisen viisauden mukaan algoritmit ja tietorakenteet ovat usein tehokkaimpia paikkoja optimointiin, ainakin suorituskyvyn suhteen. Muista kuitenkin, että arkkitehtuuri joskus määrittää, mitä algoritmeja ja tietorakenteita voidaan käyttää.

Löysin kerran ohjelmiston, joka tekee taloudellisen raportin kyselemällä SQL-tietokantaa useita kertoja jokaisesta yksittäisestä rahoitustapahtumasta ja tekemällä sitten hyvin perustason laskennan asiakaspuolella. Ohjelmistoa käyttävä pienyritys kesti vain muutaman kuukauden käytön, ennen kuin edes niiden suhteellisen pieni taloudellinen tieto tarkoitti, että upouuden työpöydän ja melko lihavan palvelimen kanssa raporttien luontiaika oli jo useita minuutteja, ja tämä oli sellaista, jota heidän oli käytettävä melko usein. Päätin kirjoittaa suoraviivan SQL-käskyn, joka sisälsi summauslogiikan - estäen niiden arkkitehtuurin siirtämällä työn palvelimelle välttääkseen kaikki päällekkäisyydet ja verkon edestakaiset matkat - ja jopa usean vuoden arvoisen tiedon myöhemmin, versioni voisi luoda sama raportti vain millisekunteina samalla vanhalla laitteistolla.

Joskus sinulla ei ole vaikutusta projektin arkkitehtuuriin, koska projektissa on liian myöhäistä, jotta arkkitehtuurin muutos olisi mahdollista. Joskus kehittäjät voivat hameutua sen ympärille, kuten tein yllä olevassa esimerkissä. Mutta jos olet projektin alussa ja sinulla on jotain sananvaltaa sen arkkitehtuurista, on nyt aika optimoida se.

Arkkitehtuuri

Projektissa arkkitehtuuri on kallein osa tosiasiallisesti muutettavissa, joten tässä on järkevää optimoida alussa. Jos sovelluksesi on toimittaa tietoja strutsien kautta haluat esimerkiksi rakentaa sen kohti matalataajuisia, suurta hyötykuormaa sisältäviä paketteja, jotta vältät huonon pullonkaulan pahentamisen. Tässä tapauksessa sinun on parasta ottaa Tetris kokonaan käyttöön viihdyttääksesi käyttäjiäsi, koska lataava kiekko ei vain leikkaa sitä. (Kidding syrjään: Vuosia sitten asensin ensimmäisen Linux-jakeluni Corel Linux 2.0: n ja olin iloinen siitä, että pitkään jatkunut asennusprosessi sisälsi juuri sen. Kun olen nähnyt Windows 95: n asentajan infomainosnäytöt niin monta kertaa, että olin muistanut ne, oli tuohon aikaan raikasta ilmaa.)

Esimerkkinä arkkitehtuurimuutoksesta, joka on kallista, syy siihen, että edellä mainittu SQL-raportti on ensinnäkin niin skaalaamaton, on selvä sen historiasta. Sovellus oli kehittynyt ajan myötä MS-DOS: n juurista ja kotikasvatetusta mukautetusta tietokannasta, joka ei ollut edes alun perin monikäyttäjä. Kun myyjä lopulta siirtyi SQL: ään, malli ja raportointikoodi näyttävät olevan siirretty yksi kerrallaan. Tämä antoi heille vuosien arvosta vaikuttavia 1000%: n + suorituskyvyn parannuksia ripustettavaksi päivityksiinsä aina, kun he saivat päätökseen arkkitehtuurikytkennän hyödyntämällä SQL: n etuja tietyssä raportissa. Hyvä yrityksille lukittujen asiakkaiden kanssa, kuten silloinen työnantajani, ja yrittää selvästi priorisoida koodauksen tehokkuutta ensimmäisen siirtymävaiheen aikana. Mutta asiakkaiden tarpeiden tyydyttäminen on joissakin tapauksissa suunnilleen yhtä tehokasta kuin vasara kääntää ruuvia.

Arkkitehtuurissa on osittain ennakoitu, missä määrin projektisi tulee pystyä laajentamaan ja millä tavoin. Koska arkkitehtuuri on niin korkeatasoista, on vaikea saada konkretisoitua 'asiaa ja vastauksia' rajoittamatta keskittymistä tiettyihin tekniikoihin ja aloihin.

En kutsuisi sitä niin, mutta kaikki muut tekevät

Onneksi Internet on täynnä kerättyä viisautta useimmista kaikenlaisista arkkitehtuureista, joita koskaan haaveillut. Kun tiedät, että on aika optimoida arkkitehtuurisi, sudenkuoppien tutkiminen taitaa melko paljon selvittää loistava visioasi kuvaava sanasana. Mahdollisuudet ovat, että joku on ajatellut samoilla linjoilla kuin sinä, kokeillut sitä, epäonnistunut, toistanut ja julkaissut sen blogissa tai kirjassa.

Sanasanan tunnistaminen voi olla hankalaa suorittaa vain hakemalla, koska FLDSMDFR: ksi kutsumallesi henkilölle joku muu on jo keksinyt termin SCOPWWHWTT, ja he kuvaavat samaa ongelmaa, jonka ratkaiset, mutta käyttämällä täysin erilaista sanastoa kuin sinä tekisit. Kehittäjäyhteisöt pelastamaan! Löydä StackExchange tai HashNode niin perusteellisella kuvauksella kuin mahdollista, sekä kaikki arkkitehtuurisi tunnussanat ei ole , joten he tietävät, että teit riittävän alustavan tutkimuksen. Joku valottaa sinua mielellään.

Sillä välin, joitain yleisiä neuvoja voi olla hyvä ajatusruoka.

Algoritmit ja kokoonpano

Ottaen huomioon suotuisan arkkitehtuurin, tässä tiimisi koodaajat saavat eniten T-blingia ajastaan. Ennenaikaisen optimoinnin välttäminen pätee myös tässä, mutta ohjelmoijiesi olisi hyvä harkita joitain tämän tason yksityiskohtia. Toteutuksen yksityiskohdissa on niin paljon ajateltavaa Kirjoitin erillisen artikkelin koodin optimoinnista, joka on suunnattu etulinjan ja vanhempien koodereiden suuntaan .

Mutta kun sinä ja tiimisi olette toteuttaneet jotain suorituskyvyn kannalta optimoimatonta, jätätkö sen todella Älä tee sitä ? Sinä ei koskaan optimoida?

Olet oikeassa. Seuraava sääntö on vain asiantuntijoille Älä tee sitä vielä .

Aika vertailuarvoon!

Koodisi toimii. Ehkä se on niin koiran hidasta, että jo tietää sinun on optimoitava, koska se on koodi, jota käytetään usein. Ehkä et ole varma, tai sinulla on O (n) -algoritmi ja luulet, että se on todennäköisesti hieno. Ei ole väliä mitä tapauksessa, jos tämä algoritmi saattaa olla syytä optimoida, suosittelen tässä vaiheessa samaa: Suorita yksinkertainen vertailuarvo.

Miksi? Eikö ole selvää, että O (n³) -algoritmini ei voi olla huonompi kuin mikään muu? No, kahdesta syystä:

1. Voit lisätä vertailuarvon testipakettiin objektiivisena mittana suorituskykytavoitteistasi riippumatta siitä, saavutetaanko ne tällä hetkellä.
2. Jopa asiantuntijat voivat tahattomasti hidastaa asioita. Silloinkin kun se tuntuu ilmeiseltä. Todella ilmeinen.

Etkö usko minua toisesta kohdasta?

Kuinka saada parempia tuloksia 1400 dollarin laitteistosta kuin 7000 dollarin laitteistosta

Jeff Atwood StackOverflow-maineesta kerran huomautti että joskus (yleensä hänen mielestään) voi olla kustannustehokkaampaa ostaa vain parempia laitteita kuin käyttää arvokasta ohjelmoijan aikaa optimointiin. OK, joten oletetaan, että olet saavuttanut kohtuullisen objektiivisen johtopäätöksen, että projektisi sopisi tähän skenaarioon. Oletetaan edelleen, että se, mitä yrität optimoida, on kokoamisaika, koska se on mittava Swift-projekti, jonka parissa työskentelet, ja tästä on tullut melko suuri kehittäjien pullonkaula. Laitteisto-ostosten aika!

Mitä sinun pitäisi ostaa? No, ilmeisesti jeniä jeniksi, kalliimmilla laitteilla on taipumus toimia paremmin kuin halvemmilla laitteilla. Joten ilmeisesti 7000 dollarin Mac Pron pitäisi koota ohjelmisto nopeammin kuin jotkut keskitason Mac Mini, eikö?

Väärä!

On käynyt ilmi että joskus enemmän ytimiä tarkoittaa tehokkaampaa kokoamista ... ja tässä nimenomaisessa tapauksessa LinkedIn huomasi kovalla tavalla, että heidän pinoansa päinvastoin.

Mutta olen nähnyt johdon, joka teki yhden virheen edelleen: He eivät edes vertailleet ennen ja jälkeen, ja huomasivat, että laitteistopäivitys ei saanut heidän ohjelmistoa 'tuntemaan' nopeammin. Mutta ei ollut mitään tapaa tietää varmasti; ja edelleen, heillä ei vielä ollut aavistustakaan pullonkaulan sijainnista, joten he olivat edelleen tyytymättömiä suorituskykyyn, kun he olivat käyttäneet aikaa ja rahaa, jonka he olivat halukkaita osoittamaan ongelmaan.

OK, olen jo vertaillut. Voinko todella optimoida Vielä ??

Kyllä, jos olet päättänyt, että tarvitset. Mutta ehkä tuo päätös odottaa, kunnes myös muut / kaikki muut algoritmit on toteutettu, joten voit nähdä, kuinka liikkuvat osat sopivat yhteen ja mitkä ovat tärkeimpiä profiloinnin avulla. Tämä voi olla sovellustasolla pienelle sovellukselle tai se voi koskea vain yhtä alijärjestelmää. Joko niin, muista, että tietty algoritmi saattaa tuntua tärkeältä koko sovellukselle, mutta jopa asiantuntijat - etenkin asiantuntijat - ovat alttiita diagnosoimaan tämän väärin .

Ajattele ennen kuin häiritset

'En tiedä sinusta ihmisistä, mutta ...'

Harkitse lopullisena ajattelun aiheena, kuinka voit soveltaa väärän optimoinnin ajatusta paljon laajempaan näkemykseen: itse projektiisi tai yrityksellesi tai jopa talouden alalle.

Tiedän, on houkuttelevaa ajatella, että tekniikka pelastaa päivän ja että me voimme olla sankareita, jotka toteuttavat sen.

Lisäksi, jos emme tee sitä, joku muu tekee.

Muista kuitenkin, että valta turmelee parhaisista aikeista huolimatta. En aio linkittää mihinkään tiettyyn artikkeliin täällä, mutta jos et ole vaeltanut missään, kannattaa etsiä joitain talouden häiriöiden laajemmista vaikutuksista ja kenestä tämä joskus lopulta palvelee. Saatat olla yllättynyt joistakin sivuvaikutuksista, joita yrität pelastaa maailmaa optimoinnilla.

Jälkikirjoitus

Huomasitko jotain, Optimus? Ainoa kerta, kun kutsuin sinua Optimusiksi, oli alussa ja nyt lopussa. Sinua ei kutsuttu Optimusiksi koko artikkelissa. Olen rehellinen, unohdin. Kirjoitin koko artikkelin kutsumatta sinua Optimusiksi. Lopussa, kun tajusin, että minun pitäisi palata ja ripotella nimesi koko tekstiin, pieni ääni sisälläni sanoi: älä tee sitä .

Perustietojen ymmärtäminen

Mikä on ennenaikainen optimointi?

Yritetään optimoida ensimmäisen koodauksen yhteydessä. Suorituskyvyn optimointi on parasta tehdä korkeimmalta mahdolliselta tasolta kulloinkin. Greenfield-hankkeisiin, arkkitehtuurivaiheessa. Vanhojen projektien jälkeen asianmukainen profilointi pullonkaulojen tunnistamiseksi sen sijaan, että pelaisit kalliita arvauspelejä.

Miksi ennenaikainen optimointi on huono?

Se on piilotettu kuoppa olettaen, että (oletettavasti) suorituskykyyn optimoitu koodi on oikeastaan ​​ensisijainen prioriteettisi, yli oikeellisuuden, selkeyden, testattavuuden ja niin edelleen. Toinen kuoppa on olettaa, että kyseisellä koodilla on riittävä vaikutus yleiseen suorituskykyyn, jotta se olisi syytä optimoida. Ennenaikainen optimointi saavuttaa molemmat.