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.

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.

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.

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.

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

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.

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



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.

@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.

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ł.

@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...

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?

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.



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.

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

Siądzie i załata

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

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.



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

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



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.

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...

Tak się zastanawiam czy tego Laravela to zajakiś bliżej nieokreślony czas przypadkiem nie spotka to co Kohanę, widzę po oficjalnym repo że ostatnie commity KO3 były kilka mies. temu na 3.3.5 jako najnowszej wersji. Laravel wydaje się być o wiele prostszy do ogranięcia niż taki Symfony (mówię o realizaji projektów nich), z drugiej strony wg. niektórych projekty mogą być trudniejsze w utrzymaniu. Wydaje mi się że w dużych komercyjnych projektach nic nie przebije Symfony, i tak widać że jest dominujący a jego znajomość jest wymagana w lwiej cześci ogłoszeń o pracę.

Ostatnio pisałem pewnien niewielki projekt w Kohanie 3.3.4., wcześniej też pewnien niewielki projekt w KO 3.2, po czym ostatnio robiłem refaktor i port na 3.3.4. Jako że są pewne istotne różnice i w sumie pewna niekompatybilność wsteczna trzeba przy czymś takim bardzo uważać. Zwłaszcza jeśli chodzi o mechanizm auto ładowania klas, w 3.2 nornalnie wszystkie klasy były w plikach o nazwach z małych liter, obecnie od 3.3 uwaględniana jest wielkość liter. I trzeba się tu pilnować. Framework jest obecnie mało popularny a jeśli chodzi o jakieś moduły typu połączenia z MongoDB, Redis, OAuth i wiele innych rzeczy to niestety musiałem sobie sam takie napisać, bo istniejące już gotowce nie były zadowalające. To jest ta jedna strona medalu.

Ogromny plus Kohany: szybki (możecie sobie porównać zestawiając to z Laravelem albo Symfony), dodatkowo ma dość dobre narzędzia do wykrywania błędów i co ważniejsze kaskadowy system plików. Ale jeśli ktoś uważa że może sobie tak liczyć na gotowce i dobrą dokumentację to muszę go rozczarować, ta w całości opiera sie na jego źródłach. I niejako jest to nawet zaletą, bo w ten sposób można poznać co się tak naprawdę dzieje i jak to wszystko działa. Dość dobry wybór dla początkujących, łatwy do nauczenia, w przeciwieństwie do Symfony. Zastanawiam sie tylko gdzie jest granica jeśli chodzi o wielkość projektów?

@com: świetnie Cię rozumiem, ale przecież wątek jest na temat pieniędzy. Mamy tutaj projekt, który zgodnie z założeniami ma trwać 2-3 lata więc nie obliczałbym tego w kategoriach inwestycji na lata. Znając realia, pewnie to jakiś projekt unijny i za 3 lata po prostu ma umrzeć.

Co do wyższości projektu nad jakością kodu - chyba nie do końca się zrozumieliśmy.
Oczywiście implementacja pomysłu jest bardzo ważna, bo każdy z nas ma szufladę pełną super projektów, które nigdy nie zobaczyły światła dziennego. Miałem na myśli to, że ważniejszy jest pomysł i jego wykonanie niż sama jakość kodu. Większości klientów nie interesuje jak piękny kod zostanie napisany, ani jakie wzorce projektowe zastosowane itd - ma działać, nie mieć błędów i spełniać swoje funkcje.

Jakość kodu ma znacznie dla programistów, ale tym mniejsze im projekt ma krótszy czas życia oraz tym mniejsze im bardziej jest zdefiniowany na starcie.
Czyli, jeśli mamy projekt, który pożyje 2 lata, całość założeń jest zdefiniowana na starcie (np przetarg na aplikację dla urzędu) - to jakość kodu ma dużo mniejsze znaczenie niż w przypadku, gdy aplikacja ma działać 4 lata i być ciągle rozwijana.
Tak czy inaczej wszystko rozbija się o kasę. Dobry kod jest łatwiej rozwijać i utrzymywać, zatem jest tańszy w długim okresie. Słabszy jakościowo kod jest po prostu tańszy, ale na krótszą metę.

Owszem jako programista zawsze chciałbym mieć możliwość pisania kodu pod którym z chęcią się podpiszę, takiego którym mógłbym się pochwalić na GH. Świetnie jest móc pisać dobry kod, mieć na to czas i środki. Niestety nie każdemu jest to dane, nie w każdym przypadku ma to nawet sens. Inaczej jest w firmach tworzących i utrzymujących swoje aplikacje, a inaczej w tych robiących je na zamówienie. Tworząc oprogramowanie, z którego firma się utrzymuje, pisanie dobrego jakościowo kodu nie jest tylko dopuszczalne, ani nawet nie jest przywilejem - jest koniecznością. W przypadku jednorazowych aplikacji już tak nie jest. Trzeba też zrozumieć stronę biznesową, gdzie kod lepszy zwykle pisze się dłużej, przez to projekt trwa dłużej i więcej kosztuje, ergo daje mniejszy zysk. Przypomnę tylko, że w tym wątku dyskutujemy na temat najtańszego rozwiązania.

Kwestia legacy.
Większość aplikacji żyje krócej niż poważne FW mają LTS. Jeśli aplikacja będzie używana dłużej to zwykle pojawia się w niej tyle zmian, że z czasem i tak trzeba ją przepisać. Nie różni się to niczym od aplikacji pisanej bez użycia FW. Jeśli napisałeś ją pod PHP4 to jaka to różnica, czy z FW czy bez skoro na PHP7 i tak nie zadziała?
Jeśli jednak trzeba ją tylko zmodyfikować/poprawić, to łatwiej będzie o programistę ze znajomością (nawet starej wersji) FW niż o takiego, który połapie się w kodzie pisanym całkowicie bez FW.
@com bug w aplikacji, która ma 10 lat jest nieistotny bo będzie ona pewnie już dawno przepisana. Jeśli nie, to i tak większym problemem będzie wersja języka dla której została napisana. Niemniej, łatwiej będzie poprawić FW niż kod bez FW. Przypomnij sobie jaki kod pisałeś 10 lat temu - czy chciałbyś z nim dzisiaj pracować?

Co do zarzutów o klepacza to je przemilczę, nie znamy się na tyle, żeby oceniać takie aspekty.

Podsumowując, w tym wątku patrzę na zagadnienie głównie z punktu widzenia biznesowego, bo takie są założenia tematu. IMHO taniej jest wybrać popularny FW, gdyż czas a zatem i koszt będzie mniejszy, a w dłuższym okresie będzie łatwiej o kogoś do jego utrzymania. Owszem FW nie wymusi jakości kodu, ale daje większe szanse że będzie on "utrzymywalny".

vokiel pozwolisz, że się odniosę do twojej wypowiedzi i powiem tak mówisz, że "ważniejszy jest pomysł i jego wykonanie niż sama jakość kodu." To jest bardzo subiektywny wniosek, jasne dla polskich realiów może tak, ale trzeba patrzeć trochę szerzej. Nie ważne czy planujemy zrobić coś co pożyje z 2 latka i potem najwyżej się przepisze. Jasne, można z projektu zrobić maszynkę do czerpania kasy, obłowić się i o nim zapomnieć, ale ile projektów jest takich, że planowaliśmy krótki ich żywot, pomysł się sprawdził i żyją lata. A naprawdę napisanie dobrego kodu, dla sprawnego developera który posiada pewną wiedzę na temat projektowania aplikacji, nie musi wcale oznaczać że projekt musi trwać dłużej, jasne mogą zawsze wyskoczyć jakieś nie przewidziane sytuacje, ale to się wszędzie zdarza.

Co do kodu są różne kody, można zepsuć nawet ten używając cudownego frameworka, nie mając wprawy. Jeśli kod pisze się zrozumiale to nie ma problemu, żeby go przeczytać czy ewentualnie poprawić.

Odniosłeś się do mojej wypowiedzi, ale to jest wyrwane z kontekstu, ponieważ ktoś tam stwierdził, że wersji oprogramowania wcale nie trzeba zmieniać nawet jak się wsparcie skończyło Kod który pisałem 10 lat temu sie zapewne do niczego nie nadawał, ale jakie miałem wtedy doświadczenie... Nie byłem tu gdzie jestem teraz i to jest zasadnicza różnica Z punktu widzenia programisty masz swoją rację, ale są też architekci, o których sie trochę zapomniało własnie przez frameworki, które robią wiele za nas.

Co do samego podsumowania, jest to jedna z możliwych dróg, ale nie jedyna

U mnie wyglądało to tak, że miałem dylemat w czym pisać własne aplikacje oraz martwiłem się o wydajność (głupek)...
W tej chwili jak mam pomysł to tworzę protopotyp w CI 3 (najszybciej i najlepiej go znam), a jak się uda to SF 2.

Za dużo czasu traci się na rozmyślanie które rozwiązanie będzie lepsze, bo dla ludzi liczy się "wygląd" aplikacji, a nie jej "wnętrze"
Lepiej zrobić 50 aplikacji i liczyć, że wypali niż dłubać jedną piękną od środka ale się nie sprawdzi

ps. z własnego doświadczenia

Jeśli to ma być projekt tylko na chwilę i do porzucenia to nie przejmowałbym się tyle tylko brał to na czym się już znam, lub znają się na tym moi ludzie lub osoby które potencjalnie będę w stanie zatrudnić. Jeśli jest to aplikacja-strona o kotach, jak ktoś już napisał, na której i tak nic nie będzie zmieniane, a podziwiać będziesz ją tylko Ty i Twoja babcia, jak ją poprosisz, to taka aplikacja raczej wcale nie potrzebuje frameworka. Jeśli natomiast jest szansa by stało to się źródłem utrzymania na długie lata to zastanowiłbym się nad The Clean Architecture - framework będzie wtedy można wymienić na inny gdy się zestarzeje i analiza kosztów wykaże że to się opłaca, będzie można łatwo rozszerzyć zasięg webserwisami, aplikacjami mobilnymi itp.

Co do kosztów, to najlepiej skupić się na czymś ze społecznością (czyli nie sezonowe wynalazki), z dużym zapleczem, o budowie modułowej, z dużą bazą kodu na wolnych licencjach, czymś co jest popularne i czego w wolnych chwilach uczą się wszyscy począwszy od dzisiejszych gimnazjalistów do osób z doświadczeniem zawodowym. Wybrałbym coś z ekosystemu Symfony lub Zend - w takiej kolejności.

Ale to jest jedynie historia powstania - został napisany na kolanie w 1995 roku, teraz jest 21 lat później. Gdyby dalej był pisany na kolanie, to dzisiaj developerzy wprowdzaliby najprostsze poprawki tygodniami. Wiem o czym pisze, bo byłem w projekcie, który także powstał laaaata temu, a w kodzie czają się tylko potwory z bagien - wielkie kolosy, gdzie jedna metoda ma kilkaset linii kodu, high coupling itd. Jeden z programistów (doświadczony i sprytny) przez 2 tygodnie próbował się połapać co zrobić, aby wykonać jego task (z opisu prosty).
Także czy jakość kodu jest ważna? Oczywiście, że tak. Jest bardzo ważna, bo liczy się to co będzie później. Gdy ktoś zakłada firmę i prowadzi projekt, który ma coś zarabiać, to dlaczego niby miałby go zamknąć po roku czy dwóch latach? Jaki jest cel w zamykaniu dochodowego projektu?


Tak, dokładnie, samemu też mam kilka fajnych pomysłów, tylko problem jest właśnie z wykonaniem. Jak nie ma czasu i środków, to można mieć super pomysły i nici z tego.


Piszesz, że ma działać i nie mieć błedów, a to właśnie w słabej jakości kodzie, bez testów i pisanych z finezją czają się setki bugów. W małym projekcie, albo w początkowej fazie projektu tego nie widać. Ale gdy zajrzysz do projektu, który przez kilka lat był pisany bez większej troski, wtedy dopiero człek zaczyna rozumieć jaką wartość ma dbanie o jakość.

Znam kilka firm (z opowieści a także z doświadczenia), które z powodu słabej jakości kodu upadły - developerzy nie dawali rady dostarczyć produktu ani nowych wersji na czas, ani ogarnąć setek bugów, przez co klienci rezygnowali, a firmy nie miały środków na działanie.

Weź też pod uwagę fakt, że programiści to rozpieszczone istoty. Gdybyś na rozmowie kwalifikacyjnej usłyszał, że masz pracować z "legacy code", który był napisany 10 lat temu, wtedy chciałbyś się w to bawić? Każdy chce się uczyć, iść do przodu, zdobywać doświadczenie z aktualnych technologii, które są "cool" - symfony, laravel, zend, angular - to jest to, czego chcemy. Nikt nie chce grzebać w gównie.

Pięknie, niech sobie wyjdzie. Moja aplikacja jest na Symfony 3 i działa elegancko, to sztuką dla sztuki byłoby przepisywanie jej na 4. W pracy piszemy w ZF1 i nikt nie myśli o przepisaniu aplikacji na nowszy framework. Aplikacja jest, działa i rozwijamy ją na tym, co mamy.

Kto przy zdrowych zmysłach będzie chciał przepisać całą istniejącą już i sprawdzoną aplikację z jednego dajmy na to mało popularnego na inny bardziej popularny albo na nowszą, niekompatybilną wstecznie wersję frameworka? Ile to kosztuje i ile to czasu zajmie? To dlatego się w ogłoszeniach o pracę szuka kogoś z preferowaną znajomością nie koniecznie popularnego Symfony ale np. Yii, CI, czasem nawet Kohana.

To się wszystko zmienia z biegiem czasu, wczoraj to co było np. w Laravel 4.2 było OK, dzisiaj jest Laravel 5, zaszły pewne dość istotne zmiany, L4.2 pozwala na uruchomienie aplikacji na PHP 5.4, L5 już na PHP 5.6, choć z tym już nie ma problemu. Ale są pewne istotne zmiany gdzie nie ma mowy o żadnej konmpatybilności wstecznej bo ze względu na rozłożenie plików i katalogów jak również przyjęte w L5 konwencje będą się różnić od tych w L4. I przez takie fanaberie programistów i jakąś tam durną modę trzeba będzie ponieść duże koszty przepisując to co jest na nowszą wersję a nie koniecznie może to oznaczać oszczędności, bo przede wszystkim to trzeba mieć sporą wiedzę a po za tym to w każdym nawet najlepszym FW kod może być do bani.

Aby przepisywać trzeba mieć mocne argumenty.
Przepisywanie w dużej mierze ma sens z Legacy Code na Sweet Unicorn Fu.... FW

daro0 wszystko fajnie, ale dobrze zbudowany fw nie robi bc co wersję, tylko dlatego, że można. A kiedyś LTS dla starych jego wersji się skończy

I co w związku z tym?

@daro0:
Osobiście byłem i jestem wielkim fanem Kohany. Wg mnie ten framework bije pod kilkoma względami wszystkie z jakimi pracowałem (właśnie CFS, walidacja danych, Query Builder itd.), a do tego jest prosty, szybki i posiada wygodny profiler. Żałuję, że projekt padł. Jeszcze ktoś tam próbuje go wskrzeszać, ale na długą metę nic z tego nie będzie.

Z tego co kiedyś czytałem Kohana nigdy nie miał być mainstreamowy a poza tym nie jest dla wszystkich. Ale z perspektywy samodzielnego freelancera, w przypadku realizacji niezbyt dużych (bo nie sądzę żeby ktokolwiek samodzielnie porywał się na coś większego) projektów typu forum społecznościowe, jakiś serwis ogłoszeń, sklep internetowy czy wiele innych aplikacji dość dobry wybór, tu chodzi mi o szybkość z jaką się pisze takie aplikacje. Może nie Query Builder w czystej postaci ale ORM który zresztą się opiera o Active Record wiele tu pomaga, tutaj chodzi mi o łatwość z jaką się tego używa.

Jednak można mieć wrażenie, że dla wielu to najważniejsze żeby było duże wsparcie społeczności (no niestety Kohana tego raczej nie ma), dobra dokumentacja (i też niestety w Kohanie dość uboga, zasadniczo opiera się na dobrze okomentowanych źródłach) no i cała masa wolnego oprogramowania które można zainstalować opierając się o zarządzanie zależnościami przy użyciu Composera. Natomiast zastanawiam się tutaj co w przypadku gdy taki Symfony czy Zend czegoś nie implementuje a nie ma tego w repozytoriach Githuba i trzeba to własnoręcznie napisać? No bo niestety, żeby coś takiego zrobić to FW trzeba dobrze znać.

Prawdopodobieństwo że nie implementuje tego inny, mniej popularny framework będzie wtedy większe. Jeśli na prawdę tego nie ma, to trzeba dopisać, być może zajrzeć głębiej w bebechy frameworka, ale i tak będzie się to opłacać. No bo gdy już go opanujesz i będziesz znał jak to wszystko działa to przy kolejnym takim problemie poradzisz sobie lepiej/szybciej. No i być może zostaniesz ekspertem. A jeśli to czego Ci brakuje jest potrzebne także innym to pisząc to w sposób modularny być może uda Ci się to komuś opchnąć lub przynajmniej udostępnić za darmo i wypromować. I tu znowu okaże się że w przypadku frameworka o większej popularności będziesz miał na to więcej klientów lub użytkowników korzystających za darmo, być może nawet pomogą Ci poprawić Twój moduł...

Ile frameworków już załatałeś? o problemie z bezpieczeństwem dowiesz się jak ktoś narobi "gnoju", wtedy będzie już za późno.



I to jest to, pełne poparcie. Za moment wyjdzie Symfony 3, Symfony 4 i oprogramowanie bedzie przestarzałe i co wtedy? od nowa pisać wszystko? Taki pomysł moga miec tylko opłacani przez grube portfele programiści, którzy siedza i sobie dłubią i nie wykonują programu, który jest kluczowy dla zysków firmy, chyba, że jest to potężna korporacja, dla której są to marginalne koszty, ale tam już są inne realia.





Przecieram oczy na myśl o tym punkcie Za dwa lata wszystko wywalac i zaczynać od nowa od zera hehe dobre. Wg mnie to bardzo złe podejście, znam firme, która jest liderem w pewnej "części branży" i tam po prostu ulepsza się udoskonala oprogramowanie, napisane obiektowo, wg ustalonego standardu, ale nie oparte w 100% na Frameworku.



Przetestowanych i ogólnie dostępnych, czyli każdy zna każdą kropke i może to wykorzystać w zły sposób.

Co do modułułów. Moduły są, ale często są to niepotrzebnie rozbudowane moduły z masą funkcji, które nigdy nie bedziemy używac

Pozdrawiam.

Ile to ja już przeżyłem Ciekawych standardów ( MustHave ), frameworków itp od php 3 wlącznie Już nie wspomne o XHTML który miał zawojować świat. Prawie wszystkie już są dziadkami, wyśmiewanymi przez młodych programistów:) Tak więc radzę zastanowic się chwike, zanim zakochacie się w pewnym standardzie, Frameworku. Plain Objects, Clean Architecture jak to kolega pisał wcześniej.

Ta jasne. Znam te plain object. Klika value objectów z interfejsami repozytoriów znajdującymi się w przestrzeni nazw o magicznej nazwie domain.
Żeby byla mowa o logice biznesowej, to projekt sam w sobie musi wynikać z biznesu, a tego w PHP-ie, który w większości służy do obsługi formularzy uświadczysz bardzo rzadko.