Люди стареют. Вместе со щёлкающей шеей, сединой в бороде и морщинами проявляется ещё одно возрастное изменение - непреодолимое желание вещать.

Политики садятся за мемуары. Спортсмены открывают тренировочные площадки . Режиссёры катают жемчужины воспоминаний о встречах с легендарными коллегами по цеху.

Программисты же бросаются излагать свои философские системы. Меня время тоже не щадит.

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

Кому может быть полезна статья:

• Неистовым фанатам разработки которые не чувствуют себя счастливыми в командной работе.

• Новичкам которые желают набить меньше шишек поднимаясь по карьерной лестнице.

• Бывалым разработчикам с сединою на висках - вспомнить битвы где раньше рубились они и поделиться своим опытом в комментах.

1. Воин исходного кода

Люди увлечённые, фанаты разработки - это самураи исходного кода. Клавиатура - их оружие. Их враги - медленный код, уродливое API, вопиющие косяки существующих систем. Войны исходного кода могут по двенадцать-четырнадцать часов вкалывать "чтобы стало как надо". Их энергии хватит на три рефакторинга в месяц. Они готовы работать по выходным - лишь бы в уродливой неуклюжести кодовой базы блеснули точёные линии совершенства.

Противьтесь, не противьтесь - это важный этап. Как пубертатные прыщи. Как подростковая неуклюжесть. Это нормально. Это необходимо. Натиск переплавится в мудрость мастера.

Режиму берсерка на смену придут зрелые подходы. Но сохраните в себе это неровное дыхание к новаторским, смелым решениям!

2. Внезапные проблемы

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

Попытка объяснить как надо использовать систему выглядит, на первый взгляд, успешной. "Дёргаешь функцию Init() для инициализации, потом UpdateState() и ChangeStatus() в течение жизни объекта и Deinit() напоследок". В ответ: "Во-от оно как, теперь понятно!" Коллега хлопнул себя по лбу и пошёл переделывать. Кажется, всё нормально... Но на очередном ревью история повторяется.

Агитации мало, думает воин исходного кода. Подавив раздражение, садится за доку. Пишет по пунктам: что за чем нужно вызывать. Создаёт схемы жизненных циклов объектов. Кидает коллеге. Тот отвечает: "Вау, супер! Теперь точно понятно!" Переделал, вышло приемлемо. Апрув, в мастер... Ура!.. Но тут приходит новый разраб. И история повторяется как по писанному.

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

Боже, что не так со всеми людьми?!

На этом этапе есть два пути. Один путь простой попервой: решить что все сумасшедшие, с этим ничего не поделаешь и насилие над чужим API у людей в крови. Постулировать для себя - никто ни с кем не договорится.

Простой путь ведёт к келейной фанатичной разработке и, в конце концов, к кабинету психиатра.

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

Вы стоите перед зеркалом.

3. Дизайн кода - это вы

Воин исходного кода часто думает, что пишет код для компьютера. "Оптимизнём логику - векторизируем, разложим cache-perfect по памяти - скомпилируем unity-билдом - идеально!" Кажется, работа воина направлена прежде всего, на то чтобы дышалось легче электронным собратьям: CPU, GPU, RAM.

Но истинное прозрение придёт с осознанием истины. Встретившись с самим собой, воин исходного кода осознает: он всегда писал код для других людей, а не для железки. Битик к битику, учёт каждого такта, проскальзывание между потоков во имя оптимизаций - всё это, на самом деле, было чтобы услышать: "Чёрт побери!.. Парнишка знает что делает! Делаем как он!"

Очевидно, процессор не способен на похвалу; даже если результаты выражен формальной метрикой - "оптимизация времени исполнения в восемь раз" - без восхищения коллег работа не принесёт удовлетворения.

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

Всё это время код был не про работу. Это было обращение к миру: "Смотрите как я думаю, смотрите что мне кажется правильным! Давайте как я!" Поэтому настолько мучительно получить в очередной раз рассеянное: "Ээ, погодь, отвлёкся... Зачем этот метод у тебя вызывать нужно?" - когда речь про своё выстраданное, родное, выкованное в овертаймах, разжёванное на пяти страницах документации. Вы обратились к инфографике, нарисовали схемы, объяснили на словах - но вас всё равно не поняли.

Чёртовы людишки!..

Приходит отчаяние. Видимо, любой проект будет оборачиваться для вас болью. Видимо, никто не поймёт как надо делать, чёрт побери!

Видимо, стоит закрыться хиковать дома, оттачивая до блеска код мечты.

4. Общение - ваше спасение

Нет, не спешите ставить крест на человечестве и на себе! Выход есть!

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

Смотрите на общение с коллегами как на экскурсию по географической местности. Всякий человек (вы, в том числе) - ещё тот домосед в смысле убеждений. За порог палкой не выгонишь. "Мой дом - моя крепость" Соберитесь с духом и терпеливо, шаг за шагом проведите собеседника по землям его понимания до ограды привычного, по дорожке мысленных экспериментов, через речку сомнений - до границы его познаний. Ваша главная задача - подвести его к этой границе с нужной стороны: там где его убеждения прилегают к территориям вашего понимания мира.

Звучит слишком психоделично... Давайте разберём пример.

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

Так, стоп! В первую очередь - не раздражаться. Вы ведь знаете слабые места мутабельности, верно? Вспомните какую-то недавнюю задачу вашего коллеги. Похвалите его за то что вам искренно понравилось в его решении и с участием задайте вопрос по возникшим трудностям: "Слушай, это ты ведь делал базовый класс для способностей игрового персонажа? Штука что надо, все ждали эту фичу: копи-паста ушла из пяти классов. И в мастер быстро зашло, да!.. Верно, я спрашивал на ревью про ассерты в сеттерах и на каждом апдейте... Хм, всё равно упало из-за влияния модификаторов на логике накопления маны?.. Расскажи, что там было?"

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

В какой-то момент коллега выговорится. Если вы правильно задавали наводящие вопросы, он окажется в этот момент на границе своих познаний - с нужной вам стороны. Проведите ему экскурсию по своей территории.

Разгул диктатуры в аргументах - не наш метод. Устройте максимально дружелюбную экскурсию по своему пониманию. "Слушай, а вот представь: что если бы класс менялся только раз - при создании. Как это?.. Начальная инициализация в конструкторе и вычисление состояний каждый раз заново вместо накопления его в тике... Да, увы, будут ограничения, хорошее замечание - от сеттеров придётся избавиться. Перфа может сесть - но незначительно, тут же сложить-умножить и по памяти на стеке всё считается... Но ты смотри какая штука выходит: не надо следить за каждым значением при каждом тике! А все ассерты уходят в конструктор. И больше нигде они теперь не нужны в принципе! Проверка консистентности состояния в конструкторе - и всё... Не надо боятся что каждый тик в состояние закрадётся ошибка"

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

Неделя-другая - и у вас есть союзник. Вы добились от него понимания - поняв в начале его самого.

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

Давайте разберём ещё один пример.

Допустим, коллега - убеждённый фанат функционального программирования. Вы же в своём API меняете состояния объектов на каждом тике, что коллеге кажется не лучшим решением. Обратитесь к его недавней задаче: "Помнишь, ты делал крутой класс для работы со способностями игрового персонажа?.. Там ещё у тебя здорово вышло избавиться от ассертов: проверки отправились в конструктор и код класса очень чистый получился. Ага... Оу, перфа села?.. Из-за копирований? Хм. А где именно?.. Жаль. И без копирования на тике никак не вышло?"

Искренно вникайте в его слова. Согласитесь как здорово было бы держать объекты в самосогласованом виде с минимальной вариативностью состояний (действительно ведь крутая концепция). Разделите боль что увы, эта концепция работает без просадок лишь если объекты выделять на стеке - а движок, собака, не позволяет создавать наследников от базового движкового объекта на стеке, только в подконтрольной сборке мусора динамической памяти. "Пытался сделать пулл короткоживущих объектов? Интересное решение... Тоже не выгорело? Блин, жаль... А что ещё пытался сделать?"

В какой-то момент он выговорится. Если вы задавали правильные вопросы, он готов пройтись с вами по свободным землям без догматов функционального программирования. "Слушай, а что если бы были поля - не все, некоторые! - значения которых менялись бы не только конструкторе?.. Да, нужно будет добавить проверок: два-три ассерата... Но проблема с лишними копированиями уйдет ведь так?".

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

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

Что ж. Наступите на горло собственной песне и попробуйте сделать так как кажется правильным вашим коллегам. Потерпите месяц. На проекте будет копиться опыт проблем с привычной для них парадигмой. Однажды за чаем вы спросите: "Слушай, я помню ты отличный класс написал недавно - для модульных заклинаний... Оу, снова упал на плейтесте? Неприятненько... Расскажи, что там было?"

Итого: Чтобы вас слышали - научитесь слышать сами! Выучите понятийные языки на которых говорят другие люди. Учитесь общаться с людьми на их языке!

5. Бремя программиста

Да... Вы, вероятно, возмутились моим примерам? Жульничество и софистика: в начале показать функциональное программирование как правильное решение, а потом привести обратный пример. Это разве честно?

Всё верно. Решение не вышло чисто функциональным. Не вышло по-мутабельному гибким в использовании... Но результат - это общее решение. Впитавшее опыт двух человек. Результат: взгляды на написание кода согласованы. Остаётся написать для практики ещё пару-тройку классов в общей парадигме, утрясти нюансы в нескольких коротких дискуссиях - всё! Не нужно дёргать друг друга по поводу подходов к организации API. Не нужно обижаться за то что окружающие глухи к вам. Вы работаете как команда, вы чувствуете и понимаете друг друга.

Это win-win стратегия коммуникации.

Бремя программиста - быть хранителем порядка в бездне хаоса. Быть пристальным и въедливым. Не уступать фронт бардаку. И злая ирония: источником энтропии зачастую выступают сами же разработчики, не способные принять позиции друг друга для выработки общих подходов.

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

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

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

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

6. Заключение

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

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

Не бойтесь говорить и умейте слушайте.

Меняйте мир к лучшему!

Он того стоит.