На одном из проектов я встретил интересное мнение. Весь код в проекте должен быть максимально открыт по умолчанию. Т.е. мы делаем все методы и поля public, а final нигде не ставим. Мотивировано это было сложностями дальнейшей поддержки:

Если я захочу наследовать класс, а там метод private, мне придется изучать код, чтобы понять, зачем его сделали private и могу ли я сделать его публичным.

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

interface FooInterface {
  public function foo();
}

class Foo implements FooInterface {
  public function foo() {
    // do stuff
    $this->bar();
    // do stuff
  }

  public function bar() {
    // do stuff
  }
}

Этой статьей я открываю рубрику из практики "Как делать не надо". В ней будет код из реальных проектов, из которого я уберу все отсылки к самим проектам. И, конечно, разъяснение: почему так делать нельзя, и как бы поступить стоило.

Итак, первый пациент. Внутри трейта используются поля его наследников. То есть, что-то такое:

trait Foo
{
    public function bar(): string
    {
        return $this->field . self::CONSTANT . $this->method() . true;
    }
}

Какие ошибки в программировании страшнее всего? Я бы выделил два типа:

• те, из-за которых бизнес теряет много денег
• и те, которые встречаются реже всего.

Почему первые - понятно сразу, а что со вторыми? Дело в том, что чем реже мы встречаем какой-то тип ошибок - тем сложнее понять, чем они вызваны.
Так случилось и у меня на работе. Однажды утром тестировщики заметили, что часть запросов бэкенду возвращала ошибку 502 (Gateway Timeout). Эта ошибка тормозила релиз, и за неё взялись все старшие разработчики и devops-инженер. Поначалу считали, что эту ошибку возвращает Nginx, и бэкенд не при чём. Через некоторое время поняли, что виноват всё-таки PHP. На что только не грешили: отключали BlackFire, меняли настройки OpCache, пробовали разные патч-версии в PHP, и так далее. Однако, сама ошибка оказалась не в инфраструктуре, а непосредственно в коде приложения.

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

Вообще есть несколько популярных подходов:

• Налево пойдешь - хайповый инструмент найдешь
• Направо пойдешь - что-то проверенное и надежное возьмешь
• Прямо пойдешь - любимый инструмент прикрутишь

Они хороши тем, что при их использовании не надо думать. Просто берешь то, что хочется - и дело с концом 😃 Ну а если есть нужда или желание подойти к вопросу более серьезно - прошу под кат, будем разбираться.

В мире разработки существует множество архитектурных паттернов. Часть из них мы используем каждый день, часть - реже. Наверняка каждый из вас много раз видел синглтон и фабрику. Многие их писали. А вот когда я впервые прочёл про паттерн Строитель, то не понял поначалу, в какой ситуации его можно применить. Что совсем смешно: я регулярно использовал его реализацию (QueryBuilder из фреймворка Yii), но глаз настолько замылился, что я не смог сопоставить название и функционал этого класса с соответствующим паттерном проектирования 😂 Конечно, через некоторое время до меня дошло. А еще через некоторое - нашлась ситуация, в которую паттерн Строитель вписался идеально.