Алексей Ю.
35 лет, Россия
49 сообщений
#4 месяца назад
В общем такой вопрос. Существует ли движок, на котором можно сделать сервис? Или же придется писать все на фреймворках.

С одной стороны много стандартного функционала:

1. Авторизация через соц. сети.
2. Личный кабинет.
3. Подключение платежных систем.
4. Обработка заказов.
5. Безопасность, капчи, 2f авторизация.
6. E-mail уведомления.

И еще много стандартных фич, без которых уважающий себя сервис сегодня не будет работать.

С другой стороны много кастомного функционала, на котором сервис специализируется.
Ну например:
1. Трекинг домашних животных по подписке.
2. Регистрация питомца в системе.
3. Хранение истории передвижений.
И т.д. и т.п.

Как это совмещают гуру-фрилансеры, когда делают проект?
Или же для таких вещей только хардкор, только самописные системы.
Артем Л.
32 года, Россия
10975 сообщений
#4 месяца назад
Пишем уже третий сервис и все с нуля, без фреймворков и прочего. Долго да, но зато все летает и масштабируемо.
А вообще на любом фреймворке можно делать, говорят сейчас Yii вроде неплох.
Александр К.
33 года, Россия
159 сообщений
#4 месяца назад
Hungry_Hunter, +++ разработка под конкретный проект с нуля
Алексей Ю.
35 лет, Россия
49 сообщений
#4 месяца назад
Разработка с нуля - самый долгий, дорогой и рискованный. Разработчику конечно в этом плане хорошо - долгосрочный проект, длинный бюджет, опыт, построение своей архитектуры, наработки, и т.д. Заказчику - риск остаться один на один с самописным монстром. Придет новый разработчик и вынесет вердикт "переписать нафиг". Фреймворки и готовые движки дают в этом плане некоторую безопасность.
Елена Б.
34 года, Украина
6650 сообщений
#4 месяца назад
Канадский сайт по продаже мультимедиа-контента с международной аудиторией и продажей собственных гаджетов медленно переводим с родного движка, разработанного компанией в прошлом, на Laravel.
В индивидуальной работе я бы его не выбирала. Есть парочка любимых, легко расширяемых напильником,  движков, которые использую как заготовки для типовых сайтов. В остальных случаях pure PHP.   Symphony Components если есть тому необходимость, но это вообще редкость. 
Владимир Ребров
33 года, Россия
2777 сообщений
#4 месяца назад
Цитата (jack31):
Заказчику - риск остаться один на один с самописным монстром. Придет новый разработчик и вынесет вердикт "переписать нафиг".
Золотые слова.  Разработчику для себя - не вопрос, хоть на Perl. В остальных случаях самым разумным решением будет использование популярного фреймворка. Сейчас это Laravel или Yii. Первый вроде перспективнее и очень быстро развивается. 
Давид Г.
27 лет, Украина
375 сообщений
#4 месяца назад
Hungry_Hunter, Вопрос поддержки. Компания VK в своем арсенале имеют kPHP, под тип от HHVM. Свои классы свои структуры - упрощенный и оптимизированный PHP. Но кто может с ним работать? Тот кто уже есть в компании - и тот кого привлекут и обучат за свои средства.  
Немного времени спустя появляется вакансия - "Платим овер дофига - но код черти что" грубо если. Вижу такую вакансию называю ценник за полгода и переписываю к чертовой матери на Laravel или Symfony. Код должен оставаться такой - что бы новый человек который приходит в компанию - залез и не задавал лишних вопросов - "Кто здесь? Что он делал? Чего пытался добиться?" что бы он понимал что к чему - для этого стандарты - а писанина с нуля - это шлак мозгов выплюнутый 1 разработчиком или еще хуже - целым коллективом) Благо если оно приносит доход. В противном случае начинать с этого - Моветон.

Простите за резкость.
Ольга Гр
37 лет, Россия
1 сообщение
#4 месяца назад
jack31, а SAAS хотите из-за цены преимущественно или есть какая-то особая принципиальность кроме проблемы смены разработчика?
Алексей Ю.
35 лет, Россия
49 сообщений
#4 месяца назад
Lillat, мне нужно разработать SAAS/сервис.
Использовать сторонние SAAS платформы я не планирую.
Цитата:
есть какая-то особая принципиальность кроме проблемы смены разработчика?
Здесь все просто. Я планирую долгосрочный проект, но не знаю насколько он будет прибыльным.
Допустим есть бюджет на 3-6 месяцев. После этого разработка может быть приостановлена, если проект не показывает необходимой динамики.
И если активная разработка будет приостановлена, например на 2-3 месяца, а проект самописный, то высока вероятность того, что разработчик, который делал этот проект, будет занят в другом, и на его замену придется срочно искать того, кто в коде не бум бум и увеличивать траты, потому что никто не любит копаться в чужом творении. Так что смена разработчика - это один из ключевых рисков, а не просто проблема. Поэтому чем меньше кастомного кода и чем больше стандартных проверенных библиотек и подходов, тем лучше для выживаемости проекта.
Что касается производительности, дополнительный сервер сегодня стоит на порядок дешевле, чем время разработчика.
Дмитрий Ч.
32 года, Россия
2697 сообщений
#4 месяца назад
А разве библиотеки из сборок, основную часть которых слепленный проект использовать не будет, не будут занимать лишнее время при загрузке проекта (открытии страниц и тд.. - на серверной части, и в особенности на клиентской части всякие js библиотеки и прочие которые вообще по-моему не возможно "почистить" под себя... всегда остается куча мусора)? 
Сервис со своим кодом, конечно, тоже без сторонних библиотек не обходится, но... их ведь можно свести до минимума. И главное, что вряд ли какой разработчик станет использовать большую библиотеку, если из нее потребуется всего пару методов (напишет/перепишет сам). А в сборках, как мне кажется, очень сложно почистить лишние библиотеки, когда в каждой есть хотя бы с десяток нужных тебе методов... нет? - или плюсы сборки перекрывают такой недостаток?
Александр К.
33 года, Россия
159 сообщений
#4 месяца назад
AiosS, да да  Laravel или Symfony рептилойды писали со сверх разумом и не один и не в коллективе.

Простите ...
Артем Л.
32 года, Россия
10975 сообщений
#4 месяца назад
Если велика вероятность потери разработчика до выхода проекта на хорошую прибыль, то действительно стоит взять какое-то готовое популярное решение.
Сидоров Влад
34 года, Россия
652 сообщения
#4 месяца назад
По-моему, вопрос сводится к "использовать готовый известный фреймворк" или "использовать свой кастомный, называя это разработкой с нуля".
Лепить в очередной раз с нуля http роутер, обработчик сессий, загрузчик файлов итд итп, как-то нерационально чтоли.
Пишите

Цитата:
А разве библиотеки из сборок, основную часть которых слепленный проект использовать не будет, не будут занимать лишнее время при загрузке проекта (открытии страниц и тд.. - на серверной части, и в особенности на клиентской части всякие js библиотеки и прочие которые вообще по-моему не возможно "почистить" под себя... всегда остается куча мусора)? 
Сервис со своим кодом, конечно, тоже без сторонних библиотек не обходится, но... их ведь можно свести до минимума. И главное, что вряд ли какой разработчик станет использовать большую библиотеку, если из нее потребуется всего пару методов (напишет/перепишет сам). А в сборках, как мне кажется, очень сложно почистить лишние библиотеки, когда в каждой есть хотя бы с десяток нужных тебе методов... нет? - или плюсы сборки перекрывают такой недостаток?
Да всем побоку.. Мифические 10-20-100 ms, обходятся гораздо "дешевле" написания велосипедов с нуля.
Особенно когда основное преимущество цели этого велосипеда - это скорость выхода на рынок.
Заморачиваться на масштабируемость не имея порядочных финансов, команды и планов дальше чем на полгода вообще не стоит.
Дмитрий Ч.
32 года, Россия
2697 сообщений
#4 месяца назад
inter-job, ну если речь о 100мс то да, конечно пофиг. Но когда речь о +2-3 секундах загрузки из-за больших библиотек которые на 99% не используются... то как бы 

и дело даже не только в библиотеках, 
а к примеру 
- в куче всяких аяксовых обращений к тем данным, которые конкретно в данном проекте не используются
- в куче доп. классов, которые нужны под те задачи, которые не нужны под данную сборку, но будут обрабатываться и тратить время и ресурсы
- к примеру та же авторизация - нужна простая сразу в кабинет, а будет кружить и редиректить, подтягивать фоном кучу доп. запросов туда, куда конкетному решению не нужно, занимая лишнее время и ресурсы
и тд...
Александр Ф.
35 лет, Россия
2008 сообщений
#4 месяца назад
Когда денег кот наплакал, а хочется многого я задаю вопрос - Вы хотите решить проблему бизнеса и запустить продукт или хотите заняться креативом, при этом сразу примите как должное что занятия креативом не решают задач бизнеса. Под креативом подразумевается что создается дизайн под клиента, верстка и прочие фишки, а затем - денег нет, бюджет освоен, но вы держитесь... 

У многих происходит просветление, они готовы заняться творчеством с детьми бесплатно и говорят, да мы хотим коробочный продукт. Потому что если абстрагироваться на сотни км и посмотреть на проект со стороны, то - через полгода мало того что программист сменится, он даже в одном лице через полгода говнокода скажет, давай напишем на фрейме заново (исключение конечно же хороший программист, который сразу напишет так как надо и через год не обхаит свой же код).  Хочу заострить внимание, что в предыдущем предложении я вновь никого не оскорбляю, это реалии, с которыми приходилось сталкиваться при самописных шнягах. И даже сам, посмотрев на работу годичной давности не всегда могу быть ей доволен чисто эстетически. А уж через 3 года смотришь и думаешь, вот я же когда то такое делал.... (не в лучшую сторону конечно).

И - Вы сами как владелец бизнеса сделаете выводы какие разделы работают, какие нет, и что действительно нужно вашей аудитории. Если есть какие то наработки и имеются выводы, пишется т.з. и решается, какой командой что пишется. Должно быть не только проф уровень команды, но крайне желательно чтобы понимался бизнес клиента и решались потребности. И это не просто слова - потребности, задачи... Потому что - не попробуешь, не поймешь что нужно делать. Сказать же команде крутых разработчиков ребята, сделайте мне это - они то сделают. Но задачу то ставили вы... А верно ли она была поставлена, когда опыта ведения портала / проекта нет...

И вот - приходим  к пониманию, что нужен некий тест продукт, который отработает год или два и дальше будет понятно что точно надо. Тогда то и делают коробочные версии. И разные фишки, которые кажутся мега уникальными заменяются на какие то типовые вещи. Зато набирается статистика, даже самой банальной Яндекс Метрики, сделав выводы по которой можно правильно ставить новые задачи. Следить за тенденциями своей аудитории. К примеру профиль бизнеса клиента окна, год назад мобильные устройства 6% посетителей, затем 15 и вот в этом году 30. Ясно что надо было делать адаптивный вариант год назад. Тогда сомневались, но делали, а сейчас сделали вывод что правильно поступили.

Вот тогда, с  набранной статистикой - можно смело тратить уже заработанные деньги с тест продукта. Или не тратить их вообще на какие то задачи.

P.S. 3 года работали с клиентом на регулярных платежах, сначала просто перед фактом имели созданный другим исполнителем проект. Затем решили написать мультидоменную шнягу. Она даже заработала, но кривовато. Фрилансер сам сбежал, не захотев исправлять косяки и матеря модх, не понравился он ему. Сейчас же пришли к отдельным узкотематическим сайтам в рамках одного бизнеса. И пока что это более завершенная цепочка событий и пониманий что во сколько обходится и что имеем. Стыдно, да. Возможно ли было сделать сразу хорошо - нет. Это зависит, как выше написал и от хозяина, который ставит задачу и от менеджеров, которые поставляют материал. Клиент может знать своих клиентов, но ответить четко о поведении своей аудитории в сети, в поиске и в пределах сайта не сможет. Тогда то и нужна статистика чужая, общедоступная и наработанная...
Дмитрий Ч.
32 года, Россия
2697 сообщений
#4 месяца назад
П.с
на мой взгяд...
самый большой минус самописных систем это конечно то, что не напишешь столько интерфейсов под всю ту чепуху, которая уже создана в сборках.
к примеру у меня, бОльшая часть админского/обслуживающего интерфейса понятна только разработчикам либо вообще пишется каждый раз с нуля под конкретные задачи (к примеру когда речь о новых аналитиках, отслеживании ошибок и тд)... и делать это красиво для обычных пользователей очень затратно, но с другой стороны все что нужно под узкие запросы бизнеса никакая сборка никогда не предусмотрит и все равно придется дописывать.
смена программиста после завершения проекта - это не проблема, как мне кажется, т.к. устаревание любых систем сегодня очень быстрое (2-3 года и нужно все менять). И если набралось большое количество изменений и есть ресурсы для их внедрения то лучший вариант писать с нуля под новые требования времени.
но с др. стороны у меня очень небольшой опыт разработок что бы спорить, поэтому скорее интересно услышать возражения в рамках темы (изв. что влез)
Владимир Ребров
33 года, Россия
2777 сообщений
#4 месяца назад
Цитата (UniText):
всю ту чепуху, которая уже создана в сборках
Цитата (UniText):
все что нужно под узкие запросы бизнеса никакая сборка никогда не предусмотрит
Вы вероятно имеете в виду CMS? Потому что фреймворк, о коих собственно и речь выше, это не сборка.

Цитата (UniText):
загрузки из-за больших библиотек которые на 99% не используются
Ну точно CMS. Причем жумла, видимо 
Дмитрий Ч.
32 года, Россия
2697 сообщений
#4 месяца назад
vovka-morkovka, с фреймворками для PHP типа Yii действительно не работал совсем, вскользь видел только несколько раз - вернее то что на нем ваяли и как мне представлялось из готовых сборок разных готовых библиотек и решений.

И представление о том что такое фреймворки имею пока небольшое, возможно ошибочное и потому негативное.

Но с тем, с чем приходилось сталкиваться это с готовыми решениями проектов под ASP - MVC и стандартные с прямыми запросами. Как мне казалось это тоже некие фреймворки задающие структуру с наобором готовых библиотек.

Любые MVC решения, как мне пока показалось, это вообще жутко тормознутые штуки с кучей бесполезных классов контроллеров, жутко затратных для сервера и времени клиента.

Вот их выше и описывал собственно... ИМХО, на моем маленьком опыте пришло большое отторжение таких заготовок, которые для сложных решений оказываются сильно тормознутыми.

Один из миллиона примеров: у винды, есть Linq - для работы с большими данными оно очень тормознутое, особенно при обращении к БД (как мне кажется у YII есть такие же готовые решения для работы с БД и буферными данными). 

И такое, опять же на моем маленьком опыте, наблюдалось с большинством готовых решений из библиотек которыми приходилось пользоваться (даже самыми базовыми вроде работы с популярными форматами файлов и тд). Свое, хоть и менее изящное работает значительно быстрее, т.к. создается под конкретную задачу и не описывает кучу классов которые тебе в данный момент не нужны. 

И опять же уже не говоря о тех библиотеках клиентских скриптов что создаются ими по умолчанию (где основная часть скриптов для любого случая жизни). Yii ведь тоже создает какие-то базовые наборы клиентских скриптов при создании проекта или я все мимо?)

п.с.
а про кучу редиректов при авторизации, подтягивании необоснованного объема фоновых загрузок это возможно действительно было про CMS - это уже на опыте работы с большим количеством сайтов для написания к ним ботов (легальных если что...))... просто иногда порожает сколько фигни тянут сайты при изучении их тем же фидлером и у большинства большинство схемы фоновых запросов стандартные, явно ведь с каких-то готовых решений (но на известные цмс не похожи, потому и думал что фреймворки). вот)
Сидоров Влад
34 года, Россия
652 сообщения
#4 месяца назад
Цитата:
Любые MVC решения, как мне пока показалось, это вообще жутко тормознутые штуки с кучей бесполезных классов контроллеров, жутко затратных для сервера и времени клиента.
Ну даже если это вам и не показалось, вычислительные мощности сейчас дешевле оплаты рабочего времени.

В своем стремлении к "простоте" главное понимать, где остановиться.
Эдак и до C можно дойти и руками сокеты смотреть.. Ведь эти ваши вебсервера и php  не используются в вашем "сервисе" даже на 5%.
Цитата:
смена программиста после завершения проекта - это не проблема, как мне кажется, т.к. устаревание любых систем сегодня очень быстрое (2-3 года и нужно все менять). И если набралось большое количество изменений и есть ресурсы для их внедрения то лучший вариант писать с нуля под новые  требования времени.
После завершения - вообще ничего не проблема. Но для переделки это ад и израиль.. Вспомните хоть кинопоиск. Ресурсов яндекса не хватило..
Владимир Ребров
33 года, Россия
2777 сообщений
#4 месяца назад
Цитата (UniText):
Любые MVC решения, как мне пока показалось, это вообще жутко тормознутые штуки с кучей бесполезных классов контроллеров, жутко затратных для сервера и времени клиента.
Это все равно, что сказать, любые транспортные средства на колесах - это "жутко тормознутые штуки".