Хабрахабр

«Мы все стремимся к сложности, а потом с ней боремся»: интервью с Венкатом Субраманиамом

Зависит от того, выступает ли в то же время в соседнем зале Венкат». «Сколько зрителей придёт на ваш доклад по Java?

Он неустанно перемещается по всей планете и недавно поставил впечатляющий рекорд, к своему 50-летию выступив за один год перед 50 разными Java User Groups. Это шутка с изрядной долей правды: в Java-мире Венкат Субраманиам — один из самых известных спикеров, действительно способный на конференциях оттянуть зрителей из других залов.

И что Венкат думает об актуальных Java-вопросах? Каково это, когда твоя Java-карьера — не «сидеть в офисе», а «постоянно перемещаться»? В октябре он доберётся до Петербурга, и в преддверии этого мы (phillennium, olegchir) взяли у него подробное интервью, где начали с «жизни в самолёте» и советов для начинающих спикеров, а затем перешли к технологиям.

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

За жизнь

— Начнём с вашего тура, в ходе которого вы посетили 50 Java user groups, вряд ли кто-либо ранее делал подобное. Какими оказались ваши впечатления?

Когда мы начинаем говорить о программировании, выясняется, что проблемы, с которыми мы сталкиваемся каждый день, одинаковые. — Интереснее всего для меня было осознание того, что в разных культурах в разных частях света люди, говорящие на разных языках, несмотря на все эти различия, объединены программированием как единой связующей нитью. Я могу без конца перечислять случаи, когда я оказывался вовлечён в разговоры про Java на другой стороне Земли. Это стало большим открытием для меня — вы можете встретить программиста в любом аэропорту мира, и у вас обязательно найдутся общие темы для разговора.

Руководить юзер-группой — это очень сложная… не хочется говорить «работа», поскольку это не работа, но усилий приходится тратить много. Поэтому опыт с этими группами был очень полезным для меня. У разных групп разная динамика — у одних на встречах присутствует 20 или 30 человек, других — 200 или 300. Я с огромным уважением отношусь ко всем руководителям, которые вновь и вновь каждый месяц собирают эти мероприятия. Так что мне очень повезло, что досталась возможность встретиться с этими группами, и я очень благодарен за неё. И тем не менее количество, в сущности, не играет роли, поскольку главное — это страсть разработчиков, приходящих на эти собрания, их интерес к технологиям и их желание учиться.

— А при упомянутом вами сходстве есть ли у юзер-групп в разных частях света какие-то заметные местные отличия?

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

Это общий тренд практически везде. Мы все стремимся к сложности, она нас затягивает, а когда затянет, мы начинаем с ней бороться. Я могу рассказывать о некотором примере людям в любой точке Земли, и после моего рассказа меня спросят: «вы случайно не работали в нашей фирме?» Наши проблемы настолько глубинные и универсальные, что, судя по всему, они общие для всего мира. Другая важная проблема, которой не избежал никто — это жёсткие требования бизнеса и недостаток времени для работы над качеством. Сколько бы мы не представляли себя гиками, повёрнутыми на технологии, мы не должны забывать о человеческом аспекте в разработке софта. Что невольно заставляет задуматься о нашей общей человеческой сущности, о психологии и философии, которым мы, в конечном итоге, следуем. Судя по всему, он является объединяющей и универсальной силой.

Когда сидишь в офисе, может быть неочевидно, понравилась ли бы жизнь наподобие вашей. — Хочется поспрашивать о «походном» образе жизни. Но, возможно, с практикой к этому приспосабливаешься? Например, для многих джетлаг — это проблема, и из-за этого постоянные перелёты могут казаться кошмаром.

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

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

Из-за постоянных перелётов у меня в определённом смысле нет постоянного, «домашнего» времени. Если же говорить именно о смене часовых поясов, то она меня не беспокоит вовсе. 30 ночи, и тело очень быстро входит в определённый ритм. У меня есть правило: я просыпаюсь всегда в одно и то же местное время, около 3. Ну и, конечно, кофе всегда очень кстати.

Удаётся ли вам посмотреть на города, или из-за нехватки времени только на конференц-залы? — Многие люди хотели бы увидеть мир, но они обычно ездят в туристические поездки, а не в деловые.

Но, помимо этого, из-за постоянных перелётов у меня есть некоторые принципы, которых я придерживаюсь. — Да, отчасти здесь проблема со временем. Я стараюсь провести как можно больше времени с разработчиками. Если путешествие связано с работой, то ничем, кроме работы, я не занимаюсь. Мне доставляет огромное удовольствие общение с разработчиками, поэтому в своих деловых поездках я практически никогда не хожу по достопримечательностям. Когда у меня есть свободная суббота или воскресенье, например, в Европе, то я обычно трачу её в юзер-группе.

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

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

В фильме «Up in the Air» персонаж Джорджа Клуни, постоянно летающий между городами, знает много приёмов для повышения эффективности путешествий: как стоять в очереди, как упаковывать багаж и так далее. — Последний вопрос о путешествиях. Возможно, у вас тоже есть некоторое неочевидное знание, которым вы хотели бы поделиться?

Часто, когда я прибываю в отель, моя одежда уже лежит там, а когда я уезжаю, я отправляю её домой. — Мне стыдно в этом признаться, но я иногда пересылаю одежду между городами по FedEx, потому что у меня попросту нет времени на то, чтобы прилетать домой и брать одежду на следующую неделю. Был один неловкий момент, когда моей жене пришлось отправиться в аэропорт, чтобы передать мне сумки, потому что у меня было только полчаса между рейсами. К счастью, это происходит не слишком часто, возможно, три или четыре раза в год, когда я нахожусь в пути по три недели кряду. Меня иногда удивляет, когда люди говорят «мне нужно собраться», потому что мои вещи всё время собраны. Но со временем действительно учишься делать некоторые вещи более эффективно.

Мы живём в мире Facebook, Twitter и различных мессенджеров, они постоянно нас отвлекают. Если говорить об эффективности, у меня есть по меньшей мере одно преимущество: я весьма однозадачный человек. Обычно у меня есть журнал, в котором я записываю вещи, которые необходимо сделать за каждую поездку. Я очень много работал над тем, чтобы это влияние сократить, потому что минуты превращаются в часы, часы превращаются в дни, дни превращаются в недели, и рано или поздно осознаёшь, что не удалось достичь того, что хотел. За восьмичасовой перелёт я вполне могу написать большую часть одной главы книги, или подготовить пример для курса. Таким образом, у меня есть расписание на каждый день (например, на 7 ноября или 8 октября), и мой телефон напоминает мне о каждом задании в соответствующий день. Мне никогда не нужны дополнительные развлечения во время полёта — вполне достаточно развлечений, связанных с отладкой кода. Поэтому перелёты для меня — крайне эффективное время. Так что профессиональный путешественник (если такой термин вообще применим) тратит время в полёте совсем иначе, чем турист.

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

Обычно мне приходит 20 или 30 писем в день. — Стоит добавить, что я преподаю в университете и получаю много писем от студентов. Где-то год тому назад я писал в блоге об одном из своих принципов: «ответь сейчас или скажи, когда ответишь».

На мой взгляд, уважение к другому человеку заключается не в обращении «sir», а в том, чтобы ценить время друг друга. Я очень ценю своё время, а это значит, что я ценю время других людей. Но бывают периоды, когда дать полноценный ответ не выходит — например, если организатор конференции просит прислать аннотацию или если коллега по отрасли задаёт вопрос о решении определённой проблемы, просит провести рефакторинг некоторого кода или спрашивает о применении некоторого метода. Поэтому если мне приходит письмо, я всегда отвечаю в течение 24 часов. Это может прозвучать немного странно, но я всё равно в таких случаях отвечаю в течение 24 часов и пишу: я получил ваше письмо, я поработаю над этой проблемой, скажем, 2 сентября и напишу вам 3-го. Иногда ответ может занять десять минут, а иногда два часа, но даже десять минут не всегда можно потратить. Одновременно с этим мой календарь пополняется соответствующей записью в день, когда у меня есть время в полёте или после обеда.

Так что я крайне дисциплинированно отвечаю на письма. Благодаря такому подходу мой ящик входящих сообщений всегда пуст, я чищу его каждый вечер перед сном. Я не хочу стоять на пути у людей, мешать им развиваться. Люди часто удивляются, что я так быстро отвечаю на их письма, а я, наоборот, не понимаю, как можно иначе. Я люблю повторять, что чем чаще вы говорите «да», тем хуже у вас будет получаться то, что вы делаете. Кроме того, я считаю важным способность сказать «нет». Поэтому иногда я отвечаю, что, к сожалению, не могу ничем помочь. В определённый момент нужно осознать, что мы не можем достичь всего на свете. На мой взгляд, это тоже говорит об уважении к человеку и нежелании тратить его время впустую. В свою очередь, я предпочитаю, чтобы мне говорили «нет» сразу, а не тянули резину и говорили «нет» потом. Поэтому важно говорить «нет». Вы не обязаны помочь, но, по меньшей мере, не мешайте. Для меня умение быстро и честно отвечать является знаком профессионализма. Так устроена жизнь, не стоит пытаться сделать вид, что вы можете успеть всё на свете.

Как организаторы конференций, мы встречаем людей, которые не имеют опыта публичных выступлений или имеют совсем немного. — Вы очень опытный докладчик. У вас в твиттере был интересный совет «заранее посетить зал, в котором будет проходить доклад» — есть ещё подобные? Возможно, у вас есть рекомендации для них?

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

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

Во-первых, вы получите критику от коллег, что позволит вам улучшить доклад. В юзер-группах или в компании, где вы работаете, у вас есть замечательная возможность попрактиковаться с выступлениями. Я считаю, что по-настоящему улучшить доклад удаётся с третьего раза. Во-вторых, даже если прямо вам ничего не скажут, вы всё равно многое поймёте сами, когда начнёте говорить. И вот что интересно: практиковаться в одиночку здесь не поможет, осознание проблем приходит только во время выступления перед другими людьми. В первый раз вы только пытаетесь свести все мысли вместе. Это не всегда заметно, но я иногда приостанавливаюсь во время выступления на третий раз — в этот момент я осознаю, что именно я пытался сказать в докладе, наступает своего рода момент истины. К третьему разу логическая цепочка вашего повествования становится более ясной для вас, оказывается завершённой. Молодому разработчику это может придать необходимую уверенность. Итак, очень важна практика, но не наедине с собой, а с людьми.

Иногда для человека проще умереть, чем выступить на публике, и их легко понять — это требует очень много нервов. Правда, некоторые делают свои первые доклады на конференциях. Ко мне подошёл очень заинтересованный человек и сказал, что я, по-видимому, сильно переживаю, на что я ответил, что это действительно так. Два или три года назад я выступал на одной конференции. Каждое выступление перед публикой требует большого эмоционального напряжения, даже если у вас есть большой опыт, просто потому, что вам небезразлично, как пройдёт доклад. Он спросил «Это ваш первый доклад?», а я ответил: «Нет, скорее десятитысячный, потому и переживаю». Это касается всех докладчиков, в том числе опытных. Вы сослужите себе большую службу, если облегчите это напряжение несколькими пробными докладами в группах пользователей или в вашей компании.

— А есть в публичных выступлениях что-то, чего, наоборот, следует избегать?

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

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

Для начала, людям следует смотреть в глаза. Хотел бы также рассказать о некоторых отрицательных привычках во время выступлений, которые, на мой взгляд, есть у разработчиков. Докладчики часто смотрят на свой монитор или, ещё хуже, на экран, встав спиной к аудитории. Я понимаю, что это очень тяжело и требует большого эмоционального усилия, но в этом нужно практиковаться. Кроме того, необходимо сохранять уверенность в себе. Всегда нужно быть обращённым лицом к слушателям и всегда следует смотреть на них. Если ваша демонстрация во время доклада не сработала — в этом нет ничего зазорного. Вы выступаете перед аудиторией программистов, и можно побиться об заклад, что ни у одного из них код не работает с первого раза. С годами я научился в таких ситуациях обращаться к аудитории за помощью с отладкой. Все присутствующие скорее всего подумают: «Чёрт, у меня всё точно так же». Вместо этого следует спросить аудиторию — друзья, не подскажете, где я туплю? Обычно докладчики в такой ситуации начинают бормотать себе что-то под нос и пытаются решить все сложности самостоятельно. Говорить и писать код одновременно одному человеку сложно, не бойтесь попросить о помощи. Вам тут же поступит множество предложений, и очень часто они помогут вам найти ошибку. Это одна из причин, по которой я посещаю доклады других людей: посмотреть, что они делают, и понять, чего именно делать не следует. Для слушателей этот опыт также ценен. На мой взгляд, эти привычки помогут вам провести рефакторинг ваших навыков докладчика.

О технологиях

— Автор известных Java-книг Кай Хорстманн рассказывал нам, что предлагал упростить в Java создание «Hello world». Потому что новички при виде «public static void main» сталкиваются со множеством новых понятий одновременно, и это отпугивает, разумнее более постепенный вход.

Вы как преподаватель, автор книг и докладчик тоже учите людей. Интересно вот что: Java-разработчики редко задумываются о пользе подобного, потому что им эти вещи уже кажутся само собой разумеющимися, а Хорстманн это понимает, потому что преподаёт в университете и лично видит испуг на лицах студентов. Вам из-за этого тоже хочется что-то изменить в Java?

Больше того, это одна из тех вещей, которые меня привлекают в Java — это уже совсем не тот язык, каким он был в 2000-м. — Да, определённо. За последние несколько лет создатели языка стали осознавать, что когда язык становится многословным и напыщенным, это существенно затрудняет работу программистов, причём не только начинающих.

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

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

Когда вы точно знаете, что именно хотите написать, Java работает идеально, но обычно программирование выглядит иначе. Именно поэтому Java 12, 13 и 14 эволюционируют в эту сторону: разработчики осознают, что, хоть Java и крайне мощный язык, с ним не очень просто экспериментировать, и ему сложно учиться. Если я работаю в компании с наработанной базой кода и определённой структурой кода и если я добавляю приложению новые возможности на основе уже существующих шаблонов, эти изменения меня существенно не затронут, здесь Java прекрасно работает в уже существующей форме. Вы всегда учитесь и экспериментируете, у вас всё время рождаются идеи, которые ранее казались бы невозможными. Поэтому, на мой взгляд, важно, чтобы языки эволюционировали в сторону меньшей напыщенности, и я большой сторонник того направления, в котором Java сейчас изменяется. Но если вы архитектор, тимлид или просто программист, который пишет код новаторски и экспериментирует, то Java в сегодняшнем виде будет во многом вас ограничивать.

В октябре Венкат откроет нашу петербургскую конференцию Joker выступлением «Don't walk away from complexity, run». Минутка рекламы. И, поскольку каждый докладчик Joker после выступления отправляется в дискуссионную зону, там будет возможность лично обсудить с ним и тему выступления, и другие вопросы.

— В контексте «менее напыщенная Java» невозможно не спросить вас о Kotlin, который часто так и называют.

И дело не только в меньшей вычурности. — Да, это действительно так. Одна из возможностей в Kotlin — запустить лямбду в контексте объекта, несмотря на то, что она не является частью класса. Для меня одна из самых захватывающих вещей в жизни — это знакомство с новыми языками и их возможностями. Там вы можете передать в вызове контекстный объект (то, что в Kotlin называется receiver), а затем выполнить эту произвольную глобальную функцию так, как если бы она была функцией некоторого объекта. Я очень заинтересовался, когда об этом узнал, потому что та же самая возможность присутствует в JavaScript. Но Kotlin — язык статический, и он делает то же самое, при этом соблюдая типобезопасность. В том, что эта возможность есть в JavaScript, нет ничего удивительного, поскольку этот язык динамический. Но на этом преимущества не заканчиваются, поскольку эта возможность позволяет создавать внутренние DSL. Отсутствие вычурности, безусловно, является большим преимуществом языка, как и тот факт, что значительную часть кода он генерирует автоматически, благодаря чему мы можем не писать одни и те же шаблоны снова и снова.

Наша область сочетает науку и искусство, от этого никуда не деться. Меня в программирование привели наука и математика, но 30 лет спустя остаюсь я программистом благодаря тому, что это искусство. Код для любого задания можно написать множеством различных способов. Умением просто заставить систему работать дело не ограничивается, здесь можно провести аналогию с написанием стихов: попросите двух человек написать о любви, и каждый напишет по-своему. Вы можете значительно меньше думать о синтаксисе языка и больше — о той мысли, которую хотите передать. Именно это меня привлекает в языках наподобие Kotlin и многих других: возможность выражать некоторые из этих идей, придавать коду гибкость и лёгкость.

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

Когда мне говорят, что код читаемый, я спрашиваю — кто его читал? — Я убеждён, что единственный способ написать читаемый код — это прочитать его. Поэтому я убеждённый сторонник код-ревью. Если его прочитал сам автор непосредственно после написания, это не считается. Это неизбежно приводит к обидам, такое публичное охаивание никому на пользу не идёт. Хочу пояснить: я против того, чтобы приводить команду в комнату с большим экраном, показывать на нём код и критиковать его.

Я с гордостью готов признать: мой код — отстой, я не умею писать хороший код. Нужно честно признать: все мы пишем плохой код. Всегда необходимо возвращаться и проводить рефакторинг, и даже когда я это делаю, у меня обычно ничего не выходит. Если вы спросите, как это сочетается с моими разговорами о качестве кода, я отвечу: написание кода — процесс с постоянными инновациями, и когда вы пытаетесь реализовать некоторую идею, качество кода вас не слишком беспокоит. Поэтому вместо того, чтобы делать вид, будто бы мой код и так отличный, я напишу его настолько хорошо, насколько смогу, и отдам вам на проверку, а сам тем временем возьму код коллеги и проверю его. Но с годами я понял, что, хоть мой собственный код и низкопробный, но у меня очень хорошо получается находить изъяны в чужом коде. В итоге и мой код, и код коллеги будут более высокого качества.

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

Не говорите: «Боже, какое жуткое название переменной», лучше так: «Ты, наверное, хотел сказать, что эта переменная показывает частоту распределения — наверное, её следует назвать соответствующим образом». Ещё один важный момент: не надо говорить человеку, что он сделал ошибку, надо сказать, что именно можно улучшить. Это также касается редактуры книг: говорите не только о том, что нужно улучшить, но и о том, что было сделано хорошо. Это поможет вам лучше передать ваши намерения. Когда я редактирую чужой код и вижу место, которое качественно выполнено, я пишу в комментарии, что мне оно очень нравится, что нам нужно чаще так делать, и объясняю, почему именно. Мы это часто забываем. Это создаёт конструктивную обратную связь, даёт разработчику понять, что вы не настроены к нему враждебно, и в конечном итоге улучшает качество кода вашей команды.

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

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

А дальше можно поступать разными способами. Когда же выбора нет, вместо того, чтобы жаловаться, следует обозначить болевые точки: что именно делает этот инструмент неудобным для вас. Либо можно провести хакатон — собраться на выходных вместе с несколькими разработчиками, организовать юзер-группу, сказать им, что вы проводите по девять часов в день с этим инструментом, что он ужасен, и попросить попробовать добавить к нему некоторые возможности. Можно связаться с разработчиками и сказать — спасибо за ваш труд, нам кажется, что ваш инструмент мог бы быть значительно лучше, если бы вы обратили внимание на такой-то и такой-то аспект.

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

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

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

Моё понимание этого понятия эволюционировало с годами, и сейчас для меня наиболее главное в функциональном программировании — это удаление посторонней сложности. — Это замечательный вопрос. Для меня функциональное программирование является надстройкой над декларативным стилем программирования, в котором мы указываем, что нужно сделать, но не говорим, как именно. Речь идёт о том, что в императивном программировании вы не только указываете, что именно нужно сделать, но и детально прописываете, как это нужно сделать.

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

Через композицию функций. Каким же образом происходит удаление этой посторонней сложности? Причём для нас важно не то, как каждый из этих шагов выполняется, а чего именно он достигает. При композиции функций ваш код проходит ряд преобразований, в ходе которых данные переходят из одной формы в другую. Проблема в том, что многие языки, в которых реализована функциональная композиция — Ruby, Python, JavaScript, Groovy и так далее — обеспечивают благодаря этому элегантность и выразительность, но обладают весьма низкой производительностью. Для меня первый аспект функционального программирования — функциональная композиция. Я же считаю, что элегантность без эффективности нежизнеспособна. Функциональная композиция в них реализована неэффективно. И здесь мы подходим ко второму, жизненно важному аспекту функционального программирования — речь идёт о ленивых вычислениях. Мало того, чтобы код был красивым, он также должен быстро работать. Благодаря этому в функциональном программировании достигается сочетание элегантности и эффективности. Результат определённой функции рассчитывается только в тот момент, когда он оказывается необходим. Итак, для меня функциональное программирование — это акцент на том, что делать, а не как делать; использование функциональной композиции как ряда преобразований данных; и возможность выполнять эти преобразования эффективно благодаря ленивым вычислениям.

Дело в том, что они — только ингредиенты для получения описанного мной результата. Обратите внимание, что я не говорил о иммутабельности и функциях высокого порядка. Мы пользуемся функциональным программированием не для иммутабельности и функций высокого порядка, они только средство для достижения более высокой цели: избавления от посторонней сложности.

Сегодня существует язык, который является эталоном того, каким должно быть функциональное программирование: Haskell (и, возможно, F#). — Прекрасное определение.

— Совершенно верно.

Но Java, очевидно, не Haskell, она во многом ограниченна. — По крайней мере, многие так считают. Ведь в нашем языке весьма ограниченный набор средств для такого подхода. Имеет ли смысл функциональное программирование как дисциплина в применении к Java?

Совершенство мне любопытно, но чтобы всё работало, я должен быть прагматиком. — Для меня скорее важен прагматический аспект, а не стремление к совершенству. Но для моих клиентов я на Haskell не пишу. Я без ума от Haskell и очень много времени провожу с ним, просто чтобы узнать, как та или иная задача решается в функциональном программировании. Собор прекрасен, но большую часть времени я провожу на базаре. Здесь можно провести аналогию с «Собором и Базаром». Когда языки эволюционируют и когда мы пытаемся соединить вместе несколько различных парадигм, нам, как программистам, нужно быть крайне осторожными с их реализацией. Вопрос в том, как выжить в этом мире.

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

Недавно я познакомился с языком Elm, который представляет из себя синтаксис Haskell с вкраплениями F#, который компилируется в JavaScript. Это одна из причин, по которым мне очень нравится изучать новые языки. Когда вы путешествуете по JavaScript, вы постоянно наступаете в лужи. Такой подход меня с самого начала заинтересовал, потому что JavaScript — это базар. И тем не менее этот соборный код оказывается возможно запустить на базаре. Elm же благодаря синтаксису Haskell однозначно является собором. Первый главный принцип заключается в том, что данные хранятся во view. Архитектура Elm изящна, в ней есть модель (то есть данные), есть view, который отображает эти данные, и есть преобразование, update. Данные неизменяемые, и функция update возвращает новые данные, которые view сохраняет вместо старых. Когда пользователь выполняет какое-либо действие (нажимает на клавишу, например), данные из view отправляются в функцию update, где происходит преобразование.

В нём существуют данные и существуют преобразователи reducers. Если подумать, то ровно по такой же схеме функционирует Redux. Но если Elm и Redux функционируют по одной и той же схеме, то такую же схему можно реализовать и в Java. Когда данные отправляются в reducers, вы получаете взамен новую копию, которую сохраняете вместо старой. Учась у Redux и Elm, мы можем сделать архитектуру Java более функциональной. Мы можем создать чистые функции, которые будут брать данные, преобразовывать их и возвращать новую копию. JavaScript, я думаю, в наибольшей степени удалён от идеала функциональной чистоты, здесь при каждом шаге вы наступаете в лужу. Я говорю об этом, потому что Redux компилируется в JavaScript, который однозначно является базаром. На меня этот подход сильно повлиял, поскольку он изменил мой взгляд на функциональное программирование и показал, что я могу реализовать эти принципы и в Java. И тем не менее Redux даёт вам функциональную чистоту в этом крайне нечистом мире.

На ваш взгляд, является ли полным и достаточным тот набор инструментов, которым мы располагаем в Java? — Хорошо, спасибо. Нужно ли нам что-либо ещё, помимо лямбда-выражений, ссылок на методы, коллекций со стримами?

Мир Java постоянно эволюционирует. — По-моему, нам ещё очень многого не хватает. Я считаю, что в Java generics сделаны очень плохо. У меня недавно был диалог с человеком, который сказал: «Я слышал, что ты был в нашем городе несколько лет назад и много спорил на тему generics», на что я ответил: «Я всегда много спорю о generics». По-моему, в этой области можно очень многое улучшить. На меня всё время сердится Брайан Гёц (Brian Goetz): «Всегда найдётся кто-нибудь, кто жалуется на generics», и этот кто-то, конечно, я. Многое может быть сделано в плане уменьшения напыщенности, избавления от шаблонного кода. Очень важна, на мой взгляд, реификация. И определённое движение в этом направлении видно уже сегодня. Код можно сделать значительно более беглым. Я думаю, что оно очень важно, и мне приходит на ум аналогия с машиной по обработке банкнот. Сейчас в Java реализуется паттерн-матчинг, что меня очень радует — мне очень нравится, как оно реализовано в Scala и Kotlin. Аналогичным образом работает сопоставление с образцом в программировании. Если пропустить через неё пачку купюр, она рассортирует их в соответствии со стоимостью каждой банкноты. Я думаю, это могло бы помочь избавиться от того огромного числа операторов ветвлений, которые мы пишем в Java. Вы пропускаете данные через параметры, которые могут извлекать данные для обработки. В общем, я считаю, что Java нуждается в большом количестве дополнений, но, судя по всему, она уже двигается в этом направлении. Код станет значительно более выразительным.

Я вырос в мире традиционного программирования. Хочу упомянуть ещё об одном аспекте, который для меня действительно любопытен. В некотором смысле это неплохой язык для первого опыта, потому что хуже быть уже не может. Я не боюсь публично признаться, что моим первым языком был Visual Basic. После этого я начал писать на Java, C#, языках вроде Ruby. Затем я долго писал на С и С++, и больше всего времени из всех языков я провёл именно с С++. Поэтому знакомство с Node стало своего рода прозрением — мне понадобилось какое-то время, прежде чем я разобрался в асинхронном программировании. В определённый момент я понял, что всегда писал на языках с многопоточностью. Под асинхронностью имеются в виду сопрограммы (coroutines) и продолжения (continuations). Но, на мой взгляд, асинхронность — одно из важнейших направлений, в котором может развиваться язык и экосистема Java. И я предполагаю, что для программистов на Java будет настолько же трудно познакомиться с асинхронным программированием, как это было для меня. Я думаю, что Java уже движется в этом направлении, и это, на мой взгляд, крайне важно. Перейти от параллельности к асинхронности потребовало для меня больших усилий. Мой подход к программированию целиком основан на параллельности, я написал диссертацию по параллельным вычислениям. Учитывая, что мир движется в сторону вещей вроде микросервисов, асинхронность в долгосрочной перспективе становится значительно более важной, чем параллельность. Теперь, зная оба подхода, я понимаю, что нам, как Java-программистам, необходимо найти способ их совместить. Java развивается в этом направлении, и я считаю это правильным.

Нет простого способа отладить асинхронный код на языках JVM-платформы, его нельзя простым способом профилировать. — Но не думаете ли вы, что асинхронность крайне сложна и достичь её тяжело? Что вы об этом думаете? Перечислять трудности можно долго.

Мне стыдно сейчас об этом говорить, но я провёл свою юность в отладчике. — Это очень популярный вопрос, но обсуждать его непросто. С годами я освоил разработку через тестирование, и сейчас я это делаю весьма дисциплинированно. Причина, по которой я сейчас этого стыжусь, заключается в следующем: утром, приходя на работу, я находил курсор на той же позиции, на которой оставил предыдущим вечером, потому что был настолько уставшим, что не мог продолжать отладку. В приложении, которое мы сейчас разрабатываем вместе с клиентом, у нас, вероятно, миллионы лямбд. Приведу пример. Мы запускаем параллельный код, который постоянно выстреливает кучей лямбд. Это проект про Big Data. И всё же, когда это случается, мы обычно узнаём об этом потому, что не срабатывает юнит-тест. Как вы понимаете, система не всегда работает ожидаемым образом. Благодаря этому мы отлаживаем не огромные массивы кода, а отдельные модули. Тогда мой клиент ставит точку останова в тесте, где произошла ошибка, и отлаживает этот тест.

Чем больше модульности, тем более контролируемым становится код. Другими словами, зачастую невозможность отладить код является следствием не качеств определённой технологии, а недостаточной модульности кода. Если у нас несколько тредов и нам трудно их отлаживать, это вполне ожидаемо, поскольку многопоточность по своей природе недетерминированна. Это верно как по отношению к параллельным вычислениям и лямбдам, так и по отношению к асинхронности. Ваша задача заключается в том, чтобы укротить этот зоопарк, обрести над ним контроль, а для этого необходимо сделать код модульным. В сущности, вы открываете клетки в зоопарке, а затем пытаетесь понять, куда вам убегать. Когда меня спрашивают, как я отлаживаю лямбды, я отвечаю: никак. То же самое касается лямбд. Вам необходима отдельная функция, для которой у вас будет юнит-тест, которую вы отладите и которую затем вызовете как ссылку на метод через лямбду. Вам не нужна лямбда, состоящая из 30 строк кода.

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

Возможно, нам следует изменить наш образ мышления относительно такого кода? — То есть дело не в технологии. Например, спецификация Reactive Streams, реализация в проекте Spring Reactor, или CQRS и event sourcing. Вернее, дело не только в мыслях, а в их сочетании с технологией. Встречались ли вы когда-либо с людьми, которые действительно пользуются CQRS?

Но, возвращаясь к тому, что вы сказали про изменение образа мышления — я полностью с этим согласен. — Да, конечно, его используют многие. В Angular вы можете написать символ «$» и получить доступ к глобальному пространству имён. В своё время я не был знаком с Angular 1, и клиент, с которым я тогда работал, попросил меня взглянуть на этот фреймворк. Так делать нельзя». Когда я об этом узнал, моей первой реакцией было: «Что за глупость. Потому что дальше я начал гуглить, и был совершенно поражён, узнав, что все так делают. Я говорю это не чтобы себя похвалить, а к слову о поднятой теме образа мыслей. Через несколько месяцев или лет — не помню точно — вышел Angular 2, в котором разработчики признались, что эта вещь действительно была глупостью и от неё нужно было избавиться. Я был убеждён, что я никогда так писать не буду.

Но, когда мы это делаем, недостаточно изучить новый синтаксис и новый API — необходимо усвоить соответствующий образ мысли. Мы, как разработчики, с радостью учимся работать с новыми библиотеками и новыми технологиями. Каких анти-паттернов следует избегать? Каким должен быть хороший код? А люди делают ошибки. Эти технологии создаются талантливыми людьми, но следует помнить, что они по-прежнему люди. Поэтому и прошло время Angular 1 — мы нашли более совершенные способы решения проблем. Именно поэтому в Java — да и в любом языке — есть deprecated-методы. В общем, когда вы осваиваете новую технологию, делать это следует прагматично и с долей здорового скептицизма.

И они хорошо сочетаются с асинхронностью, а также с микро-сервисами. Возвращаясь к другому вашему вопросу — событийно-ориентированные системы (event-driven systems), на мой взгляд, являются будущим программирования. Благодаря их взаимодействию меняется наше представление о том, как приложения будут разрабатываться в будущем. Многие из этих технологий, приложений, API и библиотек существуют уже значительное количество лет, но сейчас вокруг них поднялся настоящий бум. От приложений для настольных компьютеров мы перешли к серверным и веб-приложениям, затем к мобильным приложениям, а теперь мы думаем о микросервисах и событийно-ориентированных системах. Если взглянуть назад во времени, то вы увидите, что примерно каждые 5-10 лет меняется наше представление о том, какой должна быть архитектура приложений. Когда меня спрашивают, принадлежит ли будущее функциональному программированию, я отвечаю — нет, оно принадлежит реактивному программированию. Я думаю, что сегодня мы находимся в очередной стадии перехода. Реактивность — это композиция функций и ленивые вычисления в приложении к потоку данных. Потому что для меня реактивное программирование — это функциональное программирование++. Оно сочетает в себе событийно-ориентированную модель, функциональную композицию, ленивые вычисления, возможность асинхронности. Так что, на мой взгляд, реактивное программирование не свалилось с неба, а является логическим продолжением функционального. Каждая из этих концепций сама по себе вызывает разве что любопытство, но вместе они приводят к фундаментальным переменам в архитектуре приложений в будущем, поскольку они изменяют инструменты и техники, которые мы применяем.

— Хорошо, то есть эти изменения важны не по отдельности, а вместе.

Мой вопрос такой: развивается ли экосистема Java в целом или нет и как она выглядит по сравнению с другими мирами? Вы входите в число Java Champions, ранее были Microsoft MVP, а сейчас пишете на JavaScript, так что хорошо видите три разные экосистемы. NET, JavaScript или чем-либо другим? Можем ли мы сравнивать её с .

NET уже какое-то время. — Многое, к чему Java пока только движется, присутствует в . Но сегодня ситуация обратная. С# поначалу был слегка улучшенным вариантом Java, и мы говорили, что C# всё за ней повторяет. Аналогичным образом асинхронность появилась в C# на несколько лет раньше, чем прозвучало обещание добавить асинхронность в Java. Лямбды появились в Java на несколько лет позже, чем в С# были добавлены LINQ, которые позволяют писать лямбды, и у которых есть действие и функция (то, что они называют Func). Но асинхронность появилась в C# задолго до этого. Правда, нужно сказать, что в Java с 2014 года есть CompletableFuture.

Я знаю, что фраза «нам есть чему поучиться у JavaScript» может вызвать испуг, но программисты на JavaScript очень многое повидали и знают, почём фунт лиха. Похожее можно сказать о Java и JavaScript. В конечном итоге в мире JavaScript было найдено решение в виде Promises (обещаний), которые являются аналогом CompletableFutures в Java. У них есть понятие «callback hell», когда коллбэки плохо сочетаются друг с другом, становится крайне сложно обрабатывать исключения и оказывается очень сложно надстраивать что-либо на функциях обратного вызова, которые должны выполнять асинхронные вызовы. Одно из преимуществ Promises в том, что там возможна композиция функций. И всё же нужно признать: красота нашего мира в том, что нет единого правильного метода на все времена. Однако представьте, что в вашем коде, помимо прочего, есть несколько уровней исключений. Другое преимущество — они могут иметь дело с исключениями и через Promises можно пропускать данные. Именно поэтому в JavaScript были добавлены async и await. Он может стать достаточно сложным, и в определённый момент вы поймёте, что он выглядел бы значительно лучше, если бы был написан в императивном стиле, а не функциональном. Вы можете писать императивный код, и когда в нём делается вызов к функции, этот вызов становится асинхронным, и код под этой функцией выполняется не сразу, а после того, как асинхронная функция уже завершила свою работу. В сущности, они являются императивными оболочками для Promise. И это именно то, что делают coroutines в Kotlin. С CompletableFuture это невозможно, но с continuations в Java в будущем это будет возможно.

В определённом смысле программирование на разных языках аналогично путешествию в разные страны. Если мы сравним все эти языки, станет понято, что я полиглот из чисто эгоистических соображений. Поэтому я всегда говорю разработчикам, что одним из важнейших качеств хорошего программиста является понимание того факта, что нет одного единственно правильного способа писать код. Я обожаю бывать в России, Эстонии, Индии, разных частях США, потому что во время этих поездок я встречаюсь с разными культурами и вижу различные практики, различные способы, которыми люди решают одни и те же проблемы. Если сравнить async в C#, async/await и Promises в JavaScript и coroutines в Kotlin, мы увидим, что в одних ситуациях лучше использовать функциональный стиль, в других — императивный, но реализовать асинхронность можно и с тем, и с другим подходом. Конечно, некоторые способы в некоторых ситуациях обладают преимуществами, другие — недостатками, и нам нужно выбирать то, что лучше подходит. Java в области этих нововведений отстаёт от других языков. Мне это кажется крайне любопытным. Язык должен эволюционировать, чтобы обеспечить возможность создавать современные приложения. Но я считаю, что Java меняется не только потому, что эти изменения уже произошли в других языках, но и потому, что меняется среда, в которых мы создаем эти приложения. Java должна эволюционировать, чтобы выжить. Я думаю, что язык, который перестаёт удовлетворять требованиям бизнеса, становится устаревшим и выходит из употребления. И я не слишком обеспокоен тем, что Java отстаёт от некоторых других языков — у неё ещё есть время.

Давайте взглянем на лямбды. Я очень ценю ещё один аспект Java. Лямбды в Java появились очень поздно, но их реализация при помощи invokedynamic, на мой взгляд, потрясающая. Я обычно говорю, что Java опоздала на праздник, но принесла отличный десерт. Java не является новатором в области языков, но она — новатор в поиске более совершенных способов реализации. Она улучшает использование лямбд на всех языках, работающих на JVM. Я думаю, в будущем другие языки будут продолжать опережать Java с точки зрения доступности новых возможностей, но Java будет отыскивать лучшие, более практичные и высокопроизводительные способы реализации этих технологий на JVM. И, на мой взгляд, это весьма существенное преимущество. Нам не нужны новые возможности просто для красоты, нам необходим код, который отвечает предъявляемым нам требованиям. А нам ведь это и нужно. С этой точки зрения тот факт, что Java развивается не слишком быстро, является преимуществом.

Теперь, наверное, последний вопрос от меня, и он будет касаться темы многоязычности. — Хорошо. Несколько строчек ассемблера — это недостижимый идеал. Мы живем в очень сложном мире, больше нельзя записать все что угодно за 5 строчек ассемблера. При желании можно написать проект на двадцати языках программирования сразу. Испокон веков существали языки с гибким синтаксисом — скажем, Common Lisp, в котором можно создать свой собственный JavaScript при помощи Meta Object Protocol, а сегодня существуют крутые способы писать DSL типа Kotlin или JetBrains MPS, при помощи GraalVM скоро можно будет написать компилятор Java на Java и так далее. Каким образом возможен контроль над сложностью в многоязычном мире с динамическими и меняющимися каждый день правилами?

Я всегда говорю, что надо стараться избегать увлечения технологией. — Это крайне важный вопрос. Тут нам как разработчикам необходимо над собой работать. Под увлечением я имею в виду ощущение, когда вы видите нечто новое и вам кажется, что это непременно нужно использовать в вашем приложении прямо сейчас. Во-вторых, нам не следует применять всё, чему мы научились. Во-первых, нам не следует учиться новой технологии только потому, что она нужна на текущем проекте. Я изучал эти технологии не для непосредственного применения, а чтобы иметь представление об их существовании. Я говорю это потому, что многие из вещей, которым я научился, я не применяю по шесть или по семь лет. Сложность возникает тогда, когда мы сваливаем в кучу разные компоненты, не до конца поняв их достоинства. Нужна определённая мудрость, чтобы решить, что в данном проекте эта технология пока что не нужна. Больше того — зачем вы пытаетесь решить эту проблему? Например, когда я прихожу на сайт клиента, я всегда спрашиваю: зачем вы используете это? Поэтому я рекомендую разработчикам не торопиться и разобраться, зачем была создана интересующая их технология. Почему она настолько же важна, как и то множество других проблем, которые вы решаете? Иногда люди не могут ответить, но при этом в своём проекте они используют React. Я часто спрашиваю их: можете ли вы сказать, когда и в каких условиях вы стали бы использовать Angular, а когда — React? Я не говорю, что он не нужен, но мы зачастую не знаем, зачем мы его используем и просто делаем так, потому что кто-то сказал, что так надо. Мой вопрос в таком случае — а действительно ли вам он здесь нужен? Бороться с ней можно, изучая эти технологии и сравнивая их друг с другом, оценивая преимущества и недостатки. Сложность возникает тогда, когда мы используем технологии, не до конца понимая их предназначение. Когда мы увидим каждый инструмент с разных сторон и получим непредвзятое представление о нём, мы сможем его успешно использовать. Если разработчик не может назвать мне пять аспектов, которые его привлекают в некотором инструменте, и пять — которые отталкивают, это значит, что он недостаточно изучил этот инструмент.

Когда вы оцениваете технологию, избавляйтесь от ваших эмоций и желаний. Последнее, что я хотел бы сказать о сложности. Я рекомендую командам начертить таблицу и перечислить в ней возможности, которые необходимы вашему приложению: тестируемость, масштабируемость, асинхронность, безопасность и так далее, в зависимости от приложения. В наших обсуждениях обычно кто-то говорит: мне нравится та или иная технология, я хочу её использовать. После этого для каждой возможности напишите список существующих технологий и для каждой проставьте цифру от 1 до 10, где 1 значит «не поддерживает», а 10 — «осуществляет превосходно». Затем напротив каждой напишите цифру от 1 до 10, где 10 значит «крайне важно», а 1 значит «безразлично». Теперь ваши эмоции никак не участвуют в оценке, и это позволяет более осмысленно выбрать необходимую технологию. Наконец, подсчитайте очки и посмотрите, какие из существующих технологий заработают больше всего баллов. Поэтому мне не нравятся заявления некоторых компаний о том, что у них Angular, React или Java является общим стандартом. Вы делаете эту оценку не в глобальном масштабе и даже не в масштабе фирмы, вы её делаете исходя из потребностей текущего проекта. Мы даже ещё не знаем, что именно будем делать. Я всегда спрашиваю в таких случаях: для чего именно? Это ведь бессмысленно. Это всё равно, что сказать: вся наша компания будет передвигаться исключительно на велосипедах. В общем, я считаю, что сложность можно существенно сократить, если правильно понять, что именно мы делаем и зачем мы применяем ту или иную технологию; если избавиться от эмоций и желаний и подвести счёт ресурсам и потребностям; если правильно оценить сопоставимость имеющихся у нас решений. Всё зависит от того, чем именно мы занимаемся, и это тот вопрос, который на который нужно ответить в первую очередь.

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

На нашей конференции Joker вы как раз тоже будете говорить о сложности, так что можно будет продолжить обсуждение там. — Спасибо, это прекрасный ответ.

— Да, я с воодушевлением буду этого ждать.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть