Scream

Moje první setkání s Visual Studiem bylo několik (mnoho) let zpět – tuším u verze 6 (???).

Po prvním spuštění Visual Studia 2005 (VS) mě napadlo asi toto: Sakryš, to vypadá úplně stejně a v hlavě se mi rozsvítila varovná žárovička (stará šestka nestála za moc, i když jí řada lidí vychvalovala jako nejlepší IDE na celém světě).
Často slýchávám od lidí zaměřených na komerční produkty, že jejich výhoda spočívá v tom, že za vložený peníz získávám i podporu, tudíž pokud má výrobek nějakou chybu, mám šanci dočkat se její opravy. VS má, podle mých měsíčních zkušeností s jeho používáním, dostatek chyb, které by se daly opravovat.

Namátkou:

• při určitém typu chyby v debugovaném programu se celé visual studio kousne a jediná cesta ven je Kill, Kill, Kill! Poté VS zapomene, jaký projekt mělo otevřený naposledy a po vybrání projektu uživatelem jej znovu sáhodlouze načítá. Celkové zdržení je něco kolem minuty u projektu velikosti školní úlohy. Celá tato procedura vás pochopitelně mírně naštve – když se mi udála naposledy, říkal jsem si v duchu:“To mám ještě jako ladit i Visual Studio“. Když si k tomu připočteme inteligentní hlášku o odesílání chyb, pak asi tušíte, kam člověku vystoupí tepová frekvence (Microsoft má vůbec velmi dobré techniky pro zvyšování tepu – naposledy mě pobavil dialog Microsoft SQL Server Management Studio Express (tomu říkám ovšem název), kdy se mi celé prostředí při napsání mezery a pokusu o doplňování syntaxe dotazu „zamyslelo“ na několik minut a poté se mi objevil dialog s textem, jehož význam byl přibližně takovýto: Sql Server Management Studio neodpovídá, pokud podobné chování pozorujete častěji, ohlašte to prosím společnosti Microsoft, přičemž to nebyl onen známý dialog operačního systému, ale opravdu přímo Management Studia). Produkty Microsoftu jsou vůbec docela inteligentní – s oblibou dlouho přemýšlejí.
• Při prohlížení jisté assembly (mimochodem tenhle název mi ježí všechny chlupy na těle, Microsoft opravdu považuje programátory za dělníky) mi tvrdošíjně ukazuje obsah jiné assembly dokonce s úplně jiným názvem.
• V jednom DataGridView mi neustále přidává všechny sloupce, které nalezne v příslušném DataSource, a vůbec mu nevadí, že mi tím mnou vybrané sloupce navíc zduplikuje. Při každém otevření formuláře tedy následuje vyslovení sprostého slova.
• Na jednom ze solution mám pro spuštění nastaveny 2 projekty – jeden na spuštění serveru pro remoting a druhý s Windows Forms klientem. VS mi však ochotně leč nechtěně spouští i jeden z dalších projektů – webové rozhraní aplikace.
• Při prvním překladu jednoho ze solution zobrazí varovná hlášení o možných chybách, při druhém hlášení zmizí (jak jsem nyní pochopil, zřejmě to není chyba ale důsledek nějakého podivného způsobu překladu, každopádně pokud hodláte odevzdat část své práce na server pro správu verzí a VS vám nezobrazí žádné varovné hlášky – například o nedosažitelnosti kódu, nenastavených proměnných a podobně. Odevzdáte v klidu svou práci, leč za čas se dočkáte příjemné odezvy od vašeho vedoucího projektu).

Na internetových diskusích jsem četl, že vůči ostatním IDE, která sice pracují s jinými jazkyky, je VS rychlejší při otevření projektu a vlastně i při samotném spuštění. Možná je to částečně pravda, i když mi nepřipadá načtení projektu o deseti třídách nikterak rychlé. Ale když si uvědomím, kolik informací na začátku shromažďuje například Eclipse, aby potom usnadnila vývojáři práci, nesnese nějaké spuštění žádné srovnání. Vezměme si, že Eclipse doplňuje názvy všech tříd, které jsou dostupné v projektu (tedy i z externích knihoven jar, které jsou u projektu uvedeny). Takových tříd jsou tisíce. Díky tomu dokáže doplňovat importy automaticky a inteligentně pomáhat při vytváření potomka jakékoliv třídy a řadu dalších užitečných věcí. Visual studio 2005 nic takového neumí. Musíte zadat referenci na nějakou knihovnu (proces srovnatelný s přidáním knihovny v eclipse), ale pak musíte znát buď celé jméno třídy a VS doplní import (using) (když ovšem ještě stisknete klávesovou zkratku) nebo musíte zadat import a pak doplňuje název třídy. Tato kombinace je – jak asi sami uznáte – celkem k ničemu.

Po uložení souboru v Eclipse provede vývojové prostředí jeho validaci (v závislosti na typu souboru), a build celeho workspace (inkrementální). Takže obvykle do 1 sekundy po uložení máte celkem jistotu, že celá operace nezavlekla do projektu nějakou chybu odhalitelnou v době překladu. Vše funguje i pro xml soubory, jsp a podobně. O něčem takovém si můžeme ve VS nechat pouze zdát. Je nutný překlad celého projektu, který rychlostí příliš nevyniká.
Připočteme-li drobnost typu rychlého otvírání souborů z projektu použitím Open resource dialogu v Eclipse, začne být jasné, že na větším projektu je Visual Studio možná tak hezký editor s průměrným doplňováním syntaxe.

Rychlost, se kterou debugger pracuje je přímo žalostná. Přechod na následující řádku (kde aktuální řádka neprovádí žádnou složitou akci) trvá a trvá a trvá. Někdy se mi i stane, že VS odmítne skočit do vnitřku funkce a s klidem angličana ji přeskočí. Přitom pokud byl breakpoint uvnitř této funkce, VS se na něm zastavilo. Uživatelsky jsou podobné akce také poněkud nepříjemné – toto IDE trpí problémy se zobrazováním ve chvíli, kdy provádí nějakou akci – při některých činnostech GUI prostě zmrzne, dokud akci nedokončí nebo má odezvu hlemýžďího charakteru.

Mám k dispozici Team Edition, která pracuje s Team Serverem. Na našich projektech je zapnuto zamykání každého souboru uživatelem při jeho editaci. Tedy přidání souboru do projektu zamkne hlavní soubor projektu a dokud tuto činnost někdo nedokončí, nepřidáte do projektu žádný další soubor. Samozřejmě je to vlastnost nastavení. Ovšem co jsem nepochopil byl následující scénář: Pokusil jsem se přidat soubor do projektu. VS ohlásilo, že musí otevřít projektový soubor pro dokončení této operace. Operace skončila neúspěchem – někdo měl projektový soubor zamčený (zjištění podobné vlastnosti je sice pro uživatele triviální, avšak neustále musíte klikat v jednom dialogu na refresh – jiný způsob mi není znám). Opakoval jsem tuto akci tedy ještě 3X – naposledy úspěšně. Upravil jsem soubor a provedl jeho vrácení na server (tato operace se nazývá u VS Check In – ostatní systémy, pokud je mi známo, používají slovo commit, ale což). VS mi oznámilo, že mám nevyřešené konflikty. Trochu jsem se podivil. Operace přidání souboru se mi nikdy nepovedla, projektový soubor tedy neměl být modifikován, avšak byl. Protože projektovým souborům zatím nerozumím, rozhodl jsem se celou akci vyřešit updatem ze serveru a vytvořením souboru znovu.
Práce s Team Serverem není také příliš rychlá a zobrazování informací o stažených souborech ze serveru není zrovna komfortní.

Můj celkový pocit z VS 2005 je prostě pocit zklamání. Vím, že existuje verze 2008, ale zatím jsem ji neměl možnost používat. Její srovnání nebude zřejmě již tolik „bít“ do očí, ale chtěl jsem spíše reagovat na výroky na internetových diskusích typu Visual Studio 2005 je nejlepší IDE na světě. Není… , a bohužel s ním budu muset ještě nějakou dobu pracovat.

Tento článek jsem uvedl již na Saboter bloguje avšak zde uvedená verze je mírně upravená a doplněná. Píši poměrně ve spěchu – z práce, proto omluvte chybky a překlepy.