@bogdanconstantinescu & IDE users: nu vi se pare ca IDE-urile tot ce fac de fapt este sa mascheze complexitatea?
In sensul ca daca codul este atat de stufos incat nu reusesti sa gasesti nimic in el, poate este semnalul unui refactoring sau really bad design?
Legat de debugging et al. - eu unul prefer sa fac asta doar pt. codul meu si as close to the metal as possible - nu si pentru IDE-ul in sine (ca orice software fiind departe de bug-free) si/sau codul generat de IDE
Plus sa nu mai adaug cat de slow sunt majoritatea, vi il pot rula in terminal cu un overhead de 15M.
Pentru Microsoft tech, acolo nu prea ai alegere documentatia la tehnologiile lor fiind = deschide VisualStudio, clic acolo, adauga asta si gata merge mai putin cand nu merge.
@dakull, mie mi se pare ca daca nu folosesti un IDE ajungi la complexitate a codului. Prefer oricand sa am 100 de clase intr-un proiect, fiecare cu logica ei, definite dupa un design pattern clar in loc de a avea 10 fisiere cu 1000+ linii de cod (si nu vorbesc din povesti, am vazut “clase” de 10mii de linii).
In orice software complex vei avea o oarecare complexitate, dar faptul ca nu folosesti un IDE iti rapeste multe feature-uri cum ar fi:
debugging
navigarea usoara in proiect (“open file by class name” etc)
code formatting
rename + refactor
code generation (da, e foarte placut sa generezi getteri/setteri pentru proprietati)
find in project by regex match
etc
etc
Cat despre “slowness”, totusi suntem in 2014. Daca nu ai 4GB RAM pe masina pe care dezvolti, e problema ta. Cu tehnologia actuala nu cred ca exista IDE-uri excesiv de slow - eu sincer am momente cand am avut pornite in acelasi timp phpStorm, RubyMine, XCode si laptopul meu e probabil printre cele mai vechi de pe aici - ca idee, laptopul de pe care scriu acum si pe care il folosesc la development e din 2009 (Core 2 Duo).
Daca IDE-urile ar fi slow, crede-ma ca as observa instant.
Dintre toate astea eu fara debugging nu as putea lucra. Si daca unii numesc “debugging” faptul ca fac dump-uri (ca majoritatea de pe aici folosesc php), eu nu pot renunta la debuggerul meu in care-mi pun watch-uri si vad cum ruleaza fiecare bucatica de cod atunci cand am nevoie - salveaza ore intregi de dump-uri random.
@dakull: am o vagă bănuială că memoria folosită de un editor - fie că-s 15Mb sau 1500Mb - contează destul de puțin, având în vedere cât de ieftin este RAM
@bogdanconstantinescu: nu este vorba de o încetineală de ordinul secundelor. Storm (și cam toate aplicațiile Java dacă stau să mă gândesc) mi se pare că are un delay foarte mic la orice operațiune. Nu este ceva care să încurce cu adevărat, dar cel puțin pe mine mă enervează.
Și da, uneori „trișez” și eu cu Storm (deh, EAP are avantajul că nu expiră :D) și îl folosesc la formatarea codului în proiect sau la refactor când am un proiect mediu-mare.
Fun fact: WPML este un plugin premium pentru WordPress. Clasa principală? 10248 linii. La un moment dat glumeam cu un prieten că autorii au luat cartea Clean Code și au făcut absolut tot pe dos:
clase lungi;
metode fără sfârșit (metodele peste 300 linii sunt ceva extrem de comun)
absolut nici o separare a codului (html amestecat cu php și cu javascript)
indent cu spații dar și cu tab-uri (în același fișier!)
tight coupling of… every single thing!
etc…
Poate că într-o bună zi mă voi apuca să înșir tot ce văd eu în neregulă cu el
@iamntz acei 15M conteaza pentru ca este foarte usor de inchis si redeschis procesul (i.e. daca il inchid nu fac mini-heart attack ca am inchis n-taburi) evident facand abstractie de cpu cycles si latente pierdute pt. acel UI
debugging
try *nix CLI utils si poate TDD?
navigarea usoara in proiect (“open file by class name” etc)
vim ctrl+p / ctags etc. basic bash auto-complete / zsh / pana si file navigation included este complet utilizabil
majoritatea exista deja si in SublimeText
code formatting
orice editor poate face asta
rename + refactor
again meet *nix (pentru rename)
refactor != a modifica nume de clase si extract method - asa doar ascunzi problema sub pres
code generation (da, e foarte placut sa generezi getteri/setteri pentru proprietati)
o poti face in vi fara probleme daca este atat de greu
find in project by regex match
grep / ack / ag / git grep ? sa adaug si cat de rapide sunt?
Cat despre “slowness”, totusi suntem in 2014. Daca nu ai 4GB RAM pe masina pe care dezvolti, e problema ta.
Pe OSX 8G iar pe Win 16G ambele cu i7-uri si SSD (unul fiind conectat pe pcie) dar am explicat mai sus care este de fapt problema cu RAM-ul.
Nu neg utilitatea lui vim, daca te uiti mai sus o sa vezi ca am specificat ca folosesc vim uneori Si la fel ca orice developer folosesc CLI-ul mult spre foarte mult - de exemplu eu folosesc git in terminal (mi se pare ineficient sa fac asta in IDE), mai ales ca mi-am facut aliasuri short cu timpul.
Laptopul meu e prima generatie de MBP unibody (Core2Duo, ram upgrade la 8GB) si dupa cum iti ziceam si mai devreme, am momente cand am 3 IDE-uri pornite, un iTerm cu 5-10 taburi, Chome, Spotify si alte prostioare si chiar nu se misca incet deloc de-asta zic ca “slowness-ul” e inexistent tinand cont ca folosesc o masina cu mai putine core-uri decat your average Android smartphone (evident, nu poti compara CPU-urile, dar tot e funny).
Pe langa IDE-uri si vim mai folosesc TextMate pentru random text edits si Mou pentru markdown (live preview, export HTML sau pdf), dar in afara de astea chiar nu simt nevoia de altceva.
Sublime nu m-a atras niciodata si asta e ok, e o chestie de gusturi; IDE-urile ma ajuta sa fiu mai productiv, folosind o idee mai multe resurse si pot sa spun cu siguranta ca nu voi renunta la ele in viitor, but that’s just my personal option.
PS: Cand zic ca folosesc git in terminal, nu te gandi la git commit -am - fac absolut tot acolo, diff, stage, unstage, interactive rebase, history search etc.
“slowness-ul” este clar partea relativa aici / la fel cum zicea si @iamntz acele mici intreruperi se simt / eu unul le simteam si in SublimeText, search-ul de exemplu este uber slow.
Gusturile se discuta, la fel si opiniile, optim la bere Productivitatea este intr-adevar ceva greu de masurat si daca deja ai muscle memory primed pe IDE-uri normal ca vi sau alt text editor o va reduce (la inceput ) insa asta nu inseamna ca vi, emacs sau un simplu text editor nu poate inlocui fara probleme orice IDE.
Plus mai este si problema clasica (care mi s-a intamplat recent) work machine went down, am deschis frumos Putty cu vi si mi-am continuat work-ul fara mari batai de cap
In facultate preferam sa scriu Java in notepad decat ca configurez Eclipse pe calculatoarele din sala Pentru auto complete si cross file/method navigation exista ctags si ctrl+p deci in esenta se poate utiliza vim si pentru un limbaj verbose ca Java fara probleme plus: vim se incarca < 500ms vs Eclipse care papa secunde bune.
evident facand abstractie de cpu cycles si latente pierdute pt. acel UI
Si la fel ca orice developer folosesc CLI-ul mult spre foarte mult - de exemplu eu folosesc git in terminal (mi se pare ineficient sa fac asta in IDE), mai ales ca mi-am facut aliasuri short cu timpul.
Pentru auto complete si cross file/method navigation exista ctags si ctrl+p deci in esenta se poate utiliza vim si pentru un limbaj verbose ca Java fara probleme plus: vim se incarca < 500ms vs Eclipse care papa secunde bune.