К черту абсолютные цифры, средние значения, распределения и прочую технарскую фигню. Мы же все гуманитарии, нам интересен эмоциональный оттенок: «в Москве чуть более, чем немного бездушная, но большая зарплата, чем в Бельгии. Хотя по моим ощущениям в год в Бельгии я получаю больше, чем в Москве.» — идеальный ответ.
А конфигурации? :) Например настройки форм, пользователи, тестовые данные. Можно же частично заливать, вытягивать. Очень полезно видеть что когда и как было раньше. Конфигурации то начальные как-то создаются, и хорошо, если это не blob, а читаемый XML.
Да и речь то не о том как хранить бэкап БД в VCS, а о том как накатывать обновления (в том числе частичные), предзагружать начальную конфигурацию и т.п. А где хранить саму БД — вопрос религии, он лежит вне этой темы.
Посмотрел ваши статьи, вы видимо на Qt специализируетесь.
В этой статье описан прикладной код для корпоративных приложений на специализированной платформе. Задача платформы — избавить прикладного программиста (которые программирует бизнесс процессы) от необходимости ручками писать сами контролы как таковые. Вот с такой реализацией как в статье — можно забыть о контролах, обвесе, инфраструктуре, и писать только бизнесс код в песочнице, где ничего не сломается, все покрыто правильными транзакциями и все исключения перехватываются. По этому и такая модель, такая структура кода, такие атрибуты и реализация. Все в этом коде призвано сделать максимально простым и быстрым написание именно обработчика. От сюда и использование комментариев как заголовков, а не атрибутов, и специфичные контексты, и интерфейс, сигнатура которого реализуется. По факту для создания пустой кнопки надо ввести символов 10 с клавиатуры, все остальное делается автодополнением. Об этом и статья.
Пишу это потому что мне показалось что вы взглядом Qt разработчика не распознали о чем тут речь, и код показался стремным и корявым. Хотя практика показывает что описанные принципы жизнеспособны. Эхехе, увы статья провалилась, очень хочется понять почему…
Теоретически можно. Но это неудобно. Будет тенденция к огромным классам с тысячами методов-кнопок. Это тяжело поддерживать, тяжело тестировать. Да и класс это не такая дорогая вещь, чтоб опасаться её создавать по необходимости.
И ещё, если у вас будет много разных обработчиков в одном классе — это нарушит принципы SOLID, и вообще не в духе ООП.
Один класс — одно назначение. У кнопки, как правило, одно назначение, так что её концепция хорошо ложится на класс. В принципе можно сделать как бы одним классом как бы много кнопок, но это само по себе адЪ.
Все зависит от того, какие параметры вы хотите настраивать.
Вообще общий функционал реализуется в базовых классах. Далее наследники реализуют интерфейс, который обозначает что это кнопка и она работает в таком-то окружении. Вы можете настроить эту кнопку из интерфейса, определить права, иконки, порядок, изменить текст и прочее. Т.е. можно из одной кнопки в коде сделать 100500 кнопок в интерфейсе. Вообще строго говоря это не кнопка, а само действие, его обработчик. Кнопка — это уже элемент View, который связывается с этим действием, и берет из этого действия для своего отображения все что может.
Можно отнаследоваться и сделать 100500 классов, можно настроить одну «кнопку» и размножить её в интерфейсе, настройки выгрузить в файлы конфигурации и распространять их с системой. Она сама все подгрузит и свяжет при развертывании. Вопрос лишь в том что вам нужно сделать и что настроить. Я с ходу не могу придумать сценарий где реально нужно 100500 классов. Хотя можно сделать одну кнопку и программно нагенерировать её конфигов отображений (скажем в цикле), которые потом пользователю представятся как много много пунктов меню скажем. Но это уже более сложная вещь, порог вхождения в необходимость таких средств ещё больше, чем для вещей описанных в статье. Увы :\ Но если интересно — могу рассказать подробнее, только опишите гипотетическую проблему, чтоб можно было придумывать решение.
Посмотрел ваши статьи, вы видимо не пишете на C#. Просто в Visual Studio XML комментарии — это стандарт. Они очень глубоко интегрированы в среду, в сборку, в средства поддержки кода. Их очень просто писать, срабатывает все возможные шаблоны и автодополнения. Так что тут просто нет смысла искать альтернативу, в таком формате документация крайне хороша для Visual Studio и C#.
Если вы используете другие среды и языки, то вопрос и вправду открыт. Самому режет глаз формат документации MS для JavaScrpt. А вот для C# это безальтернативно, удобно и продуманно (вплоть до типизации специфических элементов языка, типа Generic параметров типа).
И в статье, в контексте документации, речь идет о том как избавиться от лишнего атрибута используя уже имеющиеся и нужные части кода (комментарии к классам бизнес логики). Речь не идет о том, что нужно везде писать комментарии, или о том, что комментарии надо писать только в XML. Просто сборки C# используют этот формат, он удобно обрабатывается средствами под .NET, например PostSharp. Вооооот… Надеюсь прояснил.
PS Я и сам под впечатлением от книги Чистый код, считаю что комментарий — признак отчаянья, но вот прикладные программисты пишут код по спецификации, и им просто необходимо писать комментарии на основе этой спецификации. А аналитики пишут на своем естественном нативном языке (по большей части у нас на русском).
Плюсы:
— Не надо дублировать описание в атрибуте. Классу и так и так нужна документация, а кнопке описание (в том числе и в тултипе). Поразмыслив пришли к выводу что для классов кнопок комментарий является полным отражением того, что было бы в атрибуте.
— Меньше мусора в коде. Удалось избавиться от одного атрибута.
Минусы:
— Нестандартное использование комментариев.
Вообще рабочий процесс так устроен, что с этим ни разу проблемы не возникало. Т.е. были опасения что из-за неаккуратного использования комментов пойдут косяки в UI, но такого не произошло. Там не только комментарии, ещё и версионность, выгрузка всех этих опций в XML и накатка обновлений. Все это позволило сделать прозрачной работу с заголовками кнопок как комментариями.
На локализацию это в общем-то не повлияло, ведь дальше кода, в базе это все выглядит так же, как и будь оно атрибутом. Наши механизмы локализации об это не запнулись. Так что вышло что это однозначное благо.
Точка в конце фразы круто смотрится, как бы подчеркивая что речь идет об устоявшемся факте. Может эти договоренности у вас не работают? Может это ваш косяк? Так напишите статью об этом фейле, я с удовольствием её прочитаю, выскажу пару рекомендаций по организации связей, и может и у вас заработает. Надо быть добрее к людям, и не скатываться в полемику, дискуссия продуктивнее.
Защитите приватность своих детей, используйте для имени ребенка не менее 45 символов, из них не менее 1-ой заглавной, 1-ой строчной, 3-х цифр и 2-ух спецсимволов.
Строго говоря такого соответствия нет. Это все равно что сказать мягкое = теплое.
Потоки могут блокировать друг друга, ожидать ресурсов, выполнения других потоков и т.п.
Вот то что описано в статье — это с какой-то точки зрения и есть асинхронное взаимодействие с данными, относительно данных. Т.е. операции над ними выполняются не синхронно, в порядке запроса, а асинхронно в порядке готовности к выполнению.
Проблема в том, что вы не можете слишком долго блокировать данные для асинхронного запроса исключения в функции Ф1.
Как это работает сейчас:
Пользователь П1 начал транзакцию, блокировав данные, П2 тоже начал транзакцию, но которая ожидает пользователя П1 (он что-то блокировал, что нужно транзакции П2). У П1 в методе Ф1 выплюнулось исключение, откатилась вся транзакция, данные освободились. Соответственно П2 может провести теперь свою транзакцию и выполнить Ф1 и Ф2 методы. А пользователь П1 имеет достаточно времени подумать продолжать ли ему выполнение своей операции, или же отменить её. Как описано выше — он ничего не блокирует.
Если бы запрос исключения был бы асинхронный, а его транзакция не откатывалась, а просто приостанавливалась, висела в памяти, то данные были бы блокированы значительное время. Пользователь П2 должен был бы ждать пока пользователь П1 пообедает, выпьет кофе, посидит на хабре, и после всего этого нажмет «продолжить» в своем исключении.
Вообще ситуация сложная и в деталях выглядит ещё сложенее, т.к. могут применяться разные уровни изоляции. Это простой пример как это работает, и почему так, а не иначе.
Автор предлагает следующее: У него есть метод М1, в котором грубо говоря есть две части Ф1 и Ф2.
Ф1 — проверяет данные
Ф2 — сохраняет их
Метод М1 обернут в транзакцию. Выглядит это как-то так:
метод М1()
{
НачалоТранзакции();
Ф1();
Ф2();
КонецТранзакции();
}
Предположим пользователь П1 вызвал метод М1. В проверке Ф1 у него возникло исключение, транзакция откатилась, никакие данные не сохранились, а пользователю пишел вопрос «Хотите продолжить, или отменить». Он жмет допустим продолжить и передает дополнительно к вызову идентификатор исключения, которое свалило выполнение в последний раз. Теперь исключение по этому идентификатору будет пропускаться, и таким образом метод отработает от начала и до конца, отработает Ф1 с проверкой и выполнится Ф2. После этого транзакция успешно завершится.
В такой ситуации если пользователь П2 конкурентно запустит метод М1, то у него не получится завершить транзакцию, т.к. уровень изоляции ему это запретит, ибо данные были изменены в другой транзакции пользователем П1.
Вот если на пальцах то, что предложил автор.
Таким образом получается имитация stateful поведения там, где это сложно достижимо по честному, например в многопользовательской системе (на тысячи пользователей), которая работает с огромным объемом данных, методы блокируют миллионы записей в десятках таблиц.
Предположим вы разобъете метод М1 на две части — Ф1 и Ф2.
Ф1 — проверяет данные, Ф2 — сохраняет их.
Тогда между вызовом метода Ф1 и Ф2 есть некоторое время, в которое другой пользователь может так же выполнить какие-то действия, которые сделают данные, сохраненные в Ф2 некорректными.
Предположим работает 2 пользователя: П1 и П2. Оба они запускают метод М1 (который разбит на 2 части, Ф1 и Ф2).
Пользователь П1 проверил свои данные методом Ф1, проверка прошла. Сразу за этим пользователь П2 проверил свои данные методом Ф1, у него тоже все Ок. Далее пользователь П1 сохранил данные методом Ф2, его данные валидны. А вот когда то же начал делать пользователь П2, произойдет что-то плохое, ведь П1 изменил данные, соответственно П2 сохраняет методом Ф2 уже не то, что проверила его проверка Ф1.
Таким образом и проверка и сохранение должны быть в одной транзакии, чтоб не допустить самой возможности неверного сохранения.
Вообще это основы основ работы с данными, и как бы суть транзакционности.
За такие ситуации надо руки вырывать прикладникам и перешивать на те места, откуда они должны расти у Разработчиков. Проблема надуманная, является следствием говнокода, в частности некорректного использования инструмента.
Разработчики самых лучших приложений получат возможность первыми попасть в Windows Store!
КАК ПОПАСТЬ НА ЛАБОРАТОРНУЮ РАБОТУ?
… среди желающих попасть на лабораторку мы проведем дополнительный отбор:
До 13 апреля необходимо прислать предварительную заявку на email… До 18 апреля пришлите на тот же адрес и с тем же заголовком письмо содержащее… До 20 апреля эксперты Microsoft отберут лучшие заявки, авторы которых получат приглашение на лабораторную работу.
Мне кажется, или предложение на момент публикации на хабре уже не актуально?
Для ведущих сделайте боксы, или хотя бы поставьте экраны, по тиму такого.
Ещё можно их посадить лицом к окнам (или стенам), тогда шум будет чуть меньше распространяться.
И не забывайте, человек в наушниках на оба уха не слышит как громко он говорит. По этому закупите гарнитуры на одно ухо. Если этого ещё не сделано, то возможно этой меры будет достаточно.
Проведите беседу с персооналом, объясните им что посылать менеджера в переговорную, если ему что-то надо — это нормально. Многие просто бояться попросить коллег перенести свой затянувшийся митинг куда-то по дальше от рабочего места. У вас в команде есть иерархия, так соберите представителей среднего звена и дайте им поручение — гонять всех громкоговорунов в переговорные, аля такие полицаи. Никаких санкций, просто «Василий, вы громко говорите, может лучше обсудить это в переговорной, ребятам сложно сосредоточится из-за шума». Через месяц-два все сами будут отлучаться в переговорку (ведь там можно ещё и про жизнь поболтать, про грудь девушки на ресепшене, про то, что Машка в чулках, небось собирается куда вечером… весна. В общем в переговорках свой профит, надо просто продемонстрировать его, дать распробовать).
Когда в кабинете больше 5-7 человек, то пора уже вводить правило тишины. Т.е. никаких «Здорова ребят, я пришел!!!». Вообще это удар по тим билдингу, но производительность важнее. Нужен инструктаж с объяснением, мол «если вы опаздываете, то ребята, не стоит здороваться, кричать на весь кабинет и все такое, после 9-20 все что говорится громко — говорится в переговорной». Никаких санкций. Кто не поймет — через неделю собрать отдельно, поговорить снова. Через месяц можно начать делать замечания, но это едва ли потребуется. Можете для профилактики стребовать объяснительные с опаздавших. Хоть это и демотивирует, и делает приход на работу вовремя важнее работы, но если не увлекаться, то выйдет сбить неудержную радость от встречи с коллективом и желание крикнуть «Я пришел, всем привет!». Но это крайняя мера, прибегая к ней вы теряете лояльность сотрдников и их инициативу в работе.
Задумайтесь над пересадкой отделов, которым свойственно много говорить в отдельное пространство, либо выделение им коробки, перегородки, ещё чего такого. Очень сложно заткнуть аналитика, у него работа такая — со всеми говорить и все уточнять, по этому стоит держать этих ребят отдельно. Возможно с дизайнерами та же фигня.
Сила не в компонентах, сила в том, как их организовать и граматно применить ;) Ну и чуток расширить, где надо.
Да и речь то не о том как хранить бэкап БД в VCS, а о том как накатывать обновления (в том числе частичные), предзагружать начальную конфигурацию и т.п. А где хранить саму БД — вопрос религии, он лежит вне этой темы.
В этой статье описан прикладной код для корпоративных приложений на специализированной платформе. Задача платформы — избавить прикладного программиста (которые программирует бизнесс процессы) от необходимости ручками писать сами контролы как таковые. Вот с такой реализацией как в статье — можно забыть о контролах, обвесе, инфраструктуре, и писать только бизнесс код в песочнице, где ничего не сломается, все покрыто правильными транзакциями и все исключения перехватываются. По этому и такая модель, такая структура кода, такие атрибуты и реализация. Все в этом коде призвано сделать максимально простым и быстрым написание именно обработчика. От сюда и использование комментариев как заголовков, а не атрибутов, и специфичные контексты, и интерфейс, сигнатура которого реализуется. По факту для создания пустой кнопки надо ввести символов 10 с клавиатуры, все остальное делается автодополнением. Об этом и статья.
Пишу это потому что мне показалось что вы взглядом Qt разработчика не распознали о чем тут речь, и код показался стремным и корявым. Хотя практика показывает что описанные принципы жизнеспособны. Эхехе, увы статья провалилась, очень хочется понять почему…
И ещё, если у вас будет много разных обработчиков в одном классе — это нарушит принципы SOLID, и вообще не в духе ООП.
Один класс — одно назначение. У кнопки, как правило, одно назначение, так что её концепция хорошо ложится на класс. В принципе можно сделать как бы одним классом как бы много кнопок, но это само по себе адЪ.
Вообще общий функционал реализуется в базовых классах. Далее наследники реализуют интерфейс, который обозначает что это кнопка и она работает в таком-то окружении. Вы можете настроить эту кнопку из интерфейса, определить права, иконки, порядок, изменить текст и прочее. Т.е. можно из одной кнопки в коде сделать 100500 кнопок в интерфейсе. Вообще строго говоря это не кнопка, а само действие, его обработчик. Кнопка — это уже элемент View, который связывается с этим действием, и берет из этого действия для своего отображения все что может.
Можно отнаследоваться и сделать 100500 классов, можно настроить одну «кнопку» и размножить её в интерфейсе, настройки выгрузить в файлы конфигурации и распространять их с системой. Она сама все подгрузит и свяжет при развертывании. Вопрос лишь в том что вам нужно сделать и что настроить. Я с ходу не могу придумать сценарий где реально нужно 100500 классов. Хотя можно сделать одну кнопку и программно нагенерировать её конфигов отображений (скажем в цикле), которые потом пользователю представятся как много много пунктов меню скажем. Но это уже более сложная вещь, порог вхождения в необходимость таких средств ещё больше, чем для вещей описанных в статье. Увы :\ Но если интересно — могу рассказать подробнее, только опишите гипотетическую проблему, чтоб можно было придумывать решение.
Если вы используете другие среды и языки, то вопрос и вправду открыт. Самому режет глаз формат документации MS для JavaScrpt. А вот для C# это безальтернативно, удобно и продуманно (вплоть до типизации специфических элементов языка, типа Generic параметров типа).
И в статье, в контексте документации, речь идет о том как избавиться от лишнего атрибута используя уже имеющиеся и нужные части кода (комментарии к классам бизнес логики). Речь не идет о том, что нужно везде писать комментарии, или о том, что комментарии надо писать только в XML. Просто сборки C# используют этот формат, он удобно обрабатывается средствами под .NET, например PostSharp. Вооооот… Надеюсь прояснил.
PS Я и сам под впечатлением от книги Чистый код, считаю что комментарий — признак отчаянья, но вот прикладные программисты пишут код по спецификации, и им просто необходимо писать комментарии на основе этой спецификации. А аналитики пишут на своем естественном нативном языке (по большей части у нас на русском).
— Не надо дублировать описание в атрибуте. Классу и так и так нужна документация, а кнопке описание (в том числе и в тултипе). Поразмыслив пришли к выводу что для классов кнопок комментарий является полным отражением того, что было бы в атрибуте.
— Меньше мусора в коде. Удалось избавиться от одного атрибута.
Минусы:
— Нестандартное использование комментариев.
Вообще рабочий процесс так устроен, что с этим ни разу проблемы не возникало. Т.е. были опасения что из-за неаккуратного использования комментов пойдут косяки в UI, но такого не произошло. Там не только комментарии, ещё и версионность, выгрузка всех этих опций в XML и накатка обновлений. Все это позволило сделать прозрачной работу с заголовками кнопок как комментариями.
На локализацию это в общем-то не повлияло, ведь дальше кода, в базе это все выглядит так же, как и будь оно атрибутом. Наши механизмы локализации об это не запнулись. Так что вышло что это однозначное благо.
Точка в конце фразы круто смотрится, как бы подчеркивая что речь идет об устоявшемся факте. Может эти договоренности у вас не работают? Может это ваш косяк? Так напишите статью об этом фейле, я с удовольствием её прочитаю, выскажу пару рекомендаций по организации связей, и может и у вас заработает. Надо быть добрее к людям, и не скатываться в полемику, дискуссия продуктивнее.
Потоки могут блокировать друг друга, ожидать ресурсов, выполнения других потоков и т.п.
Вот то что описано в статье — это с какой-то точки зрения и есть асинхронное взаимодействие с данными, относительно данных. Т.е. операции над ними выполняются не синхронно, в порядке запроса, а асинхронно в порядке готовности к выполнению.
Тут мы углубляемся уже в более сложные сущности.
Как это работает сейчас:
Пользователь П1 начал транзакцию, блокировав данные, П2 тоже начал транзакцию, но которая ожидает пользователя П1 (он что-то блокировал, что нужно транзакции П2). У П1 в методе Ф1 выплюнулось исключение, откатилась вся транзакция, данные освободились. Соответственно П2 может провести теперь свою транзакцию и выполнить Ф1 и Ф2 методы. А пользователь П1 имеет достаточно времени подумать продолжать ли ему выполнение своей операции, или же отменить её. Как описано выше — он ничего не блокирует.
Если бы запрос исключения был бы асинхронный, а его транзакция не откатывалась, а просто приостанавливалась, висела в памяти, то данные были бы блокированы значительное время. Пользователь П2 должен был бы ждать пока пользователь П1 пообедает, выпьет кофе, посидит на хабре, и после всего этого нажмет «продолжить» в своем исключении.
Вообще ситуация сложная и в деталях выглядит ещё сложенее, т.к. могут применяться разные уровни изоляции. Это простой пример как это работает, и почему так, а не иначе.
Ф1 — проверяет данные
Ф2 — сохраняет их
Метод М1 обернут в транзакцию. Выглядит это как-то так:
метод М1()
{
НачалоТранзакции();
Ф1();
Ф2();
КонецТранзакции();
}
Предположим пользователь П1 вызвал метод М1. В проверке Ф1 у него возникло исключение, транзакция откатилась, никакие данные не сохранились, а пользователю пишел вопрос «Хотите продолжить, или отменить». Он жмет допустим продолжить и передает дополнительно к вызову идентификатор исключения, которое свалило выполнение в последний раз. Теперь исключение по этому идентификатору будет пропускаться, и таким образом метод отработает от начала и до конца, отработает Ф1 с проверкой и выполнится Ф2. После этого транзакция успешно завершится.
В такой ситуации если пользователь П2 конкурентно запустит метод М1, то у него не получится завершить транзакцию, т.к. уровень изоляции ему это запретит, ибо данные были изменены в другой транзакции пользователем П1.
Вот если на пальцах то, что предложил автор.
Таким образом получается имитация stateful поведения там, где это сложно достижимо по честному, например в многопользовательской системе (на тысячи пользователей), которая работает с огромным объемом данных, методы блокируют миллионы записей в десятках таблиц.
Как-то так.
Ф1 — проверяет данные, Ф2 — сохраняет их.
Тогда между вызовом метода Ф1 и Ф2 есть некоторое время, в которое другой пользователь может так же выполнить какие-то действия, которые сделают данные, сохраненные в Ф2 некорректными.
Предположим работает 2 пользователя: П1 и П2. Оба они запускают метод М1 (который разбит на 2 части, Ф1 и Ф2).
Пользователь П1 проверил свои данные методом Ф1, проверка прошла. Сразу за этим пользователь П2 проверил свои данные методом Ф1, у него тоже все Ок. Далее пользователь П1 сохранил данные методом Ф2, его данные валидны. А вот когда то же начал делать пользователь П2, произойдет что-то плохое, ведь П1 изменил данные, соответственно П2 сохраняет методом Ф2 уже не то, что проверила его проверка Ф1.
Таким образом и проверка и сохранение должны быть в одной транзакии, чтоб не допустить самой возможности неверного сохранения.
Вообще это основы основ работы с данными, и как бы суть транзакционности.
P/S Когда увидел := аж всплакнул, настальгия, эх…
Мне кажется, или предложение на момент публикации на хабре уже не актуально?
Ещё можно их посадить лицом к окнам (или стенам), тогда шум будет чуть меньше распространяться.
И не забывайте, человек в наушниках на оба уха не слышит как громко он говорит. По этому закупите гарнитуры на одно ухо. Если этого ещё не сделано, то возможно этой меры будет достаточно.
Проведите беседу с персооналом, объясните им что посылать менеджера в переговорную, если ему что-то надо — это нормально. Многие просто бояться попросить коллег перенести свой затянувшийся митинг куда-то по дальше от рабочего места. У вас в команде есть иерархия, так соберите представителей среднего звена и дайте им поручение — гонять всех громкоговорунов в переговорные, аля такие полицаи. Никаких санкций, просто «Василий, вы громко говорите, может лучше обсудить это в переговорной, ребятам сложно сосредоточится из-за шума». Через месяц-два все сами будут отлучаться в переговорку (ведь там можно ещё и про жизнь поболтать, про грудь девушки на ресепшене, про то, что Машка в чулках, небось собирается куда вечером… весна. В общем в переговорках свой профит, надо просто продемонстрировать его, дать распробовать).
Когда в кабинете больше 5-7 человек, то пора уже вводить правило тишины. Т.е. никаких «Здорова ребят, я пришел!!!». Вообще это удар по тим билдингу, но производительность важнее. Нужен инструктаж с объяснением, мол «если вы опаздываете, то ребята, не стоит здороваться, кричать на весь кабинет и все такое, после 9-20 все что говорится громко — говорится в переговорной». Никаких санкций. Кто не поймет — через неделю собрать отдельно, поговорить снова. Через месяц можно начать делать замечания, но это едва ли потребуется. Можете для профилактики стребовать объяснительные с опаздавших. Хоть это и демотивирует, и делает приход на работу вовремя важнее работы, но если не увлекаться, то выйдет сбить неудержную радость от встречи с коллективом и желание крикнуть «Я пришел, всем привет!». Но это крайняя мера, прибегая к ней вы теряете лояльность сотрдников и их инициативу в работе.
Задумайтесь над пересадкой отделов, которым свойственно много говорить в отдельное пространство, либо выделение им коробки, перегородки, ещё чего такого. Очень сложно заткнуть аналитика, у него работа такая — со всеми говорить и все уточнять, по этому стоит держать этих ребят отдельно. Возможно с дизайнерами та же фигня.