Экстраполяция IT

Ребята, в эту субботу (26 октября) в Киеве будет Рубимедитейшн и я тоже планирую там побывать.

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

К слову, нам даже 10% скидки дали по коду extrapolation. Увидимся там?

http://bit.ly/2VP51Ot

Ребята, #экстрапиар от подписчика.

Основатель проекта signum.ai, подписчик канала «Экстраполяция IT», прислал ссылку с описанием своего проекта. Идея проекта состоит в том, что с помощью матмодели и собираемых данных можно определить трендовость и хайповость конкретной темы.

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

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

https://vc.ru/tribuna/67458-signum-ai-otslezhivayte-zarozhdenie-novyh-trendov-i-haypov-na-samyh-rannih-etapah

В современном мире айти-разработки, при преобладании удаленной работы и сотрудничестве с фрилансерами появился занятный феномен перекладывания ответственности за простой в работе. В офисном мире, если у программиста нет задач, он может делать что угодно и ему за это все-равно заплатят, он же в офисе! У фрилансеров же обратная ситуация. Почему-то принято считать, что отсутствие задач у фрилансера (или удаленного сотрудника) – это проблема самого фрилансера. Решение выбирают фрилансеры вполне логичное и очевидное — берут себе несколько проектов и постоянно переключаются между ними. Из-за этого, собственно, и пошла легенда, что фрилансером быть тяжелее, чем офисным сотрудником.

А быть должно все наоборот. Только никому не говорите, что это я вам рассказал. Ставьте сами себе задачи с формулировкой «Мне же все-равно нечего делать, поэтому буду делать вот эту полезную задачу. Остановить меня можно только другой задачей». Профессиональным будет считаться не только качественное выполнение таких задач, тщательное описание до и отчет после, но и адекватность поставленных задач. Очевидно, что задач вида «перепишу-ка я вот этот модуль, потому что там код – говно» быть не должно в принципе, а вот формулировка «помнится, проекту давно была нужна вот эта фича, а сейчас как раз подходящий момент, чтобы ее сделать» крайне удачная. Дополнительной выгодой от такой стратегии поведения будет демонстрация руководству проекта (менеджеру, если хотите) того, как по-вашему должны выглядеть поставленные вам задачи.

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

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

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

«Аджайл — он о процессе, а не о результате. Поэтому если вам процесс важнее результата, то смело его используйте».

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

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

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

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

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

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

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

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

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

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

Минутка ностальгии.

Много лет назад моим окном в тот мир, частью которого я отчаянно хотел стать, был журнал Ксакеп (Xakep). Я читал его весь, частенько один номер по несколько раз. И в этом журнале была юмористическая рубрика, которую вёл Даниил Шеповалов. Даня этот гнал чернуху со страшной силой, и в том возрасте это было очень свежо и весело.

Так вот, в одном из вопросов там была очень забавная шутка.

«Через пять лет я удочерю 17-летнюю девочку из сиротского приюта и на практике покажу ей, почему "жизнь - дерьмо!" и "все мужики - козлы!". Ну а после удовлетворения всех своих извращенных фантазий, естественно, продам ее в рабство на плантации сахарного тростника. ("Слово "дерьмо" возможно является бранным выражением и его употребление в литературном языке нежелательно", - вот что выдал Ворд, подчеркнув красной волнистой линией это чудесное существительное. "Какое же все-таки счастье, что программы пока что не умеют проверять смысловую нагрузку текста", - подумал Даня)

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

Я сейчас отправил пулл-реквест, на который код-климат сказал мне, что у меня там новые проблемы в коде. Проблемами являлось то, что я не написал .freeze после объявления константы, несколько строк написал в двойных, а не в одинарных кавычках и одной строкой превысил 80 символов.

То же самое он говорит и другим ребятам, и мы дружно шлём туда всякое дерьмо («слово "дерьмо" возможно является бранным выражением и его употребление в литературном языке нежелательно»), но везде написано .freeze, кавычки одинарные и строки короткие. В коде всё по смыслу, как в текстах Шеповалова и групповуха немощи по Петровичу, и одно и тоже, сделанное пятью разными способами в разных местах, и тыща sql-запросов на один http request...

Но код-климат бдительно запрещает разработчикам использовать в текстах слово «дерьмо».

Ну хоть что-то у нас в безопасности.

#dimoneverything