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

Хорошие курсы дают задачи на которых ты учишься. Учишься решать задачи. Иногда типичные задачи и часто типичными подходами. На хороших курсах не навязывают подходы но объясняют какие лучше. И инструмент решения - тот же php или ruby. Плохие курсы учат языку. Хорошие - решать задачи.

Самостоятельно сложно освоить и фундаментал и язык тк нет общей картины, что и зачем и какие задачи вообще надо решать. Как-то так.

(#экстраакадемия от подписчика, поддержите лайком, чтобы писал еще, клево же пишет!)

Итак, подошло к концу голосование и вот несколько мыслей по этому поводу:

1. Уж не знаю что сделать с аудио-видео, но я попробую в качестве эксперимента. Только не судите строго, это будут эксперименты.

2. Приятно удивлён тому, что вам хочется лонгридов. Ну как «лонгридов», особых телеграмовских лонгридов, который просто текст на несколько абзацев, а не 250 символов.

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

4. Что касается рекламы, добавил я этот пункт ради хохмы и хотел увидеть пару сообщений в личку, вроде «А! Ты же уверенно заявлял, что рекламы не будет! Дизлайк-отписка!». И, удивительно, таких сообщений нет, а почти половина проголосовавших совершенно не против рекламы. Планов зарабатывать на рекламе в канале все ещё нет, но подумать как использовать рекламу по-другому же можно? Пришлите мне личным сообщением (@aratak) идеи как можно использовать рекламу, если у вас есть мысли по этому поводу. Мне пока только приходит в голову идея розыгрыша вознаграждения за рекламу среди тех, кто по ней кликнул :-)

5. Из непрограммирования я планирую рассказывать немного внутренней кухни проектов, над которыми я работаю. Уж не знаю в какой форме это будет, но точно без философствований и выводов.

6. Уж не знаю как вам, но мне очень хочется видеть больше постов от Димы и Андрея, которые уже публиковались в Экстраполяции неоднократно. Поддержите лайком и Диму и Андрея, пожалуйста.

Всех обнимаю.

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

(#экстрасейлз от подписчиков)

Еще один #экстрасейлз от подписчика.

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

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

Шикарно расписанное и вполне весомое мнение от Эдуарда о проблеме уговорить потенциального клиента. Букв много, поэтому ссылкой:

https://telegra.ph/Vybor-partnera-03-29-2

#экстрасейлз

Сегодня продолжаем цикл постов на тему аргументов, которые нужно говорить новому клиенту постом от подписчика. Смотрите начало по тегу #экстрасейлз.

Итак, по словам подписчика «Экстраполяции» Павла нужно:

1. Дополнить отзывы нормальным описанием как именно мы работали с этим клиентом, какие методы использовали и почему они помогли.
2. Сделать с клиентом совместную двухдневную стратегическую работу. Прям вместе с ним определить, что за проблему он решает, как проблема проявляется, кого она затрагивает. Еще определить как клиент поймёт, что проблема решена и как будет выглядеть первая попытка ее решения.
3. Вместо громких рассказов о том, что «мы все из себя аджайл и работаем по скраму» простым языком объяснять, что поставлять мы будем помалу, но часто и сразу работающее, а самого клиента постоянно привлекать к обсуждению приоритетов, требований и результата.
4. Предложить контракт, в котором платежи будут завязаны на вот эти вот мелкие поставки: если мы определили цикл в две недели, привлекаем клиента к планированию в начале, координации в процессе и приемке в конце, то оплата идёт по результатам приемки. Если не успели, то оплаты не будет, пока не осилим.

Давайте затронем одну из самых животрепещущих тем айти, которые не связаны напрямую с программированием. Я имею ввиду рекрутинг. Тема обширная, и сказать есть много чего, так что все вместе почитать можно по тегу #экстрарекрутинг (блин, эта приставка «экстра» надоела даже мне, но что поделать, уникальность тегов и все такое).

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

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

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

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

Давайте «китайской комнатой» назовём некую способность человека правдоподобно общаться на заданную тему совершенно в ней не разбираясь. Если честно, я даже не понимаю порицание ли это рекрутерам в айти или комплимент.

Два шага назад и один вперед.

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

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

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

#китайскаякомната

Обратная сторона рекрутинга. Оказывается (внезапно!), что основная масса разработчиков достаточно умна, чтобы говорить о технологиях, выражать своё мнение, спорить и даже делать доклады, совершенно не разбираясь в предмете. Более того, обычное программирование в большинстве своём поощряет именно такой стиль работы.

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

#китайскаякомната

Собеседование на работу очень сильно похоже на первое свидание. И как на любом свидании, развиваться оно может по трём сценариям.

1. Когда очень сильно надо работодателю, а работовзятель перебирает ухажёров и выбирает лучшего. Тогда он выбирает себе покровителя, у кого больше денег, интереснее жизнь и круче гаджеты.

2. Когда кандидатов много и работодатель устраивает конкурс, вроде «а можно всех посмотреть» или «всем спасибо, у кого рост ниже 185 и грудь меньше третьего».

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

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

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

#экстрарекрутинг

Недавно личным сообщением мне написала подписчица Валерия, которая работает над проведением чемпионатов по программированию от мейлру (https://yangx.top/mrgchamps). У них много всяких соревнований проходит с призами и фондами. Предлагает новый вид развлечений в «Экстраполяции» — чемпионаты, задачки и всякие алгоритмические штуки. Я когда-то пытался что-то подобное сделать, но нужно что-то круче просто алгоритмических задачек, да?

Как вам идея Валерии? Устроим состязания какие-нибудь?

Внезапно Дмитрий напомнил о такой животрепещущей теме, как «микросервисная архитектура» шикарной цитатой из рабочей переписки:

«Ну ликвидируем мы свой монолит. Ликвидируем его месте с остатками понимания, ибо большие рефакторинги стоят долго и дорого. И что дальше? Не нравится слово "Монолит", так будет у нас какая-нибудь другая "микросервисная архиектура". Какая разница? Мы-то останемся все теми же самыми...»

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

В общем, в эфире #перечитываяэкстраполяцию

——

Помните тест, в котором нужно было сосчитать количество передач баскетбольного мяча? Если вы не видели, то посмотрите, прежде чем читать дальше.

В 2004 году был сформулирован принцип «ложной слепоты». Этот термин объеденяет в себе несколько разнообразных феноменов нашего восприятия. Обычно выделяют два вида ложной слепоты: слепоту невнимания и слепоту к изменениям. Слепота невнимания (или перцептивная слепота) подразумевает неготовность нашего мозга воспринимать изменения, которые мы не ожидаем увидеть. Как гориллу в ролике, которую уже окрестили «невидимой гориллой» и даже сайт отдельный есть по этому поводу. Еще причиной называют рассеянность, которая вызванная необходимостью полностью сконцентрировать внимание. Очевидно, что на себе вы этот феномен можете почувствовать только если о нем не знаете. И действительно, при повторном эксперименте с другими футболистами и совершенно другой макакой вы ее обязательно заметите, так как ожидаете ее увидеть.

Слепоту к изменениям тоже можно заметить гораздо проще, есть довольно много роликов в интернете на эту тему. Даже BBC снял передачу, посвященную этому феномену. В обычных условиях изменение наблюдаемой картины мгновенно обращает на себя внимание. Однако мы можем не замечать изменения, если они совпадают с коротким прерыванием наблюдаемой картинки. Это может быть кратковременное моргание экрана, монтажный стык видео или короткая помеха. В экспериментах по слепоте к изменениям обнаружилось, что почти 70% испытуемых не замечали подмены главного действующего лица, а изменения менее существенных деталей оставались проигнорированными почти в 100% случаев.

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

Жили-были в одном городишке два ассенизатора — синьор и джун. Канализации у них там не было, а просто ямы с этим самым. И они это самое вычерпывали ведром и заливали в свою бочку, причем синьор, как более опытный специалист, спускался в яму, а джун сверху подавал ему ведро. И вот однажды джун это ведро не удержал и обрушил обратно на синьора. Ну, тот утерся, посмотрел на него снизу вверх и сказал ему с горечью: «Чучело ты, — говорит, — огородное, тундра! Никакого толка в тебе не видно. Так всю жизнь наверху и проторчишь».

 В эфире «Экстраполяции» наш постоянный автор Дима и, я думаю, уже пора прекращать каждый пост его отдельно помечать эпиграфом. Теперь у него будет фирменный тег.

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

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

Причём, легаси-код в любом проекте появляется за полгода, так что, от него не спасут даже серьёзные попытки не браться за легаси, а плясать по "generate new projectname" стартапчикам. Легаси-код неизбежен, как всадники апокалипсиса — проект или обрастает легаси-кодом, или аннигилируется заказчиком. В этом месте можете возражать и доказывать, что это не так, и что я не очень, надо просто хорошо писать и всё такое. Вспоминается старый анекдот про «и вы тоже рассказывайте».

#dimoneverything

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

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

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

А вывод, увы, в том, что ну и что. Есть много приятных вещей в жизни — хорошие книги, фильмы и компьютерные игры, шашлыки, девушки и путешествия. То, что мы на работе игногда умудряемся тоже получить пару дней в месяц удовольствие от красивого решения сложной проблемы — уже благословение.
Конечно же, существуют разработчики, которые свою компенентность действительно смогли конвертировать в интересную работу и у них rocket science каждый день. Но их мало, сильно меньше, чем сеньоров и чем архитекторов тоже. Так что, крутейте, ныряйте, а то так всю жизнь наверху и проторчите.

#dimoneverything

Минутка ложной слепоты и код-ревью.

Хочется задать вопрос уважаемой аудитории. Тут недавно «Экстраполяция» отправилась в прошлое и повторила свой старый текст, который, надо сказать, я тогда не прочитал, а зря, ведь там интересно. И вот хочется спросить про код-ревью.

Есть два разных подхода к код-ревью. Не, есть ещё больше, но я про нормальные, а не превращающие его в бюрократию с профанацией.

Первый — это открыть пулл-реквест и промотать его сверху донизу (или в каком-то другом разумном порядке, от тестов к коду или так, как рекомендует написавший этот код в текстовом описании пулл-реквеста), тщательно его прочитав, что-то выполнив в уме, прочитав тесты и убедившись, что они проверяют код. Потом взять в левую руку Фаулера, в правую Макконнела и указать на возможные косяки, плохие имена, выделите класс, заинлайните метод, тут же N+1 у вас, хватит мокать тесты, это не REST, вы забыли authorize, не надо писать собственный map, он в стандартной библиотеке уже есть, и всякое такое. Или сказать «молодец». В общем, побыть сильно продвинутым Code Climate.

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

Мы с моим коллегой расходится в мнениях по этому вопросу и применяем разные подходы.

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

Ленивые — голосуйте кнопочками, активные — пишите комментарии, и я там тоже буду и Алексей, давайте дискутировать.

#dimoneverything

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

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

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

Получается, что как только Пуля становится Серебряной Пулей, то сразу же Серебряная Пуля перестает быть Серебряной. И перестаёт быть Пулей. В итоге получаем, что термин «Серебряная Пуля» — это состояние, длительностью в одно мгновение, а потом тотальное признание и отсутствие альтернатив.

#перечитываяэкстраполяцию

Мнения по поводу целей пулл реквестов разделились, значит подбросим ещё дровишек в огонь.

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

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

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

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

А решение у проблемы достаточно элегантное. У задачи должно назначаеться не один исполнитель, а два. Один делает, другой командует. Прежде чем начать выполнять, командир и исполнитель обсуждают решение, командир принимает стратегическое решение, исполнитель его делает, командир принимает. Ответственность, вроде бы, точно так же распределяется, как и при классическом ревью пулл реквеста, только в механике парной работы это не просто формальные правила, а естественные условия работы.

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

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

Помимо всех основных дополнительных бенифитов обычного ревью, в этой схеме есть ещё один крайне важный, но о нем как-нибудь отдельно, а то и так много букв получилось.