Warlodya

HTTP: REST, SOAP,...
P2P
WebSockets,
...
Обычное сетевое взаимодействие
7 уровней модели OSI тебе знакомы?

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

Хотя ответ очень простой и первый вопрос автора даёт очень простую подсказку.

Вся суть эмвэцэ в том, что это всего лишь интерфейс. Штепсель. Розетка, через которую твое приложение подключается к веб. Веб-интерфейс твоего приложения.

То есть к самому приложению, если подумать, отношения не имеет.

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

При этом модель - это не убогий интерфейс к таблице в бд, как думают все попугаи. А собственно все приложение и есть. Это ещё называется бизнес-логикой.

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

Ответ с картинками и видео с ютюбе https://qna.habr.com/answer?answer_id=1475989#answ...

как писать поддерживаемый код?

Если уж очень коротко, то соблюдать SOLID/GRASP. Мне понравился твит одного из авторов React Router:
https://twitter.com/mjackson/status/1171524189850701825

Most common mistake software developers make: putting stuff in the wrong place. Coupling responsibilities and concepts that should be kept separate.
For me, this is 95% of software development. Just figuring out *where* things belong.

Что гуглить, что учить?

Фундаментальные знания, вроде вышеупомянутых SOLID/GRASP, паттерны (не только классические паттерны, но и вообще, общеизвестные решения определённых задач), базовые структуры данных. Фреймворки/библиотеки всегда будут приходить/уходить, что-то будет забываться. А фундаментальные знания всегда актуальны.

Может литературу какую почитать посоветуете?

Скажу за себя. Ни одной из этих известных книжек за свою жизнь не прочитал. Писал много говнокода дома, очень много. Удалял, переписывал. Смотрел код других людей, анализировал, пытался перенять то, что считал правильным.

Можно ли себя называть миддлом, если твой код говно?

Не пытайтесь себя оценить. В каждой компании свои понятия миддла. А если кто-то 35 лет на лиспе кодил, а потом прыгнет на Angular - кто он, джун или сеньор?
И, да, все мы в какой-то степени пишем говнокод. Если кто-то Вам доказывает, что он пишет супер чистый код - не слушайте.

И ответ на главный вопрос.

Как перестать говнокодить и принимать неверные архитектурные решения?

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

Толку точно не будет, если вместо учёбы составлять планы. А по поводу курсов и видео-уроков, стоит поискать по Тостеру, здесь про этот шлак часто писалось. В частности раз и два.

Немного теории. Человек за миллионы лет эволюции приучен пользоваться отраженным светом. С другой стороны все современные девайсы отображения информации являются прямыми излучателями, т.е. грубо говоря любой экран это "лампочка". Само собой сидеть и пялится на лампочку не есть хорошо. При этом не важно какой абажур на нее натянут хоть TFT, хоть IPS или еще какая хрень.
Другое дело eInk. По сути это навороченный лист бумаги, само собой чтение электронной книги так же вредно как и обычной (почти ни как). С другой стороны приобретая электронную книгу вы должны понимать, что это всего лишь книга (ну может еще и блокнот для заметок), ни какого интернета и игр. Так же нужно учитывать что почти вся техническая литература имеет большой формат и читать на 6-7" читалке будет проблематично, а большие (10"+) стоят очень дорого, про цветные я вообще молчу.

В итоге если вам нужна именно книга (только читать) и у вас достаточно денег то ищите 10" книгу может даже цветную, если ваш бюджет строго ограничен то берите планшет 10" на Super AMOLED или хотя бы IPS

int *mas = new int(size); // массив с числами

Нет.

Никакие.
Порядок самообучения для любого языка:
1. Учим базу по официальной документации.
2. Практикуемся (LOOP: 5-10)
3. Учим следующий более сложный раздел
4. Смотрим исходный код лидирующих и актуальных проектов для понимания правильной организации кода (код микрофреймворка для разработки или код простого приложения).
5. Пробуем сделать похожую структуру кода сами.
6. GOTO 2

1. Сначала придумывается идея. С прицелом на коммерческий успех, конечно же, то есть в идеале она должна сразу содержать USP. Автор идеи, как правило, становится главным идеологом игры и в будущем контролирует её воплощение, хотя может и какую-то посредственную роль занять в будущем.

2. Пишется вижн игры. На этом этапе нужно определиться с платформой (или платформами), жанром, сеттингом, моделью монетизации и распространения, перечислить основные механики геймплея или даже составить небольшой список основных фич, графический стиль, ЛОР (в общих чертах), ссылки на похожие игры и произведения (которые вдохновили). Ну и конечно же USP - помимо основных фич нужно 1-3 киллер-фичи, которые и сделают игру успешной по вашему мнению. Это всё нужно, чтобы показывать другим людям и у них было понимание идеи игры, а не каша в голове.

3. Делается прототип игры. Можно даже не игры, а ключевой фичи. Два варианта, зачем это нужно: а) для себя, чтобы понять, что идея никуда не годится и надо её менять или улучшать б) чтобы показать инвестору, дать пощупать и понять, чего вы хотите (читать текст никто не любит, а кнопки потыкать всегда приятно и более понятно). Это минимум программирования, или вообще его отсутствие (прототип из бумаги дешево и сердито).

Максимальная команда на стадии прототипа состоит из 4 человек - автор идеи, программист, геймдизайнер, дизайнер (по крайней мере, в ubisoft опытным путем пришли именно к такому составу). Но в целом один человек может справиться.

4. Формируется, так называемый, feature list, это уже конкретные задачи, каждая из которых (если вы планируете делать по скраму) занимает не больше 5 дней, иначе делится на более мелкие задачи.

3 и 4 можно поменять местами, или делать параллельно, если вы хотите денег от инвестора. Хотя в целом это отдельная история, т.к. инвестору больше подойдет бизнес-план, составление которого выходит за рамки вопроса.

Дальше, собственно, возможно начало разработки, если есть деньги, команда, ну или если все согласны на дошираке энтузиазме работать. Одному браться за реализацию крайне не советую, хотя это и не запрещено. И с чего вы взяли, что разработка сводится к программированию? Есть же еще дизайн, геймдизайн, звук, левел-дизайн, ui, ux, ближе к альфе нужен маркетинг и т.д. В некоторых играх программирования практически нет. И всем этим зоопарком ещё и управлять нужно, не забывая про необходимую бюрократию и юридические дела (и не факт, что одного человека хватит на управление). Так что в теории там ещё огого сколько всего помимо программирования. Надеюсь, я вас немного отрезвил.

Все плохо

• Глобальные переменные — зло
  
• На лицо некий код, который и с сессией работает и с БД — явное нарушение общепринятных принципов, например SRP
  
• $dao как инициализирована? Явно не через конструктор
  
• Использование цифры, вот сиди гадай по ней — это плохо, используйте именованную константу. Например 3 — это некий статус для desktop, вот и назовите ее STATUS_DESKTOP, хотя далее...
  
• вы обращаетесь к одному методу, который шибко умный — работает с флагами, тем самым нарушая SRP и сам содержит if/else, сделайте просто 2 раздельных метода:
  

  getMobileOpinionList()
  getDefaultOpinionList()

  
  
• Предикат лучше вынести в отдельный метод isMobileOnly(), тк условия могут поменяться в нем, не будете же везде в if менять по всему проекту
  

Я такой человек который предпочитает полагаться на свои знания, да и вообще на самого себя (Ну, то есть могу взять и изобрести велосипед, как говорится)

Синдром неприятия чужого кода. Пройдёт )

Ведь невозможно абсолютно всё держать в голове и при необходимости запрограммировать что угодно или я что-то не так понимаю?

Есть базовые вещи и понимание как что-то делать или как что-то сделано, а есть кучи либ и инструментов выполняющих +/- те же задачи документацию по которым можно загуглить за пару минут и прочитать за пару часов. Запоминать нужно первое.

В гуглении нет никаких проблем и ничего предосудительного ни для кого. Совсем.
Тем более при изучении инструментов/фреймворков и т.п.

Для базовых вещей(паттерны, дизайн и т.п.), конечно, стоит начать с книг.

Забавно. Все опять помешались на + - и не могут придумать норм идей.
1. вливание темы в уже существующую. чтоб не плодить одно и то же
2. денежное поощрение за хорошие ответы (с рекламы доллар жалко да???) от администрации
3. записная книга хороших ответов
4. кнопка "на вопрос нет ответа".
5. денежное поощрение от вопрошающего (помогает при написании конфигов и скриптов)
6. кнопка "вставить ответ из книги быстрых ответов"
7. нормальные ачивы с нормальными рейгингами и чтоб это можно было вставить на другой сайт (и не стыдно!)
8. мобильные клиенты для всех платформ!
9. оперативное внедрение нововведений
10. переключение на отображение вопросов в полоску (один вопрос одна строка!). а то не торкает проматывать это буйство
11. возможность вносить примечание в конфиги и скрипты с указанием как оптимально
12. наконец сделать страницу с правилами и наказаниями!!!!!!!!!!!!!!!!!!!!!!!!
13. появление ответов в теме без обновления страницы
14. кнопка "позвать платного специалиста"
15. добавить встроенный графический редактор сети (а то иногда такие фантазеры люди!!!!) с возможностью скопировать эту сеть и изменить ее в ответе

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