jak rozwijać aplikację web PHP/MySQL?

Nie za bardzo wiem w którym dziale to puścić, ale kariera wydaje mi się odpowiednia z racji faktu, że temat ściśle związany za zatrudnieniem programisty.

Potrzebuję pomocy w temacie rozwijania sklepu internetowego. Firma 10+ pracowników, lokalizacja Warszawa, sklep internetowy PHP/MySQL. W firmie jestem jedyną osobą techniczną z podstawową znajomością PHP. Ale nie znam się na frameworkach, systemach kontroli wersji, repozytoriach itd. Do tej pory apliakcja była chaotycznie rozwijana - mamy bardzo stary połatany kod. Potrzebuję jednak sprawny zespół (tzn. 1 lub 2 osoby) do rozwijania aplikacji sklepu - zarówno front jak i backend i pojawia mi się masę pytań:

• próbować szukać programisty front + backend, czy od razu sobie darować uznając, że nie ma ludzi dobrych w jednym i drugim?
• w jaki sposób kontrolować pracę programisty, samemu się na niej nie znająć? zlecić mu założenie jakiegoś repozytorium ze zmianami i raportować czas pracy?
• jeżeli programista nie będzie na pełny 'etat' (zapotrzebowanie mamy na ok 60-80% etatu) to jak się rozliczać? uzgodnić stawkę godzinową i potem wg zraportowanego czasu pracy?
• jak dopilnować, aby nad kodem mógł potem usiąść inny programista? narzucić jakiś system dokumentowania kodu?

Generalnie temat brzmi: jak osoba o podstawowej wiedzy technicznej ma zatrudnić i współpracować z programistą PHP/MySQL/frontend aby uzyskać dobrej jakości aplikację, która może być rozwijana w przyszłości.

Wszelkie uwagi bardzo mile widziane.

Marcin

ps. nie wiem na ile to istotne, ale budżet mamy ok 6k netto/m-c, co generalnie skazuje nas na pracę zdalną, bo z warszawskimi korpo tą stawką pewnie nie możemy konkurować.

. Do tej pory apliakcja była chaotycznie rozwijana - mamy bardzo stary połatany kod

A nie ma jakichś gotowych aplikacji do robienia sklepów internetowych? Może warto użyć czegoś gotowego i budować na gotowym (i darmowym) rozwiązaniu.

Nawet jeśli będzie trzeba zatrudnić programistę, to budując to na określonym systemie masz większą szansę, że kod będzie ładny, udokumentowany, w dobrym stanie (szczególnie, że piszesz "Do tej pory apliakcja była chaotycznie rozwijana - mamy bardzo stary połatany kod") - projektami open source zwykle ktoś się opiekuje (pod warunkiem, że są to projekty aktywnie rozwijane).

Niestety nie powiem, jakiego systemu sklepowego konkretnie warto by użyć, ale myślę, że zamiast nastawiać się na ciągnięcie starej wewnętrznej "połatanej" i "chaotycznie napisanej" kobyły warto się chociaż rozejrzeć za gotowymi rozwiązaniami.

Wątpię aby dobry programista pisał się na taki układ. Dla dobrego programisty chaotycznie rozwijany projekt to tortury psychiczne, z których chciałby się jak najszybciej obudzić.

Dobry programista, który by się podjął takiej roboty i wyszedł z tego obronną ręką to musiałby być naprawdę ambitny student, bez komercyjnego doświadczenia.

Rozliczanie najlepiej zrobić z kontrolowanym kosztem. Ustalacie cenę i termin każdego zdania. Godziny wypadają różnie i stawka godzinowa nie bardzo pasuje do pracy w której liczy się efekt.

Dzięki za odpowiedzi.

Problem z aplikacją jest taki, że ona jest bardzo rozbudowana i aby wykorzystać jakieś gotowe rozwiązanie, trzeba by nad nim najpierw pracować przez minimum pół roku, jednocześnie właściwie rezygnując z rozwoju aplikacji na ten okres. Raczej myślałem, aby to co jest przepisać na 'dobry' kod partiami. Poszczególne obszary np. odpowiedzialne za funkcjonowanie koszyka czy logowanie i obsługa usera itd. Czy tak proces jest wykonalny?

Jeśli chodzi o rozliczenia - problem jaki widzę to każdorazowa wycena działań, gdzie niejednokrotnie jest ona trudna do zrobienia. Moje doświadczenia są też takie, że programiści bardzo się boją wyceniać przed podjęciem działań - najprawdopodobniej właśnie z tego powodu.. Trudno ogarnąć skalę tematu, dochodzi do sytuacji gdzie przygotowanie rzetelnej wyceny zajmie 2h, podczas gdy zlecenie jest w zakresie np. 1-2k pln dla mniejszego elementu. I takie wycenianie co 5 min przy stałej współpracy średnio się sprawdza. Chyba że coś nie tak z podejściem do tematu wycen.

pozdr,
Marcin

Raczej myślałem, aby to co jest przepisać na 'dobry' kod partiami. Poszczególne obszary np. odpowiedzialne za funkcjonowanie koszyka czy logowanie i obsługa usera itd. Czy tak proces jest wykonalny?

Przy dobry kodzie jest. Jeśli kod jest słaby to zwykle nie ma takiej możliwości, bo wszystko jest ze sobą powiązane i nie da się tego łatwo "rozplątać". Bo jak spróbujesz wydzielic jeden moduł do refaktorowania to się okaże że ten moduł jest ściśle powiązany z 10 innymi i nie da się go zmienić bez zmiany tamtych.

Poza tym dokładanie nowych rzeczy do czegoś co już jest skopane to jest tzw "rzeźba w brązie". Licz się z tym, że w pewnej chwili projekt osiągnie masę krytyczną i stanie się zupełnie nie do utrzymania i nie do rozwijania. Tzn próba dodania czegoś albo poprawienia czegoś będzie skutkowała posypaniem się innych elementów.

przede wszystkim nie baw się w dokumentację, bo prawdopodobnie nie masz czasu na to i i tak dobrze tego nie zrobisz.

1. pierwsze co bym zrobił to postarał się zrobić jak najdokładniejsze diagramy, jest taki program dia, który pozwala w miarę szybko to ogarnąć: http://dia-installer.de/
   Nawet 10 minut i jest gotowa dokumentacja dla jakiegoś podstawowego projektu.

2. w diagramach uwzględnich cały ten BPM, czyli zróbcie diagramy biznesowe, ale też programistyczne (dopasowane do tego co się dzieje w biznesie)

3. jak jest czas i ma to być porządnie zrobione, to diagramy UML dla PHP. Ale jak nie ma czasu/kasy, to trzeba prowizorkę z dia

4. rozumiem, że potrzeba jakiś podstawowy CRM. I teraz tak.
   Należy dokładnie przeanalizować co się dzieje, ile idzie przez stronę internetową, a ile idzie sprzedaży np. przez allegro, jak wygląda baza klientów, baza dostawców, przydział obowiązków, pakowanie, wysyłanie.

5. znając te procesy BPM, to możesz dopasować jakiś "gotowiec" do tego.
   Popularne są teraz: PrestaShop, Magento, opencart, zen carp, drupal ecommerce

6. prawdopodobnie wchodzisz w ingerencję z jakimiś API, czyli np. API allegro
   No tutaj ciężko z "gotowecem", a więc trzeba samemu uszyć ubranie na miarę.

Jeszcze dla mnie to jest dziwne, że jest ponad 10 osób i tylko 1 ogarnia całość od strony technicznej...
znam podobny przypadek, ale na 3 osoby to aż 2 programowały, a więc wszystko sprawnie śmigało.

7. problem jaki pamiętam, to był taki wybór "gotowca", który pozwoli na sprawną integrację z back-endem. Było coś takiego, że należało umieścić towar w formularzach, a później z tych formularzy wyciągnąć dane i je posegregować w rozbudowanych plikach *.csv. Później *.csv szły do zewnętrznych API, a efekt tego taki, 1 przedmiot był sprawnie sprzedawany w wielu miejscach. Pojawiła się kwestia synchronizacji, co się np. stanie jak 1 przedmiot zostanie sprzedany, no to trzeba było dopisać bota pod cronem który to wszystko minotoruje i sprawdza.

Generalnie im bardziej rozbudowany system e-commerce tym więcej pojawia się problemów i tym więcej jest roboty. Ale jedno wiem: najlepiej wybrać gotowca, do którego będziemy umieli sprawnie "doszyć" swoje skrypty, złączenie z jakimiś tam API, czy też będzie łatwo wyciągnąć dane (najczęściej przez SQL i csv).

albo po prostu użyj jakiegoś gotowego skryptu bądź cms'a

że ona jest bardzo rozbudowana i aby wykorzystać jakieś gotowe rozwiązanie, trzeba by nad nim najpierw pracować przez minimum pół roku

Pierwsza estymacja jest często błędna (szczególnie jeśli brak ci informacji na temat istniejących już rozwiązań choćby).

Mam świadomość, że praca na starym kodzie jest słabym rozwiązaniem. Natomiast przez lata naprawdę dorobiliśmy sporo rozwiązań, których przepisanie wymagałoby podzielenia tego na dziesiątki projektów i potem realizowanie po kolei np. pod kątem wspomnianego nowoczesnego rozwiązania typu Magento itd. Pół roku-rok minimum, a prawdopodobnie więcej. Do tego multum różnych połączeń po api - np. mamy ze 3-4 zewnętrzne rozwiązania windowsowe (wykonane przez różne firmy), które musielibyśmy przepisać, bo synchronizują się z bazą sklepu, która by się zmieniła. Generalnie skala tego jest trudna do ogarnięcia i raczej wymusiłaby rezygnację z jakiegokolwiek developowania tego co jest na wiele miesięcy. Przy obecnym b.konkurencyjnym rynku (branża kosmetyczna i okolice) jest to bardzo ryzykowne.
Aktualny software to stary oscommerce - niby jakaś w nim filozofia jest, jest podział obszarów działania na pliki, na jakieś tam klasy itd.

Znane są przypadki na rynku, gdzie do tego typu sklepu (jakaś tam rosnąca sprzedaż, ale jednak stary soft) wchodzi inwestor, robi audyt no i wniosek jeden: przepisujemy kod bo teraz będziemy drugim allegro. No i przepisują miesiącami za horrendalne kwoty, a potem się okazuje po wrzuceniu na produkcję, że jeszcze 100 detali przeoczyli które działały wcześniej. No i walka z systemem dalej aby dojść do punktu, w którym byli wcześniej. Pamięta ktoś hoopla.pl? Albo Agito.pl - ostatnio chyba wdrożyło nowy system i potem płakali na FB, że się przenoszą na nową platformę i przepraszają, ale jakoś tak ciężko im to idzie.. (Mogłem pomylić nazwy firm, ale rynek zna sporo takich sytuacji)

Wracając do meritum, chyba prowokuję dyskusję, aby ktoś napisał, że hej oscommerce to super soft, dorobienie paru obiektów w PHP7, trochę dokumentacji w kodzie i można to rozwijać jeszcze przez 10 lat.. :-)

czysteskarpety napisał(a):

albo po prostu użyj jakiegoś gotowego skryptu bądź cms'a

tyle, że własnie to nie zawsze działa, tzn. gotowce działają tylko na twojej stronie domowej typu www.mojsklep.pl. Później pozycjonowanie, marketing - i teoretycznie mamy e-sklep i więcej niepotrzeba.

Problem polega np., że jest coś takiego jak api, najbardziej znane i wykorzystywane w Polsce to: http://allegro.pl/webapi
nie zawsze znajdziesz gotowca, który automatycznie ci dopasuje www.mojsklep.pl z AllegroAPI czy tam jakimś innym API.

Jeszcze jest taki trick, ale on działa w poszczególnych przypadkach.
Mając 10 osób nietechnicznych istnieje spore prawdopodobieństwo, że osoby te umieją korzystać z pakietu MSOffice lub LibreOffice. Jest to taki standard na rynku pracy, nawet dla osób nietechnicznych. Można to wykorzystać na wiele sposobów.

Więc bierzemy kogoś nietechnicznego i karzemy mu korzystać z Excela, którym zapisujemy pliki do *.csv. Reasumując: osoba nietechniczna > pracuje przez Excela > dane generuje w pliku *.csv > mając dane w *.csv (jest to zwykły plik tekstowy oddzielony spacjami) jesteśmy w stanie dosyć szybko przekonwertować te dane i wrzucić np. do jakiegoś API, czy tam gotowca e-commerce.

pamiętam przypadek, że ten sposób (dobrze przygotowany i z wyszkolonymi ludźmi) nawet pomógł. Należało tylko nauczyć ludzi wpisywac w excelu ścieżkę do obrazka, np. C:\fotki\001\sukienka65.jpg - więc po wyszukaniu dobrych ściezek do obrazków, to mamy *.csv, z pełnymi danymi, które już można przekonwertować np. PHP i wysłać do jakiegoś API lub gotowca.
To tylko trick i nie sprawdza się zawsze, ponadto przy większych projektach lepiej dopisać porządny front-end ;)

Ja na twoim miejscu zlecił bym to jakiejś firmie która by przeznaczyła na to 3-4 ludzi przepisała wszystko w 2 miesiące i zrobiła kompletną dokumentacje co daje ci że rozwój późniejszy będzie lepszy, szybszy, tańszy, bezpieczniejszy. Dopiero wtedy możesz sobie zatrudnić doraźnego programistę, który coś pogrzebie w nowym ładnym kodzie ale ja bym osobiście po prostu trzymał się tej wynajętej firmy i wtedy zlecał im jakieś dalsze ulepszenia w czasie.

Pamiętaj ze możesz takiej firmie zlecić przepisanie lub na zasadzie outsourcingu "wynająć" doświadczonych programistów którzy ci to zrobią.

Ok, dzięki za wszystkie cenne opinie. Na ten moment skłaniam się, jednak, ku przeniesieniu całości na Magento. Magento to jedyny system o wystarczająco dobrej architekturze (skalowalność, rozbudowa itd - nie chcę popełnić drugi raz tego samego błędu), tylko strasznie to bydle jest wolne.. W każdym razie jeżeli dobudowane moduły/wszystkie customizacje zostaną dobrze zrobione i opisane, to każdy magento dev powinien bez problemu pracować dalej z takim kodem - tak to rozumiem. Przeraża mnie tylko skala inwestycji, ale to już osobny temat.

A ja się dziwię, że jesteście dobrze prosperująca firmą i na 10 osób tylko jedna ogarnia programowanie... wtf?!

sklepy stacjonarne..

Trochę mnie dziwią odpowiedzi w tym temacie. Mówimy o sklepie internetowym, a nie o skomplikowanych aplikacjach.
Przewidujesz wynagrodzenie 6000 netto miesięcznie? W zależności od rozbudowania sklepu za 5-10 tyś zlecasz zdolnemu freelancerowi stworzenie nowego systemu pod sklep i zaadaptowanie do niego już istniejących baz danych.

Napisanie samego mechanizmu sklepu to kwestia 2-3 tygodni dla jednej osoby. Pare dni na dopracowanie frontu, jak się wahasz kup jakiś projekt , który dasz do zaaplikowania i po problemie.

Męczenie się ze starym kodem to kompletna strata czasu, a zatrudnianie osoby na stale to strata pieniędzy. Za dodatkowe 2 tysiące sklep postawią ci na przyzwoitym cmsie, a że coś niecoś wiesz o programowanie, sam będziesz mógł w razie czego administrować sklepem. Jeśli czujesz, że nie podołasz złóż po prostu wykonanie sklepu jakiejś firmie, one zazwyczaj oferują drobne prace administracyjne przy dodatkowych kosztach. ( nic w porównaniu do przewidywanych 6 tyś miesięcznie, które chciałeś przeznaczyć).

Sklep internetowy to jest skomplikowana aplikacja. Ilość mechanizmów, które zostały dobudowane do tej naszej aplikacji jest ogromna. Przykładowo - moduł pobierający przelewy z rachunku mbank i korelujący go z zamówieniami, zmieniając ich statusy. Albo specjalna procedura dla obsługi zamówień odbieranych w sklepie stacjonarnym. Itd.
Zgadzam się co do jednego - rozwijanie starego kodu to strata czasu. Aktualnie próbujemy opisać posiadamy system pod kątem wykonania nowego na - prawdopodobnie - magento.

A skąd masz pewność że Magento będzie najlepszym wyborem? Znasz dobrze tą platformę? Robiłeś jakiekolwiek rozeznanie pod kątem możliwości tej platformy? Jak dużo jest potencjalnie na rynku programistów którzy się na tym dobrze znają? Oprócz tego są jeszcze frameworki takie jak Symfony, Laravel i inne. Piszę tylko dlatego żebyś potem nie narzekał że nie możesz znaleźć fachowców albo chcą więcej niż Ty możesz wydać :-)

Pracownik zdalny może być konkurencyjny bo może mieszkać w jakiejś dziupli i mieć o niebo mniejsze koszty niż ktoś miejscowy z Warszawy, stawka 6K na miesiąc może być tutaj absolutnie zadowalająca, jest tylko pytanie czy samodzielny programista w ogóle jest w stanie poradzić sobie z ogromem pracy który byłby przed nim. Z tych powodów lepiej uważaj na podpowiedzi freelancerów którzy na tym etapie często liczą na coś więcej a konkretnie że może dasz im jakąś robotę a później się okaże że założony przez nich czas realizacji jest za krótki albo się okaże że skala projektu przerasta takiego freelancera :-)

Nie sądziłem, że ten wątek będzie tak długo żył. Ale super, każdy komentarz coś wnosi do tematu.

drorat1 napisał(a):

A skąd masz pewność że Magento będzie najlepszym wyborem? Znasz dobrze tą platformę? Robiłeś jakiekolwiek rozeznanie pod kątem możliwości tej platformy? Jak dużo jest potencjalnie na rynku programistów którzy się na tym dobrze znają? Oprócz tego są jeszcze frameworki takie jak Symfony, Laravel i inne. Piszę tylko dlatego żebyś potem nie narzekał że nie możesz znaleźć fachowców albo chcą więcej niż Ty możesz wydać :-)

Pewności, że Magento to dobry wybór nigdy nie będę miał. Dość spory research robiłem i robię nt. platform ecommerce. Z Magento miałem też do czynienia i wrażenia umiarkowane - bardzo powolny, ale i rzeczywiście robił wrażenie sensownie rozbudowywalnego - a to jest kluczowe, drugi raz w to samo bagno nie wejdę. A zakładam, że problem z szybkością działania jakoś uda się rozwiązać z varnishem i innymi patentami. Ale też godzę się z tym, że strona produktowa nigdy nie będzie się generować w 0,1-0,2 sek jak na naszym starym systemie teraz..
Nie ukrywam, że w mojej ocenie też dobrym sposobem na wybór platformy jest patrzenie na dużych. Jeżeli poważne firmy programistyczne (tzn. takie, które są relatywnie znane na rynku czy obsługują większych klientów, których CTO chyba nie może się mylić? :) No więc jeżeli np. divante wdraża ecommercy na magento, to jakiś w tym sens jest - taki jest mój tok rozumowania. Poza tym opinie o architekturze Magento 2 są bardzo dobre. Z tego co zdążyłem się zorientować nie ma bardziej profesjonalnie napisanego systemu open source, a w komercyjne rozwiązania nie wejdziemy - nie ta liga raczej. Nie chciałbym tego wątku zmieniać w szeroko opisane 'która platforma jest naj', ale wszelkie uwagi mile widziane :)

drorat1 napisał(a):

Pracownik zdalny może być konkurencyjny bo może mieszkać w jakiejś dziupli i mieć o niebo mniejsze koszty niż ktoś miejscowy z Warszawy, stawka 6K na miesiąc może być tutaj absolutnie zadowalająca, jest tylko pytanie czy samodzielny programista w ogóle jest w stanie poradzić sobie z ogromem pracy który byłby przed nim. Z tych powodów lepiej uważaj na podpowiedzi freelancerów którzy na tym etapie często liczą na coś więcej a konkretnie że może dasz im jakąś robotę a później się okaże że założony przez nich czas realizacji jest za krótki albo się okaże że skala projektu przerasta takiego freelancera :-)

W tej chwili raczej myślę o znalezieniu partnera technologicznego (czyt. firmy, nie freelancera z dziupli), która zrobi wdrożenie i będzie potem rozwijać aplikację. Limit 6k już dawno odpuściłem. Ecommerce to fundament firmy na przyszłe lata. Ja muszę się zapoznać z nowymi technologiami pobieżnie i w praktyce jakoś nadzorować kierunek tylko.

dzięki za cenne uwagi.