Руководство по DevOps (Ким, Уиллис) - страница 207
Для такой организации от команд разработчиков требуются значительная дисциплина и обязательное рецензирование кода, покрывающее следующие области:
• легкая читаемость кода (нужны руководства по стилю оформления кода);
• назначение ответственных за поддеревья кода для поддержания единообразия и контроля над отсутствием ошибок;
• прозрачность кода и сотрудничество в работе над одним и тем же кодом между разными командами.
На рис. 42 показано, как время на рецензирование кода зависит от размера внесенных изменений. На оси X отмечается размер правок, на оси Y — время, затраченное на проверку кода. В общем случае чем больше объем изменений, тем дольше проходит анализ. Точки в верхнем левом углу обозначают более сложные и потенциально рискованные изменения, требующие более глубокого обдумывания и обсуждения.
Рис. 42. Длительность рецензирования в зависимости от размера кода в компании Google (источник: Ашиш Кумар, “Development at the Speed and Scale of Google,” презентация на QCon, Сан-Франциско, CA, 2010. https://qconsf.com/sf2010/dl/qcon-sanfran-2010/slides/AshishKumar_DevelopingProductsattheSpeedandScaleofGoogle.pdf)
Чтобы решить техническую проблему компании Google, Рэнди Шуп, в то время занимавший должность технического директора организации, начал свой личный проект. Он отмечал: «Я работал над этим проектом неделями и наконец решился попросить специалиста в этой области проверить мой код. Это было примерно три тысячи строк. Через них рецензент продирался несколько дней. После чего он попросил: “Пожалуйста, больше так не делай”. Я был очень благодарен ему, что он нашел время помочь мне. Именно тогда я и понял, как встроить рецензирование кода в ежедневную работу».
Теперь, когда мы ввели рецензирование кода, уменьшающее риски, сокращающее время на введение изменений и способствующее непрерывной масштабируемой поставке, как мы выяснили на примере компании Google, перейдем к тому, как тестирование может обернуться против нас. Когда происходят ошибки тестирования, типичная реакция — провести еще больше тестов. Однако если мы просто проводим тесты в конце нашего проекта, то можем ухудшить результаты.
Это особенно верно, если мы проводим тестирование вручную, поскольку оно более медленно и трудоемко. «Дополнительное тестирование» обычно требует больше времени, чем предполагалось, что сокращает частоту развертываний и повышает объем единовременно вносимых правок кода. А мы уже знаем и из теории, и из практики, что большие объемы нового развертываемого кода снижают шансы на благоприятный исход и увеличивают значение MTTR и число сбоев — совсем не то, что нам нужно.