А разве смысл этих (ваших) стендапов не в том, чтобы выносить на них проблемы и блокеры и как-то отрабатывать? Надо молчать о том, что Петя никак не доделает фичу и вы заблокированы?
Менее прозрачно, но всё-таки, если Вася классный специалист и это досадное недоразумение, то почему потребовалась помощь коллеги для исправления?
На мой взгляд ИТ-директор, не конкретизирующий ни заданный расплывчатый вопрос ни свой на него ответ близок к неадекватности занимаемой должности в части коммуникативных навыков. И тенденциозные вопросы тут совершенно не при чем.
ИМХО конкретно в таком кейсе не тактики ответной борьбы с ловушками надо изучать, а над коммуникациями своими ИТ-директору стоит поработать.
Судя по ответу «в течение недели» проблемы таки есть и они признаются и даже в работе. Но это очень странно на мутный вопрос отвечать конкретным сроком, тем более ИТ-директору.
На мой взгляд корректный ответ от ИТ-директора главбуху может быть какой-то такой:
Мы полностью исполняем согласованные с Вами SLA и проектные планы, в которых сказано, как быстро мы должны решать возникающие с программой проблемы, если это не так, прошу назвать конкретные факты, если требуется другой SLA или новый проект по доработке системы, то давайте его обсудим отдельно.
Когда я работал ИТ-директором, особенно поначалу, то на каждом совещании приходилось держать ухо востро. Спросит какой-нибудь главный бухгалтер, совершенно будничным голосом: «когда будут устранены проблемы в программе?». Ляпнешь «в течение недели» - всё, пиши пропало.
На мой взгляд довольно странно приравнивать программиста и ИТ-директора. И думаю вопрос в данном случае был про общий уровень ИТ-сервиса, за который вроде бы ИТ-директор и должен отвечать. Но интересно, что было в Вашем случае, как это всё в итоге разрешалось.
То что БД развели - это важный шаг от "распределенного монолита".
Однако единый npm-пакет с интерфейсами и общение через HTTP - на мой взгляд идут в "минус".
Например по HTTP, классический сценарий - один сервис вызвал другой, тот третий, а третий решил немного "подумать", вся цепочка начинает просаживаться по ресурсам или перестаёт выполнять свои функции.
Что за потребность такая сэкономить 3Гб ценой организационных ограничений при наличии нескольких команд? Экономическая целесообразность этого шага, на мой взгляд, сильно отрицательная.
Если слово «программисты» заменить на любых других реализаторов галлюцинаций менеджмента, то в сути статьи не поменяется ничего. Так стоит ли выносить в заголовок программистов?
Это примерно как разница — попать в мишень 50х50см с вероятностью 50% или попасть в круг диаметром 1см в центре мишени с вероятностью 50% — там и там 50%, но второе существенно сложней.
> загустевший раствор по технологии можно продолжать использовать при добавлении воды и перемешивании (те же миксеры так и делают, пока доставят до точки).
Прочность и морозостойкость падает у раствора/бетона. Нет такой «технологии», по которой так можно делать, если нет достаточного запаса по характеристикам бетона.
> Когда раствор подсыхал, становился более вязким, Костя и Рустам останавливали работу и требовали заказать следующий цементовоз. Дядя Толя просто звал нас, разнорабочих, и говорил – ребятки, пару вёдер воды плесните, и лопатами, лопатами поработайте (бетономешалки не было).
Насколько знаю 4 ведра воды на 6м3 бетона превращают марку М400 в М350. 8 ведер в марку М300. И так далее. Еще более стремительно снижается морозостойкость.
Дядя Толя конечно большой талант в стройке. Зато окно по чертежу.
Особенно печально, если в ходе строительства таких талантов набирается 3-4 подряд и наносимый ущерб перестаёт компенсироваться запасом прочности.
50% это может быть как «пальцем в небо», так и достаточно точно, надо смотреть суть показателя. Потому что одно дело если с 50% вероятностью сбывается прогноз «в июле 2022 в этой области будет от 50 до 100мм осадков» и совершенно другое, если «в июле 2022 в этом посёлке будет от 66 до 70мм осадков»
Ну и конечно они сильно ограничены средствам сбора первичной информации и вычислительными мощностями, а уже во вторую очередь — методиками прогнозирования.
> Иногда наши ожидания возможностей системы не всегда совпадают с реальностью. И в этом случае следует очень глубоко анализировать получаемые данные. Возможно стоит пересмотреть критерии оценки работоспособности системы, использовать другие метрики для ее измерения.
Т.е. не надо делать адекватные требования изначально, надо гибко их менять в зависимости от получаемых результатов?
> В свете динамических развивающихся framework’ов (react, angular, node, sping и др.), не всегда стоит их применять для разработки продуктов. Порой javascript будет работать намного эффективнее, чем что-то еще. Необходимо инструменты реализации подбирать под задачу, и думать как ваша система будет работать.
При чем тут вообще фреймворки? Проблема была не в них, а в том, какие МЕТОДЫ взаимодействия клиент-сервер были выбраны. В том числе странно, что не применяли CDN при таких требованиях. Почему бы не сделать максимально разгруженное взаимодействие с бекендом и фронтовое приложение в CDN?
По сути вопроса такая мысль — пора какой-то отдельный трактат выпускать о том, как SOLID и DRY принципы НЕ надо применять при разработке микросервисов.
Особенно забавно работает DRY в примерно таких ситуациях:
«о да тут же одинаковая задача в разных микросервисах — хранение настроек»
Уровень ужаса №1 — давайте запилим отдельный микросервис хранения настроек для всего
Уровень ужаса №2 — давайте запилим единый подход и библиотеку, по дороге выпуская релизы с breaking changes из-за того что нужно новые фичи добавить для каких-то отдельных пользователей настроек (нужные только 1-2 микросервисам).
А разве смысл этих (ваших) стендапов не в том, чтобы выносить на них проблемы и блокеры и как-то отрабатывать? Надо молчать о том, что Петя никак не доделает фичу и вы заблокированы?
Менее прозрачно, но всё-таки, если Вася классный специалист и это досадное недоразумение, то почему потребовалась помощь коллеги для исправления?
На мой взгляд ИТ-директор, не конкретизирующий ни заданный расплывчатый вопрос ни свой на него ответ близок к неадекватности занимаемой должности в части коммуникативных навыков. И тенденциозные вопросы тут совершенно не при чем.
ИМХО конкретно в таком кейсе не тактики ответной борьбы с ловушками надо изучать, а над коммуникациями своими ИТ-директору стоит поработать.
Судя по ответу «в течение недели» проблемы таки есть и они признаются и даже в работе. Но это очень странно на мутный вопрос отвечать конкретным сроком, тем более ИТ-директору.
На мой взгляд корректный ответ от ИТ-директора главбуху может быть какой-то такой:
Мы полностью исполняем согласованные с Вами SLA и проектные планы, в которых сказано, как быстро мы должны решать возникающие с программой проблемы, если это не так, прошу назвать конкретные факты, если требуется другой SLA или новый проект по доработке системы, то давайте его обсудим отдельно.
На мой взгляд довольно странно приравнивать программиста и ИТ-директора. И думаю вопрос в данном случае был про общий уровень ИТ-сервиса, за который вроде бы ИТ-директор и должен отвечать. Но интересно, что было в Вашем случае, как это всё в итоге разрешалось.
То что БД развели - это важный шаг от "распределенного монолита".
Однако единый npm-пакет с интерфейсами и общение через HTTP - на мой взгляд идут в "минус".
Например по HTTP, классический сценарий - один сервис вызвал другой, тот третий, а третий решил немного "подумать", вся цепочка начинает просаживаться по ресурсам или перестаёт выполнять свои функции.
Дайте угадаю, у вас еще и БД общая и микросервисы общаются друг с другом напрямую, а не разавязаны через какую-нибудь кафку?
Что за потребность такая сэкономить 3Гб ценой организационных ограничений при наличии нескольких команд? Экономическая целесообразность этого шага, на мой взгляд, сильно отрицательная.
Прочность и морозостойкость падает у раствора/бетона. Нет такой «технологии», по которой так можно делать, если нет достаточного запаса по характеристикам бетона.
Насколько знаю 4 ведра воды на 6м3 бетона превращают марку М400 в М350. 8 ведер в марку М300. И так далее. Еще более стремительно снижается морозостойкость.
Дядя Толя конечно большой талант в стройке. Зато окно по чертежу.
Особенно печально, если в ходе строительства таких талантов набирается 3-4 подряд и наносимый ущерб перестаёт компенсироваться запасом прочности.
Я уже хочу в эту параллельную вселенную.
> Проще всего начинать с Python и JavaScript. Но если вы начнёте с языка C, то это даст вам больше преимуществ.
Стоило только сразу сказать, чем и в каком объеме придётся заплатить за эти преимущества.
Ну и конечно они сильно ограничены средствам сбора первичной информации и вычислительными мощностями, а уже во вторую очередь — методиками прогнозирования.
Грубо говоря фреймворк — это то, что вы используете для создания программы, а рантайм — это то, на чем исполняются ваши программы.
Т.е. не надо делать адекватные требования изначально, надо гибко их менять в зависимости от получаемых результатов?
> В свете динамических развивающихся framework’ов (react, angular, node, sping и др.), не всегда стоит их применять для разработки продуктов. Порой javascript будет работать намного эффективнее, чем что-то еще. Необходимо инструменты реализации подбирать под задачу, и думать как ваша система будет работать.
При чем тут вообще фреймворки? Проблема была не в них, а в том, какие МЕТОДЫ взаимодействия клиент-сервер были выбраны. В том числе странно, что не применяли CDN при таких требованиях. Почему бы не сделать максимально разгруженное взаимодействие с бекендом и фронтовое приложение в CDN?
PS: Node.js это не фреймворк.
Особенно забавно работает DRY в примерно таких ситуациях:
«о да тут же одинаковая задача в разных микросервисах — хранение настроек»
Уровень ужаса №1 — давайте запилим отдельный микросервис хранения настроек для всего
Уровень ужаса №2 — давайте запилим единый подход и библиотеку, по дороге выпуская релизы с breaking changes из-за того что нужно новые фичи добавить для каких-то отдельных пользователей настроек (нужные только 1-2 микросервисам).