Workflow - poprawa wydajności - wymiana doświadczeń Opcje

[ziolo]

Zakładam temat(fajnie byłoby go przypiąć - pytanie do modów czy można) o wydajność workflow.

Jakie biblioteki, narzędzia, techniki, technologie wyraźnie poprawiły waszą wydajność podczas kariery programistycznej ? Można pisać o wszystkim co do głowy przyjdzie.

Myślę, że każdemu taka wymiana doświadczeń się przyda. W przyszłości wiadomo jak wszystko szybko ewoluje, co raz to nowe narzędzia dochodzą, też możnaby tu pisać.

Z mojego skromnego doświadczenia np są to:

1) Przesiadka z svn na git. Hostuje swój kod na bitbucket, wcześniej na swoim dedyku miałem serwer svn.
2) PhpStorm - narzędzie, które masakrycznie zmieniło moją wydajność pracy
3) Przesiadka z Windows na Linuxa(Ubuntu)
4) Praca na dwa monitory.
5) Pisanie testów jednostkowych.
6) Nauczenie się framoworka PHP(Ja np używam Symfony2)
7) Może głupie ale takie drobe rzeczy też są ważne - używanie przy ssh, git logowania za pomocą kluczy bez hasła. Dopiero od roku stosuje (IMG:style_emoticons/default/smile.gif)
8) Dysk SSD - ciężko mi sobie wyobrazić pracę już na zwykłym dysku.
9) Pisanie zgodnie z OOP - wzorce projektowe
10) Notism.io - swietne narzędzie do pracy grupowej
11) Nie wiem może mi coś jeszcze przyjdzie do głowy to napiszę.

W najbliższej przyszłości chcę się nauczyć w praktyce:
1) vagranta
2) angulara - przerobiłem tutorial ale jeszcze nigdy nie używałem w faktycznym projekcie, zawsze radziłem sobie z udziałem jquery - ale czasem jak strona jest (że tak to ujmę) bardziej skomplikowana dynamicznie - faktycznie dużo trzeba się napisać - i potem ciężko się do tego kodu zagląda

Ten post edytował ziolo 8.07.2014, 16:02:37

[Xirtam]

1) Przesiadka z Windows na Linux - chodzi o jak najbardziej podobne środowisko dev do produkcyjnego. Często miałęm taką sytuację, że potrzebowałem wykorzystać jakieś narzędzie z linii komend - jak mam podobne środowisko tu i tu to jest łatwiej a tak np może jakiegoś narzędzia nie być pod windowsem a jak jest to i tak trzeba stracić czas, żeby odpowiednio skonfigurować ścieżki tu i tu.

Moim zdaniem nie trzeba od razu przesiadac sie na linuxa. My rozwiazalismy to troche inaczej:
zostala przygotowana paczka z virtualna maszyna (przed dlugi czas uzywalismy virtualbox, od jakiegos czas jest to vagrant). Stworzone srodowisko jest mirrorem produkcyjnego. Do tego administrator dba o aktualnosc naszego "zestawu". Kazdy programista moze wykonac update swojej virtualnej maszyny w dowolnym momencie i miec pewnosc ze jego lokalne srodowisko pracy jest zgodne z produkcyjnym.

3) Odkrycie tego, że strony można budować/kompilowac. Zamiast wrzucać gołe pliki na serwer, można nastawić buildera, który np.
- skompiluje kod pośredni (np. Sass do CSS)
- zminifikuje kod wynikowy
- połączy ileś małych plików w jeden duży (przydaje się do łączenia CSS/JS czy nawet HTML).
- przekopiuje pliki w odpowiednie miejsca
etc.

Ciekawym narzedziem jest Jenkins. My uzywamy go do wielu rzeczy:
zaczynajac od monitorowania wolnego miejsca na dyskach, sprawdzanie jakosci kodu (w polaczeniu z Sonarem), deploy na rozne serwery testowe beta/delta (mamy ich ponad 40) az po release w srodowisku produkcyjnym (ten sklada sie m.in. z testow jednostkowych UnitTest, testy Selenium, kompilowanie plikow less (css), laczenie plikow js / css, deploy)