Трагедия Common Lisp в том, что мало у кого есть желание как следует разобраться в этом чрезвычайно интересном и мощном языке, спроектированном лучшими умами того времени. Все в основном слышали звон про размер стандарта и скобки. Автор оригинальной статьи тоже не удосужился, что совершенно явственно из его комментариев к оригинальной статье.
Рекомендую, кстати, также почитать оригинальное обсуждение по ссылке. Там автор статьи решительно выступает против введения let-statements.
Сомневаюсь, что в Яндексе ещё кто-то пользуется Jira, там есть отличный внутренний багтрекер, рядом с которым Jira несколько лет назад выглядела мамонтом (по скорости работы, интерфейсу, удобству и отказоустойчивости).
Ну и наверняка Император уже навёл порядок и унифицировал код-ревью почти везде.
Не вижу, как это что-то там подтверждает. Тем, кто безразличен, как раз нет особого резона проводить собеседования.
Я много раз был в роли собеседуемого, и почти всегда (кроме собеседования в Amazon) впечатления были строго положительные. Меня собеседовали люди, с которыми я бы хотел работать.
Для большинства инженеров собеседования — это обыденная обязанность. Они отвлекают от работы, вынуждают тебя быть пунктуальным, после них нужно потратить кучу на написание фидбека, даже если кандидат очень слабый. Мало кто в здравом уме не будет тратить столько времени и ресурсов, чтобы потешить самолюбие.
далеко не высокими зарплатами
Зависит от региона, но в целом зарплаты в гугле очень хорошие.
ни топикстартеру, ни мне никакого «детального фидбека» не предоставлялось
Речь о фидбеке, который получает комитет. Вы, разумеется, никакого детального фидбека не получите, чтобы не с чем в суд было идти.
Я на лекциях по вышке не всегда успевал от руки конспектировать.
Средний человек пишет от руки со скоростью 13 слов в минуту.
Средняя скорость при слепой печати — 40-60 слов в минуту. (источник)
Я печатаю не очень быстро — 60-90 слов в минуту (зависит от того, что печатаю). Я пробовал конспектировать лекции по топологии в университете в Emacs + рисовал картинки от руки отдельно (их потом нужно было сканировать и подставлять в документ руками, не очень удобно).
Если при записи от руки я всё время отставал от лектора, то при наборе на клавиатуре мне приходилось постоянно ждать лектора, даже без всяких продвинутых макросов. К тому же не приходится постоянно переключать зрение между документом и доской.
За это приходилось платить пост-обработкой документа для расстановки картинок.
единый тулинг для мониторинга, пуша в прод и прочее.
Нет, тулинга в всегда как минимум два — один deprecated, а другой красивый, но пока толком не работает, причём вам нужно срочно на него переехать.
Ну и для пуша в прод вариантов гораздо больше, чем 2.
Есть такая полу-шутка, что единственный способ заниматься чем-то действительно интересным в Гугле — пилить интересный стартап, который потом купит Гугл.
Оптимизации — вещь полезная, но их надо уметь преподносить.
Ключевая сложность с промо — нужно скрупулёзно собирать метрики и доказывать свою полезность, чтобы твоему менеджеру было что показать комитету, который ни про тебя, ни про твои проекты вообще ничего не знает. Чтобы сделать что-то для промо, нужно в 3 раза больше времени, чем просто это сделать.
При этом процесс всё равно не особо честен. Часто люди получают промо за запуски оперденей, выхлопа от которых нуль без палки, а мега-продуктивные люди, которые пилят ключевую инфраструктуру и получают важные результаты, годами не номинируются.
Я нигде не называл его удобным. Я один раз его пробовал использовать на одной и предыдущих работ, и так не мог дождаться завершения загрузки репозитория всего с несколькими десятками тысяч коммитов (через много часов я просто прервал процесс). Просто если ну очень нужно читать и править локальную историю — выход есть.
Использовать голый git с центральным репозиторием и trunk-based подходом, когда в команде активно работает ~100 инженеров — очень сомнительное удовольствие. Для небольших команд это ещё более-менее работает, для больших уже нужны какие-то мёрж-боты.
К слову, одна из киллер-фич Git, которых очень не хватает в SVN — index. Тем забавнее, что большинство плагинов пытаются её спрятать, по пути создавая кучу проблем.
Во-первых, он гораздо проще в освоении.
Во-вторых, в нём есть удобные и понятные порядковые номера ревизий.
Я лично всегда и везде для личных проектов использую git, мне просто не нравится дихотомия SVN — устаревшее и плохое, git — новое и хорошее. Это разные точки в пространстве возможных решений.
Если вам ну очень хочется работать в оффлайне, git svn в помощь.
случайно угодила в команию, где всё ещё пользовались SVN
А что плохого в использовании SVN? Яндекс, скорее всего, до сих пор много использует SVN, т.к. SVN хорошо умеет partial checkouts (актуально для огромных кодовых баз). Я работаю в компании, где система контроля версий ходит и крякает как Perforce начала двухтысячных, и не испытываю с этим никаких проблем (благо, добрые люди написали плагин для Emacs, который работает почти как magit).
Вот если бы компания использовала SCCS/RCS/CVS или, упаси боже, MS Visual SourceSafe, вот тут, наверное, можно было бы посочувствовать.
Интересное начинается когда добираешься до 3p кода
Ну вообще говоря, c 3p не так уж всё и плохо. Как всегда с монорепами, это — проблема тулинга. Написаны инструменты для импорта сторонних зависимостей из разных источников и синхронизации с открытыми репозиториями. Очень многие популярные вещи уже в third_party.
Зато получаем
codesearch по всем зависимостям
очередной leftpad вам ничего не сломает
вместо двух тысяч копий leftpad у вас будет ровно одна
версии всех зависимостей всегда консистентные (особенно актуально в каком-нибудь Haskell)
Связность зависит от культуры разработки, а не от структуры репозитория. Лично я не вижу никаких подтверждений этого аргумента автора статьи.
В полирепе так же просто сделать неявную зависимость между модулями: предположения о формате данных, структуре хранилища и т.п. Я точно также могу утверждать, что полирепы поощрают вас, к примеру, хранить фронт-енд и бэк-енд в разных репозиториях, и протокол между ними не генерить из общего IDL по соседству, а писать руками дважды (счастливой отладки при апдейте схемы).
И вот такое я как раз видел сплошь и рядом.
А потом без пол-литры не разберешь, а где же у этих систем границы. Где собственно зоны отвественности и все такое…
Это самый бредовый аргумент из всей статьи. У нас у каждой большой системы есть свой каталог с OWNERS файлами, в которых написано, кто владеет кодом. В нормальном воркфлоу без аппрува этой команды ничего изменить в их коде не получится. Всегда понятно, где границы, и кто за что отвечает. Сервисы взаимодействуют друг с другом через посылку сообщений поверх gRPC. Сложно представить себе более ясные границы.
Говорю следующее как разработчик, ежедневно использующий монорепу с миллиардами строк кода. Начать работать с этой монорепой было очень просто, реализовывать кросс-модульные фичи — это просто сказка, навигация по всему коду напрямую из codesearch — это божественно. Видимо, в вашей монорепе нет правильных инструментов.
Когда в команде несколько десятков разработчиков, начинается гонка за коммит в head. В линуксе это работает благодаря организационной структуре: там изменения льются в апстрим по дереву доверия, и в каждом узле небольшое код-во разработчиков.
Я работал с большими кодовыми базами с использованием обоих подходов.
Монорепы — это на порядок более удобный и продуктивный подход (полирепы вспоминаю как страшный сон), если у компании есть ресурсы для настройки (а возможно, и написания с нуля) инструментов для работы с ними. Facebook и Google выкладывают много полезного для этого кода в открытый доступ (Kythe, Bazel, Hg-experimental), но инвестировать в инфраструктуру придётся много.
Не выйдет просто взять и начать сваливать весь код в одну кучу.
Глядя на картинку, долго не мог понять, что медведь в халате делает около андроида.
Трагедия Common Lisp в том, что мало у кого есть желание как следует разобраться в этом чрезвычайно интересном и мощном языке, спроектированном лучшими умами того времени. Все в основном слышали звон про размер стандарта и скобки. Автор оригинальной статьи тоже не удосужился, что совершенно явственно из его комментариев к оригинальной статье.
Рекомендую, кстати, также почитать оригинальное обсуждение по ссылке. Там автор статьи решительно выступает против введения let-statements.
Яндекс ≠ Яндекс.Деньги.
Сомневаюсь, что в Яндексе ещё кто-то пользуется Jira, там есть отличный внутренний багтрекер, рядом с которым Jira несколько лет назад выглядела мамонтом (по скорости работы, интерфейсу, удобству и отказоустойчивости).
Ну и наверняка Император уже навёл порядок и унифицировал код-ревью почти везде.
Не вижу, как это что-то там подтверждает. Тем, кто безразличен, как раз нет особого резона проводить собеседования.
Я много раз был в роли собеседуемого, и почти всегда (кроме собеседования в Amazon) впечатления были строго положительные. Меня собеседовали люди, с которыми я бы хотел работать.
Для большинства инженеров собеседования — это обыденная обязанность. Они отвлекают от работы, вынуждают тебя быть пунктуальным, после них нужно потратить кучу на написание фидбека, даже если кандидат очень слабый. Мало кто в здравом уме не будет тратить столько времени и ресурсов, чтобы потешить самолюбие.
Зависит от региона, но в целом зарплаты в гугле очень хорошие.
Речь о фидбеке, который получает комитет. Вы, разумеется, никакого детального фидбека не получите, чтобы не с чем в суд было идти.
Средний человек пишет от руки со скоростью 13 слов в минуту.
Средняя скорость при слепой печати — 40-60 слов в минуту. (источник)
Я печатаю не очень быстро — 60-90 слов в минуту (зависит от того, что печатаю). Я пробовал конспектировать лекции по топологии в университете в Emacs + рисовал картинки от руки отдельно (их потом нужно было сканировать и подставлять в документ руками, не очень удобно).
Если при записи от руки я всё время отставал от лектора, то при наборе на клавиатуре мне приходилось постоянно ждать лектора, даже без всяких продвинутых макросов. К тому же не приходится постоянно переключать зрение между документом и доской.
За это приходилось платить пост-обработкой документа для расстановки картинок.
Не, мне и в Цюрихе хорошо. Проект у меня вполне себе интересный, грех жаловаться.
Чтобы стать богатым, достаточно запромоутиться до L7.
Нет, тулинга в всегда как минимум два — один deprecated, а другой красивый, но пока толком не работает, причём вам нужно срочно на него переехать.
Ну и для пуша в прод вариантов гораздо больше, чем 2.
Есть такая полу-шутка, что единственный способ заниматься чем-то действительно интересным в Гугле — пилить интересный стартап, который потом купит Гугл.
Оптимизации — вещь полезная, но их надо уметь преподносить.
Ключевая сложность с промо — нужно скрупулёзно собирать метрики и доказывать свою полезность, чтобы твоему менеджеру было что показать комитету, который ни про тебя, ни про твои проекты вообще ничего не знает. Чтобы сделать что-то для промо, нужно в 3 раза больше времени, чем просто это сделать.
При этом процесс всё равно не особо честен. Часто люди получают промо за запуски оперденей, выхлопа от которых нуль без палки, а мега-продуктивные люди, которые пилят ключевую инфраструктуру и получают важные результаты, годами не номинируются.
Я нигде не называл его удобным. Я один раз его пробовал использовать на одной и предыдущих работ, и так не мог дождаться завершения загрузки репозитория всего с несколькими десятками тысяч коммитов (через много часов я просто прервал процесс). Просто если ну очень нужно читать и править локальную историю — выход есть.
Использовать голый git с центральным репозиторием и trunk-based подходом, когда в команде активно работает ~100 инженеров — очень сомнительное удовольствие. Для небольших команд это ещё более-менее работает, для больших уже нужны какие-то мёрж-боты.
К слову, одна из киллер-фич Git, которых очень не хватает в SVN — index. Тем забавнее, что большинство плагинов пытаются её спрятать, по пути создавая кучу проблем.
Во-первых, он гораздо проще в освоении.
Во-вторых, в нём есть удобные и понятные порядковые номера ревизий.
Я лично всегда и везде для личных проектов использую git, мне просто не нравится дихотомия SVN — устаревшее и плохое, git — новое и хорошее. Это разные точки в пространстве возможных решений.
Если вам ну очень хочется работать в оффлайне, git svn в помощь.
А что плохого в использовании SVN? Яндекс, скорее всего, до сих пор много использует SVN, т.к. SVN хорошо умеет partial checkouts (актуально для огромных кодовых баз). Я работаю в компании, где система контроля версий ходит и крякает как Perforce начала двухтысячных, и не испытываю с этим никаких проблем (благо, добрые люди написали плагин для Emacs, который работает почти как magit).
Вот если бы компания использовала SCCS/RCS/CVS или, упаси боже, MS Visual SourceSafe, вот тут, наверное, можно было бы посочувствовать.
Ну вообще говоря, c 3p не так уж всё и плохо. Как всегда с монорепами, это — проблема тулинга. Написаны инструменты для импорта сторонних зависимостей из разных источников и синхронизации с открытыми репозиториями. Очень многие популярные вещи уже в third_party.
Зато получаем
Связность зависит от культуры разработки, а не от структуры репозитория. Лично я не вижу никаких подтверждений этого аргумента автора статьи.
В полирепе так же просто сделать неявную зависимость между модулями: предположения о формате данных, структуре хранилища и т.п. Я точно также могу утверждать, что полирепы поощрают вас, к примеру, хранить фронт-енд и бэк-енд в разных репозиториях, и протокол между ними не генерить из общего IDL по соседству, а писать руками дважды (счастливой отладки при апдейте схемы).
И вот такое я как раз видел сплошь и рядом.
Это самый бредовый аргумент из всей статьи. У нас у каждой большой системы есть свой каталог с OWNERS файлами, в которых написано, кто владеет кодом. В нормальном воркфлоу без аппрува этой команды ничего изменить в их коде не получится. Всегда понятно, где границы, и кто за что отвечает. Сервисы взаимодействуют друг с другом через посылку сообщений поверх gRPC. Сложно представить себе более ясные границы.
Полирепы вас от плохого кода точно не спасут.
На какую чудесную монорепу? В чём заключался перевод? Просто переписали билд на bazel/pants/buck?
Перевод проекта с системы сборки X на систему сборки Y, ∀ X, Y — это всегда много скучной, изматывающей, неблагодарной работы.
Я переводил ~500.000 строк кода и двумя десятками приложений на Java с кастомной ANT-сборки на Gradle, утомился. При чём тут монорепы?
Говорю следующее как разработчик, ежедневно использующий монорепу с миллиардами строк кода. Начать работать с этой монорепой было очень просто, реализовывать кросс-модульные фичи — это просто сказка, навигация по всему коду напрямую из codesearch — это божественно. Видимо, в вашей монорепе нет правильных инструментов.
Когда в команде несколько десятков разработчиков, начинается гонка за коммит в head. В линуксе это работает благодаря организационной структуре: там изменения льются в апстрим по дереву доверия, и в каждом узле небольшое код-во разработчиков.
Я работал с большими кодовыми базами с использованием обоих подходов.
Монорепы — это на порядок более удобный и продуктивный подход (полирепы вспоминаю как страшный сон), если у компании есть ресурсы для настройки (а возможно, и написания с нуля) инструментов для работы с ними. Facebook и Google выкладывают много полезного для этого кода в открытый доступ (Kythe, Bazel, Hg-experimental), но инвестировать в инфраструктуру придётся много.
Не выйдет просто взять и начать сваливать весь код в одну кучу.