Программирование: быстро мыслить или быстро печатать?

2013-10-22

«Многие думают, что программирование – это быстро печатать на языке программирования». Ворд Каннингэм, введение к книге «The Pragmatic Programmer»

Сфера разработки (дизайн, решение проблем, поиск оптимальных алгоритмов, изучение нового языка, рефакторинг кода) требует серьезного мыслительного процесса.

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

Есть и другая сторона разработки  та, которая требует действительно большое количество механически напечатанного текста. Такая деятельность нужна тогда, когда вы уже знаете то, что вам нужно сделать и как это нужно сделать. Ещё один скрипт, ещё один отчёт, ещё одно меню. Или же когда вы работаете уже на готовой платформе, и знаете, как будет выглядеть приложение, знаете подробности об API, и вам нужно много писать и не допустить ошибок.

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

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

 

Иногда программирование  это просто механический процесс

Множество бизнес-приложений имеют до статочно поверхностную структуру. Множество сводок по базам данных, файлов с элементами данных, множество CRUD-элементов, стандартных отчётов, куча работы, связанной с интеграцией, совместимостью и операционной взаимозависимостью. Длинные списки функциональных требований, множество деталей, которые нужно отслеживать и о которых необходимо помнить. Именно так построено большинство банковских, страховых, административных, бухгалтерских, биллинговых, складских, ERP-систем, CRM-систем. На этой же основе строятся веб-порталы и онлайн-магазины.

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

Если дизайн уже готов, большую часть работы занимает контроль над деталями и координация команды. Это классический проект-менеджмент: составление бюджета, планирование расходов, перераспределение обязанностей, логистика – всё, что нужно, чтобы работа не сошла с рельсов.

 

Думать-думать-думать

Другие проблемы, вроде разработки игрового движка или торгового алгоритма, расчёта онлайн-рисков, оптимизации системы, требуют глубокого осмысления. Эти системы имеют высокие нетехнические требования (масштабируемость, производительность в реальном времени, надёжность, целостность данных, точность) и сложную логику, но, несмотря на это, призваны решать очень узкий набор проблем. Очень немногие люди способны погрузиться в проблемы и определить наиболее важные из них. Да, здесь тоже нужно заниматься написанием кода, но основная часть работы, как правило, требует удивительно небольшого количества написанного кода  особенно когда отбрасываются неудачные эксперименты и прототипы.

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

 

Мыслительные процессы и механическая работа  разные виды деятельности

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

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

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

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

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

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

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

Со временем направление проекта меняется с мыслительной деятельности на механическую: тогда, когда самые сложные проблемы из ряда «Я не знаю, что и как нам нужно сделать» уже решены, все неизвестные стали известными, и дело остаётся только за деталями и реализацией.

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

 

Мышление и рутина

Мышление и механический труд являются самыми важными элементами разработки.

В книге «Программирование  это не слепая печать» (Programming is Not Just Typing) Брендан Энрик объясняет, почему парное программирование действительно работает:

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

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

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

Перевод: Люся Ширшова. По материалам Dzone


Читайте также: 

Вечный вопрос: удалённая работа или офис?

Какие языки программирования сводят разработчиков с ума?

Закончится ли «золотая эра программистов»?