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

В начале своей почти 40-летней карьеры программиста я узнал — часто на собственном опыте — что существует, по-видимому, бесчисленное множество способов потерпеть неудачу при разработке программного обеспечения. Знания, необходимые для успешного разработчика, постоянно меняются вместе с новыми технологиями и методологиями, и иногда просто идти в ногу с изменениями может показаться сложной задачей. Но это обычно не то место, где все идет наперекосяк. Наоборот, самый большой провал программных проектов можно объяснить совершенно другой причиной:

Люди не планируют потерпеть неудачу. Однако они не умеют планировать.

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

Итак, давайте сделаем этот первый шаг вместе.

Шаг 1: Открытие

У открытия есть одна простая цель; то есть «обнаружить» проблему. Почему вас просят написать программу? Слишком часто разработчики начинают программировать и пытаются понять «это» по пути, с дополнительными затратами на доработку и потерей времени в погоне за потенциально не связанными призраками. Если вы не знаете, почему вы находитесь на этой лестнице, лучше выяснить это, прежде чем упасть со следующей ступеньки.

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

Шаг 2: Анализ

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

В нашей компании мы называем это «определением готовности». Другими словами, если вы не знаете, куда направляетесь, как вы узнаете, когда прибудете? Ни одна деталь не является слишком маленькой или незначительной. Задайте все вопросы, разыграйте все «что, если» и используйте все это, чтобы найти блестящее решение.

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

Шаг 3: Реализация

На этом этапе программисты взволнованы, когда они кладут пальцы на клавиатуру и пишут код. К этому моменту вы знаете проблему, и у вас есть решение, так что просто сделайте это!

Хотя может показаться очевидным, что это будет самый трудоемкий шаг в любом программном проекте, это не обязательно так. Если открытие и анализ были всесторонними, реализация становится не более сложной, чем испечь пирог. Подумай об этом; когда кто-то впервые испек торт, этому человеку нужно было выяснить ингредиенты и процесс. Вероятно, это заняло некоторое время. Чтобы упростить процесс, они записали его в рецепт, которому каждый может следовать, чтобы повторить процесс быстро и эффективно. То же самое относится и к проектам по разработке программного обеспечения: если обнаружение и анализ были успешными, их реализация должна быть быстрой и легкой, как испечь торт.

Те, кто называет себя «настоящими программистами», возражают против этого понятия следования рецепту. «Если я не должен делать ничего, кроме слепого следования инструкциям, — утверждают они, — что в этом интересного?» Если это про вас, подумайте об этом, когда в следующий раз будете садиться в самолет. У вашего пилота есть особые инструкции, как безопасно доставить вас из Денвера в Хьюстон. Как бы вы себя чувствовали, если бы он или она проигнорировали эти инструкции просто потому, что веселее делать бочки на высоте 33 000 футов?

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

Шаг 4: Тестирование

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

(Обратите внимание, что я не сказал «исходная проблема». В зависимости от продолжительности проекта конечная игра может измениться из-за изменений в масштабе. Эта концепция, любовно ненавидимая разработчиками как «расползание масштаба», получила свою долю жертвами проекта на протяжении многих лет. Хотя расширение масштабов не является полностью неизбежным, во время обнаружения и анализа можно предпринять шаги, чтобы свести к минимуму неизвестные, которые, как правило, позволяют The Creep выполнять свои злые приказы. Таким образом, открытие и анализ могут быть похожи на игру шахмат; чем больше ходов вы знаете заранее, тем больше шансов, что вы одержите победу.)

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

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

Шаг 5: Документ

Как только код станет пуленепробиваемым и готовым к использованию в мире, времени на отдых все равно не будет. Теперь нам нужно зафиксировать все, что мы запланировали, все, что мы сделали, и все, что кому-либо нужно знать о решении, в той или иной форме записи, будь то документы, видео, наскальные рисунки (не совсем) или любой постоянный формат. Я заметил, что типичный разработчик может хранить значительные объемы информации только в течение примерно шести месяцев, прежде чем детали кэшируются для новой информации. Шесть месяцев — это также примерно то количество времени, которое проходит между развертыванием и звонком в экстренную службу поддержки или запросом на модификацию. Сейчас не время и не ситуация, чтобы пытаться вспоминать детали проекта по памяти!

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

Шаг 6: Разверните

Предыдущие шаги позади, теперь мы готовы к запуску! Процесс установки кода в рабочую среду может стать настоящим испытанием для неподготовленных. Однако установка готового к работе решения в производственной среде не является чем-то особенным. Это не значит, что что-то не может пойти не так, но если ваше планирование было надежным (и ваши инструменты развертывания дают вам «отмену» — на всякий случай), развертывание может вызвать чистую радость от достижения.

Шаг 7: Поддержка

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

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

Каждая выпущенная программа может существовать вечно. Будьте активны на протяжении всего процесса, чтобы убедиться, что ваше решение является всем, чем оно может быть: точным, эффективным, последовательным и ремонтопригодным. Нравится вам это или нет, но те, кто придет после вас, посмотрят на ваш код и составят о нем свое мнение. Говоря словами моего правила шести месяцев: «То, как вы пишете код сегодня, будет определять слова, используемые для описания вас через шесть месяцев». Хотя бы ради своей карьеры, предпримите шаги сегодня, чтобы эти будущие слова были позитивными и воодушевляющими.