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

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

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

image

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

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

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



Красивый код


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

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

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

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


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

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


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

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


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

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


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

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


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

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

Комментарии (7)


  1. G12ES
    21.04.2015 16:11
    +4

    Статья как раз в тему после — «Твой код никого не интересует»


  1. kloppspb
    21.04.2015 16:17
    +3

    >чтобы, к примеру, спустя пару лет человек, занятый поддержкой нашего проекта, воскликнул, глядя на код: „Класс! Это ведь Скотт делал, да?“

    Есть и другое мнение: если, глядя на код, можно определённо сказать кто его написал, то у вас в компании плохо с кодинг гайдлайнами :)


    1. os_alan Автор
      21.04.2015 17:04
      +1

      В защиту автора, скажу, что в оригинале стоит слово «architecture». Я же перевел как «код» имея ввиду более абстрактное понятие, чем конкретные символы, выражения.

      P.S: А так да, что-то подобное было и в моей практике. Я определял на каком ЯП этот человек программировал раньше и из какой он страны. Заказчики дивились моей прозорливости =))


    1. Humbucker
      22.04.2015 11:02
      +1

      Интересно было бы почитать про орг. меры, направленные на соблюдение всех этих «кодинг гайдлайнов», требований к коммитам и т.п в группе разработчиков размером под 10 человек и более. Очень не хватает реального практического опыта, а не теоретизирования на тему.

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


  1. Xu4
    22.04.2015 10:10

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

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

    Сама идея применить пирамиду Маслоу — прикольная, но выходные данные какие-то нелогичные. Я бы контроль версий объединил с разделом «поддержание».


    1. Humbucker
      22.04.2015 11:13

      Согласен, инфраструктура разработки — широкое понятие, и система контроля версий — только её часть.


    1. Idot
      23.04.2015 17:59

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