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

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

Можно поити дальше и добавить в правила animals.txt специально для культуры фури. Если не в курсе, то это подростки, которые идентифицируют себя с животными. Сорри за офтоп.

Главная, что работа идет. Ждем, ждем... интересно.

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

Хороший список! Для молодежи еще добавил бы в него наставничество и обучение.

Очень интересно, спасибо. Пропустил это дело. Надо последить, че там.

Интересно, спасибо.

:) Ждем новую версию, Evg - Libarea тоже ждет и мы ждем. Про сроки не спрашиваю, а желаю плодотворной работы:)

A вот в интерпретации ChatGpt

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

Первое, что я делаю при получении кода, это провожу его анализ. Я проверяю, соблюдены ли основные принципы ООП в коде, существуют ли DRY (Don't Repeat Yourself) и SOLID (Single Responsibility Principle, Open-closed Principle, Liskov Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle) принципы, как проводится работа с БД, как реализованы операции вывода и ввода данных, насколько грамотно использованы переменные, как организованы структуры данных и т.д. Если код содержит ошибки и нарушения, я начинаю вносить исправления, используя правильные методы и стандарты.

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

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

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

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

Да:) Я когда скачал картинку с оригинальной статьи - тоже нашел Yii и сразу первая мысль - надгробный камень... Я не являюсь знатоком в cms и фреймворках, но картинка как бы не очень... Понятно Laravel по центру, основные cms - WP, Drupal, Joomla присутствуют... Интересно зачем туда затесался cakephp и почему отсутствует Symfony:) Ну понятное дело, прикольная юморная картинка.

Прикольно. Только чё-то Yii расположили в парке, а этот парк как будто Laravel-a. И сама надпись не особо выделяющаяся. Принизили хулиганы :)

Если выйдет еще это сделать раньше yii3, то план действительно интересен!

Очень интересно посмотреть, жду с нетерпением.

Да, бывает такое, встречал. Вроде всё верно, правильно. Ну уж очень большой для тех задач, что надо. Один сайт вообще бы html голый оставил, т.к. там несколько страниц и они не меняются. А там laravel был.

Да, да, на Quora писали про покупку Google.com. Занятно было читать. :)

Добавил в оформление картинки сгенерированные нейросетью Midjourney

Заглянул из любопытства в две книжки. Первая Beaulieu A. - Learning SQL, 3rd edition издательства O'REILI за 2020г. В ней нет никаких вообще диаграмм на тему джойнов. Просто примеры SQL. Вторая - Моргунов Е. Язык SQL.Базовый курс за 2017. То-же самое, примеры запросов и их вывод в табличном виде. Диаграммы в проф литературе не особо жалуют =)

О! А вот еще материал, попался сегодня случайно.

Новая схема SQL Join-ов: https://telegra.ph/Novaya-shema-SQL-Join-ov-01-16

Да, они более детальны. Ранее не обращал на них внимание, спасибо +.

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

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

Добрый день! Вот в этом случае

SettingModel::editPassword(['id' => $user_id, 'password' => $newpass]);

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

public static function editPassword(int $userId, string $newpass) {
    // ...
}
public static function editCurrentUserPassword(string $newpass) {
   return self::editPassword(UserData::getId(), $newpass);
}

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

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

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

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

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

Мне показалось, что InnoDB имеет более высокую надежность хранения? Сайт есть, там трафик большой, как перевел на InnoDB всё нормальнос стало, а раньше летело почему-то.

При удалении папки database в файле composer.json нужно удалить маппинг на эту папку:

"autoload": {
    "classmap": [
      "app/",
      "database/", <- эту строку удалить
      "vendor/phphleb"
    ],
        ...

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