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

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

/bitrix/templates/template.main/components/ma/catalog/template1/ma/catalog.element/.default/

И в этой папке лежал и HTML и CSS и, даже, картинки. «Джентельменский набор» для отображения одного из блоков на странице. Все остальная верстка лежала вообще не там. Но самая жесть, присмотритесь — скрытая диррректория. По умолчанию в Linux, если название начинается с точки, то фаил или папке не отображаются. И, разумеется, не синхронизируются с IDE.

Что заставило разработчиков сделать именно так? Не надо так.

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

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

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

С услугами все не так. Ты не можешь знать результат заранее. Когда ты нанял садовника, что бы он фигурно подстриг кусты, то ты можешь получить, как «шары» так и «кубы». Если садовник опытный, то он обязательно уточнит заранее, что ты хочешь увидеть, но и с самым подробным ТЗ, результат все равно не определен, пока кусты не подстрижены. То же самое и с другими услугами. И чем сложнее услуга, тем больше переменных, которые влияют на результат. Очень сложно продавать то, чего еще не существует. Особенно сложно, когда заказчик не представляет себе конечный результат.

Постоянно работать вместе с клиентом для получения хорошего результата тяжело. А вот продать ему «сайт-визитку» просто, особенно, если есть пример. По этому, многие разработчики пошли по пути наименьшего сопротивления. Что плохого, если клиент получит понятный результат за понятные деньги? Если все стороны понимают это и согласны, то ничего. Только дело в том, что я не встречал клиентов, которым зачем-то нужен именно такой сайт. Как правило, все же нужен какой-то результат для бизнеса, а вот его такая концепция не учитывает.

Вот и дырка в абстракции. Когда человек приходит за телевизором, то знает, что хочет каждый вечер смотреть какой-нибудь сериал. И он может подобрать себе то, что нужно или спросить совета у консультанта. А потом может пойти в Яндекс.маркет и сравнить цены на телевизоры с такими параметрами. Но сайт — результат долгой совместной работы. Нельзя заказать «сайт-визитку» в двух разных студиях и получить одинаковый результат. Точнее можно, если этот результат нулевой.

Но это еще пол беды. Понятие «визитки» быстро приобрело для клиентов и совсем другое значение. А именно — самое дешевое «пакетное предложение». И расцвет такого понимания пришелся, думаю, на кризис 2008-2009. И до сих пор, когда переговоры начинаются с фразы «нам нужен сайт-визитка», это следует понимать, как «мы не готовы тратить деньги на сайт». К сожалению, часто это значит, что на этом месте переговоры можно и заканчивать.

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

И вот недавно услышал от клиента, что им нужен лендинг с двадцатью страницами. Где будет каталог, контакты, а еще страница «о компании». Как говорил герой Мета Деймона, Локи в замечательном фильме Догма, «речи, знакомые до боли».

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

Вот приходит сотрудник и говорит: «Ребята, хватит жить в прошлом веке. Есть скайп, почта и телефон. Я могу брать задачи и выдавать результат, зачем мне каждый день терять два часа в пробках?» Решили попробовать. Договорились, что пока не каждый день, но некоторые дни работать удаленно.

И вот первый же «тестовый» день. Мелкий вопрос мы обсуждали письменно в скайпе полтора часа (с перерывами на 3-5 минут), тогда, как очно ушла бы пара минут. Просьбу «сделать более подробное описание» в одной из задач нашего таск-менеджера сотрудник выполнить не смог, так как был страшно занят. Отчет, о котором мы договаривались так же подготовить не успел. А на следующий день пришлось потратить еще час, что бы узнать, чем занимался сотрудник. Выяснилось, что не тем.

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

Вы скажете, что я сам дурак. Ну зачем было переписываться полтора часа, когда можно позвонить? Да по тому, что сразу это не очевидно. Я не думал, что маленькая сложность может вызвать такие затруднения. Да и неправильно понятая фраза завела разговор в тупик дважды.

И я не против такой системы работы в целом. Просто считаю, что она не всем подходит. Например, про себя я знаю, что если есть одна большая задача, то без проблем смогу работать удаленно. Смогу сделать результат своей работы очевидным. Смогу показывать прогресс в недельной задаче и «прибивать гвоздями» ключевые точки. Но решить 10 мелких операционных вопросов за день удаленно я не смогу. А если смогу, то разгребать непонятки еще неделю потом.

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

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

Сразу оговорюсь, что текстов нужно много (о каждом товаре) и недостаточно просто перечислить характеристики. Задача — ответить на вопросы покупателей, помочь им выбрать то, что им нужно.

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

Этого текста бы не было, если бы все пошло по плану. Мы пробовали писать подробное ТЗ. Пробовали давать более общую задачу, с надеждой, что профессионал найдет источники информации, которые ему нужны. Пробовали искать самых дорогих специалистов. И каждый раз получали от клиента недоуменный взгляд и немой (а иногда и не немой) вопрос «Что это за ерунда? Полное незнание предмета и аудитории. Такой текст выкладывать нельзя». В общем, заплатили за десяток текстов, которые ушли в ведро.

Параллельно с этим, пытались помочь найти человека в штат. Сначала назвали вакансию “Копирайтер”, но не получили ни одного адекватного отзыва. Потом, пробовали найти «Маркетолога», по тому, что пришли к выводу, что такие люди должны смочь разобраться в рынке и понять, что волнует покупателей.

Тогда я написал с просьбой о совете Сергею Капличному. Огромное ему спасибо — в тот же день получил подробный ответ. Кроме прочего, в ответе присутствовал совет поискать нужного человека на бирже труда Максима Ильяхова. Всего там сейчас 25 комментариев. Из них 3 без прямых контактов. Примерно половина тех, кто написал, что не пишут технические тексты. Из оставшихся, я выбрал 6 человек и разослал письма.

Я ждал чего угодно. Огромного ценника. Сообщении о том, что проект не интересен. Сообщения о высокой загрузке. Но никак не молчания. В итоге получил всего один(!) отклик от Романа Скрупника о том, что он не может сейчас взять новый проект.

Друзья, откуда вы берете хорошие тексты на технические темы?

Первая часть

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

<?php

abstract class Infantry {
    //общие для всей пехоты методы
    abstract public function Attack();
    abstract public function Defend();
}
abstract class Archer {
    abstract public function Shoot();
}
abstract class SiegeWeapons {
    abstract public function Fire();
}

class GoodInfantry extends Infantry {
    //Спецэфическая реализация для доброго пехотинца
    public function Attack();
    public function Defend();
    
    public function Treat();
}
class GoodArcher extends Archer{
    public function Shoot();
    
    public function Treat();
}
class GoodSiegeWeapons extends SiegeWeapons{
    public function Fire(); 
    
    public function Treat();
}

class EvilInfantry extends Infantry{
    //Спецэфическая реализация для злого пехотинца
    public function Attack();
    public function Defend();
    
    public function Invisible();
}
class EvilArcher extends Archer{
    public function Shoot();
    
    public function Invisible();
}
class EvilSiegeWeapons extends SiegeWeapons{
    public function Fire();
    
    public function Invisible();
}

abstract class AbstractFactory
{
    abstract public function createInfantry();
    abstract public function createArcher();
    abstract public function createSiegeWeapons();
}

class GoodFactory extends AbstractFactory
{
    /**
     * @return Infantry
     */
    public function createInfantry()
    {
        return new GoodInfantry();
    }

    /**
     * @return Archer
     */
    public function createArcher()
    {
        return new GoodArcher();
    }

    /**
     * @return SiegeWeapons
     */
    public function createSiegeWeapons()
    {
        return new GoodSiegeWeapons();
    }
}

class EvilFactory extends AbstractFactory
{
    /**
     * @return Infantry
     */
    public function createInfantry()
    {
        return new EvilInfantry();
    }

    /**
     * @return Archer
     */
    public function createArcher()
    {
        return new EvilArcher();
    }

    /**
     * @return SiegeWeapons
     */
    public function createSiegeWeapons()
    {
        return new EvilSiegeWeapons();
    }
}

Код стал не таким красивым по тому, что появились методы, которые приходится копировать. В php нет множественного наследования и приходится выбирать наследоваться белому лучнику от белых или от лучников. Мы априори выбрали второй вариант и теперь думаем, как сделать наш код красивее, а его поддержку удобнее. НР предлагает использовать примеси (trait), которые появились в php 5.4. Вынесем обшие методы в примесь.

<?php

abstract class Infantry {
    //общие для всей пехоты методы
    abstract public function Attack();
    abstract public function Defend();
}
abstract class Archer {
    abstract public function Shoot();
}
abstract class SiegeWeapons {
    abstract public function Fire();
}

trait Good {
    public function Treat();
}

trait Evil {
    public function Invisible();
}

class GoodInfantry extends Infantry {
    use Good;
    
    //Спецэфическая реализация для доброго пехотинца
    public function Attack();
    public function Defend();
}
class GoodArcher extends Archer{
    use Good;
    public function Shoot();
}
class GoodSiegeWeapons extends SiegeWeapons{
    use Good;
    public function Fire();
}

class EvilInfantry extends Infantry{
    use Evil;
    
    //Спецэфическая реализация для злого пехотинца
    public function Attack();
    public function Defend();
}
class EvilArcher extends Archer{
    use Evil;
    public function Shoot();
}
class EvilSiegeWeapons extends SiegeWeapons{
    use Evil;
    public function Fire();
}

abstract class AbstractFactory
{
    abstract public function createInfantry();
    abstract public function createArcher();
    abstract public function createSiegeWeapons();
}

class GoodFactory extends AbstractFactory
{
    /**
     * @return Infantry
     */
    public function createInfantry()
    {
        return new GoodInfantry();
    }

    /**
     * @return Archer
     */
    public function createArcher()
    {
        return new GoodArcher();
    }

    /**
     * @return SiegeWeapons
     */
    public function createSiegeWeapons()
    {
        return new GoodSiegeWeapons();
    }
}

class EvilFactory extends AbstractFactory
{
    /**
     * @return Infantry
     */
    public function createInfantry()
    {
        return new EvilInfantry();
    }

    /**
     * @return Archer
     */
    public function createArcher()
    {
        return new EvilArcher();
    }

    /**
     * @return SiegeWeapons
     */
    public function createSiegeWeapons()
    {
        return new EvilSiegeWeapons();
    }
}

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

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