Kromě express edicí VS je možné zdarma využít tento plugin:
ten by vám měl pomoci psát čistší a přehlednější kód, jak pro C#, tak i VB.NET
Šikovná věcička, a zdarma.
úterý 4. srpna 2009
čtvrtek 30. července 2009
úterý 28. července 2009
Řízení maličkých IT projektů - ano nebo ne?
Jedním slovem:
- ANO
Všechny?
- ANO
Proč?
- Protože i ty nejmenší projekty se vám mohou rozrůst
Jak je řídit?
- Rozumně!
(To vám asi moc neřekne, takže to rozeberu trochu víc.)
Pokud chcete zabít mouchu, berete si na to brokovnici? Asi ne. (Tacklebarry, tebe nepočítám.)
Stejné je to se řízením projektů.
Asi těžko budete instalovat Project Server kvůli projektu, který dohromady trvá 5MD a pracujete na něm jen vy.
Co byste ale rozhodně měli při projektech takto malého objemu udělat?
1) Uložit si veškerou e-mailovou komunikaci s klientem
2) Pokud musíte vyvinout speciální knihovny, řádně je dokumentujte
3) Veškeré know-how získané na projektu si poznamenejte do nějaké vaší databáze poznatků
4) Obrovskou pozornost věnujte Quick-Wins a jejich dokumentaci
5) Poznamenejte si čas, který jste odhadli při naceňování projektu a skutečný čas (pozor! včetně čtení e-mailů, brainstormingu, komunikace s klientem a další časy spojené s projektem)
6) Striktně vyžadujte rozhodnutí klienta v digitální nebo písemné formě
Potřebujete to vysvětlit?
Dobře, ale krátce.
add 1)
Uložením e-mailů nemám na mysli jejich ponechání v Outlooku. Dejte si tu práci a uložte si je do projektových složek na disku, umístěte si je do nějakého vašeho informačního systému, cokoliv, kamkoliv, jen je nenechávejte pouze ve vašem poštovním klientovi.
Až naberete dalšího kolegu, který bude dělat update. Až vám havaruje Outlook (prý se to stává ;-), až vám havaruje disk, až havarujete vy (omylem poštu smažete) - Poděkujete mi.
add 2)
Jestli tento bod musím vysvětlovat, obávám se, že byste se měli začít věnovat jiné profesi.
add 3)
Za půl roku vás klient kontaktuje, že potřebuje rozšířit funkcionalitu. Není nic horšího, než dva dny přicházet na to, co ten kód vlastně dělá a proč to dělá, jak to dělá.
V know-how můžete mít odkazy na stránky, blogy, kusy textu opsané z knihy, obrázky, popisy API a všechno co vám pomůže rychle se do projektu znovu dostat.
Myslíte si, že u tak malého projektu, na kterém právě pracujete se to stát nemůže?
Hoši, hoši, ale může...
A jak by řekl Murphy, taky se to stane.
add 4)
OBROVSKOU!!! Napsal jsem to dostatečně jasně?
Jo ták, vy nevíte, co je Quick-Win. A už jste někdy zapsaly heslo přímo do kódu? Proměnnou jste předali metodě a pak v té metodě zahardkodovali její hodnotu, aniž byste provedli code-review a řádný refaktoring?
Že se vám tohle nestává? Promiňte, ale nevěřím. Tohle se prostě stává. Nemusí často, ale stává.
Jde o to, že na projekt máte vyšetřený nějaký čas, provedli jste odhad, ale nějaká část vám dala řádně zabrat. Víc, než jste čekali. Abyste v tom nezahučeli a projekt pro vás nebyl vysloveně ztrátový, musíte si někde pomoct.
A v ten okamžik jde někdy řádný návrh, objektovost a další věci stranou.
Projekt jste odevzdali, vše funguje, zákazník je spokojený.
To je dobře.
Věnujte ale trochu toho času a alespoň komentujte kód nebo si jinak poznamenejte, co vylepšit, až vás klient bude kontaktovat, že potřebuje další funkcionalitu.
add 5)
Toto je velmi důležité z pohledu návratu do budoucnosti. Pokud budete řádně měřit časy, odhadované a skutečné, pomůže vám to odhadovat čas na dalších projektech přesněji.
Hodně vám to také prozradí o vás samotném. Například, že si moc věříte a některé věci vám trvají mnohem déle, než odhadujete. Nebo naopak (ano, toto je přesně váš případ, já vím) se zbytečně podceňujete a práci odvedete mnohem rychleji.
add 6)
Jedete autem, klient volá, něco si vzpomněl, vy mu to odsouhlasíte, provedete, implementujete. Po dokončení projektu vás seřve, že toto nikdy v životě nechtěl a jak je to možné, a jak se to tam dostalo a vy nebudete moci říct nic.
Nehledě na to, že zadavatelů pro váš projekt může být více a klasickou cestou "levá ruka neví, co dělá pravá" se v tom můžete pěkně vymáchat.
Někteří klienti na to dokonce vysloveně "hrají". Prostě si vás povodí. Jeden chce to, druhý chce ono, vy kódujete celé noci a na konci jste rádi, že dostanete alespoň část peněz za vysvícené oči vaším monitorem.
Sbírejte a pečlivě uschovávejte důkazy, bude vás vysloveně těšit, až původní cena bude pod víceprácemi pěkně bobtnat.
To je vše, víc vám toho neřeknu.
Snad jen, hodně štěstí - budete ho potřebovat. Proč? Protože Murphy je hajzl.
- Příště více o těch projektech většího typu -
CSS - jak bojovat proti prohlížečům a neprohrát
Pokud chcete podvádět, tak pořádně. CSS Cheatsheets a další tipy, triky, layouty zde:
úterý 9. června 2009
Sharepoint - nástroje a šikovné utilitky
A opět bez dlouhých řečí, proč psát o něčem, o čem existuje daleko hezčí povídání:
čtvrtek 28. května 2009
Popis architektury
Nedávno jsem se dostal k jednomu projektu, na němž tým vývojářů s menšími obměnami pracuje přes tři roky.
A už dlouho jsem se necítil tak hloupě, jako právě u tohoto projektu.
Proč?
Protože, abych pochopil celkovou architekturu, musel jsem studovat zdrojový kód. Na začátku jsem dostal krátký briefing, od mimořádně sdílného programátora, jehož nejdelší věta se skládala z pěti slov.
Když jsem se zeptal, zda mají k dispozici nějakou dokumentaci, pomocí níž bych se s celým projektem seznámil, začali se hýkavě smát.
Dovedete si asi představit, že to celé vedlo k naprosté frustraci a vyčerpání. Hodiny strávené studiem kódu, jež měnil styly a sémantiku téměř s každou třídou, byly naprosto ubíjející. Nicméně se mi podařilo do kódu proniknout a podařilo se mi svůj úkol splnit.
Po dokončení práce jsem přešel na jiný projekt, a musím přiznat, velmi rád.
Nedokumentovat kód je obecně špatná věc. To víme všichni. Jenže zároveň dokumentovat kód je strašně otravná věc a pro vývojáře naprosto nedůstojná a pokud to jen trochu jde, nedělá se to. Ne nadarmo se říká, že nejlepší programátor je programátor líný. A chtěli byste po takovém člověku, aby dokumentoval kód. Našel v sobě zbytečky vyjadřovacích schopností a popsal význam, chování a příklady použití třídy, kterou navrhl za pět minut, ale dokumentací by měl strávit půl hodiny.
Nemyslitelné.
Na jednu stranu je to dobře. Tedy, částečně dobře. Umění je rozhodnout, kdy kód dokumentovat a do jaké míry a kdy ne. Nepředpokládám, že u malé utility aplikace byste vytvářeli dokumentaci na dvacet stran.
U složitějších aplikací je potřeba mít alespoň popsanou rámcovou architekturu a její důležité části, například ty, u kterých se při implementaci vyskytly problémy a bylo je potřeba řešit konkrétním způsobem.
U vysloveně složitých aplikací je potřeba dokumentovat a to velmi důsledně. Vy, kteří tak nečiníte, mnoho štěstí, řítíte se do pekel.
Věřte mi, sám jsem tam už několikrát byl.
Přihlásit se k odběru:
Příspěvky (Atom)