Сборник гайдов разных компаний с группировкой по разделам.
Даёт возможность
1)посмотреть "а как у них"
2)узнать об аспектах/проблемах которые в co-статьях редко освещаются, а на старте проекта могут быть не видны.
Скажем, что все хорошо, но есть нюансы.
Главное, что из того что написано в манифесте не всегда получается тот код, который ожидается, поэтому приходится или править манифест или править получившийся код или вкладываться в развитие генератор
во всех этих архитектурных концепциях, которые так сладки уху бизнеса, главный компонент — собрать все лавры и идти дальше прежде чем начнутся последствия этих решений
«управляемость» не повышает потому что не появляется из воздуха и соответственно добавление прокси между вызовами само по себе управляемости не добавит.
Да и визуализация межсервисных вызовов- есть широкий ассортимент инструментов трассировки.
Не обязательно вводить доп.нагрузку и точку отказа для этого.
В остальном — судя потому куда ветер дует сейчас — в service mesh — это в некотором смысле происходит «под капотом».
Думаю, тут дело не столько Вузах и программа от компаний (в конце концов этого и раньше не было и это не помешало php стать массовым), сколько в том, что да — сильные инженеры переходят на другие стеки, роль языка с быстрым стартом для новичков перехватил js (чтобы начать что-то писать на js и базовая алгоритмика -достаточно браузера) +фактор размера рынка и зарплат + "суть" проектов на рынке.
Но возможно, загляну на митап — вдруг тоже ништяк дадут
Условный бизнес "принял" ограничения и случилась "ещё одна оглушительная победа гибких методологий", продолжил бы заваливать нелепостями с приоритетом major и critical — получили бы как всегда.
Полностью разделяю эту точку зрения.
Но осознанность и идея ответственности за свои решения и их результаты — скорее "не популярна". Об этом много любят говорить, бравировать, но как дело доходит до принятия негативного результата — виноват кто-то/что-то.
Ну и плюс — у нас как ни крути достаточно "молодая" отрасль и инфантов здесь хоть отбавляй, даже в возрасте 30+.
+Ситуация на рынке, что даже самый расположений инфантильный говнокодер на java — сможет получить достаточно предложений работы чтобы выбирать среди них.
Unitесты и тдд экономят время на нескольких этапах:
1)на этапе разработки: сидеть в отладке получается гораздо быстрее чем раз за разом запускать систему и подводить к нужному состоянию.
2) на этапе украшательства: когда работающий лапшекод хочется немного подписать перед коммитом.
3) мягко подталкивают мамкиных архитекторов к более прагматичным решениям.
Так что да — это приносит пользу и в стартапах.
Важно только чтобы тот человек в команде кто исполняет роль Лида/навязывает всем свое мнение по любому решению — умел в solid in action, а не только на собеседованиях спрашивать. Без этого — это будет путь боли.
Про кейс с бд — это уже другой класс тестов и там вопрос уже сложнее: сильно зависит от того сколько надёжности вы готовы оплачивать и да — для стартапа действительно вопрос открытый.
Про продолжительность помидора — не стоит делать из этого каргокульт и искать «самую правильную» длительность. Это зависит от характера работы: если ты «синьер» и нет стажёров — помедор по 50 минут попробовать, если ты тимлид/манагер — у тебя характер работы другой, поэтому когда надо концентрироваться, лучше ориентироваться на 25 минут, именно потому, что реальность такова, что шансы на прерывание выше, а значит подождать 15 минут до очередного перерыва им будет проще, чем 30-40.
Помидор не запланирует за вас вашу работу на день и не приведет план в исполнение: составляйте списки дел, составляйте расписание в публичном календаре, и все несрочные вопросы — в отведенные периоды времени
А тут менеджер всех тестировщиков, по сути, призывает сидеть в теплом липком болотце безрезультатного комфорта :)
Если вы так для себя поняли написанное в статье и это стало триггером для таких категоричных суждений, то, возможно, вам будет интересно узнать, что я в статье такого не увидел :)
Я в статье увидел некие мысли по поводу «вредности оценок сроков» и того, как они обустроили процесс по-другому в своей части общей работы. С «чем-то» я согласен, с «чем-то» — нет, «что-то» «работает» только по стечению конкретных обстоятельств, «что-то» вообще не влияет на итоговый результат. Но призыва сидеть в болтце — не увидел.
P.S. Со временем и Судья Дред и Виталик Бутерин кое-что всё же поняли :)
1)упаковать эти тесты в артефакт и добавить его как test-зависимость и убедиться что runner их видит
2)Магия CI пайплайнов
Статья достаточно базовая и на этому уровне все довольно очевидно.
Проблемы начинаются в чуть более сложных кейсах, но об этом уже не пишут.
В этом смысле довольно полезна http://apistylebook.com/
Сборник гайдов разных компаний с группировкой по разделам.
Даёт возможность
1)посмотреть "а как у них"
2)узнать об аспектах/проблемах которые в co-статьях редко освещаются, а на старте проекта могут быть не видны.
Скажем, что все хорошо, но есть нюансы.
Главное, что из того что написано в манифесте не всегда получается тот код, который ожидается, поэтому приходится или править манифест или править получившийся код или вкладываться в развитие генератор
А что творится в ВТБ, чего не творится в Сбере?
Да и визуализация межсервисных вызовов- есть широкий ассортимент инструментов трассировки.
Не обязательно вводить доп.нагрузку и точку отказа для этого.
В остальном — судя потому куда ветер дует сейчас — в service mesh — это в некотором смысле происходит «под капотом».
Места закончились!
Кмк по этой теме нелишним будет упоминание паттерна Transaction Outbox и самостоятельного управления оффсетами на стороне Consumer
Зарабатываете на перепродаже Лего?
Думаю, тут дело не столько Вузах и программа от компаний (в конце концов этого и раньше не было и это не помешало php стать массовым), сколько в том, что да — сильные инженеры переходят на другие стеки, роль языка с быстрым стартом для новичков перехватил js (чтобы начать что-то писать на js и базовая алгоритмика -достаточно браузера) +фактор размера рынка и зарплат + "суть" проектов на рынке.
Но возможно, загляну на митап — вдруг тоже ништяк дадут
Отток сильных инженеров из php в более востребованные/хайповые языки, снижение популярности.
Все верно.
"Порядок", бьёт "класс".
Условный бизнес "принял" ограничения и случилась "ещё одна оглушительная победа гибких методологий", продолжил бы заваливать нелепостями с приоритетом major и critical — получили бы как всегда.
Расскажите, какие ответы кажутся вам самыми правильными?)
Лучше не изобретать велосипеды и следовать рекомендациям owasp
Полностью разделяю эту точку зрения.
Но осознанность и идея ответственности за свои решения и их результаты — скорее "не популярна". Об этом много любят говорить, бравировать, но как дело доходит до принятия негативного результата — виноват кто-то/что-то.
Ну и плюс — у нас как ни крути достаточно "молодая" отрасль и инфантов здесь хоть отбавляй, даже в возрасте 30+.
+Ситуация на рынке, что даже самый расположений инфантильный говнокодер на java — сможет получить достаточно предложений работы чтобы выбирать среди них.
Unitесты и тдд экономят время на нескольких этапах:
1)на этапе разработки: сидеть в отладке получается гораздо быстрее чем раз за разом запускать систему и подводить к нужному состоянию.
2) на этапе украшательства: когда работающий лапшекод хочется немного подписать перед коммитом.
3) мягко подталкивают мамкиных архитекторов к более прагматичным решениям.
Так что да — это приносит пользу и в стартапах.
Важно только чтобы тот человек в команде кто исполняет роль Лида/навязывает всем свое мнение по любому решению — умел в solid in action, а не только на собеседованиях спрашивать. Без этого — это будет путь боли.
Про кейс с бд — это уже другой класс тестов и там вопрос уже сложнее: сильно зависит от того сколько надёжности вы готовы оплачивать и да — для стартапа действительно вопрос открытый.
Если это место твой выбор и твое решение, то смеяться, если нет — плакать.
Почему все же продолжил заполнение анкеты для сб?
Помидор не запланирует за вас вашу работу на день и не приведет план в исполнение: составляйте списки дел, составляйте расписание в публичном календаре, и все несрочные вопросы — в отведенные периоды времени
Если вы так для себя поняли написанное в статье и это стало триггером для таких категоричных суждений, то, возможно, вам будет интересно узнать, что я в статье такого не увидел :)
Я в статье увидел некие мысли по поводу «вредности оценок сроков» и того, как они обустроили процесс по-другому в своей части общей работы. С «чем-то» я согласен, с «чем-то» — нет, «что-то» «работает» только по стечению конкретных обстоятельств, «что-то» вообще не влияет на итоговый результат. Но призыва сидеть в болтце — не увидел.
P.S. Со временем и Судья Дред и Виталик Бутерин кое-что всё же поняли :)