Чтобы провести встречу у доски, надо оторвать человека от работы. И часто это не ограничивается двумя людьми для принятия решения. Значит, надо прервать работу N человек
Встреча у доски работает далеко не всегда. Уровень вовлеченности будет падать с ростом количества участников
Эффективность рассматривается только с точки зрения донесения информации, но не с точки зрения времени, денег, удобства и тд.
По каждому критерию ставится оценка по 100-бальной шкале.
Судя по тексту, оценка ставится не группой, участвующей в исследовании, а самим автором статьи. Соответственно, она субъективна.
🔹 Личная встреча с возможностью визуализации (у доски), несмотря на появление множества альтернатив, до сих пор остается наиболее эффективным способом коммуникации.
И поэтому данный вывод точно также является лишь мнением автора, а не подтвержденным фактом. То есть, вроде бы есть и ссылка на источники, но оценка не от них.
Да, поразгонять у доски круто. Но необязательно это будет максимально эффективно. И далеко не для всех команд.
Факты предоставили те самые операторы связи, которые жаловались, что из-за звонков в мессенджерах у них доходы падают? Интернет все помнит! Ну да, ведь так плохо, что люди перестали платить за звонки, а тем более - за роуминг! Ой, простите, все из-за мошенников, что это я.
Начало вроде неплохое, валидные замечания, требования. Но дальше есть ощущение, что энтузиазм автора закончился.
Базы данных. Например — PostgreSQL. Различные принципы и протоколы общения — rest, http, grpc. Принципы асинхронного взаимодействия — jms, kafka.
Как jms и rest относятся к базам данных? Конечно, за уши связь можно притянуть, но это совершенно разные темы.
С другой стороны, если разбираются протоколы взаимодействия, то не хватает и понимания app серверов. То есть, надо понимать, где заканчивается дефолтный Tomcat и начинаются всякие Jetty и прочее.
Вспомогательные инструменты. Например, git
В целом, конечно, middle без git невозможен. Но ушли те времена, когда джуны не знакомились с гитом и сборщиками. Впрочем, знать надо. Но не просто гит, а стратегии ветвления, например.
Также при обилии требований к софтам, не хватает требований к пониманию работы jvm, общего понимания работы с памятью, gc и тд.
И тут компании из примера выше сталкиваются с реальностью. Оказывается, что часто готовы работать за меньшую зарплату те, кто не умеет столько, чтобы устроиться в Москве и Питере. И выясняется, что это не толковый специалист, а остатки рынка.
Да, тут есть исключения. Явно будут находиться скиловые люди, которые будут работать за меньше денег. Но это именно, что исключение.
Да, я потому и пишу, что тут решение из разряда it depends. Не хватает более широкого обоснования, почему принимается именно такой выбор.
Понятно, что тут больше книга рецептов, но вероятно из нее надо убрать общепринятые принципы, а сосредоточиться на персональных, но более глубоко. Либо писать несколько статей.
В принципе, неплохой свод правил для себя. Но, как и написано в начале статьи, есть вещи как спорные, так и имеющие не совсем правильное обоснование.
Я думаю, что у этой статьи будет ряд читателей с не очень большим опытом, но находящихся в поиске конвенций. И они могут начать просто копировать все написанное, не вникая в обоснование. Именно поэтому стоит в каждом из пунктов разобрать, что же он реально под собой имеет. Тем более, что большинство пунктов - это общепринятые дизайн и архитектурные принципы.
В DI подставляем реализации, а не интерфейсы
Выше уже написали об этой проблеме. DI на то и DI, чтобы была возможность легко подменять реализации. Конечно, при наличии небольшого набора зависимостей оно проще читается.
Не надо пробрасывать в классы весь контейнер целиком
Почему? Тут есть утверждение без доказательства.
5. Чем меньше методов в интерфейсе, тем лучше.
Большие интерфейсы сложнее поддерживать и реализовать. Нарушается принцип единственной ответственности.
Тут нарушается не SRP, а ISP. SOLID явно определяет принцип разделения интерфейсов.
В интерфейсах указываем какие exception могут быть выброшены
Весьма общее требование. Например, в слое адаптеров реализуется обращение к мессенджерам. По-хорошему, мессенджеров может быть много, они будут добавляться. Допустим, у нас есть задача рассылать в Slack, Telegram, WhatsApp и еще куда-то. У каждого мессенджера может быть, скажем, внешняя библиотека со своими кастомными исключениями. Перечислять их все в интерфейсе клиента и пополнять каждый раз?
Используем strict_types=1. Типы указываем максимально жестко.
Чтобы что? Опять же, утверждение без доказательства. Понятно, что это полезно, но те, кто будут читать статью, могут не понимать причин. Получается, что будет просто бездумный копипастинг правила.
Если аргументов много - значит метод выполняет слишком много действий
Эта штука идет из "Чистого кода" Роберта Мартина. Принятие более 3 аргументов еще не означает, что метод обязательно нарушает SRP. Тут утверждение очень общее. Присмотреться к такому методу при рефакторинге, разумеется, стоит. Тут уже речь о code smell. Вероятно, стоит заменить параметры вызовами внутри или передачей объекта.
Но иногда избавление от параметров может привести к усилению связанность между классами.
Не мутировать объекты переданные в метод/функцию
Так тут проблема скорее в том, что мутировать объекты в принципе можно. Свойства и методы в публичном доступе - это доступный контракт. Значит, либо его забыли инкапсулировать, либо к нему таки можно обращаться.
Заполнение DTO через конструктор с именованными аргументами
Вот тут про читабельность могу поспорить. Пихать в конструктор сразу же и определение свойств - такое себе. Имхо, спорное нововведение. Ведь так в одном полотне и определение свойств, и типы, и дефолтные значения, и конструктор. И вообще, что мешает навесить readonly вне конструктора?
Класс меньше ~150 строк, метод меньше ~30 строк. Это значительно упрощает чтение кода.
Классы и методы не должны определять свое качество количеством строк. Они должны руководствоваться принципами, такими, как, например, SOLID, GRASP. Да, как я писал выше, размер класса - это повод к нему присмотреться. Но не повод сразу идти его рефакторить.
На любой код обязательно пишем unit тест
Тут рекомендую почитать вот эту статью. "Обязательно" - термин огульный. 100% покрытия в хотя бы среднем проекте не будет. Да оно и не требуется. Особенно, если помимо unit-тестов есть другие составляющие пирамиды тестирования.
15. Композиция, а не наследование
Собственно, тут бы читателям статьи привести ссылки на примеры, когда это плохо.
По умолчанию указываем final для классов
И еще пара полезных статей: раз, два. И рекомендую обратить внимание вот на этот комментарий
В конфронтации удаленка vs офис победителем будет вариант "не навязывать сотруднику формат присутствия", если работа идет нормально.
Единый формат для всех будет резать конверсию найма, создавать демотивацию для тех, кто не хочет работать в другом формате. Но это, разумеется, требует определенного уровня зрелости как со стороны работодателя, так и со стороны работника.
Большинство на Joomla-сайтах не занимаются вопросами безопасности вообще
Это же не делает материал сам по себе сложным :) Вы рассказываете о базовых вещах.
Заголовки и CSP - это не ноу-хау, а вполне себе фундаментальные вещи, которые изучаются не то, что гуглением, а просто чтением мануалов и спецификаций.
Я бы рекомендовал тут ставить самый простой уровень сложности, потому что эта статья будет полезна как туториал для джунов.
А сложность материала тут точно определена правильно? Настройка плагина в CMS - это явно материал уровня Tutorial для тех, кто недавно узнал, что такое header.
Думаю, что это может быть полезно для тех, кто прям работает с Joomla, но это явно не "сложный" материал.
Если бы вы добавили ссылку на мой профиль в соцсети, то получили бы ровно тот же результат
Что для начала не так уж и плохо, если нет опыта сочинения специфических cover letters. Получается некий скелет, который можно уже под себя допилить. К сожалению, большинство результатов требует доработки высокоточным напильником.
Но вот замечание про отличия 3 и 4 версий вполне валидное. Спасибо! Надо будет по подписке потестировать.
то есть в выборе "запрограммировать за 1 час в знакомой среде" или "выучить новую систему no code и запрограммировать за 10 минут" вы предпочитаете второй вариант?
Допустим, у Вас есть стартап, которому надо рассылать триггерные письма по своим пользователям. В стартапе есть 1-2 программиста с очередью задач. Благодаря no code можно выделить более дорогостоящий ресурс на более приоритетные задачи, а триггерную рассылку сделать через систему no-code.
Да и интерфейсы систем интеграции, которые я встречал, не требуют глубокого изучения. Поэтому с ними достаточно один раз познакомиться, чтобы опять же не уводить простые задачи на уровень разработки, которая всяко будет стоить дороже.
Если мы говорим про более крупные проекты и команды, то выбор уже не столь очевиден, да. Но все сводится к математике расходов и доходов.
то есть писать проект пять недель, например, чтобы потом начать с нуля писать на конкретном языке?
Если на low-code платформе проект надо писать пять недель, а мы опять же рассматриваем вариант с небольшой командой, к примеру, то скорее всего разработка точно займет больше пяти недель. Потому что надо обеспечить среды разработки, архитектуру, наблюдаемость, тесты и тд.
Если no code предоставляет всё то же самое
No code - он как кредит. В определенных условиях он может оказаться выгоден. А иногда - разрушителен для собственного бюджета.
Да, языки программирования гибки, но не стоит забывать стоимость этой самой разработки по отношению к доходам.
Разумеется. Но есть решения, где дальше «крестиков за ноликом» и не нужно. Понятно, что есть ряд систем, которые вырастают в потребность полноценного кода. Но так бывает не всегда.
Тут проблематика состоит в том, чтобы вовремя уловить момент, при котором нужно перейти от «мышки» к полноценному программированию.
Простите, но исследование просто рисует те цифры, которые захотелось нарисовать.
Статья называется "зарплаты IT-управленцев", но география исследования достаточно узкая. В ней архитектор может и получает больше, чем CIO. Но давайте говорить по-честному - распределение доходов в РФ по гео не носит характер гауссовского.
Отсюда мы получаем, что название статьи не очень-то соответствует содержанию.
Также в статистике из 2500 респондентов совершенно непонятно, сколько было опрошено тимлидов, а сколько - директоров.
Нисколько не отрицаю, что архитекторы и лиды важны. Но вот достоверность результатов исследования вызывает вопросы.
Кажется, это исследование не обладает полнотой
Чтобы провести встречу у доски, надо оторвать человека от работы. И часто это не ограничивается двумя людьми для принятия решения. Значит, надо прервать работу N человек
Встреча у доски работает далеко не всегда. Уровень вовлеченности будет падать с ростом количества участников
Эффективность рассматривается только с точки зрения донесения информации, но не с точки зрения времени, денег, удобства и тд.
Судя по тексту, оценка ставится не группой, участвующей в исследовании, а самим автором статьи. Соответственно, она субъективна.
И поэтому данный вывод точно также является лишь мнением автора, а не подтвержденным фактом. То есть, вроде бы есть и ссылка на источники, но оценка не от них.
Да, поразгонять у доски круто. Но необязательно это будет максимально эффективно. И далеко не для всех команд.
Факты предоставили те самые операторы связи, которые жаловались, что из-за звонков в мессенджерах у них доходы падают? Интернет все помнит! Ну да, ведь так плохо, что люди перестали платить за звонки, а тем более - за роуминг! Ой, простите, все из-за мошенников, что это я.
Начало вроде неплохое, валидные замечания, требования. Но дальше есть ощущение, что энтузиазм автора закончился.
Как jms и rest относятся к базам данных? Конечно, за уши связь можно притянуть, но это совершенно разные темы.
С другой стороны, если разбираются протоколы взаимодействия, то не хватает и понимания app серверов. То есть, надо понимать, где заканчивается дефолтный Tomcat и начинаются всякие Jetty и прочее.
В целом, конечно, middle без git невозможен. Но ушли те времена, когда джуны не знакомились с гитом и сборщиками. Впрочем, знать надо. Но не просто гит, а стратегии ветвления, например.
Также при обилии требований к софтам, не хватает требований к пониманию работы jvm, общего понимания работы с памятью, gc и тд.
> не готов ли кто из моего окружения перебраться на несколько сотен километров юговосточнее
Логично, что рынок в регионах будет по количеству спецов достаточно узким. Но так можно его расширить, если нанимать на удаленную работу.
Да, она возможно не везде. Особенно, если надо у станка стоять. Но большинство IT-служб вполне переводятся на удаленку.
И тут компании из примера выше сталкиваются с реальностью. Оказывается, что часто готовы работать за меньшую зарплату те, кто не умеет столько, чтобы устроиться в Москве и Питере. И выясняется, что это не толковый специалист, а остатки рынка.
Да, тут есть исключения. Явно будут находиться скиловые люди, которые будут работать за меньше денег. Но это именно, что исключение.
Осмелюсь предположить, основываясь вот на этом факте
что причиной проблемы являются так называемые "региональные зарплаты".
Компании придумали, что можно платить не в Москве и Питере меньше, потому что в условном Омске по их мнению дешевле жить.
Да, я потому и пишу, что тут решение из разряда it depends. Не хватает более широкого обоснования, почему принимается именно такой выбор.
Понятно, что тут больше книга рецептов, но вероятно из нее надо убрать общепринятые принципы, а сосредоточиться на персональных, но более глубоко. Либо писать несколько статей.
В принципе, неплохой свод правил для себя. Но, как и написано в начале статьи, есть вещи как спорные, так и имеющие не совсем правильное обоснование.
Я думаю, что у этой статьи будет ряд читателей с не очень большим опытом, но находящихся в поиске конвенций. И они могут начать просто копировать все написанное, не вникая в обоснование. Именно поэтому стоит в каждом из пунктов разобрать, что же он реально под собой имеет. Тем более, что большинство пунктов - это общепринятые дизайн и архитектурные принципы.
Выше уже написали об этой проблеме. DI на то и DI, чтобы была возможность легко подменять реализации. Конечно, при наличии небольшого набора зависимостей оно проще читается.
Почему? Тут есть утверждение без доказательства.
Тут нарушается не SRP, а ISP. SOLID явно определяет принцип разделения интерфейсов.
Весьма общее требование. Например, в слое адаптеров реализуется обращение к мессенджерам. По-хорошему, мессенджеров может быть много, они будут добавляться. Допустим, у нас есть задача рассылать в Slack, Telegram, WhatsApp и еще куда-то. У каждого мессенджера может быть, скажем, внешняя библиотека со своими кастомными исключениями. Перечислять их все в интерфейсе клиента и пополнять каждый раз?
Чтобы что? Опять же, утверждение без доказательства. Понятно, что это полезно, но те, кто будут читать статью, могут не понимать причин. Получается, что будет просто бездумный копипастинг правила.
Эта штука идет из "Чистого кода" Роберта Мартина. Принятие более 3 аргументов еще не означает, что метод обязательно нарушает SRP. Тут утверждение очень общее. Присмотреться к такому методу при рефакторинге, разумеется, стоит. Тут уже речь о code smell. Вероятно, стоит заменить параметры вызовами внутри или передачей объекта.
Но иногда избавление от параметров может привести к усилению связанность между классами.
Так тут проблема скорее в том, что мутировать объекты в принципе можно. Свойства и методы в публичном доступе - это доступный контракт. Значит, либо его забыли инкапсулировать, либо к нему таки можно обращаться.
Вот тут про читабельность могу поспорить. Пихать в конструктор сразу же и определение свойств - такое себе. Имхо, спорное нововведение. Ведь так в одном полотне и определение свойств, и типы, и дефолтные значения, и конструктор. И вообще, что мешает навесить readonly вне конструктора?
Классы и методы не должны определять свое качество количеством строк. Они должны руководствоваться принципами, такими, как, например, SOLID, GRASP. Да, как я писал выше, размер класса - это повод к нему присмотреться. Но не повод сразу идти его рефакторить.
Тут рекомендую почитать вот эту статью. "Обязательно" - термин огульный. 100% покрытия в хотя бы среднем проекте не будет. Да оно и не требуется. Особенно, если помимо unit-тестов есть другие составляющие пирамиды тестирования.
Собственно, тут бы читателям статьи привести ссылки на примеры, когда это плохо.
И еще пара полезных статей: раз, два. И рекомендую обратить внимание вот на этот комментарий
О том и говорю) Довольно забавно читать про всякий «cloud native» с балансировщиками и трейсами, но с морально устаревшим веб-сервером под капотом.
Если отправить на веб-сервер больше 10 запросов, он ложится? /sarcasm_mod_off
В конфронтации удаленка vs офис победителем будет вариант "не навязывать сотруднику формат присутствия", если работа идет нормально.
Единый формат для всех будет резать конверсию найма, создавать демотивацию для тех, кто не хочет работать в другом формате. Но это, разумеется, требует определенного уровня зрелости как со стороны работодателя, так и со стороны работника.
Это же не делает материал сам по себе сложным :) Вы рассказываете о базовых вещах.
Заголовки и CSP - это не ноу-хау, а вполне себе фундаментальные вещи, которые изучаются не то, что гуглением, а просто чтением мануалов и спецификаций.
Я бы рекомендовал тут ставить самый простой уровень сложности, потому что эта статья будет полезна как туториал для джунов.
А сложность материала тут точно определена правильно? Настройка плагина в CMS - это явно материал уровня Tutorial для тех, кто недавно узнал, что такое header.
Думаю, что это может быть полезно для тех, кто прям работает с Joomla, но это явно не "сложный" материал.
Что для начала не так уж и плохо, если нет опыта сочинения специфических cover letters. Получается некий скелет, который можно уже под себя допилить. К сожалению, большинство результатов требует доработки высокоточным напильником.
Но вот замечание про отличия 3 и 4 версий вполне валидное. Спасибо! Надо будет по подписке потестировать.
Допустим, у Вас есть стартап, которому надо рассылать триггерные письма по своим пользователям. В стартапе есть 1-2 программиста с очередью задач. Благодаря no code можно выделить более дорогостоящий ресурс на более приоритетные задачи, а триггерную рассылку сделать через систему no-code.
Да и интерфейсы систем интеграции, которые я встречал, не требуют глубокого изучения. Поэтому с ними достаточно один раз познакомиться, чтобы опять же не уводить простые задачи на уровень разработки, которая всяко будет стоить дороже.
Если мы говорим про более крупные проекты и команды, то выбор уже не столь очевиден, да. Но все сводится к математике расходов и доходов.
Если на low-code платформе проект надо писать пять недель, а мы опять же рассматриваем вариант с небольшой командой, к примеру, то скорее всего разработка точно займет больше пяти недель. Потому что надо обеспечить среды разработки, архитектуру, наблюдаемость, тесты и тд.
No code - он как кредит. В определенных условиях он может оказаться выгоден. А иногда - разрушителен для собственного бюджета.
Да, языки программирования гибки, но не стоит забывать стоимость этой самой разработки по отношению к доходам.
Разумеется. Но есть решения, где дальше «крестиков за ноликом» и не нужно. Понятно, что есть ряд систем, которые вырастают в потребность полноценного кода. Но так бывает не всегда.
Тут проблематика состоит в том, чтобы вовремя уловить момент, при котором нужно перейти от «мышки» к полноценному программированию.
Это тоже вполне вероятно. Собственно, никто не говорит, что это серебряная пуля. И проверять за тем, что было нагенерировано, точно надо.
Без проблем) Я заодно решил сам себя перепроверить в тексте, так как с утверждением о разнице полностью согласен.
Да, тег тут огульно поставлен, поправлю. В статье вроде бы знака равенства я не указывал :)
Простите, но исследование просто рисует те цифры, которые захотелось нарисовать.
Статья называется "зарплаты IT-управленцев", но география исследования достаточно узкая. В ней архитектор может и получает больше, чем CIO. Но давайте говорить по-честному - распределение доходов в РФ по гео не носит характер гауссовского.
Отсюда мы получаем, что название статьи не очень-то соответствует содержанию.
Также в статистике из 2500 респондентов совершенно непонятно, сколько было опрошено тимлидов, а сколько - директоров.
Нисколько не отрицаю, что архитекторы и лиды важны. Но вот достоверность результатов исследования вызывает вопросы.