Максим Федоров

По факту две стратегии поведения -

очень трудно найти нормальную документацию по платформе

писать документацию, скорее всего долго и бесплатно

Может сразу идти учится у первоисточника?

или присоединится к лидеру

И ваш выбор "куда пойти" вы уже скорее всего сделали

А вот чтоб

не хочу остаться у разбитого корыта

нужно изучить оба решения и их конкурентов, а не связать всю карьеру только с одним.
"Не ложить все яйца в одну корзину"

Ключевые слова:
- Обьектно-ориентированный анализ и дизайн
- UML
- Use case's
- Class Diagramm
Гайд на скорую руку тык

На эту тему есть конечно же много книг. В зависимости от состояния проета используются разные методы. Иначе же на этот вопрос нельзя конкретно ответить.

Очевидно, что Database() можно вынести в отдельную модель, типа ActiveRecord

объект для работы с СУБД никоим образом не относится к паттерну AR. AR не должна наследоваться от объекта СУБД.

и просто наследовать её

https://refactoring.guru/ru/replace-inheritance-wi...

Мне не комфортно, что приходится создавать объект в __construct, чтобы пользоваться им в классе.

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

Здравствуйте, решил все-таки научиться хоть немного программировать по-взрослому

прочти хотя бы 1/3 этой книги

Adminer

Вам самому не кажется что это дно? Используйте роутер какой-нибудь нормальный и не костыльте херню вида path to controller

https://cloudcannon.com/deconstructions/2014/11/15...

Смысл в том что рисуется такая заглушка, а потом ее заменяет контент при загрузке

А про https://bitbucket.org/ забыли?
Насоздавал себе проекты, поставил задачки, отметил важное не важное, документацию написал сам себе))

Я юзаю YouTrack - его можно поставить в рамках локальной сети бесплатно. Отличная штука, мне лично по функционалу (простоте), нравится в разы больше Jira.

Изучите промисы

function do() {
  return new Promise((res, rej) => {
      getUrl(() => {
          const a = 5;
          res(a);
      })
  })
}

do().then(res => console.log(res));

Вот как раз что именно для успешной соц. сети и смысла нет сразу.
Имеет смысл докупать мощности по мере роста сети.

Ибо разница очень и очень велика на начальном этапе и то что будет через год-два. Ну это если проект "взлетит" конечно. Это я в предположении, что инвесторов не интересует невзлетающие проекты. Значит, рассчитываем на то, что н взлетит.

Кроме того, если вы разработчики - то вам самим следует это знать.

Если вы способны создать крайне эффективный проект, то:

StackOverflow буквально несколько лет назад уже был известным и раскрученным на весь мир проектом. Наверное самым известным среди проектов подобного рода. И все миллионы пользователей, которые активно пишет на нем и активно читают - обслуживало всего навсего 2 сервера, под фронтенд и СУБД (не считая резервных/репликационных, само собой). Это были сервера на неплохом железе, но не дорогие. Поищите в сети, есть подробности.

Вдумайтесь, весь мир, миллионы посетителей, активные пользователи, нагружающие СУБД операции поиска и записи. И всего пара серверов.

В то же время мне доводилось видеть и прямо таки обратные примеры. Когда примерно такое же железо и пару тысяч посетителей в день не может вытянуть.... Ну говнокодеры делали, чего взять.

---------

Оцените масштаб и необходимая скорость реагирования на рост.

1. Если вы прям серьезно хотите, то вам в микросервисную архитектуру (Kubernetes вам в помощь) и в облака.
2. Однако я полагаю, что первые пару лет посетителей не будет много. Поэтому начать можно вполне себе с VDS просто переключая тариф на постарше и постарше. Это копейки. Единственно, что я сразу бы вынес картинки/видео в облака, это очень удобно и не заботишься ни о месте на диске не о конфигурировании ПО. Использовать для этого специализированные сервисы: Openstack Swift (много хостеров), Google Storage, AWS S3 и т.п. При вынесении подобной тяжелой вещи с сервера - движок будет совершенно не требовательным.

---------

Вам тут в соседнем посте правильно ответили:

Стоимость разработки и раскрутки этой хрени огромна на фоне стоимости серверов.
Сервера - копейки стоят.

Если инвестор начитает уже и тут докапываться, то, очевидно, что команда будет пахать за копейки.

А так то расходы на команду в неделю могут быть больше чем за все сервера за год.
В течение первых лет пяти раскрутки.

И только по мере стабилизации сети, меньших объемов работ, но большей масштабности серверов - стоимость серверов будет превышать стоимость услуг людей.

---------

Если бы я начал этот проект сам:
то заложил бы на первый год сумму 6000 рублей в месяц на два сервера (основной и репликацию, движок и БД на одной машине, картинки/видео на отдельном облачном сервисе). Причем это VDS, а не выделенный сервер.
На второй год 40 000 рублей в месяц (два кластера по 3 сервера в каждом).
Начиная с третьего года ушел бы в облака.
Там, полагаю, ценник был бы на уровне 30 000 - 60 000 рублей в месяц первое время.
С четвертого года рассчитывал бы на 90 000 - 180 000 расходов в месяц.
После этого начал бы подумывать, не уйти ли с облаков на свою инфраструктуру.

Но это про мою гипотетическую архитектуру.
Возможно у вас другая цель и другая архитектура.

---------------

Как считать:

Прикидываем количество пользователей.
Прикидываем объемы генерируемого ими контента (причем это и фото и видео и сообщения и технические логи тоже не забыть, их немало)
Умножаем на 3 (в серьезных системах нужно двойное реплицирование: оригинал и 2 копии)
И добавляем еще 1 копию под разработку и "ранний доступ к бете", сплит-тестирование и пр.
Дальше тут уже зависит от вашей архитектуры. Как я уже писал микросервисная архитектура хороша для взрывного роста, но довольно требовательна при небольшой нагрузе. Если вы прям не на 100% уверены в взрывном росте - лучше от нее отказаться, она и в разработке и в поддержке геморнее. Но зато масштабируется классно, это у нее не отнять.
Дальше, если это будет на весь мир - нужно подумать насчет пары-тройки кластеров разной географии.

-----------------

Если у вас нет информации об количестве пользователей и объемах генерируемого ими контента - говорить тут конкретику невозможно.

Слышал различные мнения по этому поводу, от "маркетинг важнее производства", до "50/50" и ниже.

Зависит от того - что именно вы производите:

Если вы производите простые зубные щетки - маркетинг не важен. Важна минимизация цены на производстве, дешевая логистика и тп.
Если вы решите производить "премиальные" зубные щетки, то вам нужно будет объяснить потенциальным покупателям как именно щетина ваших щеток позволит им выигрывать в лотерею, например.
Если же ваша щетка - это самолет, и ваше имя Боинг, то конкурентов у вас по всему миру - ну 2-3-4 фирмы. Маркетинг тут чисто условный.
Если же вы собрались представить миру новый супер проект, вложили миллиард (ну что то вроде первых iPhone) - разумеется вы не захотите рисковать весь вложенный миллиард просрать. И весь проект будет хорошо согласован с маркетингом.

То есть ситуации с важностью маркетинга в каждом конкретном случае есть разные - вплоть до противоположенных.

Понимаю что бывает по разному, много факторов, но предлагаю взять за реальный или выдуманный пример компанию веб-разработки до 10 человек.

С маркетингом все как раз просто.
Нужна ли кому-то ваша фирма сама по себе, обеспечена ли она заказами на 2 года вперед, или вам приходится, мягко говоря, навязываться?

По поводу менджмента не все так просто.

Но если фирма наприрает на схему - дешевые разработчики, много. Да, тут нужно хороших менеджеров-погонщиков иметь.

Приходилось работать на обеспечении Олимпиады в Сочи. Так вот там принята эта схема, западная (несмотря на то, что конечные спецы были высоковалифицированными админами, но масштабность проектов - обязывала) - число менеджеров всех уровней, думается, превышало число конечных специалистов раза в три. И это тоже отлично работает.

Если же вы полагаетесь на специалиста-разработчика. Если его квалификация высока, если он достаточно обязателен, а вы не боитесь получить от него полную зависимость (bus factor) - можно минимизировать менеджерскую составляющую. Что уменьшит и себестомость вашу. Но поднимет риски.

То есть и с менеджментом есть в корне различные варианты.

Предыдущий ответ мне показался вообще не по теме, поэтому отвечу тоже.

У вас немного не в ту степь вопрос. Вы пытаетесь спросить что-то типа: зачем за 100к мне пилить человеку сайт на yii если я могу отдать фрилансерам за 30к и 70к положить себе в карман?

Ответ простой: если вы предлагаете два варианта человеку: фреймворк или, условный, вордпресс и человек выбирает фреймворк, на это есть причина. Сайт на фреймворке скорее будет поддерживаться и развиваться либо вами же, либо без вашего участия.

Если речь идет о каком-то простеньком сайте на 5 страниц, то человек выберет вордпресс, потом зайдет в админку и поймет что это вордпресс.

Если человеку нужен серьезный проект, который будет допиливаться месяцами, поверьте, он знает как отличить ложку от топора, и знает почему он использует топор, а не ложку.

Обратите внимание на ответ Максим Федоров , который вам дали в комментариях, примерно об этом и идет речь. Дело не в том, сколько и за что вам заплатят, а в том, что человек знает какие задачи должен выполнять проект и делает выбор в пользу того или иного инструмента.