Понимание того, почему мы делаем то, что делаем

Есть принципы, а есть практика. Принцип – это универсальная истина, применимая везде. Практика — это конкретная реализация принципа, которая может варьироваться в зависимости от ситуации.

Понимание разницы между ними — важный шаг к тому, чтобы стать мудрее. Когда вы понимаете принцип, лежащий в основе практики, вы понимаете, почему мы делаем то, что делаем. Вы понимаете правила, а также когда их нарушать. Понимание принципа, лежащего в основе этой практики, поможет вам быть более гибкими и применять здравый смысл в своих повседневных решениях.

Давайте рассмотрим некоторые принципы и практики в мире разработки программного обеспечения.

Тестирование и проверка

Обычно считается хорошей практикой писать тесты для вашего кода. Если мы согласны с тем, что нам следует писать тесты, некоторые дополнительные вопросы могут быть такими:

  1. Насколько достаточно покрытия кода?
  2. На каком уровне я должен писать свои тесты? Модуль, интеграция или сквозной?
  3. Когда можно не писать тесты?

Все это хорошие вопросы. Эксперты отрасли высказали свое мнение, у меня есть свое мнение, и я уверен, что у вас тоже есть свое мнение. Как правило, мои ответы на эти три вопроса будут такими:

  1. Стремитесь к 100% охвату кода, но не будьте фанатичны. Иногда получение последних 5% покрытия не оправдывает возврат инвестиций. Но если вы не собираетесь что-то тестировать, у вас должна быть веская причина, почему бы и нет.
  2. Продвигайте свои тесты как можно ниже по пирамиде тестирования. Большинство вещей можно протестировать на уровне модульных и интеграционных тестов, и эти тесты имеют то преимущество, что их легко писать и быстро запускать. Важнейшие рабочие процессы, такие как проверка на сайте электронной коммерции или вход в веб-приложение, должны быть проверены сквозными тестами.
  3. В некоторых случаях может быть оправданным не писать тесты для вашего кода. Например, если у вас есть однострочное исправление CSS, вероятно, нет хорошего способа проверить это, кроме быстрой ручной проверки, взглянув на пользовательский интерфейс. Если вы вносите небольшое изменение в репозиторий устаревшего кода без какой-либо существующей тестовой инфраструктуры, а код в этом репозитории меняется очень редко, вы можете обойтись без написания автоматических тестов.

Итак, это некоторые общие практики тестирования и мои краткие размышления по этому поводу, но какие принципы лежат в основе этих практик? Вот некоторые из них, которые приходят на ум в произвольном порядке:

  1. Мы должны свести к минимуму риск развертывания. (Написание автоматизированных тестов, обеспечение высокого охвата тестами, проверка кода и внедрение конвейеров непрерывной интеграции — вот как мы реализуем этот принцип.)
  2. Мы должны предпочесть автоматизировать повторяющиеся задачи, а не выполнять их вручную. (Написание автоматизированных тестов — это то, как мы реализуем этот принцип.)
  3. Мы должны предпочесть быстрые циклы обратной связи, чтобы мы очень быстро знали, когда сделали что-то не так. (Написание автоматизированных тестов, продвижение тестов по пирамиде тестирования и использование конвейеров непрерывной интеграции — вот как мы реализуем этот принцип)
  4. Мы должны максимизировать ценность для бизнеса, тратя время только на самые важные вещи. чтобы проверить небольшое изменение, возможно, как мы реализуем этот принцип.)

Филиалы функций

Типичной стратегией работы над кодовой базой с большим количеством разработчиков является использование ветвей функций. Основная ветвь служит источником правды для кодовой базы, и разработчики создают ответвления функций от основной ветки при написании нового кода. Когда разработчик готов слить свой код обратно в основную ветку, он создает запрос на слияние, получает код-ревью, делает обновления на основе отзывов по мере необходимости, а затем объединяет свой код.

Хорошей практикой при создании мерж-реквестов является убедиться, что ваша функциональная ветка обновлена ​​до последней версии кода от мастера. Если, например, у вас есть функциональная ветка, которая отстает от master на 10 коммитов, существует риск того, что изменения в этих 10 коммитах могут повлиять на функциональность, над которой вы работаете.

Как правило, если кто-то еще коснулся тех же строк кода, которые вы изменили, вы увидите конфликт слияния и вам все равно придется вытащить последнюю версию из master в вашу ветку, чтобы разрешить эти конфликты.

Но иногда проблемы могут быть более скрытыми, когда что-то изменилось, что влияет на функциональность вашей функции, фактически не изменяя непосредственно файлы, над которыми вы работали, или вызывая конфликт слияния. Если вы объедините свой код, когда все еще 10 коммитов позади master, вы можете столкнуться с головной болью из-за сломанной функциональности или сломанных тестов, как только оба набора изменений будут вместе в основной ветке.

Теперь, всегда ли проблема, если ваша функциональная ветка отстает на несколько коммитов? Не обязательно. Если отсутствующие коммиты не затрагивают ту же область кода, над которой вы работаете, у вас должно быть нормальное слияние, даже если вы немного отстаете от основной ветки. Или, если вы работаете над большим монолитом, совместно используемым всей инженерной организацией, над которым разработчики работают сотни раз в день, есть вероятность, что оставаться в курсе самого последнего кода будет дурацкой затеей. Пока вы в достаточной степени обновлены, когда вы объединяетесь, все должно быть в порядке.

Итак, давайте еще раз посмотрим на принципы, лежащие в основе практики. Почему мы хотим, чтобы наши ветки функций обновлялись до последней версии от мастера? Некоторые принципы включают в себя:

  1. Мы должны свести к минимуму риск развертывания. (Это то же самое, что и первый принцип из предыдущего раздела. Обеспечение того, чтобы наша ветка функций также содержала другие изменения, которые в настоящее время находятся в основной ветке, помогает нам избежать неожиданностей. и это один из способов реализовать этот принцип.)
  2. Мы должны избегать легко предотвратимых ошибок. (Мы не хотим устранять неполадки с двумя отдельными ветвями, которые хорошо работали сами по себе, но при совместном использовании ломались. Мы также не хотим чтобы бороться с неисправной функциональностью, которая была объединена с мастером, когда мы могли бы легко обнаружить проблему заранее.Поддержание наших веток функций в актуальном состоянии — один из способов реализации этого принципа.)

Общение и Slack-этикет

Давайте рассмотрим еще один пример. На этот раз мы обсудим менее техническую тему, но важную для совместной работы людей в организациях: общение.

Многие компании используют Slack для обмена мгновенными сообщениями. Slack позволяет отправлять сообщения в общедоступных каналах, частных каналах или прямых сообщениях. Сообщения в общедоступных каналах видны всем, сообщения в частных каналах видны только тем, кто приглашен на канал, а прямые сообщения видны только двум людям, участвующим в обмене.

Допустим, у вас есть вопрос, который нужно задать другой команде по поводу проблемы, с которой вы столкнулись. Куда вы отправляете свое сообщение?

В общем, вы должны предпочесть использовать общедоступные каналы частным каналам и прямым сообщениям.

Публикация сообщений в общедоступных каналах имеет несколько преимуществ. Это позволяет любому желающему участвовать в беседе. Это гарантирует, что нужные люди будут включены, и уменьшит необходимость вести один и тот же разговор несколько раз с несколькими разными группами людей в различных частных каналах и прямых сообщениях. Это также снижает нагрузку, связанную с ответом на вопрос, поскольку он делится им со всей командой, а не только с одним человеком, который знает, что есть вопрос. В качестве дополнительного бонуса функция поиска Slack позволит другим пользователям искать тот же вопрос в будущем и находить нужные им ответы.

Теперь не каждое сообщение должно быть в общедоступном канале. Некоторые разговоры могут носить более личный характер, например, обсуждение решений о найме или изменения вознаграждения. Или они могут носить более личный характер. Частные каналы и прямые сообщения лучше подходят для таких сообщений.

Таким образом, мы должны размещать сообщения в общедоступных каналах, когда это возможно и уместно. Такова практика. Теперь давайте рассмотрим принципы, лежащие в основе практики:

  1. Мы должны вовлекать нужных людей в любой разговор. (Если вы отправляете прямое сообщение одному человеку, вам может потребоваться некоторое время, переходя от человека к человеку, пока вы не найдете нужного человека или группу, с которой можно поговорить. Или, даже если вы нашли кого-то, кто может помочь, остальная часть команды может нуждаться в некоторой информации о том, что происходит. Публикация вопросов в общедоступных каналах — один из способов держать всех в курсе и реализовать этот принцип.)
  2. Мы должны уважать время наших коллег. (Если вы отправляете сообщение кому-то напрямую, теперь вы возлагаете ответственность за ответ на него одного. Этот человек может быть занят, его может не быть в офисе или он может даже не знать ответа. Публикация вопросов в общедоступные каналы позволяют членам команды, которые могут и готовы ответить, и являются одним из способов реализации этого принципа.)
  3. Мы должны эффективно и продуктивно общаться. (Я не могу сказать вам, сколько раз я вел один и тот же разговор четыре раза подряд с четырьмя разными группами людей, пока мы, наконец, не нашли один и тот же канал для совместной координации. Публикация вопросов в общедоступных каналах устраняет эта избыточность и является одним из способов реализации этого принципа.)
  4. Мы должны сделать так, чтобы людям было легко находить нужную информацию. (Функция поиска в Slack превращает Slack в прекрасный неформальный инструмент для документации. Использование Slack, а также вики-страниц — это несколько способов реализовать этот принцип.)

Как избежать карго-культа

Теперь мы изучили несколько практик и принципов, лежащих в их основе. Если эти практики не работают для вас, ничего страшного!

Что хорошо в практиках, так это то, что они по определению гибки по своей природе. Они могут различаться в зависимости от компании, страны или культуры. Но если вы цените и понимаете принципы, лежащие в основе этих методов, вы сможете разработать методы, адаптированные к вашей уникальной ситуации.

С другой стороны, остерегайтесь тех, кто следует практикам, не понимая их причин. Догматизм в отношении стратегий разработки программного обеспечения или шаблонов проектирования приводит к негибкости, неэффективности и культовому программированию. Вы всегда должны быть в состоянии объяснить, почему вы делаете то, что делаете.

Практика меняется, но принципы остаются. Понимание разницы — важный навык, которым нужно овладеть.