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

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

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

Главной проблемой быстрого устаревания кода является принцип «Работает — не трогай». Казалось бы, как в той истории, Солнце всходит каждый раз на востоке и менять ничего не надо, но как ни парадоксально то, что не нужно менять, не работает.

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

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

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

Команда разработки должна контроллировать весь код, который она пишет и код, от которого зависит их код.

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

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

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

На днях пришлось общаться с сантехником по всяким сантехническим делам и он поделился со мной крупицей мудрости своей профессии.

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

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

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

Недавно, в разговоре с коллегой обнаружилась устойчивая ассоциация, что тесты — это всегда дополнительное время на разработку. Мол, «мы пока тесты не пишем, потому что время нужно экономить. А вот, как время не надо будет экономить, вот тогда и напишем». Да, можно, конечно, начать убеждать, что такого времени не настанет никогда и что тесты — это неизбежное зло и просто накидывай 15% времени к оценке, но это в корне ошибочная риторика.

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

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

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

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

UI в целом такой же на стороне пользователя.

Единственное, теперь на нём мерзко мерцает blank state, когда сначала показывается пустая таблица, а потом она идёт за данными, и если всё не прям шустрое-шустрое, ты успеваешь увидеть ‘You have no teams’ или там ‘Data loading’.

Других фундаментальных прорывов пользовательского интерфейса, достигнутых при помощи доминирующей технологии разработки UI, по сравнению с тем, что мы делали эпохи назад на js.haml и jQuery я пока не разглядел. Мы делали не хуже, но это было понятно.

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

Да, да, я/мы просто не умею это готовить. Старческое брюзжание.

#dimoneverything

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

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

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

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

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

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

Да что вы знаете о хотфиксах?

#dimoneverything

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

Давайте скажем, что IDE — это такой вот богатый и многофункциональный способ редактировать файлы и делать что-то ещё в довесок. А текстовый редактор умеет лишь редактировать файлы.

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

Такой парадокс не работает с ортогональными понятиями и, само собой, предполагается, что любой редактор — это просто маленькая IDE и наоборот. Как-то так.

Из рабочей переписки.

«Жаль что те, кто могут управлять разработкой продукта, уже работают тестировщиками, верстальщиками и админами»

Помните идиому с наточкой топора и вырубкой леса? Ну, в которой абстрактному разработчику некогда наточить топор, потому что лес рубить надо. Тут есть и обратная сторона этой проблемы — преждевременная наточка топора. Топор нужно точить, когда будет точно понятно, что затраты на заточку топора будут окупаться скоростью вырубки леса. А для этого нужно:

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

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

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

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

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

​​Продолжая вчерашнюю тему, в игре X-Com на высоких сложностях и без права на ошибку, самое главное — чтобы в твою сторону не стреляли вообще, потому что если будут стрелять, то иногда будут попадать.

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

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

#dimoneverything

Вы только представляете? Собирались лишить глаз только за то, что она робот! Это же не расизм, потому что у робота нет расы. И не феминизм, потому что у робота нет пола. Роботизм? Нам срочно надо отдельное слово какое-то для такого.

https://tjournal.ru/news/459178

По аналогии с термином «пуленепробиваемый дизайн», сформулируем «пуленепробиваемый код».

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

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

Это и есть пуленепробиваемый код.

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

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

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

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

Пора уже постоянную рубрику делать в Экстраполяции. Назовём её #продакшенхотфикс

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

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

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

Ребята, мы тут, в рамках эксперимента, запилили приложение для слэка, которое помечает любое сообщение, как задачу. Никаких внешних сервисов, никаких зависимостей. Просто правой кнопочкой и «Create Task». Само собой, бесплатное. Отзывы и предложения можно прям в личку (@aratak).

https://slack.riter.co

Ещё один совет на одну звёздочку экспертности из десяти. Назову его «нейтральная среда разработки».

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

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

1. Сделайте глобальный .gitignore и добавьте туда всё, что специфично для вашего конкретного компьютера. Всякие там Thumbs.db, .DS_Store, *.wsp или .rubymine.

2. Опишите в файле README.md (или даже лучше в CONTRIBUTING.md) всё то, что важно для вашего проекта. «Мы используем вот такой вот линтер и запускается он вот так», «создаётся мерж реквест вот так-то и вот в этой папочке описано что за этим следует», «Мы предпочитаем yarn, а не npm» и всякое такое.

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

4. Научитесь запускать проект без докера. Как говорит наш девопс, «запуск проекта с докером, это как без докера, только с докером». Строго говоря, полагаться нужно не только на докер-инфрастуктуру. Например, все запускаемые процессы можно описывать в ставшим уже стандартом файле ./Procfile, а не в docker-compose.yml.

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

Во многих языках есть штука, которую называют «тернарным оператором». Как правило, эта штука записывается, как 'c ? t : f'. Штука замечательная, без споров, но вот её название звучит как-то коряво.
Даже если вы не знаете латинского, то совершенно очевидно, что смысл слова «тернарный» означает «тройной», что по сути сводит смысл оператора к тому, что у этого оператора три, вместо двух аргументов. Ну, вот оператор сложения (a+b) — с двумя аргументами, но мы не называем его «бинарным оператором», так как таких операторов у нас много и совершенно непонятно о каком конкретно операторе речь. А вот тернарник у нас один, и все как-то привыкли, что «тернарный оператор» — это на самом деле «условный оператор в тернарной форме».
Это если бы в маленьком городке жил один негр по имени Степан Илларионович, а всё село его бы вместо этого называло «Негр». Потому что он у них такой один. Вот такое себе легкое проявление расизма в программировании, ребята.

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

Хочу к вам в ваш информационный пузырь.

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

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

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

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

Всех обнял ❤️

У каких-нибудь коренных племен каких-нибудь островов какой-нибудь Новой Зеландии может быть свой язык, терминология которого в корне не совпадает с другими языками. Сам принцип построения предложений и формулировка мысли может в корне несоответствовать тому, к чему мы привыкли. Скажем, у такого племени нет понятия «лево» и «право», а ориентируются в пространстве аборигены исключительно по сторонам света. У них есть понятие «южнее» или «восточнее», а приложение-навигатор будет объяснять не относительное положение поворота, а абсолютное. «Через сто метров держитесь южнее» или как-то так. Давайте для сгущения красок этой аллегории предположим, что у этого же племени не существует вопросительных предложений, а только лишь утвердительные. И вместо вопроса, допустим, «Как пройти в библиотеку?» на этом языке канонично говорить «Ты мне должен показать дорогу в библиотеку». И, чтобы еще сильнее вас запутать, давайте скажем, что этот язык напрочь лишен местоимений и числительных. Пример с библиотекой с этим новым правилом будет звучать, как «Чака должен показать Фасимбе дорогу в библиотеку». А Чака такой в ответ «Обезьяноподобным шагом на юго-восток и потом медвежий шаг на юг».

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

Сейчас очень модно рассуждать на тему того, что настоящий программист не должен привязывать себя к какому-либо языку и должен мыслить категориями, выходящими за рамки конкретного языка или парадигмы. Мол, формулировка собственной профессии или должности, вроде «PHP-разработчик» или «HTML-верстальщик» обречена на провал и с такими людьми лучше не стоит иметь дело. А дело как раз и состоит в том, что язык программирования в первую очередь — это язык, а во вторую — программирования. И важно знать на каком языке думает программист, чтобы понимать его основу мышления и точку опоры в дальнейших дискуссиях. Не спрашивайте на каком языке программирования умеет программировать собеседник. Спрашивайте на каком языке он думает.

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