Я тоже так думал, пока здесь же под влиянием коллег, не перешёл с любимого Django/Python на Spring/Kotlin :)
Теперь понимаю, что не технологии и не стек делают работу. Делают её люди. Если приятно вместе с коллегами заниматься любимым делом, то какая разница, что это за стек?
Карелия, Саво, Лапландия. В Турку, Тамппере и Оулу как-то получше будет, но всё-равно, ниже чем в окружности Хельсинки.
П.С. последний раз изучал вопрос пару лет назад, сидя в Йоэнсуу.
Если вы хороший разработчик — такая ли большая разница, на чём писать? Желательно конечно знать что-то из перечисленного, но это не является обязательным условием.
Вот не надо. Супруга после года курсов те кескуса (официальной конторы по трудоустройству), перешагнкв по ходу через пару уровней, сдала языковой экзамен на кескитасо (уровень языка достаточный для получения гражданства). Устроилась на оплачиваемую практику в больницу. Ещё через год сдала первый экзамен по защите диплома врача (а их надо сдать аж целых три, иностранцам извне ЕС).
А на тех же курсах, она слышала как один эмигранты советовал другому похуже сдать промежуточный тест, чтобы подольше сидеть на курсах и соответственно пособии)
В основном — согласен. В небольших скриптах / программах аннотации скорее добавляют шума. Но уже (условно) в коде на 1000 строк хочется большей видимости и контроля над типами.
Но вот городить класс CustomIntFloatDict — увольте. Уж лучше аннотации.
Уважаемый автор, собственные исключения, или скорее исключения предметной области, будь то базовые исключения языка, фреймворка или бизнес-логики — это прекрасный инструмент.
Но вот пример, который вы привели — это не то чтобы из пальца высосано — это ужасно.
Потому что в современном (sic!) питоне, грамотный разработчик использует аннотацию типами и например mypy, чтобы объявить тип IntFloatDict = Dict[Any, Union[float, int]] и пользоваться им в нужных местах.
Будучи на вашем месте, я привёл бы пример например исключений Django / DRF — та же DoestNotExist или интересную ValidationError.
В нашей команде 5 человек. Мы пилим бэкенд. Мы девопсы и отвечаем за всю цепочку, благо AWS, infrastructure-as-code и приложения в контейнерах.
Мы сидим в одной комнате площадью ~ 30m^2 и с коммуникацией нет никаких проблем. Более того, мы большие любители посидеть за одним столом вместе, обычно вдвоём, втроём, даже всей командой.
TDD особенно легко даётся когда работаешь в паре. Всевозможные линтеры локально и в CI-пайплайне отметают замечания в стиле "ты тут пропустил пробел". И благодаря всему этому число код-ревью сведено к минимуму. От формальных ревью мы уже давно отказались. Обычно это сообщение в Slack "ребята, мы тут запилили <что-то>, гляньте пожалуйста <ссылка на commits diff в Gitlab>".
О, у нас есть ветки. Но они в большинстве своём — для экспериментов и редко напрямую сливаются в master. И живут эти ветки, самое большее — пару дней.
И ещё важные столпы нашего процесса — чистая архитектура, микросервисы и формализованное общение между ними (с помощью инструментария pact.io).
Мы отказались от спринта и релизов раз в Х недель. Коммит-пуш-CI-деплой — Continuous Delivery. Если билд сломан и сломан серьёзно, то все остальные дела откладываются — смысл работать над фичей, если билд сломан? Если обнаруживается баг, то разработка чего-то нового приостанавливается в принципе — смысл пилить фичу, если в коде ошибка и она ведёт к проблемам у клиента, соответственно — к потере НАШЕЙ репутации? И как вы понимаете, багфикс выходит не через две недели, а через 10-15 минут, после того как код был залит в репозиторий.
Для нас TBD — это способ сократить время обратной связи (feedback loop). Он не дался нам легко и сразу. Мы набили много шишек и успели обрасти различными ритуалами. Например если сломался билд, то разработчик сломавший билд отписывается в комментарии (к автоматическому оповещению на специальном канале в Slackе), почему сломался билд и что он собирается с этим делать.
Нормой считается заявить во всеуслышание о том, чем собираешься заняться дальше и поинтересоваться мнением коллег на эту тему. TBD стал ответом на вызовы Continuous Delivery. И как я писал выше, мы стараемся свести количество Feature-флагов к минимуму и выкидывать их при первой же возможности.
Может когда проекту будет 100-человеко-лет и в команде будет 10-15 разработчиков, нам придётся изменить подход. Но пока всё работает и мы, а главное — наши клиенты, очень довольны :)
Не скажу, что приведённый автором пример мне очень пришёлся по душе. Мы используем TBD и feature flags, которые контролируются в рантайме посредством LaunchDarkly. Но feature флаг — это всегда кратковременное явление. В идеале их количество должно быть нулевым!
Зато соглашусь насчёт TBD. Там, где от коммита до релиза в dev, staging и production — один цикл CI, нет никакого смысла разветвлять код, чтобы попилить фичу. Добавляется флаг, фича пишется и деплоится во все среды и её сразу же можно протестировать на заданной группе пользователей.
В чём профит? — Код един во времени и пространстве. Пропадают ситуации когда "мы замёрджили и всё сломалось". Нет багфиксовых веток. Нет специальных деплоев для разных клиентов. Каждый разработчик сделав "git pull" получает код в том же состоянии, в каком он находится на боевых серверах.
И самый кайф — решаются проблемы с рефакторингом! Переименовали класс? — коммит и деплой. Переделали сигнатуру метода? — коммит и деплой. И всё это — маленькие, понятные коммиты, за которыми легко следовать.
Хоть кто-то на Хабре пишет разумные статьи! Всё борюсь с коллегами, ежедневно доказывая, что "х-к, х-к и в продакшн" — самая продвинутая и современная методология разработки! Побольше бы таких единомышленников, как автор!
А теперь добавьте к этому шаблоны вроде "requirements.dev.txt" и "requirements.dev.freeze.txt" :)
Я ни в коем случае не оспариваю, что можно обойтись одним pip и virtualenv (идущим из коробки python3 -m venv). Но для меня poetry — это удобный высокоуровневый инструмент, который избавляет от рутины и тем самым уменьшает количество ошибок.
Пока вы перечисляете все зависимости (и зависимости зависимостей) указывая их точную версию, может и ничем.
Но poetry и ему подобные инструменты могут "замораживать" установленные версии пакетов. Poetry записывает эти версии в poetry.lock. Таким образом вы можете воспроизвести установленные зависимости как на любой девелоперской машине, так и в продакшене.
Нужно доверие "сверху" и желание "снизу". Доверие менеджеров команде профессионалов и доверие членов команды к менеджерам и друг к другу.
В противном же случае, если у менеджера продукта в голове Скрам, и спринты ему необходимы как мана небесная — это плохо. Если у разработчиков отношение, как писали выше, "работать на дядю и делать таски записанные в бэклоге" — это ещё хуже.
Как писали в обсуждении — дело в культуре. Культуру не изменишь, поменяв скрам на канбан.
Мне кажется, что рабочий вариант при такой ситуации — выделить маленькую мотивированную команду из 3-4 человек, пересадить их спина к спине в отдельное пространство и дать им карт-бланш на пол-года. Пусть пробуют новые процессы, подходы к разработке, DDD, DevOps. Пусть тратят своё время на совместный просмотр лекций (или котиков).
У такой команды безусловно должны быть цели и сроки, должна быть отчётность. Но вместо категорических вопросов из серии "почему вы не работаете над вот этой очень_нужной_фичей?", должны быть "ребята, как ваши коллеги и компания может вам помочь?".
А дальше — смотреть по результатам. Если эксперимент удался — внедрить в команду ещё 1-2 человека. Дать им поработать ещё пол-года. Потом разбить команду на две и внедрить в каждую новую команду новых людей. Буквально — распространять новые практики как вирус :) И стараться не переусердствовать, влив в команду больше новых людей, чем она может "переварить".
Да, так оно и есть :) И как порой бывает сложно работать с ребятами из соседней команды, у которых тоже Аджайл, под соусом Scrumbut-a. "Мы это уже написали, но сможем выложить на интеграцию только через неделю...".
Нет. Государственные языки — финский и шведский и официальное общение происходит на нём.
Моя предыдущая компания — Keypro, CTO — замечательный человек родом из Костомукши.
Я тоже так думал, пока здесь же под влиянием коллег, не перешёл с любимого Django/Python на Spring/Kotlin :)
Теперь понимаю, что не технологии и не стек делают работу. Делают её люди. Если приятно вместе с коллегами заниматься любимым делом, то какая разница, что это за стек?
Карелия, Саво, Лапландия. В Турку, Тамппере и Оулу как-то получше будет, но всё-равно, ниже чем в окружности Хельсинки.
П.С. последний раз изучал вопрос пару лет назад, сидя в Йоэнсуу.
Если вы хороший разработчик — такая ли большая разница, на чём писать? Желательно конечно знать что-то из перечисленного, но это не является обязательным условием.
На переферии 3.5 — 5
youtu.be/o4vJOHJ9OPA
А на тех же курсах, она слышала как один эмигранты советовал другому похуже сдать промежуточный тест, чтобы подольше сидеть на курсах и соответственно пособии)
Добавьте пожалуйста вариант в голосование "Пишу на Kotlin/Scala/Clojure/Other-JVM и мне всё-равно что там в ванильной Java"
В основном — согласен. В небольших скриптах / программах аннотации скорее добавляют шума. Но уже (условно) в коде на 1000 строк хочется большей видимости и контроля над типами.
Но вот городить класс
CustomIntFloatDict— увольте. Уж лучше аннотации.Остаётся надеяться, что "Питер", прогнав некоторое количество материала через Хабр, не станет переводить и продавать книги с подобными примерами :)
Уважаемый автор, собственные исключения, или скорее исключения предметной области, будь то базовые исключения языка, фреймворка или бизнес-логики — это прекрасный инструмент.
Но вот пример, который вы привели — это не то чтобы из пальца высосано — это ужасно.
Потому что в современном (sic!) питоне, грамотный разработчик использует аннотацию типами и например mypy, чтобы объявить тип
IntFloatDict = Dict[Any, Union[float, int]]и пользоваться им в нужных местах.Будучи на вашем месте, я привёл бы пример например исключений Django / DRF — та же
DoestNotExistили интересную ValidationError.Разберу как и почему это работает у нас.
В нашей команде 5 человек. Мы пилим бэкенд. Мы девопсы и отвечаем за всю цепочку, благо AWS, infrastructure-as-code и приложения в контейнерах.
Мы сидим в одной комнате площадью ~ 30m^2 и с коммуникацией нет никаких проблем. Более того, мы большие любители посидеть за одним столом вместе, обычно вдвоём, втроём, даже всей командой.
TDD особенно легко даётся когда работаешь в паре. Всевозможные линтеры локально и в CI-пайплайне отметают замечания в стиле "ты тут пропустил пробел". И благодаря всему этому число код-ревью сведено к минимуму. От формальных ревью мы уже давно отказались. Обычно это сообщение в Slack "ребята, мы тут запилили <что-то>, гляньте пожалуйста <ссылка на commits diff в Gitlab>".
О, у нас есть ветки. Но они в большинстве своём — для экспериментов и редко напрямую сливаются в master. И живут эти ветки, самое большее — пару дней.
И ещё важные столпы нашего процесса — чистая архитектура, микросервисы и формализованное общение между ними (с помощью инструментария pact.io).
Мы отказались от спринта и релизов раз в Х недель. Коммит-пуш-CI-деплой — Continuous Delivery. Если билд сломан и сломан серьёзно, то все остальные дела откладываются — смысл работать над фичей, если билд сломан? Если обнаруживается баг, то разработка чего-то нового приостанавливается в принципе — смысл пилить фичу, если в коде ошибка и она ведёт к проблемам у клиента, соответственно — к потере НАШЕЙ репутации? И как вы понимаете, багфикс выходит не через две недели, а через 10-15 минут, после того как код был залит в репозиторий.
Для нас TBD — это способ сократить время обратной связи (feedback loop). Он не дался нам легко и сразу. Мы набили много шишек и успели обрасти различными ритуалами. Например если сломался билд, то разработчик сломавший билд отписывается в комментарии (к автоматическому оповещению на специальном канале в Slackе), почему сломался билд и что он собирается с этим делать.
Нормой считается заявить во всеуслышание о том, чем собираешься заняться дальше и поинтересоваться мнением коллег на эту тему. TBD стал ответом на вызовы Continuous Delivery. И как я писал выше, мы стараемся свести количество Feature-флагов к минимуму и выкидывать их при первой же возможности.
Может когда проекту будет 100-человеко-лет и в команде будет 10-15 разработчиков, нам придётся изменить подход. Но пока всё работает и мы, а главное — наши клиенты, очень довольны :)
Не скажу, что приведённый автором пример мне очень пришёлся по душе. Мы используем TBD и feature flags, которые контролируются в рантайме посредством LaunchDarkly. Но feature флаг — это всегда кратковременное явление. В идеале их количество должно быть нулевым!
Зато соглашусь насчёт TBD. Там, где от коммита до релиза в dev, staging и production — один цикл CI, нет никакого смысла разветвлять код, чтобы попилить фичу. Добавляется флаг, фича пишется и деплоится во все среды и её сразу же можно протестировать на заданной группе пользователей.
В чём профит? — Код един во времени и пространстве. Пропадают ситуации когда "мы замёрджили и всё сломалось". Нет багфиксовых веток. Нет специальных деплоев для разных клиентов. Каждый разработчик сделав "git pull" получает код в том же состоянии, в каком он находится на боевых серверах.
И самый кайф — решаются проблемы с рефакторингом! Переименовали класс? — коммит и деплой. Переделали сигнатуру метода? — коммит и деплой. И всё это — маленькие, понятные коммиты, за которыми легко следовать.
Хоть кто-то на Хабре пишет разумные статьи! Всё борюсь с коллегами, ежедневно доказывая, что "х-к, х-к и в продакшн" — самая продвинутая и современная методология разработки! Побольше бы таких единомышленников, как автор!
А теперь добавьте к этому шаблоны вроде "requirements.dev.txt" и "requirements.dev.freeze.txt" :)
Я ни в коем случае не оспариваю, что можно обойтись одним pip и virtualenv (идущим из коробки
python3 -m venv). Но для меня poetry — это удобный высокоуровневый инструмент, который избавляет от рутины и тем самым уменьшает количество ошибок.Пока вы перечисляете все зависимости (и зависимости зависимостей) указывая их точную версию, может и ничем.
Но poetry и ему подобные инструменты могут "замораживать" установленные версии пакетов. Poetry записывает эти версии в poetry.lock. Таким образом вы можете воспроизвести установленные зависимости как на любой девелоперской машине, так и в продакшене.
А вам не кажется, что такое поведение — обман работодателя?
Нужно доверие "сверху" и желание "снизу". Доверие менеджеров команде профессионалов и доверие членов команды к менеджерам и друг к другу.
В противном же случае, если у менеджера продукта в голове Скрам, и спринты ему необходимы как мана небесная — это плохо. Если у разработчиков отношение, как писали выше, "работать на дядю и делать таски записанные в бэклоге" — это ещё хуже.
Как писали в обсуждении — дело в культуре. Культуру не изменишь, поменяв скрам на канбан.
Мне кажется, что рабочий вариант при такой ситуации — выделить маленькую мотивированную команду из 3-4 человек, пересадить их спина к спине в отдельное пространство и дать им карт-бланш на пол-года. Пусть пробуют новые процессы, подходы к разработке, DDD, DevOps. Пусть тратят своё время на совместный просмотр лекций (или котиков).
У такой команды безусловно должны быть цели и сроки, должна быть отчётность. Но вместо категорических вопросов из серии "почему вы не работаете над вот этой очень_нужной_фичей?", должны быть "ребята, как ваши коллеги и компания может вам помочь?".
А дальше — смотреть по результатам. Если эксперимент удался — внедрить в команду ещё 1-2 человека. Дать им поработать ещё пол-года. Потом разбить команду на две и внедрить в каждую новую команду новых людей. Буквально — распространять новые практики как вирус :) И стараться не переусердствовать, влив в команду больше новых людей, чем она может "переварить".
Да, так оно и есть :) И как порой бывает сложно работать с ребятами из соседней команды, у которых тоже Аджайл, под соусом Scrumbut-a. "Мы это уже написали, но сможем выложить на интеграцию только через неделю...".