А что, рефлексировать над своей головой и, если само не идёт, то обратиться к психологу -- это что-то неочевидное?
А вот шелуха про "инсайты", "другим человеком", "стал счастлив" -- вот это похоже на инфоцыганскую труху. Как будто человек пытается себя убедить в этом.
Может быть проблема не в e2e тестах, а в том, что пишут их иногда левой пяткой, что ведет к сложной поддержке, поломкам и т.п.
Наверное не открою Америку, если скажу, что хороший фреймворк интеграционного тестирования -- это такой же программный продукт как и то, что он тестирует. И требования к качеству кода, архитектуре и документации у него, соответственно, должны быть такими же строгими. Тогда и ломаться раз в день не будет и поддержка станет легче.
Согласен с автором в том, что все надо оценивать с позиции стоимости (написания и поддержки) и ценности (сэкономленное время QA и разработчиков, стабильность продукта), но тезис "не автоматизируйте test cases" явно неверный. Правильно: думайте, прежде чем автоматизировать, а если автоматизируете - то делайте это хорошо.
На деле такое стимулирование ведет к снижению качества. Зачем делать делать хорошие машины, если
а) плохие все равно купят (принудительное импортозамещение)
б) купят по цене хороших, а то и дороже (преференции при госзакупках)?
По акциям кроме изменения их стоимости еще полагаются дивиденды, которые зависят от прибыли и влияют на стоимость акций. Так что вы не правы, связь между работой компании (ее прибыльностью) и стоимостью акций все же есть.
Вы неверно понимаете скрам (как и многие). Скрам это не про «обсуждаем раз в день project state из под палки», а про «все могут высказать свое мнение, помочь друг другу найти лучшее решение». Скрам — это про поощрение инициативы и инноваций, гибкое принятие решений исходя из наиболее полной информации + всеобщее понимание «что» за продукт они разрабатывают.
Ну и такие банки проиграют конкуренцию со временем всяким финтех стартапам, либо будут вынуждены их за большие-большие деньги покупать. Раб на галерах и хозяин с плеткой априори обречены, потому что не эффективны (наемный труд, внезапно, намного эффективнее рабского, как и творческий подход эффективнее подхода из под палки).
Не стоит драматизировать. Если время вашего отдела не ценится и вы нужны только для авральных фиксов (которые априори не эффективны, т.к. работа, выполняемая в спешке с жесткими дедлайнами имеет довольно посредственное качество), то потеря для вас как разработчика будет не велика.
Найдете, наконец, нормальное место, где
1. Вас будут уважать
2. Вас не будут заставлять работать в аврал, потому что «кому-то очень это нужно»
Никаких проблем нет в том, чтобы поработать в аврал при некоторых условиях:
1. Дополнительная плата (овертаймы в двойном размере минимум)
2. Наличие свободного времени для этого у разработчика
Остальные мотивации, типа соответствия корп. ценностям и лояльность компании — это не более чем желание получить больше, за меньшие деньги. Надо стараться такого не позволять никому, тем более начальству.
А что, рефлексировать над своей головой и, если само не идёт, то обратиться к психологу -- это что-то неочевидное?
А вот шелуха про "инсайты", "другим человеком", "стал счастлив" -- вот это похоже на инфоцыганскую труху. Как будто человек пытается себя убедить в этом.
Хохо, так это ж Gitlab Community Edition! :)))
А есть разница? И так, и так валидно :)
Не ясно почему бы не продать/передать разработку сторонней компании или в опенсорс. Почему можно только форкнуть?
Может быть проблема не в e2e тестах, а в том, что пишут их иногда левой пяткой, что ведет к сложной поддержке, поломкам и т.п.
Наверное не открою Америку, если скажу, что хороший фреймворк интеграционного тестирования -- это такой же программный продукт как и то, что он тестирует. И требования к качеству кода, архитектуре и документации у него, соответственно, должны быть такими же строгими. Тогда и ломаться раз в день не будет и поддержка станет легче.
Согласен с автором в том, что все надо оценивать с позиции стоимости (написания и поддержки) и ценности (сэкономленное время QA и разработчиков, стабильность продукта), но тезис "не автоматизируйте test cases" явно неверный. Правильно: думайте, прежде чем автоматизировать, а если автоматизируете - то делайте это хорошо.
Автор изобрёл динамическое программирование?
UPPER CASE ни разу не способствует популяризации библиотеки… А еще FS больше напоминает File System, а не Feature Selection.
Но все равно круто, удачи вам :)
asyncio же?
а) плохие все равно купят (принудительное импортозамещение)
б) купят по цене хороших, а то и дороже (преференции при госзакупках)?
Найдете, наконец, нормальное место, где
1. Вас будут уважать
2. Вас не будут заставлять работать в аврал, потому что «кому-то очень это нужно»
1. Дополнительная плата (овертаймы в двойном размере минимум)
2. Наличие свободного времени для этого у разработчика
Остальные мотивации, типа соответствия корп. ценностям и лояльность компании — это не более чем желание получить больше, за меньшие деньги. Надо стараться такого не позволять никому, тем более начальству.