«Программирование лучше секса»
Эту фразу на заре своей трудовой деятельности я услышал от начальника отдела АСУ одного из Советских заводов, когда он предлагал идти работать к нему в отдел.
Естественно, тогда я не считал, да и сейчас не считаю, что программирование может быть заменой хорошему сексу. Но только спустя годы смог в полной мере оценить глубину эмоций, которую он вкладывал в свою крылатую фразу. В том числе и потому, что сам иногда испытываю трепетные чувства при создании совершенной архитектуры или красивого программного кода. И хотя понятия о красоте у каждого человека может быть свое, но тяга к совершенству бывает у всех одинаковая.
Однако, эмоции это одно, а человек инженер разумный, это другое. И меня давно занимал вопрос, а в чем же реальная причина по которой хочется делать код красивым?
Кому интересно размышления о логическом обоснование поиска прекрасного в разработке программного обеспечения и в других технических дисциплинах, прошу под кат.
Предисловие
Толчком к написанию данной статьи послужил недавний материал на Хабре «Хватит уже бояться субъективно красивых решений в коде — вы же не роботы», в которой автор пытается обосновать свою интуитивную тягу к созданию красивого кода.
Однако, судя по комментариям к той статье, не все читатели разделяют аргументы автора на уровне «инженерной чуйки». Хотя есть и согласные подобной аргументацией:
«Конечно, код должен быть красивым. Ёлки-палки, ВСЁ в жизни должно быть красивым! Иначе, если что-то уродливо, можно железобетонно сказать «это баг» (иногда с этим приходится жить, но это — баг!)»
Правда другие предлагают сопротивляться внутреннему голосу и не откладывая начать лечение «патологического перфекционизма, который может быть видом обсессий, компульсий или ОКР».
Но если отбросить стеб и шутки, то феномен тяги к красоте замечен с давних времен и не чужд любой из технических дисциплин. Ведь вряд ли кто будет спорить, что результат работы архитектора или инженера по проектированию автомобилей не может быть одновременно и техническим и эстетическим совершенством.
Но для меня ближе разработка программного обеспечения, о которой дальше и пойдет речь.
Таинства процесса творения программного обеспечения
К разработке ПО можно подходить с разных сторон. С одной стороны, это сугубо техническая дисциплина, которая не допускает вольностей, построенная на жестком и последовательном подходе к разработке. Это давно выверенный и отлаженный процесс, который включает в себя сбор требований, разработку ТЗ, планирование, контроль выполнения планов, оформление полученных результатов и т.д.
Другой вариант разработки программного продукта, это бесшабашный Agile, который плюет на условности и превозносит желания заказчика. Он готов хоть каждую итерацию переделывать архитектуру программного продукта в попытке достичь желаемого результата. Такой способ больше похож на искусство достижения баланса между получением работающего ПО и полным исчерпанием доверия и ресурсов заказчика.
И только со временем начинаешь понимать, что прописные истины гораздо гибче. И в четком водопаде есть толика гибкости, и в Agile есть планы и сроки. Поэтому истина как всегда, где-то посередине.
Но все это касается только внешней стороны рабочего процесса. А самое печальное, что создание красивого кода никаким образом от этого не зависит.
Более того, один и тот же код может быть признан и красивым и уродливым одновременно! А это означает, что понятия о красоте сугубо индивидуальны (кто бы сомневался). Что такое красивый код, и как его писать?, Итоги 20-го международного конкурса непонятного кода на C.
Поэтому пришлось копать глубже, до основания этого процесса. В сторону личной индивидуальности разработчика, который может выступать в роли программиста, архитектора, тестировщика, аналитика или быть даже всем ими сразу одновременно или в разные моменты времени.
Так что же движет этими винтиками, в маленьких компаниях и больших корпорациях, в бездушных машинах индустрии генерации программных продуктов?
Конечно, поиск движущей силы не может обойтись без психологии.
В чем же движущая сила?
Нет, я не собираюсь цитировать научные работы по психологии или личностной мотивации. Сейчас любой при желании найдет множество статей по данным темам.
Мне же была интересна классификация побудительных причин, мотивирующих разработчиков создавать программный код. Так как была надежа, что в этом можно отыскать причину тяги разработчиков иногда оценивать исходники с эстетической точки зрения.
К сожалению, мне так и не встретилась подобная классификация (возможно, я не нашел или не там искал), поэтому в результате анализа собственного опыта и общения с коллегами, решил самостоятельно выделить следующие типы мотивации разработчиков с условными названиями: Материальная, Социальная и Внутренняя.
Материальная мотивация
Данный тип мотивации основан на экономическом стимулировании. Разработчику все равно, что и как писать. Он будет стараться придерживаться утвержденного стиля кодирования в проекте и его не заботит красота кода. Соответственно, и оценка результатов работы (как своей, так и результатов работы коллег), будет происходить с формализованной точки зрения, где нет места эстетике.
Социальная мотивация
В этом случае главным мерилом оценки результатов работы выступает мнение коллектива, которым может быть коллеги по работе, друзья по университету и т.д. Причем оценка производится не только по формальным критериям на соответствие стилю кодирования. Тут уже присутствует и эмоциональная составляющая, некий абстрактный критерий красоты.
А для разработчика уже становится важным, что бы результат его работы был в первую очередь принят и одобрен в коллективе, а материальные причины могут уходить на второй план. В самых запущенных случаях разработчик готов писать код даже «за еду», что бы удовлетворить чувство собственной значимости среди целевой группы или в своей социальной среде.
Внутренняя мотивация
Подобная мотивация очень похоже на социальную, только оценивающим фактором выступает не коллектив, а непосредственно сам разработчик. При внутренней мотивации материальные стимулы полностью отсутствуют, а результат работы может вообще никогда не быть опубликованным, т.к. он уже принес (или продолжает приносить) удовлетворение своему автору просто самим фактом своего существования и не требует никакой подтверждающей оценки со стороны.
Конечно, подобное разделение мотивов работы программистов является условным и может перетекать из одного типа в другой или даже являться комбинацией сразу нескольких мотивирующих факторов.
Но если смотреть на результат труда программистов с этой точки зрения, то в подобной системе классификации уже можно найти некую логику и пытаться найти красоту практически в любом исходном коде.
typedef unsigned char t;t*F="%c",l[]="|\\/=_ \n](.\0(),*(.(=(}*.)[[*.",N='\n',*
r;typedef(*H)();extern H Ar;Q(a){return(a|-a)>>31;}H S(c,a){return(H)(a&~c|(int
)Ar&c);}extern t*ist;V(t*u){*u^=*u&2^(*u>>7)*185;}Z(t*u,t n){*u-=n;}e(t c,H h){
R(h,Q(* r^c));}
I(){r=l +7-4*Q(
getchar ()^*l);
}R(H h, int c){Ar=S
(c,h);- main() ;}P(){r
++;}z() { O(&N);}
O(t*c){ printf( F,+*c);
}T(){r= "This is not a function\n" ;}w(U){
U=Z(r,8 ); r-=~Q(*
r/8-4); return 0; }M(){r=
ist-68; } h(){t G
=r[1]-r [2]^*r;
G^=30;V (&G);e(
0,(O(&G ),P(P(*
r++)),z));}g(){M();R(h,0);}f(){P(O(r));e('f',g);}p(){P();e('a',f);}d(){P(O(r));
e('n',p);}c(u){u=r[-2];T(Ar=d);R(f,Q(u^'"'));}n(){e(w(O(l+*r%8)),c);}a(){I();R(
n,0);}main(){S(Q(Ar),a)();}H Ar;t*ist="Rene Magritte"-(1898-1967);Когда шутка заставляет задуматься
Изначально эта статья писалась как шутка, да и её название говорит за себя, поэтому и картинку подобрал соответствующую.
Каково же было мое удивление, когда я понял, что сформулированная классификация мотивов тяги программистов к красоте мне очень сильно что-то напоминает. Эти мотивы очень четко проецируется на известную пирамиду потребностей Маслоу.
Материальная мотивация закрывает потребности в основании пирамиды. Это физиологические потребности и потребность в безопасности. Социальная мотивация приходится на середину пирамиды и приводит к удовлетворению потребностей в принадлежности, любви и признании. И, наконец, Внутренняя мотивация очень четко проецируется на самый верх пирамиды и закрывает потребности в познании, эстетике и самоактуализации.
Это уже не шутка?
В результате не серьезной попытки изучить тягу к прекрасному у программистов, получились вполне обоснованные выводы, которые при желании можно использовать в индустрии разработки программного обеспечения.
Ведь в случае появления реальной методики оценки красоты кода с точки зрения мотивации, уже не составит большого труда добавить её в различные утилиты для оценки стиля кодирования, такие, как pylint, cpplint и прочие lint. И после это появится возможность оценивать мотивацию конкретных разработчиков без проведения каких либо психологических тестов и заполнения нудных опросников. Достаточно будет пропустить их код через анализатор.
Возможно, я даже выпустил джина из бутылки, т.к. если появится возможность измерять мотивацию по создаваемому коду, то следующим естественным шагом будет переход к её управлению. Ведь такой способ оценки мотивации очень легко автоматизируется, а там, где есть возможность для оперативного измерения, появляется и возможность для оперативного управления измеряемым параметром.
Другими словами, наличие у менеджеров проектов оперативной информации о душевном состоянии членов команды будет помогать им оценивать результаты попыток смещения мотивации в сторону социальных или внутренних побуждений, естественно, чтобы сэкономить на экономических стимулах. ;-)
