Я тут немного экспериментировал со своей диетой и думаю перейти на «палео»-диету. Впрочем, это очень самонадеянно c моей стороны, вот так вот, в корне, изменить свое отношение к еде. В наше время только весьма обеспеченные люди могут позволить себе в полной мере экспериментировать в этой области.
Человек не склонен заботиться о благах высокого порядка до тех пор, пока не удовлетворены потребности более низкого порядка. Ниже пример пирамиды потребностей по Маслоу:
Недавно я общался с заказчиком, где один хороший человек большей частью был озабочен стилем кода: расположением фигурных скобок, применением проверенных решений («best practices») в дизайне интерфейсов и еще кучей важных, но едва ли критичных вещей. В то же время в их организации не было поставлено модульное тестирование («unit-testing»), развертывание («deployment») проводилось вручную, а сборки были слабо верифицируемыми («verifiable build»).
Говоря иначе, он был сосредоточен на проблеме «достаточно ли я потребляю витамина А?», упустив из виду проблему «есть ли у меня вообще что приготовить к ужину?».
Я подумал: что если спроецировать пирамиду потребностей Маслоу на нашу предметную область — разработку ПО? Под катом пример того, что у меня получилось (благодарю Фила Хаака, Джона Галлоуэя, Джонатана Ванагела и Пола Стовела за участие в «мозговом штурме»).
Красивый код
Лучше всех об этом выразился Пол, сказав: «На вершине пирамиды Маслоу лежит самореализация… в какой-то степени я убежден, что нам нравится самовыражаться через код, чтобы, к примеру, спустя пару лет человек, занятый поддержкой нашего проекта, воскликнул, глядя на код: „Класс! Это ведь Скотт делал, да?“.
В самом деле, ты „пишешь софт“ или ты его „разрабатываешь“ (»crafting")? В какой момент разработка становится искусством?
Это весьма благородная и однозначно привлекательная цель. Но, по моему убеждению, стремиться к ней надо лишь после того, как были удовлетворены более насущные потребности.
Реструктурируемый («refactorable») код
Насколько легко провести рефакторинг вашего кода? Не охватывает ли вас уныние при одной лишь мысли о подобной задаче? Соблюдены ли в нем соглашения, принятые для данного языка программирования? Следуете ли вы «духу» выбранного ЯП, используя соответствующие шаблоны проектирования, реализации и решения типовых задач? Используете ли вы в работе автоматизацию тестирования?
Поддерживаемый код
Ответьте на следующие вопросы: реально ли вообще внести изменения ваш код? Исправить ошибки без слез? Если да, то после правки есть ли возможность проверить, не сломалось ли чего? Как там дела с модульными тестами?
Автоматизация сборки и развертывания
Способны ли вы развернуть вашу систему с такой же легкостью, как и собрать версию? Непрерывная интеграция («continuous integration»), несомненно, стандарт в современном мире разработки ПО. Впрочем, есть кое-что на порядок важнее — непрерывное развертывание («continuous deployment»)… с возможностью отката до предыдущей версии.
Управление изменениями
Используете ли вы систему контроля версий? Принятые у вас стандарты работы с изменениями очевидны и понятны всем в команде? Насколько легко вы можете откатить сделанные изменения в коде, пометить текущую рабочую версию кода? А как насчет ветвления и слияния? Что? Вы в архивах все храните? Друг, не надо так… Даже на заикайтесь о дизайне классов и перестаньте колдовать над UML-диаграммами до тех пор, пока не поднята система контроля версий.
Вместо эпилога: о важности лидерства
Вышеперечисленные пункты подчеркивают важность наличия в команде сильного и вменяемого лидера. Творчество — это, конечно, хорошо, но далеко не всегда это то, что нужно для очередного шага к сдаче проекта. Технический лидер должен различать, когда уместны творческие порывы, а когда пришло время по-серьезному вложиться в фундаментальные процессы разработки.
Иными словами: «Достаточно ли зелени в рационе нашей команды? Ммм… давайте начнем с того, что организуем ужин в целом, а там видно будет».
Комментарии (7)
kloppspb
21.04.2015 16:17+3>чтобы, к примеру, спустя пару лет человек, занятый поддержкой нашего проекта, воскликнул, глядя на код: „Класс! Это ведь Скотт делал, да?“
Есть и другое мнение: если, глядя на код, можно определённо сказать кто его написал, то у вас в компании плохо с кодинг гайдлайнами :)os_alan Автор
21.04.2015 17:04+1В защиту автора, скажу, что в оригинале стоит слово «architecture». Я же перевел как «код» имея ввиду более абстрактное понятие, чем конкретные символы, выражения.
P.S: А так да, что-то подобное было и в моей практике. Я определял на каком ЯП этот человек программировал раньше и из какой он страны. Заказчики дивились моей прозорливости =))
Humbucker
22.04.2015 11:02+1Интересно было бы почитать про орг. меры, направленные на соблюдение всех этих «кодинг гайдлайнов», требований к коммитам и т.п в группе разработчиков размером под 10 человек и более. Очень не хватает реального практического опыта, а не теоретизирования на тему.
По моему горькому опыту примерно лишь половина разработчиков из команды понимает зачем всё это нужно, остальные в разной степени считают это необязательными пожеланиями и относятся соответственно. При попытках объяснить натыкаешься на позицию «вот понапридумывали всякого барахла, главное чтобы код работал!». Может и правда всё это лишняя шелуха?
Xu4
22.04.2015 10:10Я вот никак не могу согласиться, что сборка и развёртывание находится выше контроля версий. Придание программе работоспособности — это более базовая вещь, чем контроль версий.
У них, вероятно, контроль версий триггерит сборку проекта. Да, понятно, это прикольное и распространённое решение. Но если убрать контроль версий, то развёртывание всё равно можно делать — от F5 в двухпанельнике до rsync. А при сборке запускаются специфические утилиты — компиляторы/трансляторы/линкеры/т.д. Эти утилиты можно и без контроля версий запускать. Контроль версий в этом случае не может лежать ниже сборки. Контроль версий добавляет удобства разработке а не утоляет базовые потребности.
Сама идея применить пирамиду Маслоу — прикольная, но выходные данные какие-то нелогичные. Я бы контроль версий объединил с разделом «поддержание».Humbucker
22.04.2015 11:13Согласен, инфраструктура разработки — широкое понятие, и система контроля версий — только её часть.
Idot
23.04.2015 17:59И согласен с тем, что контроль версий не является самым важным и критичным. Потому что, если программа не работает, то следующая версия и контроль версий могут вообще не понадобиться, по причине отказа заказчика выбравшего другой продукт вместо вашего.
G12ES
Статья как раз в тему после — «Твой код никого не интересует»