V komentářích za mým předchozím blogpostem se objevila otázka na to, jak velký projekt se dá zvládat ve vimu (nebo obecně textovém editoru) bez IDE. Tak jsem se rozhodl spočítat soubory a řádky ve svých největších projektech. Vyšlo mi toto:
Projekt | Souborů | Řádků |
---|---|---|
Desktopový klient | 193 | 49000 |
Webový výrobní IS | 307 | 64000 |
Jiný webový výrobní IS | 144 | 21000 |
Webový interface k ERP | 174 | 35000 |
Já nepoužívám IDE proto, že je mi z práce v něm fyzicky špatně. To ale nemyslím jako kritiku IDE, prostě to tak na mě působí. Upřímně teda řeknu, že poslední IDE, které jsem používal, bylo Visual Studio 6, a takové přidávání souborů do projektů, definice nějakých post-build kroků a tak bylo pro mě utrpení. Kromě toho, ten textový editor v něm patřil tak do 17. století. Doplňování kódu? Stačí mi bezkontextové – Ctrl+P. Class Browser? Dobře, v neznámém projektu to může pomoct, ale stejně potom budu z IDE rychle utíkat.
Když se podívám do historie, tak jsem začínal (asi jako všichni v mém věku) v Turbo Pascal / Borland C. Pak jsem přešel na Emacs, a když jsem pak znovu zakopl o Borland C, tak mě překvapilo, jak je ten integrovaný textový editor mizerný. Pak jsem přešel na vim, hlavně proto, že vi je všude, a že byl přece jen menší než ten Emacs. Uvažoval jsem, že zkusím Sublime Text, nebo Atom, ale teď jsem v situaci, že mám tak 50–100 počítačů (Windows), na kterých musím občas něco udělat, no a vždy, když dostanu nový, tak na něj nainstaluju balíček, ve kterém je Python + nějaké knihovny, a vim.
Jestli jste napsal 64 000 řádků pouze ve VIM, potom bezodkladně navštivte svého psychiatra, tam už budou vědět co a jak.
Ve volné chvíli nám můžete napsat, jak ve VIM řešíte navigaci mezi soubory ve smyslu Ctrl+Click, správné doplňování názvů a nebo debug jako třeba breakpointy, watch, call stack seznam threadů, pro zasmání to bude luxusní.
Jsem rad ze nejsem sam :) obcas se mi stava, ze se ve me kolegove s ruznymi eclipse apod. snazi vzbudit dojem, ze to bez IDE nejde, ale stale plati, ze ve Vimu jsem "doma".
Zaujala me ta veta o logicke strukture - cim dal vice zacinam zjistovat, jak moc dulezite to je a jak moc je to vesmes prehlizeno. Protoze pracuji na projektech srovnatelne velikosti, docela by me zajimalo, jak tu strukturu resi ostatni. Mohl byste o tom treba napsat dalsi blogpost?
[1] chapu, ze si myslite, ze to bez IDE nejde. Klidne si to myslete dal.
Jinak jenom ve zkratce (za me, za autora mluvit nemuzu):
a) navigaci mezi soubory "Ctrl+Click"? na mys pri praci nesaham
b) doplnovani nazvu? vim umi doplnovat cokoliv
c) debugger pouzivam pri debugovani problemu (tj. cca 1x za rok), ne pri programovani. Na hledani chyb v novem kodu jsou unittesty. Tj. podobne veci nepotrebuji.
Tak se zasmejte, a zkuste si predstavit, ze temer u vseho existuje nekolik ruznych zpusobu, jak neco delat. A protoze jsou lide ruzni, i zpusoby jsou ruzne.
Ono IDE (slušné, funkční IDE - zkušenosti mám s Eclipse (PyDev, CDT, ADT), VS2010 a XCode a jediné slušné je XCode) má spoustu hezkých vlastností a často pomůže. Ovšem Vim má taky spoustu hezkých vlastnosti, které v IDE nejsou, zejména tedy slušný textový editor, který se na, ehm, editaci textu docela hodí...
Nedalo mi, a pozrel som sa do archivu na projekt v PHP nad ktorym som zabil par rokov:
- 901 suborov
- 198 122 riadkov
- priemerny pocet vyvojarov 2-3
- pisane v davnej minulosti bez IDE vo VIMe/notepade
Ten projekt casom umrel na nedostatok zdrojov, nemal som pocit, ze sa v nom neda orientovat, ci ze je problem zaucit noveho cloveka.
[1] ach, ta rozmaznana mladez :)
Pre tych "expertov" co si myslia, ze bez IDE sa neda programovat odporucam knihu Pragmatic Programmer: http://pragprog.com/the-pragmatic-programmer
Vim je v prvom rade vyborny textovy editor. Co je pri pisani kodu zaklad. Okrem toho navigaciu medzi subormi a rozne ine veci zvlada bez problemov.
[4]: XCode že vede? Snažím se v něm už několik měsíců a oproti Eclipse mi dost přijde polovičatý. Podotýkám, že jsem nastudoval většinu klávesových zkratek a snažil se neopomenout žádné důležité části editoru. Co se vám na XCode tak líbí?
Mě tam schází našeptávání metod s rozlišením zda jsou zahrnuty i zděděné (v Eclipse 1x CTRL+O, 2x CTRL+O), hledání dle kritérií (typ souboru, cesta, ruční výběr) s výpisem shod a možností ve shodách nahrazovat (v Eclipse file search + file results), zobrazení typové hiearchie (v Eclipse type hiearchy), automatické sbalení/rozbalení kódu (folding) alespoň na úrovni metod (se snadným rozbalení či sbalením všeho). Taby se chovají divně (při otevření nového tabu se otevře včetně naposledy editovaného souboru, což mi přece nemůže být k ničemu dobré), občas zmizí záhlaví tabu takže netuším co tam je. Storyboard editor neumožňuje otevřít controller v novém tabu, scény nelze v seznamu ručně seřadit, scény v seznamu nejsou v zabaleném stavu klikací takže abych skočil na danou scénu musím ji rozbalit (čímž se stane seznam nepřehledným), navíc ze Storyboardu nelze snadno skočit rovnou na kód akce nebo outlet (nebo to neumím). Celkově musím často sahat na myš.
Mám dojem, že by mé problémy řešil http://www.jetbrains.com/objc/features/ ale nezkoušel jsem to.
C++, velikost momentálního projektu cca 40k řádků, všechno vim. Debugger (breakpointy, krokování) nastartovaný tak jednou, dvakrát za rok - vždycky se nechám nachytat a vždycky konstatuji, že jsou efektivnější metody, jak nahánět chyby. V gdb spuštěný program prakticky pořád, abych nepřišel o občasný sigsegv a backtrace.
Na editoru vim se mi libí, že je rychlý. Ještě jsem nikdy nenarazil na IDE, které by bylo schopné pobrat všechny znaky tak rychle, jak já dokážu psát. Naprostá tragedie je Netbeans, v závěsu za tím Eclipse. Občas nastartuji i QtCreator, ale ani ten to nedává. Je zoufalé, když mi IDE vyrobí v odstavci tři překlepy.
Někdy se bohužel nedá bez IDE obejít - tuhle jsem psal nějakou aplikaci pro Android v Qt a co se nakonec vlezlo do jednoho Makefile na deset řádků, bylo v návodu popsané na patnácti stránkách i s třiceti obrázkama. Nastavit něco v IDE bývá složité.
IDE mi připadá jako klacek pod nohama, který se staví mezi mne a mou práci.
Mě by zajímalo jak bez IDE děláš refaktoring (v pythonu nedělám takže nevím jestli je podporav IDE). Věřím, že takto malé projekty bez IDE zvládneš, ale představ si třeba systém co má několik milionů řádků a více autorů. V takovém projektu ti ani navigace mezi soubory nestačí, protože je zbytečné mít stáhnuté všechno (navíc když se to pořád mění). Dál práce s verzovacím systémem je základ. Nedokážu si představit, že by editor, v kterém píšu neuměl anotovat řádky podle toho kdo je kdy opravil nebo neuměl vyřešit konflikty při slučování. Dál třeba velice často potřebuju vyhledat všechny použití nějakého symbolu.
Bez IDE se programovat dá, ale kromě malých projektů to dá mnohem víc práce.
Tak jsem se schvalne podival na nejake me projekty. Vybral jsem jeden mensi v C#. Budu vypadat jako blbec, ale ted rychle nevim, jak zjistit pocet radku kodu, takze jsem zjistil jen pocet souboru. Jasne, muze byt v kazdem souboru jeden radek :-) Takze me projekty maji od 719, pres 1399 po 4245 souboru.
Take jsem napsal docela rozumny IS v php jen ve vimu a s vimem rad delam a delam v nem docela casto. Ve VS casto mackam esc, :, w a divim se, ze to nedela co chci. Stejne jako $ pro skok na posledni radek a podobne. Ale delat neco rozumne velkeho jen pres nej, to by mi prislo dost silene. Napovidani, skoky na definice, refaktorizace, debuger, memory dumpy a cert vi co jeste, na to vsechno mozna do vimu jsou nejake "pluginy", ale dobre IDE to ma rovnou a prece jen GUI ma proti textovemu rezimu neco do sebe :-)
Dulezite je, aby se prace darila, at ji dela kazdy v cem chce :-)
Jeste na to tady cumim a trochu mi to pripomina debaty z jineho fora :-). Jine forum je forum fanousku VAZu (patrim mezi ne ;-) ). Tam je mnozstvi lidi, kteri jsou tvrdymi zastanci myslenky, ze dnesni auta jsou na nic, ze jedina spravna jsou ta, ktera se delala pred 20 - 30 lety. Jde jim o to, ze dnesni auta vam "kecaji do rizeni", ze maji ruzna vykonova omezeni, ze ridic nema kontakt se silnic a ze prece udrzovane stare auto prece dojede tam kde ta nova, staci mu jen dat trochu pece a udrzby. Tezko se jim vysvetluje, ze kdyz v tom aute ma clovek cestovat casto, delsi trasy a uz neni nejmladsi, tak mu to nove auto pomuze, zbavi ho jistych utrpeni. Tempomaty, klimatizace, posilovac rizeni...
Ano, s vimem a trochou te snahy najit si pluginy a pri mladem mozku jiste muzete udelat zazraky. Ale, jsou i nastroje, ktere vam udelaji praci prijemnejsi a pohodlnejsi. Kazdy at uziva co mu vyhovuje. Uzivatel IDE by mel umet zvladnout i textovy editor jako je vim a uzivatel vimu by si mel nekdy zkusit rozumne IDE. Na program v C o 10 souborech nepujdu s IDE a na system mereni sireni zvuku s gui nepujdu vimem.
Typická jalová debata, typ 27B.
Uvědomte si prosím, že je ZÁSADNÍ rozdíl mezi situací kdy člověk programuje SÁM a situací kdy na projektu pracuje TÝM (no obecně větší množství lidí, kteří se navíc v čase vyměňují). Jakékoliv debaty o způsobu práce (ať už se jedná o IDE, programovací jazyk nebo dokonce paradigma) nemají naprosto žádný smysl pokud účastníci diskuse stojí v těchto odlišných světech.
PS: Nejde o velikost - i samotný člověk dokáže vytvořit velké věci. Naopak, občas je to jednodušší :-)
[18] to neni pravda. Pred par lety jsem delal ve firme, kde 2 lide (vcetne me) jeli ve Vim-u, jeden clovek jel v EMACSu a 2 dalsi pouzivali nejake IDE (vazne nevim jake) - nejvetsi a v podstate jediny problem, jaky jsme meli bylo dohodnout se na odsazovani (tedy tabelatory ano/ne, kolik mezer atd) :) a par dalsich detailech coding stylu, coz se predpokladam resi vsude.
Myslim ze IDEisti meli trochu problem s tim, ze museli delat nejakou praci navic, protoze ty jejich IDE nejak importovalo makefiles neboco.. v kazdem pripade projekt (linux, C, oracle) postupoval a po vyreseni coding stylu jsem nezaznamenal zadne problemy vyplyvajici ze spoluprace.
Nedokážu si představit, že bych dával přednost editoru, který nemá historii úprav, zobrazení změněných řádků proti CVS, debugování, kontextové doplňování kódu se zobrazováním dokumentace dané metody / funkce (užitečné hlavně v PHP, kde jazyk nemá moc dobrou konvenci pojmenování - s IDE to tolik nevadí), kontextové přejmenování, skok na definici funkce/metody, statickou analýzu kódu během psaní.
V minulosti jsem napsal kód, zjistil, že mi chybí středník, opravil, zjistil, že mi chybí středník jinde, opravil, zjistil, že mám překlep v názvu proměnné, opravil, zjistil, že mám jen jedno rovnítko místo dvou v ifu, opravil, kód se spustil, zjistil jsem, že kvůli chybějícím složeným závorkám u podmínky se mi provede jen první řádek, místo celého bloku, opravil.
Vše tohle mi IDE zanalyzuje před tím, než se vůbec kouknu na výsledek.
[20] A co přesně není pravda? Že nejde používat různou směs různých věcí? To asi opravdu pravda není, ale já jsem také nic takového netvrdil, že. Já jsem jen tvrdil že v této debatě padají jen nevalidní argumenty (nevalidní v logickém smyslu: závěr neplyne z předpokladů).
Mimochodem, k tématu: osobně nevidím žádný přínos IDE pro kombinaci C/Linux, kombinace vim+ctags+makefile by měla být zcela dostačující. A pokud by nebyla, tak to znamená že nejsou nastavena dostatečná pravidla a celý projekt se rozsype tak jako tak :-) Odvážné tvrzení, uznávám. Navíc jsem nikdy v C nedělal na dostatečně velkých projektech a ani neviděl žádné pořádné IDE.
Já různě přecházím mezi Eclipse CDT a Visual Studio 2010 (kde mám nainstalovaný Visaul Assist X). Osobně se mi lépe pracuje v Eclipse CDT i když má své chyby. Tam to samo sestavuje makefile, takže stačí jen pridávat nové soubory do adresáře. Ve visual studiu stále musím přidávat soubory ručně.
Hodně často používám hledání referencí a deklarací. Mezi zdrojáky neprocházím klepnutím na jméno, ale klepnutím na symbol. Velice často přepínám pouze mezi H a CPP a Ctrl+Tab musí fungovat pro přepínání mezi nejčastějšími soubory jako ve Windows Alt+TAB.
Driv jsem taky zvladal velke kvanta kodu bastlit v geany nebo ve vim. A ano opravdu to jde a nemam pocit ze bych byl nejak mene produktuvni. Teda aspon co se tyce rychlosti generovani kodu. Hlavni vyhodu v pouzivani IDE vidim v tom ze napriklad pro PHP je to velky pokrok. Diky tomu ze PHPStorm dokaze velmi slusne nejen napovidat ale i hlavne kontrolovat jakykoliv preklep, nebo predavani promene spatneho typu, spatny pocet parametru a podobne, tak se kvalita kodu zvysila mnohonasobne.
Dokonce to odhali veci jako nepouzita promena, nebo promena pouzita ale nedeklarovana atd.
Pokazde kdyz otevru jakykoliv program napsany v php, ktery nebyl vyvijen za pomoci PHPStormu tak se nedokazu divit kolik chyb v nem je. Ono jedna vec je ze to nejak funguje (napriklad predavat funkci ktera ocekava 2 parametry 3 parametry), ale co se stane kdyz pak pridame dalsi? Ve vimu bych neco takoveho hned nevidel.
Jinak prave to ze pouziva clovek vim muze casto byt duvodem ze je ten projekt vetsi, jelikoz slusne IDE umoznuje celekem snadno refaktorovat a tim i snizovat pocet radku. Take umoznuje odstranovat nepouzity kod a hledat duplicitni kod. Takze ono nakonec je mozne ze ty obrovske projekty napsane ve vimu na 40000 radku by se za pomoci poradneho IDE daly napsat na treba jen polovinu radku a z mnohem kvalitnejsim a mene chybnym kodem.
[27] Tohle mi přijde jako jeden z prvních rozumných argumentů, proč používat IDE. Mým nejužívanějším jazykem je C++ a v PHP jsem taky občas dělal nějaké věci. U PHP mě nepřestávalo udivovat, jak obrovské množství chyb jsem schopný v kódu vygenerovat, a přesto to jaksi "funguje" - čím víc jsem pak programoval v C++, tím více mě tato vlastnost PHP nestačí udivovat.
Jenže ono naštěstí C++ není PHP. C++ mi přijde jako jeden z nejstriktnějších jazyků, co jsem kdy používal. Konstrukce, které v PHP projdou (špatný počet parametrů, špatný datový typ v parametrech, konstanta místo proměnné), jsou v C++ nepřeložitelné. Před časem jsem hodil nějaký úkol v C++ na dlouholetého programátora v PHP a docela jsem se bavil, když prskal, že půl hodiny už honí v kódu chybějící středníky a ještě se mu nepodařilo program spustit.
Někdy mě mrzí, že nejsem na IDE zvyklý, některé věci se v IDE dělají opravdu pohodlně - občas mě například potřeba pohodlného ladění vláken přesvědčí k nastartování QtCreatoru, ale to jsou spíš výjimečné situace. Někdy používám QtCreator častěji, potom začnu blbnout ve velkém s breakpointama a krokováním, IDE k tomu svádí, než zjistím, že kód, který se hemží časovači, je v něm desítka vláken a nejdelší kus synchronního kódu má kolem stovky řádků se takhle prostě ladí špatně.
Překvapilo mě, že i QtCreator ani na mém počítači často nestíhá a nestačí psát, co do něj klepu. Při práci s Netbeans jsem si připadal, jakobych pracoval přes lagující mobilní spojení - když se do toho ještě přidal našeptávač, který občas přepsal, co jsem napsal před dvaceti úhozy, lezl jsem z toho po zdi. Bylo to jak diktovat blondýně heslo po telefonu.
"debugger pouzivam pri debugovani problemu (tj. cca 1x za rok), ne pri programovani. - mohli by ste priblizit tu aplikaciu? predpokladam, ze single thread ziadna integracia, vacsina kodu balast. Ak nie klobuk dole a hop sup do Google, MS a podobne. Za cloveka co nepotrebuje debuger a vsetko dokaze pokryt unit testami (???) zaplatia zlatom. Sice sa budete citit ako v ZOO ked sa budu menej obdareny kolegovia na vas chodit pozerat a nasavat vas talent ale cert to ber. Ak napiste knihu som prvy co pobezi si ju kupit, lebo pouzit debuger raz za rok je moj sen.
Jmenuju se Petr Blahoš. Programuju něco přes 20 let. Tady se snažím psát hlavně o Pythonu, webovém frameworku Pyramid, a občas i o něčem úplně jiném.
Přečteno 19 025×
Přečteno 11 763×
Přečteno 9 139×
Přečteno 8 651×
Přečteno 8 451×