В статье описывается ситуация из какого то кровавого бодишопа. Ничего не могу сказать про такие места, никогда там не работал. Но могу сказать с точки зрения нормальной компании. В нормальной компании никогда не разрешат регулярные переработки, а уж тем более не будут их провоцировать:
1) Это дорого, каждый час x2 и выше
2) Люди очень быстро сгорят, а стоимость поиска, найма и анбординга нового инженера это очень дорого
По поводу искусственных дедлайнов — да, их ставят, но не чтобы закабалить разработчиков, а чтобы держать в тонусе. По сути весь скрам это искусственный дедлайн. Если ты дашь срок на перекрашивание кнопки в 3 месяца — ее будут перекрашивать все три месяца. Разработчики очень быстро расслабляются и начинают работать расслабленно и/или оверинжинирить на элементарных задачах. Делаем лендинг на одну промо акцию на месяц, после чего он будет выкинут в мусор? Конечно же надо сделать фреймворк для решения таких задач, спроектировать его на года поддержки вперед и подготовиться к нагрузке в миллиард запросов в секунду. Я конечно утрирую, но смысл понятен.
Главное в разработке это баланс. Делать хорошо, но не слишком долго. Не надо делать идеально, не надо делать на коленке за час. Менеджеры должны понимать стоимость изменений в будущем, инженеры должны понимать, что пока их код не приносит прибыль он не стоит ничего.
Честно говоря, в шоке от комментариев. Может я что-то пропустил и где-то в статье написано большими буквами «УНИВЕРСАЛЬНАЯ СХЕМА ДЛЯ ВСЕХ ВИДОВ СОБЕСЕДОВАНИЯ ОТ ДЖУНА ДО СТО»? У технарей же должно быть какое-то критическое мышление, чтобы иметь возможность наложить это на свою ситуацию и выбрать только полезное? Видимо к каждом пункту надо добавлять десять сносок вида «не кладите кошку в микроволновку». Спасибо за статью, вопросы очень полезные, особенно когда устраиваешься на должность инжиниринг менеджер+ в стартап.
В конкретном случае да, но это легко только пока простыми вещами вроде строк и чисел приходится оперировать. Когда доходит до структур или ссылок, то уже не все так радужно. Тут уже надо садиться и разбираться как это все работает на стыке языков.
По-моему самое сложное в этом вопросе это то, что надо разобраться как работает cgo( который по-факту и не С и не Go), тоже самое наверняка и со стороны раста.
Могу поделиться своим опытом тимлидства удаленной команды:
1) Никогда не отменяю 1:1, в крайнем случае переношу на другой день. Так и люди понимают что у тебя всегда есть на них время и регулярные встречи вырабатывают привычку. Если какие то встречи становятся нерегулярными, то со временем будут реже и реже, пока совсем все не забьют. А это один из важных инструментов для лида, чтобы понять что в команде и с каждым ее членом происходит, особенно учитывая что ты их не видишь в офисе. Я всегда готовлюсь к встрече заранее и готовлю 3-5 тем для разговора. Если есть какие то животрепещущие темы у члена команды, то обсуждаем сначала их, если нет то заготовленные. На хабре есть пара статей на тему о чем говорить на 1:1 с пользой.
2) Вместо отдельных чатов под тему многие обсуждения, которые не требуют срочного решения, выносим в асинхронное общение ( аналог форума, где не требуется немедленная реакция). Во-первых так люди могут вопрос лучше переварить и дать более продуманный ответ, а во-вторых не нужно прерываться во время выполнения задачи и выпадать из потока.
3) Стендапы проводим ежедневно и отказываться не будем, это позволяет видеть друг друга каждый день ( психологически важно на удаленке ) и понимать кто чем занимается
4) В статье еще не упомянута тема производительности. У меня постоянно спрашивают как ты понимаешь что люди на удаленке работают, а не балду гоняют. Я тут обычно отвечаю, что когда вы сидите в одном офисе это не улучшает твое понимание кто чем занимается, т.к. отсидеть 8 часов != работать. Единственные способ оценивать работы это закрытые задачи и командные/личные метрики, а в этом случае тебе наоборот удаленка помогает на них концентрироваться, ведь других вариантов у тебя и нету.
Попробовал новую систему модулей, довольно неплохо. После статьи остается много вопросов
1) «Модули также избавляют от необходимости в $GOPATH, которая была камнем преткновения для новых разработчиков Go».И добавили GOPROXY. А это не одно и тоже получается?
2) Как будет работать билд через прокси? каждый раз выкачивать пакеты или хранить в локальном кеше? в чем профит по сравнению с вендорингом?
3) Радует конечно что теперь можно назвать пакет mypackage вместо github.com/myawesomeaccount/mypackage без всякой возник с GOPATH, но интересно тогда он просто не будет автоматически скачивать зависимости проекта (а отдельный реджистри позволит и это" или еще какие подводные камни есть? надо будет потестить этот момент
4) Как будет разруливаться вопрос откуда брать пакет? Есть на гитхабе пакет github.com/a/b и есть в прокси модуль с названием github.com/a/b. Вообще тема с импортом довольно спорная, с одной стороны просто указать ссылку на репозиторий и готово, просто и эффективно. С другой стороны длиннющие пути до репозиторией, одинаковые названия пакетов, геморой с контрибьютингом через форк и т.п
4) я про гитлаб и говорю, их можно совмещать. Просто при старте стейджа не руками запускать все, а запускать плейбук в котором все описано уже.
5) docs.gitlab.com/ee/ci/docker/using_docker_images.html. Предварительно нужно создать свой образ, например если бы нужен был libvips для сборки можно было бы что то вроед этого сделать
FROM golang:latest
RUN apt-get -qq update && apt-get install -y --no-install-recommends libvips-dev -qq
1) посоветовал бы использовать dep или vgo для того чтобы управлять зависимостями. Если уж все таки через go get, то go get -d ./… сразу все выкачает и не надо будет тянуть каждый пакет отдельно
2) внутри раннера уже доступно содержимое репозитория, только артефакты (производные сборки полученные уже внутри стейджа) нужно копировать между стейджами
3) Ключ безопаснее пароля хотя бы тем, что состоит из двух частей и потеряв половину ключа (открытый ключ) злоумышленник сможет только шифровать сообщения, но не расшифровывать. Ключ нужно сгенерировать один раз на сервере и в CI передавать только публичный ключ, а приватный должен храниться на сервере.
4) Для такого деплоя еще бы посоветовал посмотреть в сторону ansible
5) Вместо того чтобы использовать golang:latest можно от него создать свой образ с уже установленными либами, будет намного быстрее собираться
1) Это дорого, каждый час x2 и выше
2) Люди очень быстро сгорят, а стоимость поиска, найма и анбординга нового инженера это очень дорого
По поводу искусственных дедлайнов — да, их ставят, но не чтобы закабалить разработчиков, а чтобы держать в тонусе. По сути весь скрам это искусственный дедлайн. Если ты дашь срок на перекрашивание кнопки в 3 месяца — ее будут перекрашивать все три месяца. Разработчики очень быстро расслабляются и начинают работать расслабленно и/или оверинжинирить на элементарных задачах. Делаем лендинг на одну промо акцию на месяц, после чего он будет выкинут в мусор? Конечно же надо сделать фреймворк для решения таких задач, спроектировать его на года поддержки вперед и подготовиться к нагрузке в миллиард запросов в секунду. Я конечно утрирую, но смысл понятен.
Главное в разработке это баланс. Делать хорошо, но не слишком долго. Не надо делать идеально, не надо делать на коленке за час. Менеджеры должны понимать стоимость изменений в будущем, инженеры должны понимать, что пока их код не приносит прибыль он не стоит ничего.
1) Никогда не отменяю 1:1, в крайнем случае переношу на другой день. Так и люди понимают что у тебя всегда есть на них время и регулярные встречи вырабатывают привычку. Если какие то встречи становятся нерегулярными, то со временем будут реже и реже, пока совсем все не забьют. А это один из важных инструментов для лида, чтобы понять что в команде и с каждым ее членом происходит, особенно учитывая что ты их не видишь в офисе. Я всегда готовлюсь к встрече заранее и готовлю 3-5 тем для разговора. Если есть какие то животрепещущие темы у члена команды, то обсуждаем сначала их, если нет то заготовленные. На хабре есть пара статей на тему о чем говорить на 1:1 с пользой.
2) Вместо отдельных чатов под тему многие обсуждения, которые не требуют срочного решения, выносим в асинхронное общение ( аналог форума, где не требуется немедленная реакция). Во-первых так люди могут вопрос лучше переварить и дать более продуманный ответ, а во-вторых не нужно прерываться во время выполнения задачи и выпадать из потока.
3) Стендапы проводим ежедневно и отказываться не будем, это позволяет видеть друг друга каждый день ( психологически важно на удаленке ) и понимать кто чем занимается
4) В статье еще не упомянута тема производительности. У меня постоянно спрашивают как ты понимаешь что люди на удаленке работают, а не балду гоняют. Я тут обычно отвечаю, что когда вы сидите в одном офисе это не улучшает твое понимание кто чем занимается, т.к. отсидеть 8 часов != работать. Единственные способ оценивать работы это закрытые задачи и командные/личные метрики, а в этом случае тебе наоборот удаленка помогает на них концентрироваться, ведь других вариантов у тебя и нету.
1) «Модули также избавляют от необходимости в $GOPATH, которая была камнем преткновения для новых разработчиков Go».И добавили GOPROXY. А это не одно и тоже получается?
2) Как будет работать билд через прокси? каждый раз выкачивать пакеты или хранить в локальном кеше? в чем профит по сравнению с вендорингом?
3) Радует конечно что теперь можно назвать пакет mypackage вместо github.com/myawesomeaccount/mypackage без всякой возник с GOPATH, но интересно тогда он просто не будет автоматически скачивать зависимости проекта (а отдельный реджистри позволит и это" или еще какие подводные камни есть? надо будет потестить этот момент
4) Как будет разруливаться вопрос откуда брать пакет? Есть на гитхабе пакет github.com/a/b и есть в прокси модуль с названием github.com/a/b. Вообще тема с импортом довольно спорная, с одной стороны просто указать ссылку на репозиторий и готово, просто и эффективно. С другой стороны длиннющие пути до репозиторией, одинаковые названия пакетов, геморой с контрибьютингом через форк и т.п
5) docs.gitlab.com/ee/ci/docker/using_docker_images.html. Предварительно нужно создать свой образ, например если бы нужен был libvips для сборки можно было бы что то вроед этого сделать
2) внутри раннера уже доступно содержимое репозитория, только артефакты (производные сборки полученные уже внутри стейджа) нужно копировать между стейджами
3) Ключ безопаснее пароля хотя бы тем, что состоит из двух частей и потеряв половину ключа (открытый ключ) злоумышленник сможет только шифровать сообщения, но не расшифровывать. Ключ нужно сгенерировать один раз на сервере и в CI передавать только публичный ключ, а приватный должен храниться на сервере.
4) Для такого деплоя еще бы посоветовал посмотреть в сторону ansible
5) Вместо того чтобы использовать golang:latest можно от него создать свой образ с уже установленными либами, будет намного быстрее собираться