A jó mérnök ha a big picture-t nézi, akkor tudja, hogy úgy kell megírnia a kódját, hogy cserélhető legyen az algoritmusa: amint probléma van egy rész teljesítményéből, a rendszer többi elemének megbontása nélkül kidobható. És nem, nem arról beszélünk, hogy ebédszünetig érdekli, és Lookup.Contains vs List.Find.
l
Arról van szó, hogy az eredeti állítás szerint a Nagyon Alapos Programozó nem tud hatékony kódot írni a keretrendszereinek komplexitása ismerete nélkül. És arról, hogy szerintem ez a valóságban baromság. Ha valaki jó mérnöknek tartja magát, az tudja, hogy nem KELL tudnia az összes framework metódusainak komplexitását, ugyanis ennek az információnak a megtanulása, felkutatása is olyan erőforrásokat igényel, amelyek nem érik meg a ráfordítást. Igen, van az a performance optimalizálás, ami triviális, de nem mindegyik az. Egy jó mérnök nem megy el a végsőkig a teljesítmény optimalizálásában, mert tudja, hogy más szempontok is léteznek, mert látja a big picture-t.
A software bloat más téma: nem csak azért eszik sokat a Skype, mert van CPU és RAM bőven. Hanem azért, mert sok mindent csinál. Olyat is, amire esetleg neked nincs szükséged: szépen animálja az emotikonokat, rajzolja a saját kis UI-ját, esetleg XML-alapú vagy más szöveges protokollt használ (hiszen fontos ám az, hogy ember által olvasható legyen a hálózati kommunikáció...)*.
Az, hogy bőségesen van RAM és CPU, az azt jelenti, hogy sokkal nagyobb méretű problémákat is meg tudunk oldani már, mint régebben. Gondolj bele, hogyan néznél egy magas bitrátájú és felbontású filmet régi gépen?
Valamint: még mindig tartom, hogy a komplexitások ismerete papíron nem segít. Attól, hogy egy algoritmusod O(n) komplexitású, attól még lehet, hogy akkora a konstans szorzótényezője, hogy egy másik O(n^2) algoritmust megéri használni azoknál a bemeneteknél, amelyek előfordulnak a valóságban. Maga az O(n) jelölés önmagában nem hordoz olyan információt, ami nélkül ne tudnál hatékony kódot írni. Sőt, félre is vezethet. Nem valószínű, de előfordulhat. Pont azért, mert "a konstans szorzótényező nem számít" és hasonló problémaforrások. Egy jó mérnök pontosan tudja, hogy az O()-jelölésben ismert komplexitás nem feltétlenül szükséges és nem is elégséges a hatékony kód írásához.
*: A Skype 2014 óta a Microsoft Notification Protocolt használja, ami strukturált szöveg alapú. Csomó idő elmegy a parzolással.