Пирамида Маслоу в аспекте разработки ПО

Предлагаю читателям «Хабрахабра» перевод заметки «Maslow's Hierarchy of Needs of Software Development» ^[1], которую я нашел в блоге Скота Ханселмана.

Я тут немного экспериментировал со своей диетой и думаю перейти на «палео»-диету. Впрочем, это очень самонадеянно c моей стороны, вот так вот, в корне, изменить свое отношение к еде. В наше время только весьма обеспеченные люди могут позволить себе в полной мере экспериментировать в этой области.

Человек не склонен заботиться о благах высокого порядка до тех пор, пока не удовлетворены потребности более низкого порядка. Ниже пример пирамиды потребностей по Маслоу:

Недавно я общался с заказчиком, где один хороший человек большей частью был озабочен стилем кода: расположением фигурных скобок, применением проверенных решений («best practices») в дизайне интерфейсов и еще кучей важных, но едва ли критичных вещей. В то же время в их организации не было поставлено модульное тестирование («unit-testing»), развертывание («deployment») проводилось вручную, а сборки были слабо верифицируемыми («verifiable build»).

Говоря иначе, он был сосредоточен на проблеме «достаточно ли я потребляю витамина А?», упустив из виду проблему «есть ли у меня вообще что приготовить к ужину?».

Я подумал: что если спроецировать пирамиду потребностей Маслоу на нашу предметную область — разработку ПО? Под катом пример того, что у меня получилось (благодарю Фила Хаака ^[2], Джона Галлоуэя ^[3], Джонатана Ванагела ^[4] и Пола Стовела ^[5] за участие в «мозговом штурме»).

Красивый код

Лучше всех об этом выразился Пол, сказав: «На вершине пирамиды Маслоу лежит самореализация… в какой-то степени я убежден, что нам нравится самовыражаться через код, чтобы, к примеру, спустя пару лет человек, занятый поддержкой нашего проекта, воскликнул, глядя на код: „Класс! Это ведь Скотт делал, да?“.

В самом деле, ты „пишешь софт“ или ты его „разрабатываешь“ (»crafting")? В какой момент разработка становится искусством?

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

Реструктурируемый («refactorable») код

Насколько легко провести рефакторинг вашего кода? Не охватывает ли вас уныние при одной лишь мысли о подобной задаче? Соблюдены ли в нем соглашения, принятые для данного языка программирования? Следуете ли вы «духу» выбранного ЯП, используя соответствующие шаблоны проектирования, реализации и решения типовых задач? Используете ли вы в работе автоматизацию тестирования?

Поддерживаемый код

Ответьте на следующие вопросы: реально ли вообще внести изменения ваш код? Исправить ошибки без слез? Если да, то после правки есть ли возможность проверить, не сломалось ли чего? Как там дела с модульными тестами?

Автоматизация сборки и развертывания

Способны ли вы развернуть вашу систему с такой же легкостью, как и собрать версию? Непрерывная интеграция («continuous integration»), несомненно, стандарт в современном мире разработки ПО. Впрочем, есть кое-что на порядок важнее — непрерывное развертывание («continuous deployment»)… с возможностью отката до предыдущей версии.

Управление изменениями

Используете ли вы систему контроля версий? Принятые у вас стандарты работы с изменениями очевидны и понятны всем в команде? Насколько легко вы можете откатить сделанные изменения в коде, пометить текущую рабочую версию кода? А как насчет ветвления и слияния? Что? Вы в архивах все храните? Друг, не надо так… Даже на заикайтесь о дизайне классов и перестаньте колдовать над UML-диаграммами до тех пор, пока не поднята система контроля версий.

Вместо эпилога: о важности лидерства

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

Иными словами: «Достаточно ли зелени в рационе нашей команды? Ммм… давайте начнем с того, что организуем ужин в целом, а там видно будет».

Автор: os_alan

Источник ^[6]