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

С учетом этого, что означает сдвиг влево в разработке программного обеспечения?

Кирсти Магован довольно элегантно определяет это в своем блоге:

Сдвиг влево — это практика, предназначенная для обнаружения и предотвращения дефектов на ранних этапах процесса доставки программного обеспечения.

Хотя это в значительной степени верно, я хотел бы немного расширить определение и сказать, что сдвиг влево — это практика получения более быстрого отзыва о вашей работе. Дело не только в недостатках.

Итак, как мы это сделаем?

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

Обзор кода

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

Таким образом, это сдвигает обзор кода влево. Но мы можем сделать лучше. Намного лучше.

Хотя процесс проверки кода невероятно ценен, он не очень эффективен. Когда перед нами большой объем кода, мы склонны просматривать его, а не просматривать, или, как красиво выразился Гирей Озил:

Попросите программиста просмотреть 10 строк кода, и он найдет 10 проблем. Попросите его написать 500 строк, и он скажет, что это выглядит хорошо.

Разговор может выглядеть примерно так:

Технический руководитель: "Итак... это работает?"

Разработчик: «Ага».

Технический руководитель: "Ну... думаю, все в порядке. Мы исправим это позже».

Нет. Не будешь. Давайте исправим это сейчас.

Как? Попробуйте парное программирование.

Вы можете по очереди общаться со своими товарищами по команде и сразу же получать отзывы о бизнес-логике, проверке ошибок (лучше всего делать это на чужой шахматной доске, не так ли?), стиле кода и даже использовании IDE — Бог свидетель, я научился лучшим приемам IDE, наблюдая кто-то другой типа.

"Подождите, подождите... то, что вы только что сделали — как вы это сделали?"

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

Качество

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

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

Итак, да, мы должны писать автоматические тесты. Но какие?

Пирамида тестирования Google говорит сама за себя: напишите очень мало, очень важные (но очень надежные!) сквозные тесты, еще несколько интеграционных тестов и метрическую тонну модульных тестов. Как много? 10%, 20% и 70% соответственно.

Ура модульные тесты!

Так что просто напишите кучу юнит-тестов — дело закрыто, верно? Хорошо, может быть.

В последнее время я думаю, что, возможно, все эти годы мы неправильно занимались контролем качества. Возможно, тестирование — наименее важная часть работы QA-инженера. Но это тема для другого поста.

Сборка и развертывание

Вы или ваши разработчики иногда объединяете что-то, что ломает сборку?

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

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

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

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

Безопасность

Я вижу три простых способа сдвинуться влево в вопросах безопасности: планирование, обучение и автоматизированное тестирование.

Планирование

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

Образование

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

Еще один способ обучения безопасности — обучение тестированию на проникновение. Я получил огромное удовольствие, обучая этому на нашем собственном программном обеспечении. Есть что-то странно забавное в попытке сломать то, что ты построил.

Автоматизированное тестирование

Наконец, когда код готов, вы должны запустить автоматические тесты безопасности. Они могут быть созданы вашими командами разработки, контроля качества или безопасности или предоставлены сторонними инструментами, такими как OWASP ZAP.

Итак, как влево вы можете сместиться?

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

Если вы еще не занимаетесь большинством из них, вы можете подумать: это слишком много — с чего нам начать?

Моя рекомендация? Начните с парного программирования. Я не могу переоценить ценность этой практики. Вы получаете тимбилдинг, обучение, проверку кода и качественную работу в одном пакете. Обещаю, вы не пожалеете.

Далее, хороший конвейер CI/CD имеет большое значение. Запустите автоматизированные проверки и тесты и объявите политику «зеленой» сборки. Это предотвратит много лишней работы.

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

Желаю вам удачи на вашем пути!

Сохраняйте спокойствие и смещайтесь влево.