Mam dość długi staż w programowaniu i uważam się za przynajmniej średniozaawansowanego programistę.
Niestety jestem typowym samoukiem, a studia, które skończyłem, nie miały zbyt dużo wspólnego z typowym programowaniem (uczelnia ekonomiczna).
Nie pracowałem nigdy w typowej firmie programistycznej, ani nie miałem praktyk tak więc nie miałem skąd nabrać dobrych zwyczajów projektowych.

Obecnie aplikacje piszę np. w CI korzystając z IDE PhpStorm. Zawsze projekt jest na docelowym serwerze, automatycznie uploaduje zmiany via FTP, które widzę ja i klient. Nie korzystam z systemów wersjonowania (PhpStorm ma funkcję historii zmian pliku), nie pracuje lokalnie, nie korzystam z konsoli, nie robię testów jednostkowych. To się sprawdza, raczej nie powoduje to, że pisze kiepskie aplikacje, ale mam wrażenie, że jestem troszkę jakby jedną epokę wstecz.

Niedługo czeka mnie duży projekt, który chciałbym aby był takim przełomem w mojej pracy jako programista. Po pierwsze chciałbym przerzucić się na lepszy FW jakim byłby Laravel.
I tu już mam problem bo to FW, którego nie pobiera się na dysk i wrzuca na FTP.

1) W jaki sposób powinna odbywać się tak naprawdę praca nad dużym projektem przyjmując, że jest jeden programista i jedna osoba odpowiedzialna za frontend (/views).
2) Czy praca na localu jest normą w świecie programistów?
3) Jeżeli tak - to w jaki sposób pogodzić pracę kilku osób i w jaki sposób synchronizować ją? Czy PhpStorm pozwoli mi to jakoś zautomatyzować, czy muszę się uczyć komend systemu SVC?
4) Czym jest tak naprawdę konsola w FW? Wiem do czego służy ale pytam od środka? Skąd te komendy (instrukcje) się biorą? To program instalowany na Linux czy w plikach FW są jakieś skrypty bash czy inne?
5) Jakieś inne sugestie jak zorganizować pracę przy projekcie?

1) Jedna aplikacja w 2 miejscach. Tz. devel (wersja na której aktualnie pracujecie) i produkcja. Jeśli nie będziesz chciał nie grzebać w view to na pewno wystarczy. I obowiązkowo system kontroli wersji. Edit na serwerze -> commit -> up plików na produkcji.

2) Nie. Na localu robię tylko frontend. Pracuję na serwerze łącząc się przez ssh, według mnie to najlepsze rozwiązanie.

3) Do tego własnie służą systemy kontroli wersji. A co do nauki, z Gita nigdy nie korzystałem ale komendy dla svn [commit, up, diff] - najpotrzebniejsze nie są na tyle trudne aby odwlekać ich naukę.

5) "System zleceń" - Według mnie jest to bardzo dobre rozwiązanie do koordynowania pracy. Chodzi w tym mniej więcej o to że zapisujesz tam zadania które masz do zrobienia. I nie bój się rozwalać zadań na parę mniejszych. Dzięki temu nie pogubisz się. Dobrym pomysłem również jest integracja "systemu zleceń" z systemem kontroli wersji, coś w rodzaju tracka. Dla przykładu, masz już zrobiony projekt. Ale klient chce aby zmienić tam wygląd okienka popup i dodać do niego nową funkcjonalnośc. Więc w systemie zleceń zakładasz 2 zadania. Jedno na zmianę wyglądu a 2 na funkcjonalność. Tą z grafiką dajesz do grafika, tą z funkcjonalnością do programisty. Po dodaniu/zmianie kodu programista i grafik robią commit do SVC, potem sprawdzasz na serwerze testowym czy wszystko działa, i jeśli tak to leci na produkcję.

2) tak, do tego celu albo maszynka pod linuksem albo Vagrant. Pracowałem po SSH ale to mordęga była, po ssh tylko jakieś zmiany ew. odpalanie czegoś z konsoli np czyszczenie cache itp.
3) SVN, GIT, co kolwiek. Raczej skupiłbym się na Git, mniej zachodu na przyszłość.
4) Konsola w Laravel to nic innego jak zwykłe skrypty PHP odpalane z konsoli.
5) J.w coś typy Redbooth, Redmine czy inne dziadostwo (Dla upartych Mantis ) które pozwoli Ci wpisać Taski nad którymi masz pracować. Np. możesz sobie wpisać "Stworzenie struktury BD dla produktów" i tam sobie opisujesz, możesz wpisywać czasy żeby wiedzieć np. ile pracowałeś itd.

2 miejsca, rozumiem, że może to być ten sam serwer?
Grzebie w widokach czasem, jakie to ma znaczenie?
Edit na serwerze, ok, ale czym ma robić owy "commit"? Nie można tego jakoś zautomatyzować?
Teraz zapisuje bezpośrednio jeden plik na FTP, a tak rozumiem, że musiałbym mieć otwarte 3 aplikacje:
- PhpSTORM włączony z "develem"
- Konsolę gdzie dam owe "commit" (i nie wiem czy to da się zrobić globalnie czy pojedynczo każdego plik)?
- No i jeszcze zmiany chce wrzucić na produkcję czyli muszę mieć jakiś program, który wyślę pliki z DEV na Produkcję
Pozostaje problem, że np. koder coś na szybko zmieni na produkcji i mu to nadpiszę (teraz PhpStorm ostrzega, że plik został zmieniony).
Jakoś to skomplikowane wszystko..

Tak nie powinno być. Myślę, że w różnych firmach są różne praktyki czy "praktyki", ale generalnie nie powinno być tak, że ktoś coś "szybko zmieni na produkcji". Poza tym, jak się pracuje w systemie kontroli wersji to zwykle każdy programista pracuje na swojej gałęzi (na swoim "branchu"), i robi zmiany niezależnie od siebie. Później wysyła to do zdalnego repozytorium, tam się odbywa code review. Później dopiero się te gałęzie scala ze sobą do gałęzi produkcyjnej (albo do gałęzi develop).
http://nvie.com/posts/a-successful-git-branching-model/


i tak, i tak się da.

edit:


cóż, nawet przy zastosowaniu GITa są czasem konflikty (kiedy dwóch programistów edytowało ten sam plik), ale wtedy masz pokazane dokładnie które linijki są skonfliktowane i musisz je ręcznie scalić (WebStorm ma opcję która to ułatwia)

No ok, czyli system wersjonowania ma tylko sens gdy nawet zwykły koder z niego korzysta, a to niestety ciężkie do zorganizowania :/

Jak to? czemu? Przecież to standard.

W firmach typowo informatycznych, które pracują nad projektem na pewno.
Ale np. w firmie gdzie jestem tylko ja i np. osoba, która zna tylko HTML/CSS i absolutne podstawy PHP to nie widzi mi się nauka konsoli (nie korzysta z IDE).
Skoro taka osoba chciałaby np. poprawiać coś w widoku chociażby literówkę to musiała by znać GIT'a i móc np. odpowiednio reagować na wspomniane konflikty itp.

Twoje podejście jest straszne. Dla ciebie co nieznane jest złe i nie masz ochoty się tego uczyć. Z resztą nie ważne.

Jeśli pracujesz pod windowsem jest IDE do obsługi git'a(nie wiem jak pod linuksem), po za tym PHPStorm chyba ma obsługę git'a. Grafik tworzy brancha(1 komenda), po wprowadzonych zmianach tworzy commit'a(2 komendu) i wrzuca na serwer(1 komenda). Czyli łącznie cztery komendy do nauki, więc nie rozumiem "co cię tak boli". 10 minut i opanowane. Merge możesz zrobić sam, więc konflikty odpadają.

Gdyby było tak jak mówisz to nie zakładałbym tego tematu

W takim razie http://git-scm.com/downloads/guis, ponieważ chciałeś GUI.

Gdybyś jednak chciał się nauczyć parę komend: http://blog.end3r.com/119/git-latwy-system-kontroli-wersji/

Chwila nauki, a ogromne korzyści

To o czym piszesz to jakieś firemki, raczej nie opłaca się tam nawet wysyłać CV. No chyba, że to jedyna firma w okolicy, która zajmuje się programowaniem... Poza tym piszesz, że:

w takiej sytuacji raczej opłaca się szukać firmy, gdzie będą lepsi od ciebie, którzy cię nauczą tych praktyk, gdzie mógłbyś pracować jako junior uczący się pod kątem seniorów - a nie do firmy, gdzie byś był najlepszy w firmie (czyli de fakto pracowałbyś z gorszymi od siebie, ludźmi "którzy znają tylko HTML/CSS, absolutne podstawy PHP" i nie znają Gita). Czego byś się nauczył w takiej firmie?

na windows'a instaluj SourceTree - piękne GUI, bardzo przyjemnie się na nim pracuje. Jeśli wciskanie 2 przycisków będzie dla Ciebie za turdne, to już nie wiem jak Ci pomóc. Konsola w FW służy tylko do pomocy i nie jest niezbędna. A teraz idź odkrywać świat, do roboty !

Nie wysyłam nigdzie żadnych CV, chodzi np. o kontrakt na tworzenie i obsługę serwisu. Nie idę się tam czegoś uczyć (tzn. na pewno nie programowania) tylko po prostu stworzyć produkt i zarobić.
Przychodzę do firmy zwykle jako jedyny programista. To jest fajne ale ma swoje wady właśnie w tym, że nie ma mnie kto podciągnąć i podejść krytycznie do mojej pracy (bo użytkownicy końcowy zawsze są zadowoleni - ale wszyscy wiemy, że to niczego nie uwadniania od strony kodu i struktury mojej pracy.).


Już podjąłem konkretniejsze kroki w nauce, dziękuje, a te złośliwości nie były potrzebne - nic nie jest trudnego, po prostu chce dociec pewnych rzeczy przed ich nauką.

też dobre podejście (bo jakby nie było, kasa twoja), ale na dłuższą metę bardziej opłaca się pracować w jakiejś firmie, która cię nauczy dobrych praktyk (bo dzięki temu będziesz lepszym programistą, i będziesz mógł uderzać do lepszych firm i zarabiać więcej (chyba, że już wystarczająco zarabiasz teraz...). Poza tym będziesz miał lepszą organizację pracy = będziesz bardziej efektywny).

GIT pozwoli Ci na swobodną pracę w 2,3 50 osób

naucz się jak korzystać z konsoli bo 80% juniorów nie wie jak commita zrobić z konsoli, co jest i zabawne i straszne (a zdarza się ze phpstorm wywali się po mergu i nie pozwoili na zrobienie commita).

To i ja się przyłącze do dyskusji. Jakieś 4 miesiace temu byłem w sytacji podbnej do twojej. Byłem od programowania i czasami ktoś zdarzył się do frontendu.
Robiłem wszsytko lokalnie, po wykonaniu jakeigoś modułu wgrywałem wszystko na serwer.

Później zaczałem korzystać z narzedzia jakim jest Assana do rozpisywania zadań. Na poczatku były tylko maile. Fakt wymagało to od mnie poświecenia kliku chwil, żeby sobie rozpisać projekt i przekonać klienta żeby korzystał z tego ;p ale jak już wszystko było gotowe to dużo mniej czasu traciłem nad szukaniem po maila co jak ma wyglądać, czy co jest jeszcze do zrobienia. jednym słowem oszczędność czasu.

Później postanowiłem pójść na etat i do tej pory tak pracuję. Tutaj używa się narzędzia do zarządzania projektem i gita. Na poćżatku było mi ciężko się przestawić; ale teraz widzę jaka jest różnica. PM rozposuje zadania, programiści dostają info na maila, że mają coś do zrobienia, tworzy się branch z numerkiem zgłoszenia wprowadza zmiany wysyła zmiany do oceny. I dopiero później lecą na produckje czy do testów. Dzięki temu wiadomo po co był ten kod wprowadzany co robił i kto go wprowadził. I łatwo cofnąć efentualne błędy. Do tego tylko osoba uprawniona może przesłać plik na serwer testowy i nkt niczego bokiem nie wsadzi i kod dzieki temu jest u wszystkich taki sam.

Teraz po kilku miesiacach sam w swoich prywatnych projektach korzystam z takich rozwiązań. Choć jestem jedynym programistą to oszczędzam bardzo dużo czasu i mam podgląd na wszsytkie zmieny i wiem po co on były robione. Do swoich mały proejktów korzystam z https://bitbucket.org/ łączy on system kontroli wersji z systemem do zarzadzania projektami. Oczywiscie w bardzo, bardzo okrojonej wersji; ale mi do prostych rzeczy wystarcza.

No i to tyle mojej histori ;p

ad1 nie robienie tego samego, w tym samym czasie, aby nie mieć jakichś konfliktów przy pobieraniu commitów i generalnie jakaś komunikacja.
ad2 praca na localu to IMO jest kwestia samego projektu. Bo są projekty których nie odzwierciedlisz łatwo lokalnie. Co nie zmienia faktu że vagrant powinien stać się twoim przyjacielem.
ad3 phpstorm ma wbudowaną obsługę gita, chodzi fajnie, można sobie przekliikać, ale warto znać jakieś podstawy i link do manuala.
ad4 ktoś już odpowiedział, więc nie ma sensu powtarzać się.
ad4 jeżeli chcesz iść do przodu, to koniecznie nie stawiaj sobie jakichś dziwnych ograniczeń. Przykładowo ktoś ostatnio na grupie laravela zapytał się o hosting, poleciłem odruchowo mydevil, bo to jest hosting dla typowych devów, gdzie przez konsole możesz zrobić wszystko. To jeden taki gość, stwierdził że konsola jest dla nerdów - spoko, może i jest, ale ktoś kto jest devem, raczej nie powinien tak uważać, bo cli napisanych jest sporo fajnego softu, które albo nie będzie mieć innej graficznej powłoki, albo nie będzie sensu aby miało. A z racji że głównie przyjdzie ci pracować na linuxie, bo php na windowsie działa dziwnie, i ogólnie windows jest bez sensu, kiedy za free masz lepszy system do tego celu. To przyjdzie ci korzystać z konsoli częściej niż ci się wydaje. I jak będziesz stawiać sobie takie dziwne ograniczenia w stylu: "konsola jest dla nerdów, ja sobie to przeklikam na moim windowsie", no to dość szybko możesz zapomnieć o czymś poważniejszym.

rzeczywiście straszne