Ричард Шеридан - Работа мечты. Как построить компанию, которую любят

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

В 1980 году я устроился на работу программистом в компанию Manufacturing Data Systems (MDSI) – одну из самых успешных технологических компаний в истории Анн-Арбора. Я все еще учился в колледже Мичигана, так что, пока не закончил учебу, работал неполный день. В MDSI я попал в окружение отличных людей, включая маму Ларри Пейджа [38], Глорию, которая работала там программистом, а также Томаса Нолла [39], который продолжал создавать свой Photoshop.

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

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

После завершения той летней стажировки молодых программистов в MDSI я получил назначение в другой отдел, а также четкие указания моего нового босса забыть о принципе разработки через тестирование, потому что у нас есть реальная работа. Я бы больше так и не встретился с этим методом, если бы Кент Бек и Мартин Фаулер не представили вновь данную концепцию миру программирования в 2000 году в своей книге «Рефакторинг» [40].

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

Гастроном Zingerman’s [41]имеет собственную версию систематической проверки качества. Там диспетчер магазина каждый заказ повторяет клиенту. Когда вы размещаете заказ, его зачитывают вам для подтверждения. Когда вы оплачиваете его, кассир делает это еще раз. Когда заказ привозят к вашей двери, его состав зачитывают вам в третий раз, чтобы подтвердить, что вы получили правильный набор продуктов. Каждый сотрудник Zingerman’s поступает так всегда. Вы можете себе представить, какое хорошее мнение о компании создает такой подход у клиентов? Он не улучшает качество самих продуктов (для этого есть другие процессы), но он поддерживает уровень удовлетворенности покупателей на самом высоком уровне. Очень просто упустить очевидные ответы на серьезные вопросы, касающиеся качества.

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