2013-10-22
«Многие думают, что программирование – это быстро печатать на языке программирования». Ворд Каннингэм, введение к книге «The Pragmatic Programmer»
Сфера разработки (дизайн, решение проблем, поиск оптимальных алгоритмов, изучение нового языка, рефакторинг кода) требует серьезного мыслительного процесса.
Вы пытаетесь сделать что-то, что никогда не делали ранее. Или чего никто никогда не делал ранее. Или вам нужно избежать ошибки прошлого. Или вы пытаетесь понять чей-то код или найти баг. Всё это требует очень много времени, но на количестве итогового кода это никак не отражается.
Есть и другая сторона разработки —та, которая требует действительно большое количество механически напечатанного текста. Такая деятельность нужна тогда, когда вы уже знаете то, что вам нужно сделать и как это нужно сделать. Ещё один скрипт, ещё один отчёт, ещё одно меню. Или же когда вы работаете уже на готовой платформе, и знаете, как будет выглядеть приложение, знаете подробности об API, и вам нужно много писать и не допустить ошибок.
Дебаггинг — это прежде всего мыслительный процесс. Сам процесс локализации бага, его тестирования и отладки – это механическая работа. Ранние стадии разработки и дизайна, определение технических нюансов и построение архитектуры проекта – мыслительный процесс. Создание третьего, четвёртого, сотого меню или отчёта — механическая работа. Развитие новой идеи мобильного приложения — мысль. Работа над ним — труд и рутина.
Те, кто основную часть времени проводят за мыслительным процессом, и те, кто в основном занимаются рутиной, заняты абсолютно разной деятельностью, и управлять этой деятельностью нужно тоже по-разному.
Иногда программирование — это просто механический процесс
Множество бизнес-приложений имеют до статочно поверхностную структуру. Множество сводок по базам данных, файлов с элементами данных, множество CRUD-элементов, стандартных отчётов, куча работы, связанной с интеграцией, совместимостью и операционной взаимозависимостью. Длинные списки функциональных требований, множество деталей, которые нужно отслеживать и о которых необходимо помнить. Именно так построено большинство банковских, страховых, административных, бухгалтерских, биллинговых, складских, ERP-систем, CRM-систем. На этой же основе строятся веб-порталы и онлайн-магазины.
Можно сказать, вы строите дом, мост, или торговый центр, или занимаетесь их реконструкцией. Проблемы обычно касаются большого количества элементов, и их решение очень дорого обходится. Всё это решается за счёт дикого количества рутинной работы. В процессе работы над такими проектами проблемы часто повторяются, и вы можете использовать уже знакомые шаблоны, инструменты и подходы.
Если дизайн уже готов, большую часть работы занимает контроль над деталями и координация команды. Это классический проект-менеджмент: составление бюджета, планирование расходов, перераспределение обязанностей, логистика – всё, что нужно, чтобы работа не сошла с рельсов.
Думать-думать-думать
Другие проблемы, вроде разработки игрового движка или торгового алгоритма, расчёта онлайн-рисков, оптимизации системы, требуют глубокого осмысления. Эти системы имеют высокие нетехнические требования (масштабируемость, производительность в реальном времени, надёжность, целостность данных, точность) и сложную логику, но, несмотря на это, призваны решать очень узкий набор проблем. Очень немногие люди способны погрузиться в проблемы и определить наиболее важные из них. Да, здесь тоже нужно заниматься написанием кода, но основная часть работы, как правило, требует удивительно небольшого количества написанного кода —особенно когда отбрасываются неудачные эксперименты и прототипы.
Здесь и кроется особая магия в разработке ПО — для успешного проекта требуются авторские или патентованные алгоритмы, а также дизайнерское вдохновение. Это деятельность, включающая в себя исследовательскую работу, прототипирование, умение решать проблемы, глубокие технические знания в своей области.
Мыслительные процессы и механическая работа — разные виды деятельности
В зависимости от того, какая деятельность является приоритетной в том или ином проекте, и решается, сколько людей необходимо для исполнения, и какие именно исполнители нужны. Это играет решающую роль в том, каким образом организовать работу команду и управление ей. Например, механическую работу вполне можно доверить аутсорсу. Мыслительную деятельность – нет. Для успешного выполнения проекта нужно разделить, какие проблемы решаются рутинными задачами, а какие нет, и когда мыслительный процесс становится рутинным трудом.
Мыслительную деятельность лучше организовывать в небольших командах опытных специалистов, работающих вместе — либо с помощью одного гения, работающего независимо. Большое количество при поиске вариантов дизайна, решении сложной проблемы, проведении экспериментов только навредит. Кто бы ни работал над этими задачами, ему (или им) необходимо погрузиться в суть вопроса, иметь достаточно времени для исследования альтернатив, возможность совершить ошибки и просто посмотреть в окно.
Тут и совершаются фундаментальные ошибки: ошибки в построении архитектуры, провальные проекты и неудачные повороты карьеры. Это происходит из-за неудачного выбора технологической платформы, неверной установки сроков, неверного определения действительно важных проблем, неправильного подбора людей в принципе.
Для такого рода деятельности нужны дейсвительно лучшие люди, обладающие правильными знаниями и владеющие нужными инструментами. Их внимание должно быть строго сконцентрировано на одной задаче, ни в коем случае нельзя их отвлекать на побочные.
Мыслительный процесс непредсказуем. В нём нет места копипасте, потому что просто неоткуда копировать, и некуда вставлять. Вы не можете оценить этот труд привычными методами, потому что вы не знаете, чего вы не знаете. Но эту деятельность можно регулировать, поставив задачу найти оптимальное решение в допустимые сроки.
Механическая работа очень предсказуема. Её как раз можно и нужно оценивать. Здесь важно включить все задачи, которые решаются рутинным написанием кода и вовремя вычислять возникшие ошибки, поскольку ком ошибок будет непрестанно нарастать. Небрежность, упрощения, непонимание требований, отсутствие тестирования, злостный копипаст — это то, за что придётся поплатиться в будущем.
Такая работа предназначена для рядовых работников, не для экспертов. Для такой деятельности нужны компетентные, понимающие основы языка и инструментов, внимательно следующие инструкциям, терпеливо пишущие необходимое количество кода. Конечно, порой несколько опытных разработчиков могут обойти в производительности большую команду джуниоров — но только до тех пор, пока им не наскучит. Управление командой рядовых исполнителей требует другого подхода и других навыков: для этого нужно быть дипломатом, логистом, стандартизатором, администратором и экономистов. Здесь уже задействовано управление рисками проекта и человеческих ресурсов, а не управление техническими рисками.
Со временем направление проекта меняется с мыслительной деятельности на механическую: тогда, когда самые сложные проблемы из ряда «Я не знаю, что и как нам нужно сделать» уже решены, все неизвестные стали известными, и дело остаётся только за деталями и реализацией.
Количество механического труда неизбежно увеличивается, когда у проекта становится всё больше пользователей, встаёт необходимость в новых интерфейсах, кастомизации, технической поддержки и решении проблем совместимости. Система продолжает расти, но большинство возникающих проблем уже знакомо и легко решаемо. Уже написано большое количество кода, на который можно опираться. На этом этапе проекту нужны люди, которые понимают, что происходит и могут быстро писать код.
Мышление и рутина
Мышление и механический труд являются самыми важными элементами разработки.
В книге «Программирование — это не слепая печать» (Programming is Not Just Typing) Брендан Энрик объясняет, почему парное программирование действительно работает:
«Оба работника думают, но о разных вещах. Один разработчик всегда имеет под рукой клавиатуру и держит в голове ту задачу, над которой он работает в настоящий момент (для этого разработчика важна скорость написания кода). Он пишет не структуру приложения, а кусок кода. Здесь действительно важна скорость реакции.
Другой программист, не печатающий так активно, большую часть времени проводит в размышлениях. Он держит в голове то, что печатает его коллега, но совсем иным образом. Он заботится о синтаксисе языка. Он — проводник, который следит за тем, чтобы код не сходил со своего наиболее оптимального пути».
Хороший разработчик — это нечто большее, чем тот, кто умеет быстро писать код. Тот, кто умеет быстро писать код — это гораздо большее, чем секретарь-машинист. Разработчик хорошо знает язык, инструменты, их возможности, умеет передвигаться по коду, умеет его писать. Да, его пальцы порхают по клавиатуре. Для успеха разработчику необходимо великолепное знание механики процесса, и да, скорость печати здесь не помешает.
Перевод: Люся Ширшова. По материалам Dzone.
