Jim

Подход процедурного программирования - во главе стоят функции и алгоритмы.

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

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

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

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

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

с HR и командой тоже профессионал будет разговаривать?

Два Мёрфи этому господину

Привет, тоже кину пять копеек.
Во первых задай себе вопрос, чего ты хочешь, и чего тебе надо. С этого надо начать.
Мы что-то делаем не просто так, а ради чего-то. Задай себе простые вопросы, кто ты, где ты находишься, в чем твои цели и предназначение. Программирование само по себе отстой, но с него можно начать. Когда то в 80 годы меня обуял восторг, когда я в классе третьем смог понять смысл a=a+1 Но с тех пор много воды утекло. Пойми чем ты хочешь на самом деле заниматься. Что является твоей настоящей целью, заработать денег, вырасти в социуме, поднять детей, прожить интересную жизнь. Как правило в жизни не выйдет получить всё, время это такой ресурс, который можно пустить либо туда, либо туда, либо еще куда. Делай всегда это с умом.

Когда поймешь что тебе нужно, составь список целей, цели это не что-то постоянное, но вполне себе динамичное и постоянно меняющееся, мы меняемся, мир меняется. Следуй своим целям. Запомни один хороший принцип - возьми сначала себе. Работа хорошо, ты лучше. Как и где взять дело твое. Способы есть разные. Я ниже напишу немного конкретики. Каждый день нужно осознавать свой список целей и учитывать его в текущем дне. Ставить себе задачи на день и назначать самую важную. Если ты не выполнил эту задачу, считай что день неудачен. Каждый день выдели 15 минут времени вечером и делай анализ дня. Это вместе с пониманием своих ценностей и целей самое важное.

Теперь немного конкретики.
Вариантом отщепить время себе масса.
1) Сними комнату рядом с работой.
2) Вставай раньше. Ложись раньше
3) Усталость, это усталость от схожего вида деятельности. Усталость можно легко побороть если заняться чем-то иным. Умственно / физически например переключается будь здоров.
4) Первый час на работе посвяти только обучению. Обычно люди первый час тратят на котиков, чатики и прочую п-нь, будь не как все.
5) Поговори с начальником, и скажи что тебе нужно развиваться и обучаться. Посмотри на реакцию. Если он не монстр вопрос можно решить.
6) Всегда думай перед тем как делать. Решения существуют, часто не на поверхности.

Теперь несколько вредных советов. Как стоит жить и работать.
1) Если решил связать свою жизнь с программированием, стоит понимать, что платят те у кого есть деньги, и платят столько сколько готовы заплатить. Отсюда выводы. Больше получают узкие специалисты, которые работают с чем то редким и нужным тем у кого есть деньги. Работая на бедных ты заработаешь ровно чуть больше чем на спасибо. Это как у врачей, стоматологи, к которым захаживают сытые бюргеры с зубной болью на коне, кокой-нибудь травматолог / хирург имеют 90 процентов своей обычной клиентуры бомжей и нищебродов. Но процентов 10 попадается людей с деньгами. А вот анестезиолог вообще с клиентурой не работает, денег дополнительно ему вообще не приходит. Отсюда обилие медицинских анекдотов про бедных анестезиологов.
2) Собственники и заинтересованные в бизнесе люди на платят просто так, а платят за решение проблем. Чем страшнее на первый взгляд проблема, тем больше за нее можно попросить денег. Сложные проблемы решаются разбиением на более мелкие задачки. Но переоценивать свои силы тоже не стоит. Если сделал что-то крутое скромничать не надо. Тебя будут оценивать в том числе по тому, сколько ты просишь.
3) У предыдущего пункта есть небольшое следствие. Владельцу главное решение и сроки, ему похрен на красоту кода и прочий глупый перфекционизм.
4) Лучше место работы для получения стартового опыта, какая-нибудь программисткая контора, но она же худшая в плане роста. Ты окружен людьми примерно твоего уровня и способностей, которые будут неизбежно грызться за место под солнцем, каждый твой начальник будет воспринимать тебе как угрозу своему месту. Прорваться в такой системе сложно. Кроме того работать надо на первое звено в пищевой цепочке. Пока линейному программисту что-то перепадет от базовой ставки 10 человек отщипнут по цепочке.
5) Если ты работаешь в обычной конторе, постарайся выйти со своими идеями на руководителя бизнеса (гендира), он единственный кто заинтересован в проекте в целом, и может воспринять что-то от твоих мыслей лично. Люди ниже просто попытаются тебя использовать в своих целях.
6) Люди если смотреть поверх бла бла бла всегда действуют в своих интересах, но только так как сами их понимают. Людей можно предсказывать и читать.
7) Руководители нагружают тех лошадей что тянут. Идеальный работник тот, кто просит мало работает много. Повышения? Не слышали. Зачем повышать того кто хорош на своем месте.
8) Добиваются чего-то только те, кто выходит за флажки. Есть загон для стада, где всегда будет скучно, обыденно и тухло, но жить можно, есть и другие возможности.
9) Самая тупая ошибка людей верить, что если будешь хорошо и долго работать что-то изменится. Ничего не изменится.

Ну хватит в общем, что-то я увлекся, всегда думай головой, вот мой совет.

ПС: Забыл добавить. Обязательно надо выбираться из провинции в Москву Питер, лучше в Москву. Дальше уже можно как остаться, так и двигать дальше. Если возраст и прочие дела позволяют.

Товарищи, большое вам спасибо. Я читал и был рад прочитать такое количество разных (хотя и имеющих что-то общее) подходов, которые при этом являются очень дельными. Чтобы как-то собрать воедино предложенное вами, я выделил главные идеи, уверен, тчо кому-то может еще пригоидиться.

• Учиться перед с утра сразу после сна ( Петр )
  
• Учиться и практиковаться (используя знания на практике) на работе (@f-end, Andrew Lewman, x67, cap_nemo, galliard )
  
• Помнить о том, что и ты , и работодатель заинтересованы в твоем развитии ( Andrew Lewman )
  
• Использовать время в пути на работу и с неё с пользой ( Макс, cap_nemo )
  
• Заниматься спортом ( sim3x, Дмитрий, Jony1337 )
  
• Систематизировать дела и задачи (@EvilsInterrupt)
  
• Отдыхать после работы (@EvilsInterrupt, Петр )
  

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

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

0. Начать следить за своим состоянием - понять, когда у тебя пик трудоспособоности
1. Сделать приоритет - обучение или работа
2. Научиться спать мало
3. Научиться спать по 30 мин для разделения между учебой и работой
4. Привыкнуть к мысли, что ето надолго (навсегда), те мотивация не при чем.
Твой новый график - ето твой новый стиль жизни
5. Заняться спортом, для улучшения кровообращения
6. Изучить техники улучшения запоминания

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

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

Спарсить миллион страниц с сайта который ОЧЕНЬ не хочет этого это довольно таки сложная работа.
Либо не сложная, но долгая и/или дорогая.
Зачастую даже на этом можно построить бизнес, если вдруг сумеешь спарсить хоть что-то полезное и не забаниться.

Пока вы не понимаете адекватно сложность и объем этой работы и/или не можете её сделать - не стоит за это браться.

Короче используйте то что есть или платите деньги тем кто это умеет лучше.
Это не пара строк кода на тостере ответить.

Читай стоя

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

- Сетевой стэк. Нужно иметь хотя бы базовое представление о том как с сервером общаются. Ну то есть не нужно лезть в дебри, но понимать что такое 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 джуниорам знать не обязательно просто потому, что их врядли допустят сходу к управлению инфраструктурой. А так пару неделек на изучение и вперед.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из недорогих можно посмотреть в сторону Chairman 769.

Django by Example
Другие варианты (с подобной информацией) лично мне неизвестны.

Кликните на изображении обложки книги (над которым стоит указатель со стрелкой Look inside), перейдите в раздел Table of Contents и ознакомьтесь с информацией о темах, представленных в книге.

у меня в подписи + djbook.ru ( и мануал, и форум)

практически свободно читаю

это вовсе не

без знания английского

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