Сергей Протько

Стоит задача превратить это всё в ООП

давайте не так, не в ООП а просто в читабельный и поддерживаемый код.

- избавьтесь от дублирования кода. Вынесите для начала все действия в отдельные функции. Например:

$("#addComment").css("display", "block");

и подобные можно заменить как

// функции хэлперы для устранения дублирования
function hide(selector) {
   return function () {
        $(selector).css("display", "none");
   };
}
function show(selector) {
   return function () {
        $(selector).css("display", "block");
   };
}

// специализированные хэлперы с говорящими названиями
var showCommentsForm = show("#form");
var hideCommentsForm = hide("#form");
var showAddCommentButton = show("#addComent");
var hideAddCommentButton = hide("addComment");

идем дальше...

var counter = parseInt($("#counter span").html())+1;
          $("#counter span").html(counter);

Тут явно стоит использовать data-*. Или любой другой способ подсчета. Знать бы еще что считается, судя по всему вам надо посчитать количество сообщений. В этом случае вообще так себе идея так делать.

$(document).on("click", "input[name='send']", function (){

лучше случать сабмит формы. Обязательно устраните "глобальный поиск" по селекторам.

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

что должен знать идеальный джуниор (мое личное мнение):

- Сетевой стэк. Нужно иметь хотя бы базовое представление о том как с сервером общаются. Ну то есть не нужно лезть в дебри, но понимать что такое HTTP или чем TCP от UDP отличается - нужно. В целом это пара часов чтения википедии.
- GIT или любая другая распределенная VCS. Базовые навыки, что бы хотя бы понимал что есть git revert или git rebase, что такое фичабрэнчи и примерное представление как это работает и зачем надо.
- Базовые основы unix. Ну то есть что бы не пугаться таких вещей как ssh хотя бы.
- PHP. Без этого никуда. Он должен понимать что такое слабая динамическая типизация (не заучивать табличку кастов типов, а понимать плюсы и минусы, такая же история с приоритетами операторов - не заучивать а знать как избегать проблем с чтением кода)
- Понимать что код чаще читают чем пишут, а потому не экономить 5 минут на написании кода, а писать так, чтобы сэкономить 30 минут человеку, разбирающемуся в куске кода.
- Знать базовые вещи в плане безопасности. XSS и как защищаться, SQL инъекции и как защищаться, CSRF, MITM. Понимать что такое NDA, что данные пользователей - секретная информация. Как хэшировать пароли (не md5 а password_hash) и почему это важно.
- Знать SQL. Глубоких знаний не требуется, нужно лишь понимание того, что такое нормальная форма, желательно разобраться с вопросом денормализации данных. Идеально иметь хотя бы базовые представления о том как работать с NoSQL решениями.
- Процедурное программирование: почему глобальные переменные порождают сложность, что такое состояние, как можно использовать классы для изоляции состояния и т.д. Инкапсуляция. Инварианты, пост/пред условия, сохранение целостности...
- Разделение ответственности. Это один из важнейших принципов, и упрощать все это до "mvc фреймворк" слегка неправильно. Вы должны понимать что от чего отделяете и главное зачем.
- Автоматические тесты. Джуниор должен знать что это такое и иметь хотя бы минимальный опыт их написания. Должен понимать разницу между юнит и интеграционными тестами. Быть знакомым с пирамидой тестирования.
- Уметь решать стандартные задачи не задавая слишком много вопросов. Например регистрацию пользователя по email-у вы должны написать, или авторизацию через соц сети, или комментарии, или новостную ленту.
- Уметь дебажить. xdebug, blackfire и тд.

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

p.s. Я в списке специально не указывал ООП, поскольку всеравно первые пару лет у разработчиков выходит процедурщина на классах. Это не плохо, но того что в моем списке более чем должно хватать для решения стандартных задач. Но термины вроде "инкапсуляция/полиморфизм/наследование" требуются в обязательном порядке подавляющем количеством интервьюверов, а стало быть знать это надо. Единственное что - рекомендую в свободное время глубже погрузиться в этот вопрос а не тупо заучивать формулировки.

Так же вещи вроде docker джуниорам знать не обязательно просто потому, что их врядли допустят сходу к управлению инфраструктурой. А так пару неделек на изучение и вперед.

1. "factory" это способ порождения сервиса. То есть хранить данные вы будете в сервисе. Ну и такой момент - вы там не храните данные а храните логику получения этих данных.
2. почитайте про анонимные функции, не надо указывать имена для колбэков
3. почитайте про промисы, это решит вашу проблему. Так же почитайте про event loop в javascript, про то как работать с асинхронными операциями и т.д.
4. Очень удобно такие вещи выносить в резолверы, оставляя контроллеры максимально тупыми
5. компоненты. Подход с регистрацией "независимых контроллеров" считается устаревшим.

Последние два пункта обязательны к изучению но не прямо сейчас. Это если вы захотите научиться делать "удобно".

json rpc - это когда все запросы post.

rest же, это стиль архитектуры. Он не про урлы и не про http. Просто на http он ложится очень неплохо.

Ну то есть вы можете сделать все придерживаясь принципов REST. Главное не путать http и rest и не ограничивать себя мыслью что ресурсы это отображение табличек в базе.

При этом нужно учитывать что методов или урлов будет несколько сотен.

А какая разница? У вас так и так будет какой-то роутер.

Реально ли вообще с нуля самому не смотря не документацию или чужой код создать Движок?

Нет. Хватит лениться.

1. Кнопка пожаловаться, которая отправляет комментарий на модерацию. Сортировать список можно по количеству жалоб. Делается очень легко и быстро. Работает надежно.
2. При наличии матных слов (тупая проверка по словарю) можно блочить отправку комментария. В этом случае стоит сделать словарь либеральнее оставляя только очевидные варианты. Далее будет работать кнопка "пожаловаться". Проверять на ссылки бесполезно - часто дают полезные.
3. Greg Young - Stop over engineering - рекомендую к просмотру и осмыслению.
4. Воспользоваться существующей системой комментариев.
5. Можно защититься от тупых краулеров сделав отправку комментариев через JS и добавив опциональное скрытое поле. Тупые боты их заполнят. Такие запросы можно отбрасывать. Защищает от доброй половины спама.

Т.е. сложно понимаю, что "засунуть" в один объект, что в другой, что должно быть статическим методом, что приватным и тд.

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

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

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

И главное, у каждого объекта есть своя область ответственности. UNIX way. Каждый объект делает что-то одно и делает это хорошо. Бывает так что ну... нужно сделать так что бы один объект делал две вещи. НЕ вопрос, мы можем его попросить сделать что-то сложное, а он будет как хороший менеджер тупо делегировать работу другим объектом. То есть он и сложную штуку сделает, и сам не будет знать как она делается.

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

Вообщем писав всё время на процедурке, сложно перейти на ооп.

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

Вы можете начать погружаться в ООП с того, что разобраться "почему глобальные переменные это плохо", почему "состояние порождает сложность" и что такое эта "сложность" (многие почему-то думают что сложность выражается в написании кода а не в его чтении или поддержке), почему "изоляция" (и как следствие инкапсуляция) - это хорошо. Как это все соотносится с декомпозицией. Что такое "ответственность", что такое зависимости, связанности

Подскажите, какой проект начать писать (гостевая, блог), или может начать изучать фреймворк.

Фреймворки универсальны, а значит чистого ООП там быть не может. Во всяком случае нет ни одного фреймворка на котором стоит учиться ООП.

Есть хорошие упражнения на развитие понимания объектно-ориентированного проектирования. Например вот: https://habrahabr.ru/post/206802/

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

Или может подскажите книгу/сайт где пошагово в ооп написан какой-то проект, чтобы быстрее пришло понимание.

Так вы научитесь делать один конкретный проект а на втором вы уже проиграете. Так дела не делаются. Надо разобраться с причинами появления идеи ООП. Ну то есть что было до. Можно еще с функциональным программированием попробовать разобраться. В PHP оно слабо применимо, но основные идеи очень тесно переплетаются с ООП и познав немного функциональщины ваше ООП будет лучше. Да и если про ООП вы можете найти много булшита, про функциональщину врут мало.

но так и не понял, в чем его прелесть.

Не делать все руками. Описать граф зависимостей а он уже как-то сам соберется. То есть собирать граф зависимостей руками оно может даже правильнее, но с точки зрения читабельности кода, поддерживаемости кода (особенно учитывая миллионы зависимостей во фреймворках), да и просто увеличения скорости разработки, лучше использовать какой-нибудь контейнер в main и там запросить вершину графа зависимостей. А он уж разберется.

По сути главное что бы ваш код о контейнере ничего не знал. ЧТо бы вы в один долгий зимний вечер могли влегкую заменить все на "ручную" сборку и сам код трогать не пришлось... Ну аннотации/атрибуты это уже компромис для удобства.

но статья меня пугает, так нужно ли учить ООП или функциональное программирование: Welcome?

ООП учить не нужно. Большинство вроде как и учат но выходит плохо. ООП надо понимать. Причем это скорее именно проектирование нежели программирование.

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

А так... скажем так, использовать классы вам придется. В PHP другого способа изолировать состояние нет. Просто не надо думать что ООП про наследование (о чем большая часть статьи), оно про изоляцию состояния, взаимодействие объектов/модулей посредствам "общения" (tell don't ask, закон деметры), про позднее связывание (возможность подменить реализацию)... А не как не про классы. Классы лишь способ. Инкапсуляция, полиморфизм, наследование - все это было до ооп. Разве что наследование в Simula67 сделали в более удобном виде. Но все же считать этот язык объектно ориентированным не стоит. На его основе потом Страуступ плюсы сделал, и так же не думал делать объектно-ориентированный язык. Он хотел структурировать процедурный Си, задать так сказать культуру разработки. Менять парадигму он не собирался.

В основном проблема нынче в том что под ООП люди понимают только классы, паттерны и все. А зачем его придумывали и чем оно отличается (если отличается) от старого доброго процедурного - это уже не вкурсе.