Jaki framework jest najtanszy? Opcje

[cepa]

Czesc,

projektuje pewien system ecommerce, poki co wysokopoziomowo, wymagania, mockupy, procesy biznesowe, generalnie co to ma robic. Na dniach bede musial zejsc poziom nizej na architekture, model danych i pojawia sie kwestia technologi i frameworka do implementacji.

Pytanie w jakiej technologi i w jakim frameworku to zaimplementowac?
Jakich narzedzi byscie uzyli do zbudowania systemu ecommerce tak aby mozna bylo oddelegowac prace zewnetrznej firmie lub zatrudnic programistow?

Zalozenia sa z grubsza takie:
- projekt wewnetrzny
- czas zycia systemu 2..3 lata
- wiele brandowanych instalacji
- frontend uzywany przez klientow i automatyczny backend
- brak backoffice (osobny projekt)
- integracje z zewnetrznymi systemami (platnosci, analityka)
- 1k...10k zarejestrowanych kientow
- relacyjna baza danych
- brak potrzeby skalowania (przy wiekszym ruchu i tak zostanie przepisany)

Nie jest to rocket science wiec po przekazaniu projektu do wdrozenia dobrze by bylo zeby mozna bylo go wykanac praca ludzi na poziomie junior/mid developer. Najlepiej ludzmi dostepnymi na Polskim rynku. Takze aby mozna bylo zmienic developerow w trakcie pracy nad systemem i pozniejszym utrzymaniem. Sklaniam sie ku PHP jako stosunkowo taniej i dostepnej technologii.

Dzieki z gory za odpowiedzi i sugestie.

Ten post edytował cepa 6.06.2016, 12:40:05

[mrc]

Jeżeli chodzi o użycie frameworka, to użyj dowolny który jest dobrze udokumentowany (Symfony, Zend, Yii, Cake itp). Polecam Ci użyć frameworka jedynie do obsługi czystego mvc. Resztę zrób sam, będzie wtedy łatwiej przy zmianie frameworka gdyby ten był zły.

[by_ikar]

Jeżeli chodzi o użycie frameworka, to użyj dowolny który jest dobrze udokumentowany (Symfony, Zend, Yii, Cake itp). Polecam Ci użyć frameworka jedynie do obsługi czystego mvc. Resztę zrób sam, będzie wtedy łatwiej przy zmianie frameworka gdyby ten był zły.

Nie ma w php frameworków MVC, a samo nazwanie jakiejś klasy modelem, widokiem czy kontrolerem nie czyni tego magicznie MVC. Opisywanie jakiegoś frameworka w php że jest MVC, to zwyczajne użycia buzzword'a.

Polecam symfony i inne zbudowane na jego komponentach (np laravel), bo jak trzeba będzie rozbudować czy coś poprawić, to nie będzie trzeba szukać magika, tylko kogokolwiek kto umie czytać dokumentacje.

Ten post edytował by_ikar 6.06.2016, 15:08:35

[daro0]

Dla ścisłości tak naprawdę frameworki PHP opierają się o pochodną MVC czyli MVP. Nie ma bezpośredniej komunikacji widoków z modelem, tym wszystkim steruje prezenter. Pewnie że Symfony albo Laravel, te są najpopularniejsze. Ale opieranie się tylko na dokumentacji nie jest dla mnie żadnym argumentem. Są frameworki gdzie ich dokumentacja opiera się na źródłach i to oficjalnie niemal w całości, spróbujcie wykorzystać taki np. Kohana i życzę powodzenia. Jest dość prosty ale mało popularny. Poza tym trzeba również dobrze znać FW, żeby móc poprawnie (a właściwie zgodnie z tym co narzuca FW) zaimplementować np. integrację z jakimś zewnętrznym serwisem płatności, tutaj nie liczyłbym na gotowce.

Ten post edytował daro0 6.06.2016, 15:44:15

[com]

Ja bym się zastanowił, czy tak naprawdę framework jest Ci potrzebny, ostatnio pojawiła się inicjatywa stworzenia takiego systemu przez community https://github.com/dumplie/dumplie, który powstaję niezależnie od ram narzucanych przez jakaś konkretną implementację oferowaną przez fw. A ecommerce na Symfony to już mamy nazywa się Sylius, zawsze można iść w rozwój któregoś z nich.

[aniolekx]

jak chcesz miec Active Record to YII2, jak future proof i DDD to Symfony, a jak chcesz miec jak najwiecej out of the box to Laravel (czesto hejtowany ale ale popularny bo developer friendly), reszty nawet nie bierz pod uwage

ogonie to powinienes wybrac ten framework, ktory najlepiej znasz

[Dejmien_85]

Pytanie w jakiej technologi i w jakim frameworku to zaimplementowac?

Nie jest to rocket science wiec po przekazaniu projektu do wdrozenia dobrze by bylo zeby mozna bylo go wykanac praca ludzi na poziomie junior/mid developer. Najlepiej ludzmi dostepnymi na Polskim rynku. Takze aby mozna bylo zmienic developerow w trakcie pracy nad systemem i pozniejszym utrzymaniem. Sklaniam sie ku PHP jako stosunkowo taniej i dostepnej technologii.

Może to zabrzmi okrutnie, ale technologia i framework nie mają nic do rzecz jeśli chodzi o sukces projektu. Możesz to zrobić w PHP, Node, a nawet i dałbyś radę w Cobalu. Fakt jest taki, że jak Ci to będą Juniorzy rozwijać, to wszystko spier...lą i ostatecznie będziesz miał spaghetti (code) i setki robali (bugów). ; )

Framework to detal - po latach tak naprawdę zrozumiałem, że framework to tylko kanał wejścia/wyjścia. Parsuje jedynie request, daje Ci routing, przy okazji dostajesz ORM-a i to tyle. Cała aplikację powinieneś napisać w Plain Objects, beż żadnego couplingu z frameworkiem, czy bazą danych. Clean Architecture się kłania.

Jedyne co widziałem przez ostatnie lata to pisanie, a później narzekanie, że kod stary, że framework stary, że przepisać by się przydało - takie stałe programistyczne pitolenie. Coupling to śmierć. Frameworki to zwykłe kanały I/O wypchane setkami niepotrzebnych pierdół, które tworzą niepotrzebny coupling Twojej logiki biznesowej z farmeworkiem.

Framework powinien być pluginem, niczym więcej - ale nie zrozumie tego ten, kto całe życie frameworki uważa za "szkielety". Tak, to szkielet - porażki.

Tyle z mojej strony, szerokości.

Ten post edytował Dejmien_85 14.06.2016, 22:13:01

[vokiel]

Może to zabrzmi okrutnie, ale technologia i framework nie mają nic do rzecz jeśli chodzi o sukces projektu.

Na sukces projektu w głównej mierze składa się pomysł a nie jakość kodu.

Cała aplikację powinieneś napisać w Plain Objects, beż żadnego couplingu z frameworkiem, czy bazą danych. Clean Architecture się kłania.

Jedyne co widziałem przez ostatnie lata to pisanie, a później narzekanie, że kod stary, że framework stary, że przepisać by się przydało - takie stałe programistyczne pitolenie. Coupling to śmierć. Frameworki to zwykłe kanały I/O wypchane setkami niepotrzebnych pierdół, które tworzą niepotrzebny coupling Twojej logiki biznesowej z farmeworkiem.

Tu się nie zgodzę. Framework to zestaw gotowych przetestowanych rozwiązań. Te setki gotowych pierdół powodują, że nie musisz ich pisać sam. Oszczędzają czas i pieniądze, minimalizują ryzyko wprowadzenia kolejnych bugów podczas implementacji. Poza tym co to za argument, że niepotrzebnych? Modułowość dzisiejszych rozwiązań pozwala na wybranie tylko tych fragmentów, które są potrzebne.

Patrząc na wymagania projektu: intranet, 2-3 lata. Tytuł: Jaki framework jest najtanszy?
IMHO najlepszym rozwiązaniem jest znany i popularny, przy tym stabilny framework (typu Symfony, Laravel). Krótszy czas tworzenia projektu niż w przypadku manufaktury czy korzystania z mniejszych frameworków. Duża dostępność programistów, a przy tym krótki czas wdrożenia nowych osób w projekt. Jakość kodu na zbliżonym poziomie niezależnie od poziomu programisty. Łatwe utrzymanie w przyszłości (LTS). To wszystko powoduje, że stworzenie i utrzymanie projektu jest stosunkowo tanie, a przy tym szybie.

[mrc]

@vokiel
@Dejmien_85

Storm pomiędzy klepaczem kodu a programistą, który rozwija swoje umiejętności.

Osobiście stoję po stronie Dejmien_85. Używając wszędzie kodu który jest przywiązany do frameworka ograniczasz swoją wyobraźnię oraz umiejętności planowania architektury oprogramowania. Pisząc coś samemu, zamiast zastanawiać się jak to zrobić by było prawidłowo, po prostu piszesz - tworzysz klasy, funkcje, które później będziesz wykorzystywał wielokrotnie.

[phpion]

To w takim razie po co nam framework skoro i tak większość aplikacji piszemy poza frameworkiem? Jak dla mnie taka aplikacja nie będzie spójna. Wolę mieć w kodzie porządek nawet na takim poziomie, jak przynależność do konwencji danego frameworka. M.in. z tego powodu nadal nie potrafię przekonać się do tego nowego podejścia z odchudzonymi frameworkami oraz Composerem. Wciąż bardziej do mnie przemawia idea frameworków-kombajnów, które instaluję i mam dostępne wszystko co potrzebne, a do tego współgra to ze sobą idealnie bez konieczności dogrywania kolejnych paczek.

Czuję, że ta pozorna wymienność frameworków przy proponowanych przez Was podejściach jest jak z abstrakcją bazy danych umożliwiająca stosunkowo łatwe przejście na inny silnik: każdy się nad tym podnieca, ale mało kto z tego kiedykolwiek skorzystał.

[mrc]

@phpion

Piszesz kod pod Symfony 3. Pięknie. Przychodzi Symfony 4, które usunie pewien komponent, zmieni zasadę działania czegoś itp. Żeby przenieść kod na nową wersję frameworka, musisz przepisać pewną (może nawet sporą) część systemu.

[aras785]

@phpion

Piszesz kod pod Symfony 3. Pięknie. Przychodzi Symfony 4, które usunie pewien komponent, zmieni zasadę działania czegoś itp. Żeby przenieść kod na nową wersję frameworka, musisz przepisać pewną (może nawet sporą) część systemu.

Ale nikt nie wymusza przenoszenia aplikacji na nową wersję frameworka...

Ten post edytował aras785 15.06.2016, 09:47:27

[SHiP]

Najważniejsza jest równowaga. W kwestii opłacalności frameworku liczy się jest cena programisty oraz jego wydajność. To jak kod będzie wyglądał nie ma ogromnego znaczenia. Świetnym przykładem jest FB, który był zaprogramowany fatalnie, ale gdy osiągnęli pewien pułap wartości spółki po prostu wydatek związany z przepisaniem/optymalizacją kodu był ułamkiem procentu ogólnego dochodu. Jednak wracając na Ziemię ;-).

Wybierając:

- zenda 2/3 - potrzebujemy mało drogich programistów, ale ich znalezienie będzie bardzo trudne
- symfony framework - potrzebujemy mało drogich programistów
- laravel - potrzebujemy mało troszkę tańszych programistów niż SF
- wiem, że to nie FW, ale potrzebuję porównania - wordpress - potrzebujemy nieskończenie dużo bardzo tanich programistów

Oczywiście można wziąć niedoświadczonego programisty do SF/zenda ale połowę czasu zmarnuje na czytanie dokumentacji zamiast na programowaniu, co się po prostu nie będzie opłacać.

Jak robimy stronę o kotach, to bym chwycił za WP, jak coś dużego to SF, Laravel. Jeżeli ktoś chce korzystać tylko z komponentów, a cały szkielet napisać samemu to zend 3 wraca do modułowości znanej z zenda 1.

PS: w firmie mamy projekt napisany w zend 1, który nie jest aktualizowany od około 4 lat i nikomu nawet nie przychodzi do głowy, aby go przepisywać na nic nowszego. Bo po co? Aby mieć przestrzenie nazw w kodzie?

[com]

aras785 gdzie Ty żyjesz, coś co nie ma wsparcia, nigdy nie będzie dobre na tyle, żeby się na zawsze tam zatrzymać, jak za 10 lat znajdę Ci security buga, to nikt nie siadzie i Ci go nie załata. Będziesz musiał sam się wysilać, żeby naprawić core frameworka z którym się tak silnie związałeś. Przywiązanie do architektury, było kiedyś dobre, kiedy do jakości kodu nikt nie przywiązywał wagi. Tworzyło się monolity i projekty działały lata. Tylko programiści, zaczęli być coraz bardziej wygodni, narzędzia coraz bardziej im to umożliwiały i jesteśmy tu gdzie teraz, gdzie każdy zaczyna projekt od wyboru frameworka, w którym go napisze. A dobór technologii to jest tylko jeden z wielu punktów fazy przygotowania do projektu. Trzeba się tak naprawdę zastanowić czego potrzebujemy, jakie casy ma obsłużyć nasz system, a nie od razu myśleć a zrobię to w Zendzie/Symfony/Laravelu czy czymkolwiek się tam komuś wymarzy, bo np tylko to potrafi. Framework to tylko platforma do obsługi Requestów, a nie maszynka do wszystkiego. Każdy kto go inaczej chce używać robi to źle, bo to my jesteśmy architektami naszego oprogramowania, a nie użyty przez nas super wypasiony framework.

SHiP Jak sam zauważyłeś "nie jest aktualizowany od około 4 lat", nikomu nie przychodzi bo nikt wam za to po pierwsze nie zapłaci, bo kto by chciał, przecież działa, a druga sprawa nikt tego nie chce tykać, bo nikt nie lubi pracować z legancy.

To jak kod będzie wyglądał nie ma ogromnego znaczenia.

I tu się mylisz, jeszcze jak widać sporo lat doświadczenia przed tobą

I przytoczony prze Ciebie przykład fb, to zupełnie inna bajka. Tam największym problemem, był problem skali. Ówczesne wersje php, nie były na to gotowe by podołać takiemu ruchowi jaki on generował, owszem kod może nie był obiektowy, bo duża cześć była napisana strukturalnie, wiec nie dało by się tego utrzymać po dziś dzień, ale to nie znaczy, że ten kod był przez to mniej wydajny, czasem nawet się mówi, że strukturalny działa szybciej od obiektowego, tylko jego zmora są problemy w utrzymaniu tego.

Ten post edytował com 15.06.2016, 12:26:13

[Spawnm]

@SHiP w Symfony 2 też jest duży problem z brakiem programistów.

[aras785]

aras785 gdzie Ty żyjesz, coś co nie ma wsparcia, nigdy nie będzie dobre na tyle, żeby się na zawsze tam zatrzymać, jak za 10 lat znajdę Ci security buga, to nikt nie siadzie i Ci go nie załata.

Siądzie i załata

[mrc]

To jak kod będzie wyglądał nie ma ogromnego znaczenia.

I właśnie tym różni się klepacz od programisty. Dla mnie kod ma największe znaczenie zaraz po poprawnym działaniu.

[Dejmien_85]

Na sukces projektu w głównej mierze składa się pomysł a nie jakość kodu.

Sam pomysł jest wart tyle, co ogromna kupa słonia. To tyczy się wszystkich dziedzin. Nie liczy się pomysł, tylko jego implementacja. Pomysł to dopiero początek drogi.

Tu się nie zgodzę. Framework to zestaw gotowych przetestowanych rozwiązań. Te setki gotowych pierdół powodują, że nie musisz ich pisać sam. Oszczędzają czas i pieniądze, minimalizują ryzyko wprowadzenia kolejnych bugów podczas implementacji. Poza tym co to za argument, że niepotrzebnych? Modułowość dzisiejszych rozwiązań pozwala na wybranie tylko tych fragmentów, które są potrzebne.

Spoko, możesz wykorzystywać jakieś funkcjonalności frameworka, ale w jego rydzach i nie mieszkać tego z logiką biznesową Twojej aplikacji.

[SHiP]

Nie zrozumieliśmy się :-). Nie twierdzę, że kod powinien być najgorszej jakości i wypraszam sobie niskie doświadczenie i klepacza kodu . Chodziło mi o to, o czym wspomniał wcześniej vokiel

Na sukces projektu w głównej mierze składa się pomysł a nie jakość kodu.

Ponadto gdybym miał wybierać jako programista framework, to wybrałbym Zenda 3, bo moim zdaniem jest najbardziej elegancki, ale jako właściciel firmy nie wybrałbym go nigdy ponieważ byłoby to marnowanie pieniędzy. Zamiast inwestować ogromne pieniądze stworzyłbym prototyp np. w laravelu, a gdyby w pewnym momencie okazało się, że zmiana FW zaoszczędzi pieniądze (bo np. brakuje programistów), to bym go zmienił. ZAWSZE najistotniejszym elementem są pieniądze. To czy kod będzie obiektowy, strukturalny, napisany w php, czy w cobolu determinuje jedynie to czy w danym momencie się to opłaca. Jest to zawsze kwestia drugorzędna.

EDIT:
@Dejmien_85: zgadza się, ale powstawały projekty na kolanie, które osiągały sukces np. pierwsza wersja ebaya napisana w weekend. A gdyby ktoś usiadł i teraz napisał we wręcz idealny sposób kopię ebaya, to sukcesu wcale nie ma zagwarantowanego.

Ten post edytował SHiP 15.06.2016, 17:02:29

[com]

aras785 tak ale najprawdopodobniej, to będziesz musiał sam zrobić, ok jasne, że może się znaleźć ktoś życzliwy, ale tak naprawdę to stare wersję są martwe.

SHiP jak mniemam do mnie też to było, nie znam Cie i nie kategoryzowałem twojego poziomu wiedzy, bardziej chodziło mi o to, że jak sam mówisz zgodziłeś się z faktem przedstawionym przez vokiel. A tak jak mówi Dejmien_85, sam pomysł jest tyle warty co ta kawa przy której siądziesz i mi o nim opowiesz. Bo można mieć pomysł na wspaniały biznes, widzieć się jako milionera, a projekt nie utrzyma się nawet 2 lata.

I nie nie zgodzę się, kasa owszem jest ważna, każdy chce dobrze zarobić i najlepiej się przy tym nie narobić, ale to jest tylko wynagrodzenie, za prace, twoje do niej przygotowanie, za wiedzę, doświadczenie. Jasne, że bez niej nie ma sukcesu, bo nikt nie chce być niewolnikiem, ale z projektem jest jak z domem to jest inwestycja na lata. Żeby go utrzymać w dobrej kondycji trzeba o niego dbać, a najprościej to zrobić, dbając o jakość kodu, bo potem nie ważne czy nam przyjdzie go supportować czy ktoś inny po nas to odziedziczy, poco robić sobie dodatkową robotę. Tak jak wspomniane, zróbmy w przykładowo laravel, potem się przepisze, to nie jest dobre...