Ho letto con molto, molto interesse questi post di Raffaele, Lorenzo e Marco che dicono in breve di stare attenti e di conoscere bene certi meccanismi intrinseci di .NET quando si lavora a basso livello. Memory leak, metodi virtual, handle, finestre, generazioni della garbage collection, heap, stack, intermediate language sono tutti argomenti che io reputo affascinanti ma credo anche che non si possa chiedere a tutti di avere conoscenze di questo tipo.
Da una parte viviamo in un mondo che ci spinge ad usare framework più o meno complessi capaci di eliminare problemi, o per meglio dire nascondere problemi. Da una parte Microsoft ci pubblicizza prodotti come Enterprise Library e XNA, esistono ORM capaci di farci dimenticare SQL & company. Ma allo stesso tempo ci viene richiesta una conoscenza a basso livello. Lorenzo all'ultimo workshop ha parlato di software factories, blocchi applicativi di una certa importanza che un giorno potranno incastrarsi l'uno con l'altro per fornire funzionalità ad alto livello. Esattamente come accade un po' oggi con Enterprise Library. Ma allora?
Ma allora...mi chiedo...da che parte gira il mondo? Dobbiamo pendere di più verso la conoscenza del basso livello o dell'alto livello? Non potete farmi sbavare facendomi vedere le meraviglie di WPF o di WWF, e poi d'altro canto mettermi in guardia su argomenti come la keyword virtual. Attenzione, non è Igor Damiani che dice queste cose, sto solo cercando di impersonare, di mettermi un po' dalla parte dello sviluppatore a cui non si può davvero chiedere di avere una conoscenza approfondita di cosa fa il CLR quando viene eseguito un metodo fatto in chissà quale modo.
Non per niente mi piace e mi sto studiando WPF, XAML e trovo sublimi strumenti come NHibernate che astraggono i problemi e mi semplificano la vita. Trovo assolutamente giuste le osservazioni di Raffaele e di Lorenzo, ci mancherebbe, ma mi viene in mente anche tutto quello che ho imparato leggendo Code Complete 2: non fatevi troppe paranoie mentali senza un valido motivo. Steve McConnell in molti punti del libro dice chiaramente di non preoccuparsi inizialmente di scrivere codice performante, perchè potrebbe essere fatica sprecata. Concentratevi sulle performance solo se vi rendete conto che ne avete bisogno davvero. Lavorare sulle performance vuol dire innanzitutto poterle misurare, capire che il metodo di una classe potrebbe essere molto più veloce, oppure che un altro metodo va riscritto perchè troppo esoso in termini di risorse (risorse = memoria o cpu time o handle, o decidete voi). Non è che io posso preoccuparmi di certe questioni ad ogni riga di codice che scrivo, altrimenti impazzisco, non credete? Se il cliente a cui ho consegnato un mio software mi chiama per segnalarmi problemi di stabilità, allora devo cominciare a prendere in considerazione il refactoring di certe parti del codice, analizzando per bene cosa succede, dove e perchè. Allora sì che entrano in gioco concetti importanti come quelli evidenziati nei post accennati prima. Ma fino ad allora....