Многим нормально. Буквально говорили, что "моя хата с краю". Если сидеть в уголке, починять примус и не отсвечивать, то всё вполне себе. Стабильность, так сказать.
У меня опыт работы в конторе с "anti-toxic culture", как заявляло руководство. На деле это сводилось к тому, что "не токсичный" это 1) тот, кто ничего не требует от руководства и 2) тот, кто не генерирует НИКАКИХ конфликтов.
По очевидной логике, работники, которые горели своей деятельностью, пахали за двоих и продвигали инициативы, были массово записаны в "токсичные" и планомерно вычищены. Лучшей тактикой выживания оказалось просто ничего не делать и делать работу спустя рукава.
Как только с GovTech или FinTech работаешь, такая проблема отпадает сама собой. Потому что банк сказал вот так вот у них по бумажкам должно быть! И бюрократия им вторит. И тут внезапно оказывается, что абстрактные first & last names своим пересечением как раз покрывают требования почти всегда.
Но общей атмосфера небольшой идиотии это не отменяет, да :)
О, а я всё думал, когда же новая статья с хейтом JS? А то запаздывает по расписанию. Хорошо хоть про округление чисел в очередной раз не вспомнили.
У меня есть претензии, но не к ЯП, а к экосистеме и фронтовым "фреймворкам". Серьёзно, если сам стандарт ECMAScript и Node последние годы делают хорошие успехи (но недостаточно быстро!!!), то вот в комьюнити всё печально.
Иронично, что на сервере воцарился Nest (слава богам), а JS функции уже запихали почти во все БД, старые и новые, а на клиенте дела всё хуже и хуже. React отвратителен. Ember и Angular, к сожалению, катастрофически не популярны в СНГ, да и это просто лучшее из худшего. Vue умер и превратился в клон React. И ещё 50+ React-like библиотек.
А теперь ещё начали разрабатывать платформы. Next.js и иже с ним да будут трижды прокляты.
В целом, ужасающих масштабов раздробленность. Ну думал, что буду скучать по Backbone и Bower.
На полминуты завис над переводом "скользящее обновление", хорошо дальше дают нормальный термин в скобках. Когда уже официальные переводчики научатся не коверкать специфичные для сферы понятия? Никто же латинские названия костей или животных не переводит просто так... Либо пора бить по рукам выпускающих редакторов.
FSD - это когда авторы опять решили, что Clean Architecture слишком сложно и вообще непонятно, нужно обязательно скрыть всё это структурой папок. Попутно решили, что фронт и бэк вещи не совместимые, слои там разные, логика разная, напишем об этом прямо на главной странице и окончательно превратим идею в монстра Франкенштейна.
Вся проблема с "реальными" РПГ и геймификацией в целом в том, что она подразумевает наличие правильного пути достижения правильной цели. В реальной жизни таких условий не существует.
Радостный такой иду на сайт... А там только предзаказ... Только бумаги... Ладно, предзаказа цифры нет, но даже выпущенные книги половины нет в цифре, что глубоко печально :(
ТС путает тёплое с мягким, сначала говорит про гуманитариев, потом почему-то переключается на поведенческие паттерны, а в конце признаётся, что всех нас налюбил кликбейтным заголовком. Не будьте, как ТС.
Ну, и раз в тексте есть типичная ошибка обращения к уникальной выборке, давайте я тоже сыграю на этом поле. Я гуманитарий, за спиной филфак и истфак, в разработку попал случайно, начинал с админства сайтов, сейчас занимаюсь всяческим engineering management'ом.
Имею ровно противоположный опыт: подавляющее большинство "технарей" и всяческих выпускников профильных ВУЗов обладают максимальной психической ригидностью в том, что касается работы. В идеале, решение должно быть написано в книге, документации, докладе, в общем, зафиксировано. И вообще, "всегда делали вот ТАК, зачем делать по-другому".
Выходцев из "технарей", особенно СТО, это тоже касается. "Мы не будем пользоваться этим инструментом, потому что я когда-то пользовался, мне не понравилось, значит инструмент плохой" - сплошь и рядом встречал.
Теперь осталось опровергнуть моё личный опыт чужим личным опытом и так мы быстро доберёмся до мордобоя :)
Извините, но это просто накиданные рандомно игры с тегом "космос". И всего списка действительно похоже на SF только The Outer Worlds и, с очень большой натяжкой, Mass Effect. Можно так же отнести Немужицкое небо сюда, но это сравнение затрагивает только де необязательные активности из SF, что так же сводит сравнение на нет.
Я читал и "Мама, я тимлид!" и "Карьера Software Engineering Manager". Лично моё мнение - именно для новичка-практика "Мама" гораздо лучше. Лаконичная, конкретная, проблемно-ориентированная. Её я даю читать ребятам, кого промоутят в лиды.
А вот "Карьера" это здоровенный талмуд с текстом в лучших традициях американской школы науч-попа. Автор чрезвычайно многословен, постоянно растекается мыслью по древу и норовит свернуть в какие-нибудь исторические дебри или личные переживания по типу "когда мы были молодыми". Скажу честно, я не смог осилить её целиком и очень много просмотрел по диагонали.
Но есть вариант, когда я бы советовал именно почитать именно "Карьеру". Это отличный обзорник для HR, малоопытных CTO и прочих нанимающих менеджеров, чтобы они понимали, кто такой Software Engineering Manager сегодня и что вообще такой специалист в дикой природе существует.
Это да, это нормально :) Founding CTO, вот это вот всё. Понятное дело, что в вакансии предполагался какой-то "сформировавшийся уже" продукт, от того и странности.
Смотря что это за приложение и что именно считать бизнес логикой. Например, сложный wizard, экраны и поля которого динамически определяются на основе данных на клиенте и который должен породить некую бизнес сущность.
Бля меня глобально отличается тем, что это view-компонент конкретной библиотеки представления. Если вы пишите бизнес логику (возьмём пример с контролом паспорта выше) в таком компоненте, а потом тестируете его, то, по факту, вы пишите интеграционный тест, ведь нужно ещё эмулировать виртуальный дом, работу рантайма реактуа и тд и всё это ради чего? Чтобы проверить разметку при двух вариантах if? Вы реально сомневаетесь в способностях реакта к условному рендерингу?
Но вот код, который генерирует тот самый bool для контрола на основе входящих данных протестить хочется, но как это сделать, не делая тест на компонент реакта? Вынести логику и использовать её как сторонний сервис по отношению к компоненту.
В этом случае код автоматически разделяется по слоям, представление зависит от логики, а мы получаем маленький и простой тест.
S в SOLID означает Single Responsibility — единственная ответственность Разбивайте код на модули, каждый из которых имеет одну ответственность.
Видишь такое в статье про SOLID - можно смело пропускать. Ну, сколько можно из раза в раз повторять одну и ту же повсеместную ошибку! Я уже говорил, что такое безумие?!
Давайте просто заглянем в источник (будет локализованный вариант, да простят меня адепты английского):
Традиционно принцип единственной ответственности описывался так: Модуль должен иметь одну и только одну причину для изменения.
<...>
Фактически принцип можно перефразировать так: Модуль должен отвечать за одного и только за одного пользователя или заинтересованное лицо.
<...>
Соответственно, окончательная версия принципа единственной ответственности выглядит так: Модуль должен отвечать за одного и только за одного актора.
Неужели там нет ни слова про разделение кода на мелкие части с одной функциональностью? На самом деле, есть, прямо выше по тексту!
Самое интересное, что такой принцип действительно существует. Он гласит: функция должна делать что-то одно и только одно. Этот принцип мы используем, когда делим большие функции на меньшие, то есть на более низком уровне. Но он не является одним из принципов SOLID — это не принцип единственной ответственности.
Многим нормально. Буквально говорили, что "моя хата с краю". Если сидеть в уголке, починять примус и не отсвечивать, то всё вполне себе. Стабильность, так сказать.
Я пришёл за этим комментарием!
У меня опыт работы в конторе с "anti-toxic culture", как заявляло руководство. На деле это сводилось к тому, что "не токсичный" это 1) тот, кто ничего не требует от руководства и 2) тот, кто не генерирует НИКАКИХ конфликтов.
По очевидной логике, работники, которые горели своей деятельностью, пахали за двоих и продвигали инициативы, были массово записаны в "токсичные" и планомерно вычищены. Лучшей тактикой выживания оказалось просто ничего не делать и делать работу спустя рукава.
И опять всё свелось к "неправильным работникам" у "правильного директора".
Как только с GovTech или FinTech работаешь, такая проблема отпадает сама собой. Потому что банк сказал вот так вот у них по бумажкам должно быть! И бюрократия им вторит. И тут внезапно оказывается, что абстрактные first & last names своим пересечением как раз покрывают требования почти всегда.
Но общей атмосфера небольшой идиотии это не отменяет, да :)
Не пугайте так. Это же выглядит как совершенно настоящая новость в нынешних реалиях.
О, а я всё думал, когда же новая статья с хейтом JS? А то запаздывает по расписанию. Хорошо хоть про округление чисел в очередной раз не вспомнили.
У меня есть претензии, но не к ЯП, а к экосистеме и фронтовым "фреймворкам". Серьёзно, если сам стандарт ECMAScript и Node последние годы делают хорошие успехи (но недостаточно быстро!!!), то вот в комьюнити всё печально.
Иронично, что на сервере воцарился Nest (слава богам), а JS функции уже запихали почти во все БД, старые и новые, а на клиенте дела всё хуже и хуже. React отвратителен. Ember и Angular, к сожалению, катастрофически не популярны в СНГ, да и это просто лучшее из худшего. Vue умер и превратился в клон React. И ещё 50+ React-like библиотек.
А теперь ещё начали разрабатывать платформы. Next.js и иже с ним да будут трижды прокляты.
В целом, ужасающих масштабов раздробленность. Ну думал, что буду скучать по Backbone и Bower.
На полминуты завис над переводом "скользящее обновление", хорошо дальше дают нормальный термин в скобках. Когда уже официальные переводчики научатся не коверкать специфичные для сферы понятия? Никто же латинские названия костей или животных не переводит просто так...
Либо пора бить по рукам выпускающих редакторов.
Зато сразу видно следующий потенциальный рынок. Будет Ньютон Мини какой-нибудь.
Сделал для себя открытие на Хабре, подписался.
Написаны очень правильные вещи, которые откликаются у меня, буду ждать новостей про проект как с точки зрения бизнеса, так и с точки зрения медицины.
Успеха вам!
FSD - это когда авторы опять решили, что Clean Architecture слишком сложно и вообще непонятно, нужно обязательно скрыть всё это структурой папок. Попутно решили, что фронт и бэк вещи не совместимые, слои там разные, логика разная, напишем об этом прямо на главной странице и окончательно превратим идею в монстра Франкенштейна.
В целом, лучше бы был минус один подход.
Пока я всё это изучу, успею умереть, переродиться, как раз выйдет третий дайджест и придётся нагонять...
P.S. Спасибо, не хватало не-языковых дайдежстов!
Вся проблема с "реальными" РПГ и геймификацией в целом в том, что она подразумевает наличие правильного пути достижения правильной цели. В реальной жизни таких условий не существует.
Радостный такой иду на сайт... А там только предзаказ... Только бумаги... Ладно, предзаказа цифры нет, но даже выпущенные книги половины нет в цифре, что глубоко печально :(
ТС путает тёплое с мягким, сначала говорит про гуманитариев, потом почему-то переключается на поведенческие паттерны, а в конце признаётся, что всех нас налюбил кликбейтным заголовком. Не будьте, как ТС.
Ну, и раз в тексте есть типичная ошибка обращения к уникальной выборке, давайте я тоже сыграю на этом поле. Я гуманитарий, за спиной филфак и истфак, в разработку попал случайно, начинал с админства сайтов, сейчас занимаюсь всяческим engineering management'ом.
Имею ровно противоположный опыт: подавляющее большинство "технарей" и всяческих выпускников профильных ВУЗов обладают максимальной психической ригидностью в том, что касается работы. В идеале, решение должно быть написано в книге, документации, докладе, в общем, зафиксировано. И вообще, "всегда делали вот ТАК, зачем делать по-другому".
Выходцев из "технарей", особенно СТО, это тоже касается. "Мы не будем пользоваться этим инструментом, потому что я когда-то пользовался, мне не понравилось, значит инструмент плохой" - сплошь и рядом встречал.
Теперь осталось опровергнуть моё личный опыт чужим личным опытом и так мы быстро доберёмся до мордобоя :)
Извините, но это просто накиданные рандомно игры с тегом "космос". И всего списка действительно похоже на SF только The Outer Worlds и, с очень большой натяжкой, Mass Effect. Можно так же отнести Немужицкое небо сюда, но это сравнение затрагивает только де необязательные активности из SF, что так же сводит сравнение на нет.
Я читал и "Мама, я тимлид!" и "Карьера Software Engineering Manager". Лично моё мнение - именно для новичка-практика "Мама" гораздо лучше. Лаконичная, конкретная, проблемно-ориентированная. Её я даю читать ребятам, кого промоутят в лиды.
А вот "Карьера" это здоровенный талмуд с текстом в лучших традициях американской школы науч-попа. Автор чрезвычайно многословен, постоянно растекается мыслью по древу и норовит свернуть в какие-нибудь исторические дебри или личные переживания по типу "когда мы были молодыми". Скажу честно, я не смог осилить её целиком и очень много просмотрел по диагонали.
Но есть вариант, когда я бы советовал именно почитать именно "Карьеру". Это отличный обзорник для HR, малоопытных CTO и прочих нанимающих менеджеров, чтобы они понимали, кто такой Software Engineering Manager сегодня и что вообще такой специалист в дикой природе существует.
Это да, это нормально :) Founding CTO, вот это вот всё. Понятное дело, что в вакансии предполагался какой-то "сформировавшийся уже" продукт, от того и странности.
Смотря что это за приложение и что именно считать бизнес логикой. Например, сложный wizard, экраны и поля которого динамически определяются на основе данных на клиенте и который должен породить некую бизнес сущность.
Можете.
Бля меня глобально отличается тем, что это view-компонент конкретной библиотеки представления.
Если вы пишите бизнес логику (возьмём пример с контролом паспорта выше) в таком компоненте, а потом тестируете его, то, по факту, вы пишите интеграционный тест, ведь нужно ещё эмулировать виртуальный дом, работу рантайма реактуа и тд и всё это ради чего? Чтобы проверить разметку при двух вариантах if? Вы реально сомневаетесь в способностях реакта к условному рендерингу?
Но вот код, который генерирует тот самый bool для контрола на основе входящих данных протестить хочется, но как это сделать, не делая тест на компонент реакта? Вынести логику и использовать её как сторонний сервис по отношению к компоненту.
В этом случае код автоматически разделяется по слоям, представление зависит от логики, а мы получаем маленький и простой тест.
Видишь такое в статье про SOLID - можно смело пропускать.
Ну, сколько можно из раза в раз повторять одну и ту же повсеместную ошибку! Я уже говорил, что такое безумие?!
Давайте просто заглянем в источник (будет локализованный вариант, да простят меня адепты английского):
Неужели там нет ни слова про разделение кода на мелкие части с одной функциональностью? На самом деле, есть, прямо выше по тексту!