2008. április 9., szerda

Hatékonyságnövelő tippek a Visual Studio 2008-hoz

Az egyik MSDN blogban megjelent egy bejegyzés, 10 tippel, ami a kódolás hatékonyságát növelheti Visual Studioban.
Ki ne szeretne hatékonyabb lenni, hát átolvastam, itt most továbbadom, a saját véleményemmel kiegészítve. Amit jónak tartok így jelölöm: (!), amit nem azt így (?), ahol ezek a jelek nem szerepelnek azt döntsd el magad :)

1. tipp: Tanuld meg a gyorsbillentyűket.

Ez nem túl fantáziadús javaslat, mondhatnám, hogy triviális, de tény ami tény, valóban hatékonyságnövelő tényező, ezért is hívják úgy, hogy GYORSbillentyű.
A legfontosabbakat felsorolja a cikk, bár SZVSZ ezeket mindenki ismeri, hacsak nem ma látott először Studiot.
  • Build: CTRL + SHIFT + B
  • Word completion: CTRL + SPACE
  • Start with debugging: F5
  • Start without debugging: CTRL + F5
2. tipp: Automatikus dokumentációgenerálás GhostDoc segítségével (?)
Ez a tipp erősen vitatható. Egyetlen esetben van értelme használni, ha valaki olyan cégnél dolgozik, ahol a dokumentációt "kilóra" mérik. Ugyanis egyedül ilyen esetben csinál épeszű ember ilyen "dokumentációt":

Vagy ilyet:
A magam részéről úgy gondolom, hogy ennek semmi értelme. Ugyanis a függvény, property, osztály neve ha "önleíró", mint fent, akkor gyakorlatilag csak szószaporítás az ilyen típusú dokumentáció, ha azonban nem az, akkor semmilyen automatikus eszköz nem tudja értelmesen dokumentálni, csak a programozó.

3. tipp: Használd az automatikus tulajdonságokat
Ezt én inkább így írnám:
Használd ki a nyelvi újdonságokat (!)

Az automatikus tulajdonságok egy hasznos újítás a C# 3.0-ban. Mindenkit bátorítanék ennek az anyagnak az átolvasására, aki még nem tette, itt minden újdonság, szépen jól magyarul olvasható el.
A hatékonyságnövelő újdonságok bajuszokban, rövid példával:

Automatikus tulajdonságok


Új lehetőség az objektumok inicializálására



Lokális típusfeloldás


Lambda kifejezések


Erről itt írtam egy szemléletes példát.

4. Tipp: Használd a Refactort

Ha nem tudsz vagy nem akarsz automatikus tulajdonságot alkalmazni, hasznos lehet a Refactor menü Encapsulate field... menüpontja.
Így kezded:


..és ez lesz belőle:

A Rename is igen hasznos lehet, bár néha igen lassúcska, illetve kétségtelenül hasznos és (általam) gyakran használt tool az Extract interface..., ami nem meglepő módon interfészt állít elő az osztályunk alapján pikk-pakk módon.

Az 5. tipp (egyéni parancsok) részben emlegetett PowerCommands toolt ki fogom próbálni, mert a projekt oldalán látok néhány ígéretes dolgot (Copy/Paste Class, Copy/Paste References).

6. tipp: a build testreszabása

Egy nagyobb projekt esetében perceket vehet el az életünkből fölöslegesen, ha olyan dolgok is be vannak kapcsolva a projekt fordítása során, amelyekre például csak a végső változatban lesz szükség. Példaként a post az XML dokumentáció generálását hozza. Érdemes ezekre odafigyelni.



7. tipp: használd a VS unit test generáló funkcióját (??)

Hát ez nálam erősen kérdőjeles. Nem tudom mennyit ér egy ilyen automatikusan generált teszt. Érzésem szerint ez ugyanaz a kategória, mint a fentebb tárgyalt automatikus dokumentálás, vagyis csak kilóra van haszna, érdemben nem nagyon. Emgem ez azért sem érint különösebben, mert az NUnit és a Testdriven.NET használata mellett köteleztem el magam egyelőre, így a VS saját teszteszközeit nemigen használom.

A következő két tipp valóban hasznos, azonban a C#-hoz, de főleg a Studiohoz társítani némileg erős, hiszen mindkettő iknább módszertani kérdés, bár a szükséges eszközök valóban rendelkezésre állnak VS2008-hoz, ha másképp nem, hát külső fejlesztésként.

8. tipp: Interfész-központú tervezés

Az interfész alapú tervezés az én olvasatomban az agilis módszertanok fegyvertárába tartozik. A cikk arra mutat rá, hogy ennek a módszernek jelentős hatékonyságnövelő hatása lehet, főleg teamek esetében. A lényeg röviden annyi, hogy a többrétegű alkalmazások fejlesztésekor legelőször a kommunikációs felületek kialakítása a célszerű, mert így a csapat tagjainak nem kell egymásra várniuk, hiszen például az üzleti logika készítői elkészíthetik a saját - nyilván egyszerűsített - adathozzáférési objektumaikat vagy a következőben emlegetett mocking technikát alkalmazhatják, így párhuzamosan tud zajlani a fejlesztés szorosan kapcsolt rendszer esetében is. Jah igen, ami a Visual Studiot illeti, az objektumtervező lehetőséget ad minimális erőfeszítéssel az interfészek előállítására



9. tipp: A függőségek kiiktatása mock objektumok segítségével

A tipp kétségtelenül hasznos, bár ez nem a Studio vagy a C# fejlesztőinek érdeme :)
Mivel jómagam is newbie vagyok a tesztvezérelt fejlesztésnek nevezett metodológiában, ezért nem szeretnék itt mélyen belemenni a dolog taglalásába. A lényeget már majdnem le is írtam az előző pontban. Gyakorlatilag arról van itt szó, hogy az álobjektumokat egy eszköz segítségével úgy állítjuk elő, hogy azok megvalósítsák azokat a függvényeket, tulajdonságokat, amelyeket a tesztek során használni szeretnénk (lehetőség szerint CSAK azokat). Így egyrészt valóban függetlenítjük a programrészünket a többitől, másrészt a tesztjeink jelentősen gyorsulhatnak is, ha ezzel a módszerrel kiiktatunk például adatbázisműveleteket vagy más idő és erőforrásigényes eljárásokat. A cikk írója által ajánlott rendszer a RhinoMocks névre hallgat, jómagam is ennek használatába kezdtem bele a közelmúltban, az elterjedtsége és nem utolsó sorban az ingyenes volta miatt.
A cikk szerzője hoz egy rövid példát is, amit idelinkelek:



10. tipp: Adatvezérelt egységtesztek

Ismét röviden arról van itt szó, hogy X darab teszt írása helyett egyetlen tesztet írunk, amelyet a VS segítségével egy adatbázis X sorára lefuttathatunk. Ez a tesztek írását valóban gyorsítja, ellenben a futtatáskor - az előző pontban írottal szemben - éppen, hogy megterhetljük a tesztet egy kvázi fölösleges adatbázis és/vagy fájlolvasással. Én kis adatmennyiség esetében (és hogy ne kelljen megválnom a jó öreg NUnittól ;)) inkább az NUnit egyik kiegészítőjét használom (RowTest Extension for NUnit). Ki-ki döntse el, hogy melyiket akarja szeretni.

2 megjegyzés:

Biri írta...

A GhostDoc szerintem azert jo, mert megkimel egy rakas gepelestol. Termeszetes, hogy amit general, azt nem hagyjuk ott, mert egyreszt altalaban magyarul szeretnenk latni a kommenteket, masreszt meg tenyleg csak azt tudja legeneralni, amit az eljaras nevebol amugy is tudunk mar.

Viszont nagy elonye, hogy peldaul a tipusokat is jelzi, es ha ebbol doksit generalsz, akkor abban szep linkek lesznek a hivatkozott tipusra. Ez pedig hasznos, es kezzel pruntyolgetni az ilyen infokat xml formaban faraszto. :-)

NJoco írta...

Hogy ilyen esetben hasznos, azt nem vitatom, éppen erre gondoltam, mikor azt írtam "kilóra" lehet vele dokumentálni. Ha viszont nem hagyjuk ott amit generál, akkor hogyan kímél meg a gépeléstől ?!? A summary taget három slash után generálja neked, az XML tagekhez meg csak a ctrl+space-t kell kalapálnod...
Hm.. Típusok jelzése... Ok, elfogadom az érvet :)