Přejít k navigační liště

Zdroják » Různé » Mírný pokrok v mezích zákona

Mírný pokrok v mezích zákona

Články Různé

Před časem jsme zopakovali anketu mezi vámi, našimi čtenáři, abychom věděli, kdo jste, co děláte a jak. Pojďme se společně podívat na výsledky, na to, co jste o sobě prozradili, na to, jak se složení od loňského roku proměnilo, a jestli z toho můžeme něco vyvodit.

Nálepky:

V první řadě děkujeme všem, co v našem dotazníku odpověděli. Kdybych tu teď napsal, že si vašich odpovědí velmi vážíme a že nám poskytly cennou zpětnou vazbu, bude to vypadat příšerně uměle, ale ona to je pravda.

To, že jsou naši čtenáři především programátoři, to víme. V anketě jste to potvrdili: 82 % zaškrtlo možnost „programování server side“, 73 procent pak „programování client side“. 68 procent zaškrtlo i „kódování HTML / CSS“.

Pokud tyhle informace přečteme z jiného úhlu, tak vidíme, že minimálně polovina hlasujících zaškrtla kombo „server side programování + kódování“. Nevím jak vy, ale já jsem z tohoto obrázku jen omezeně nadšený. Ano, chápu, že některým freelancerům nic jiného nezbývá, ale bohužel i v mnoha firmách a studiích je normální, že programátor programuje server side, client side a rovnou si píše i HTML/CSS. Někde i navrhuje design a UI. A to není dobře – v první řadě proto, že je, upřímně, jen málo lidí, co všechno tohle umí na velmi dobré úrovni.

Téměř polovina čtenářů má na starosti analýzu, čtvrtina vede projekty či týmy, čtvrtina dělá design. 

Stran přijímání nových technologií je velmi potěšujících 49 procent čtenářů, kteří aktivně hledají novinky a způsoby, jak je využít (před rokem jich bylo 42), a neméně potěšujících je 29 % hlasujících pro možnost „použijeme to, co se nejlíp hodí“ (před rokem 32). Možnost „dlouhodobě odzkoušené“ před rokem zvolilo 26 % čtenářů, letos už jen 22.

Používané programovací jazyky stále drží stejný poměr a víceméně odpovídají světovému žebříčku. Takže přes 70 procent PHP, čtvrtina Java, 17 procent .NET, Python, Ruby. 17 procent pro JavaScript na serveru je poměrně překvapivých, a osobně bych řekl, že část hlasujících přehlédla dodatek „Na serveru“.

Smutnější, ale rozhodně ne překvapující, je stále vysoká preference „modelu vodopád“. Vývojáři jsou velmi konzervativní, to je známá věc, a věci, které fungují, používají (někdy i když už fungovat přestanou). Přístup „rozebereme to, pak to poskládáme, pak to odladíme, pak to předáme“ fungoval desítky let a vývojáři i vedoucí týmů dobře znají jeho slabiny, takže s nimi dokážou počítat. Dvě třetiny to takto praktikují. Jedna třetina respondentů používá některé prvky z agilního programování, nebo dělají čistě agilní vývoj.  Je to nadějná zpráva, a možná časem přestanou kolovat jedovaté vtípky „Naprogramovali jsme to agilně. Vytvořili jsme sice zabugovaný nepoužitelný software, ale měli jsme ho hotový za tři týdny!

U deploy webového projektu stále vede „FTP ručně“ (40 procent). Jen o tři procentní body míň získala možnost „verzovacím systémem“. 12 % pak zvolilo „jiný automatizovaný postup“. Zajímavé je srovnání s anketou u článku „Prostě to tam nahraju FTPčkem – nebo ne?“, který vyšel v lednu letošního roku.

Sedmatřicet procent pro možnost „deploy verzovacím systémem“ bude asi souviset se 48 % čtenářů, co používá Git. O něco víc než polovina používá SVN. Vypadá to, že verzování „na sdíleném disku“ bude brzy minulostí, což je dobrá zpráva.

Pěkných je i 31 % pro online repozitáře, v tomto směru jsou čtenáři Zdrojáku tedy poučení, progresivní a novinek se nelekají. Další online služba z ankety, Google Docs, má dokonce 48% zastoupení.

Nad deset procent se ještě dostaly CSS preprocesory, a těsně na hranici zůstal Basecamp. CoffeeScript, HTML preprocesory a Node.js získaly svorně po devíti procentech, což na druhou stranu není vůbec špatný výsledek, na to, že se jedná stále o „žhavé novinky“.

Lehce zarážejících je 19 procent čtenářů, co si píšou většinu kódu sami. Ale budeme věřit, že to jsou hlavně čtenáři, pracující na tak specifických úlohách, že žádné knihovny, které by jim pomohly, neexistují, a že zákazník má tak vysoké požadavky na bezpečnost, že si i třídění pole musí napsat sami (co kdyby byl v knihovně backdoor). Každopádně jsem rád, že jsem vynechal původně zvažovanou otázku „Testujete kód?“

Třetina čtenářů by na všechny otázky odpověděla stejně jako loni. Šest procent pak zcela jinak. Polovina zvolila možnost „změna u jedné, dvou otázek“. To je povzbudivé zjištění – víme, že čtenáři nestagnují, že se vyvíjejí. Má tedy smysl přicházet s novými podněty.

Možná by bylo zajímavé zjistit, jak velká byla korelace mezi odpovědí „letos stejně jako loni“ a „Startup je nesmyslný buzzword“. Nebudu spekulovat a jen zmíním, že třetina čtenářů zvolila tuto možnost. 40 procent respondentů by ve startupu klidně pracovalo, a desetina nějaký startup provozuje.

Suma sumárum nám vychází Průměrný Čtenář Zdrojáku:

Programátor, který píše v PHP. K tomu i kóduje HTML/CSS a píše klientský JavaScript. Novinky sleduje, a pokud pro ně má využití, tak je nasadí. Programuje „vodopádem“, agilní techniky spíš nepoužívá. Verzuje SVNkem a vytvořené dílo nasazuje pomocí FTP uploadu na server. Změnám se ale moc nebrání, a napřesrok pravděpodobně už bude používat Git.

Ještě jednou díky všem za odpovědi a za celou redakci přeju všem čtenářům, průměrným, neprůměrným i extrémním, klidný konec roku, bez zmatků, shonů a dodělávání projektů na poslední chvíli…

Komentáře

Subscribe
Upozornit na
guest
18 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Clary

Bohužel to není jen o vývojáři. Tam kde jsem pracoval předtím jsme jeli SCRUM (zaškoloval nás Vašek Stoupa), využívali jsme TDD (vývojáři psali smoke testy a základní selelenium testy) ,k verzování používali Git a CI v podání Jenkinse, který nám špatné commity vracel (buď neprošly testy, cyhběl phpDoc nebo byly jiné formální chyby v kódu). Co prošlo Jenkinsem začleňoval dohromady merger, takže ještě před začleněním do stable kód prohlédl další člověk. Na složitější (ve smyslu že měl přijít na to jak to rozbít) byl tester (člověk co píše, ne kliká, testy) a na HTML/CSS kodér. Ještě doplním že jsme používali Nette

V nové firmě jede vývoj stylem co příjde, to se zpracuje dle priority (nízká, normální, vysoká). Mírný posun bylo vydávání novývh verzí po týdnu, avšak k verzování se používá SVN (osobně používám utilitku git svn) a přesvědčit ostatní o tom že Git je lepší není tak jednoduché, protože pro SVNku už mají napsané skriptíky a utility co jim pomáhají s commity (proč bych měl psát nějaké git rebase, když mi do toho Pepova skriptu stačí nspat číslo tasku a on to začlení za mě). Argument ostatních proti kodérovi je ten, že tím že v aplikaci je namícháno HTML společně s PHP a kodér by to nezvládl (Aplikace je napsaná v ZF bez šablonovacího fw). Scrum byl označen za něco, kde se hodně povídá a málo dělá, případně vadí slovíčka „zavázat se“. Citelná je absence testů (na testování nejsou prostředky) což znemožňuje refaktoring. (Možná to není napsané nejlépe, ale funguje to a nechceme to přepisovat aby se to nerozbilo). QA oddělení ve firmě není, takže kvalita=funguje to a vysvětlit proč psát kód hezky je občas nadlidský úkol, když kolegové nemají rádi „ukecané programy“ (foreach($result as $articleId => $articleData) – ukecaný, foreach($result as $k => $v) – neukecaný)

Jenže na chleba se vydělávat musí.

Clary

Máš na mysli firmy prvního nebo druhého typu? :) Připomínám že obě firmy jsou ve svém oboru úspěšné.

Kolemjdoucí

Hezká upřesňující otázka. :-D

Pracuju jako vývojář v malé firmičce – jsme jen dva, takže nás rozhodně považuju za freelencery a musím přiznat, že to pracujeme nějak tak, jak si popsal v prvním příspěvku.

Srigi

tak, jak si popsal v prvním příspěvku.

V prvej, alebo druhej casti?
Otazka pre Clary: Preco stale nepacujes u tej prvej firmy?

Clary

1) Chtěl jsem zkusit něco nového, podívat se také jak to dělají jinde.
2) Hypotéka se sama nezaplatí :-) (ale bylo by to krásné)

Oldisy3

A ani neni duvod proc by nemeli byt stejne uspesne.

ET

mozna by nebylo od veci zverejnit (imho to nejdulezitejsi), tj. kolik lidi se celkem zucastnilo ankety ?

František Kučera

A taky by se hodila nějaká tabulka/graf – v tom textu to sice všechno je, ale…

Srigi

Grafy su v povodnom clanku. Treba si u kazdej otazky kliknut vpravo dole na „Zonrazit vysledek“.

František Kučera

Ad „Smutnější, ale rozhodně ne překvapující, je stále vysoká preference ‚modelu vodopád‘. Vývojáři jsou velmi konzervativní…“

To je pouze jedna strana mince – tou druhou je zákazník resp. osoba, která za něj jedná. A to může být člověk, pro kterého je jednání s dodavatelem jen otravná pracovní povinnost, ten člověk nemá motivaci, nemá osobní zájem, nechce trávit hodiny na schůzkách s dodavatelem a čmárat si něco na papír a nedejbože… přemýšlet nebo zodpovědně schvalovat jednotlivé iterace. Chce sedět u svého počítače a flákat se, nebo plnit svoje běžné úkoly – zařídit nový web dostal příkazem shora a je to něco navíc, na co nemá čas a co se mu těžko vejde do rozvrhu. Takovým lidem perfektně vyhovuje vodopád, protože zpracují zadání/analýzu, předají ho dodavateli a pak mají zase nějakou dobu čas a klid na svoji normální práci.

Vyvíjet jinak než vodopádem, když zákazník chce právě vodopád, sice jde, ale musíme vzít (a zaplatit) někoho ze své firmy a postavit ho do role zákazníka* – skutečný zákazník nebude nic dělat, ale ten náš zaměstnanec ho bude simulovat. Takový způsob vývoje ztrácí poměrně velkou část svého kouzla a smyslu a nikdy se nedosáhne takového efektu, jako kdyby se v projektu angažoval zákazník (a ten náš člověk by potřeboval věšteckou kouli). Navíc hodně webových projektů je dost malých na to, aby se ještě drobily na iterace. Takže se pak vůbec nedivím těm dodavatelům, kteří to nelámou přes koleno a prostě na ten vodopádový vývoj za takových podmínek přistoupí.

P.S. někdy tu z toho mám dojem, že jediný správný vývoj je agilní a konkrétně SCRUMem (jako kdyby jiné metodiky neexistovaly) a kdo to dělá jinak, je sto let za opicemi. Nemyslím si, že by byly nějaké obecně špatné metodiky – pouze můžeme zvolit nevhodnou metodiku pro ten který projekt.

*) ono i „být zákazníkem“ je svého druhu práce

Jaroslav Martinec

p.s. on ani ten git není žádná velká výhra a určitě nesedne všem, i když ho tak mnozí rádi tlačí

Hard core vývojář se jistě neztratí ve změti parametrů a nevadí mu chabá dokumentace. Já jsem po několika fatálních problémech s gitem raději zvolil Mercurial. A to ještě lze zvážit Bazaar.

viz http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/

wim

Kromě SVN jsem průměrný. Úplně přesně.

gofry

„A to není dobře – v první řadě proto, že je, upřímně, jen málo lidí, co všechno tohle umí na velmi dobré úrovni.“

Na tom nie je nič zlé. Priemernej firme stačí priemerný web/eshop. Na veľmi dobrý jednoducho nemajú zdroje a nemôžu si ho dovoliť. Takže na otázku „priemerný web“ alebo „žiadny web“ je odpoveď jednoduchá.

x y

Na úvod podotýkám, že nejsem vývojář a k programování jsem se dostal nejblíž kdysi ve škole, případně spatláním (doslova) několika skriptů pro InDesign pro svou práci grafika, sazeče. Nicméně některé články zde čtu i tak rád (pokud jim rozumím ;)), zajímají mne postupy z jiných oborů. A také nacházím nejednu podobnost v cizích zkušenostech a inspiraci k různým řešení.

Co ale chci říct, že občas se při chválení nových postupů, nových programů, jazyků či technologií, zapomíná na zákazníka. I v mém oboru slýchám hodně hlasů, že teď je moderní jiný design, měl by se používat jiný software apod. (a sám vývoj sleduji velmi pečlivě a používám novinky, jak to jen jde), ale pokud se potkám se zákazníkem, který jednak nechce příliš měnit své stereotypy a jednak není ochoten uvolnit dostatek financí, tak prostě musím použít postupy pět, deset let staré (a pokrok jen jen opravdu velmi mírný, daný v zásadě jen vynucenou nekompatibilitou s aktuálním softwarem).

Je skutečně krásné (i dobré) mít určitý ideál nových postupů, které evidentně někde fungují. Je dobré k tomu ideálu směřovat a seznamovat s ním své zákazníky, přesvědčovat je, vysvětlovat… Ale stejně tak je nezbytné (a dobré) umět poznat, kdy je nový postup pro daného zákazníka kontraproduktivní – už třeba jen proto, že zákazník je příliš konzervativní a pokud ho budeme tlačit do něčeho, nač není zvyklý, tak dá zakázku jinam. A lidé, kteří mají to štěstí, že dělají v pokrokové firmě s pokrokovými, svobodomyslnými klienty, by neměli zapomínat na ty ostatní (natož nad nimi ohrnovat nos).

Oldisy3

se zazemim, pravidelnym mesicnim prijmem od zakazniku, s velkymi klienty, takova firma si muze dovolit mit jednostranne zamerene zamestnance, kde se deli na kreativce a kodery, kde si mohou dovolit do puntiku respektovat zvolene workflow, testovat, mit vlastni server na hosting, kde si mohou spustit prakticky kazdou sluzbu ktera jim pomuze pri praci. Jen mi prijde docela zle ohrnovat nos nad zacinajicimi firmami, nad zacinajicimi freelancery, kteri pochopitelne nemaji zazemi a proto aby se uzivili musi delat vsechno, rychle a levneji.

B.F.U.

no, popravdě řečeno, pokud firma začne tak že, abych tak řekl, „plácá páté přes deváté“ a bude jí to „fungovat“ tak nikdy nebude mít potřebu na tom „fungujícím“ systému něco měnit (bez ohledu na to že/jestli by na tom vydělala)

Mám praktické zkušenosti s oběma typy firem a musím říci že ne vždy to jak říkáte že „velká firma se zázemím“ dělá dobře a malá špatně, potkal jsem dost takových kde to bylo naopak.

Výmluva typu „nejsou na to prostředky ani čas“ je skutečně jen výmluvou za kterou se skrývá „neumím si představit nic jiného a hlavně se nechci nic jiného/nového učit“ – praxe je totiž taková (reálně ověřeno) že pokud si uděláte ve věcech systém, najednou jde všechno rychleji a je nutno řešit méně problémů. A na ten pořádek lze přejít i u rozjeté firmy, jen musí někdo s autoritou nakopat programátory do zadku – a tam bývá největší problém v tom že vedoucím je jedno jak programátoři/ko­déři/etc. pracují, hlavně když klient platí.

A něco jako team leadera či head programátora který by se STARAL ve většině firem které jsem nemají nebo ho mají jen tak papírově bez pravomocí, aby měli někoho kdo je zodpovědný za průsery….

Clary

Jop, souhlas. Taky mám podobnou zkušenost.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.