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

Этот эффект можно назвать «отложенной сложностью добавления новой функциональности».

К слову, ребята, не зачастил ли я с постами? Может, реже писать?

👍 все хорошо, продолжай
😤 лучше писать реже, не хочу ничего пропустить
🤓 можно даже чаще писать, не стесняйся
😵 я все-равно редко читаю, просто подписан
🤮 обожаю соц. опросы

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

Это действительно так, и факториал в данном случае хуже квадрата, что лишь усиливает основную мысль поста.

Ещё одно сравнение с «Ночным Дозором», только в этот раз будем говорить о квалификации.

Лукьяненко просто замечательно описал систему уровней магии и магов, да так, что на протяжении чтения книг иерархия сложности заклинаний и квалификация отдельного сотрудника сомнений не вызывали вовсе. В книгах уровни распределялись от седьмого к первому. Однозначным определением уровня мага был набор заклинаний и умений, который способен он сделать. Продвижение по карьерной лестнице у «иных» зависело не только от опыта, но и от текущей формы. «На пике своей формы», как говорили герои книг. Получается, что однажды освоив третий уровень Силы, вовсе не обязательно маг останется на нем до конца своей карьеры. Вполне вероятно, что через некоторое время он окажется на четвертом или даже пятом уровне (седьмой уровень — самый слабый, если что). Опять же, не все маги, прийдя в систему сразу становились семиуровневыми джунами. Некоторых из них определяли на, скажем, третий уровень силы с приставкой «неопытный, но перспективный». Интересно, как им платили зарплату? Как третьему или как седьмому уровню?

Ребята, как вам идея существования черных дыр, которые старше самой вселенной? По-моему все довольно элегантно.

http://telegra.ph/Eldar-Black-Holes-02-24

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

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

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

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

Лайвхаки от Экстраполяции

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

Первый — GitX. Только не оригинальный, а форк. Хоть даже форк давно уже не поддерживается, с визуализацией он справляется отлично. Кроме того крайне легковесен, что немаловажно в эру реакт-нейтивов и электронов. http://rowanj.github.io/gitx/

Второй — консольная команда git log --graph --abbrev-commit --date=relative --all. Конечно же, запоминать ее вообще не обязательно, а лучше добавить в глобальный gitconfig. Мой гитконфиг публично доступен и лежит в репозитории dotfiles на гитхабе. С таким конфигом, чтобы увидеть дерево коммитов, я использую команду git la.

Еще один клёвый инструмент для работы с гитом от читателей «Экстраполяции» — tig (https://jonas.github.io/tig/). Работает в консоли и позволяет все то, что полноценные оконные инструменты вроде GitX. Выглядит просто отлично! Попробуем?

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

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

Wrong number of arguments — объективно худшая ошибка в Руби.
Худший дизайн сообщения, который вообще мог бы быть.
Ошибка при вызове метода на nil прекрасна.
Ошибка wrong number of arguments могла бы быть не менее прекрасной, но нет.

Мы не говорим "передали вот это: тыц, тыц, тыц, пердыц, но надо было три аргумента".

Мы говорим "передали четыре аргумента, а надо было три".

И это в среднем 15-20 человеко-минут на одну такую ошибку.
Серийные убийцы.

Ребята, #хайринг. Воспользуюсь служебным положением и расскажу, что нам в команду (cimon.io) нужен дизайнер.

Чтобы хороший был, добрый и с бородой. Или без. И не обязательно «был», можно чтобы и «была». Но дизайнер. Ещё главное, чтобы добрый. Хотя, если будет злой, то тоже хорошо. Но только если дизайнер.

Работать нужно будет над одним из нескольких проектов, вроде riter.co или vault8.io. Работы вагон и маленькая тележка, прийдется много думать и принимать самостоятельные решения.

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

Дизайнеры, присылайте ссылку на работы свои личным сообщением в телеграме (@aratak). Отдельное спасибо за форвард сообщения друзьям-дизайнерам и в подконтрольные каналы и группы.

В каждом уважающем себя трекере задач всегда есть место для маркёра важности задачи. Ну, там «minor» или «important» или вообще «critical». Такие маркировки задач лишены смысла почти полностью и следующими несколькими постами давайте разберём почему.

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

Если проблема действительно критически важна, то разработчик, расслаблено набирая class MySuperSer..., должен немедленно это бросить и, как пожарник, броситься срочно тушить пожар. Там уже не до трекеров, оформлений багов, стикеров и оценок. Бумаги заполняются после пожара, а не до него.

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

Если постоянно кричать «Волки!», то люди перестанут обращать на это внимание.

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

С автором канала «Айти без галстуков», Дмитрием, мы знакомы лично и я уверенно могу сказать, что ему есть что рассказывать интересного ещё очень долгое время.

https://yangx.top/notieinIT

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

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

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

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

Сойдет за рубрику #полныйаджайл?

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

https://www.youtube.com/watch?v=deb8o1UCGsI

К слову, в тизере один из засветившихся в кадре — это я. Справа или слева?

Нужно ли слушать пользователя или не нужно? Конечно же, «слушать» не означает созваниваться лично с каждым пользователем и внимательно выслушивать как вчера рожала его кошка, нет. Разнообразные метрики и всевозможные выводы, собранные со статистики тоже попадают под определение «слушать пользователя».

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

Знаете кто лучше всего знает как делать ваш продукт? Вы. Пользователи могут хотеть вполне здравые вещи в их случае, но совершенно бессмысленные для развития продукта. Тут, наверное, уместнее всего вспомнить Генри Форда и его «более быструю лошадь», но в современном мире она звучит так: «Если бы я делал все то, что хотят пользователи, то мы бы получили более красивенький эксель».

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

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

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

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

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