fomiash / Фома Тутуров ¹⁸⁸

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

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

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

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

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

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

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);
}

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

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

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

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

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

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

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

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

Инструкция по настройке работы фреймворка для Open Server Panel

@YuraN, озадачившись вопросом переустановил Open Server 5.4.3 (на Windows 10), выбрал PHP 8.1, MySQL 8.0, направил домен в папку public проекта (тот, что под этим постом по ссылке на архив),

создал базу test и внёс настройки:

define ("HLEB_TYPE_DB", "mysql.example");

define("HLEB_PARAMETERS_FOR_DB", [

    "mysql.example" => [
        "mysql:host=localhost",
        "port=3306",
        "dbname=test",
        "charset=utf8",
        "user" => "root",
        "pass" => "",
    ]
]);

Выполнил команду php console hlogin/create-login-table-task в корне проекта, чтобы сгенерировать нового администратора. Под ним захожу свободно, лайки ставятся, пользователи добавляются. Так что воспроизвести проблему не удалось.

В случае запуска с одной базой данных, но разными установками фреймворка, может быть такое, что уникальные ключи каждой установки (если это два разных проекта по разным папкам) различаются. Это сделано для безопасности и для их синхронизации (чтобы шифрованные пароли пользователей подходили на этих установках) нужно из той папки, где вы регистрировали администратора, скопировать секретный ключ /storage/cache/key/security-key.txt в другие установки. Если база данных от старого проекта на основе фреймворка HLEB, а установка его новая, соответственно ключ не подходит, можно просто восстановить пароль как пользователям, так и администратору.

Если нужно подтвердить E-mail локально, в этом случае поможет то, что "отправленные" письма сохраняются в лог (/storage/logs/). В письме нужно найти ссылку после слов Для подтверждения адреса E-mail необходимо пройти по и вставить в браузер. Второй способ - изменить в базе данных пользователю значение regtype на 2.

Сохранение писем в логи (а также капча и другое) настраивается в админпанели при входе под администратором.

Чтобы каждый раз не писать в view(...) префикс папки, а соотнести контроллер с папкой, можно создать класс MainModuleController в таком виде:

<?php
// Файл /modules/MainModuleController.php
namespace Modules;
class MainModuleController extends \MainController
{
    protected function view($to, $data = null): array
    {
        $type = \Request::get('type');
        $controller = \Request::get('controller');
        return view("$type/views/$controller/"  . ltrim($to, '\\/ '), $data);
    }
}

и все контроллеры в модулях наследовать от этого класса. Это позволит размещать шаблоны в папке modules/api/views/<название контроллера>/ для api (у остальных аналогично), а в контроллерах вызывать через $this->view(...) по названию шаблона в этой папке.

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

Более развернутая информация, как используется модуль регистрации в маршрутах: ответ в одном из предыдущих этапов(Маршрутизация) создания этого приложения.

Ещё часто сейчас упоминаются в IT-сообществе soft skills и эмоциональный интеллект, наборы коммуникативных качеств, которые не всякий раз встречаются у продажников и руководителей, но почему-то востребованы и при найме разработчиков.

Вот например, есть условный кандидат, работает за семерых, зарплату не берёт, сам доплачивает, но вместе с тем очень токсичен, всем хамит, строит интриги, разрушает коллектив. Насколько бы такой был востребован? А наоборот?

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

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

Концепция MVC появилась ранее DDD (предметно-ориентированное-проектирование) в последнем "моделью" обозначается сопоставление программной сущности её реальному (переносимому в область OOП) прототипу, что и называется "модель". В терминах DDD указанная выше Модель из MVC может быть представлена как Хранилище.

Такое Хранилище является обёрткой для запросов к базе данных или иному типу их хранения, при этом может не только записывать/читать данные, но и производить вычисления в рамках компетенции Хранилища. Это может быть получение одного значения или коллекции объектов (списка) данных по значению какого-либо атрибута или сложной комбинации параметров, но также возможно и количества, среднего значения или иного числового значения по результатам выборки.

Во фреймворке даётся шаблон для Хранилища (Модели) реализованный как Синглетон и примеры использования в инструкции, но не возбраняется использование любого другого способа для доступа к хранимым данным.

В версии v1.6.77 фреймворка HLEB добавлена команда php console --update-routes-cache, которая обновляет кэш роутов к текущему их состоянию. Ранее нужно было осуществить реальный запрос к одному из роутов, чтобы перерасчитать кэш.

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

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

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

Вам нужно проверить слеш в конце запроса и его обязательность в константе HLEB_PROJECT_ENDING_URL, может быть что с POST '/test' идёт редирект на GET '/test/'.