Привет, это снова Катя из Яндекс.Денег. Продолжаю свою историю о том, как я перестала верстать и начала жить. В первой части я рассказала, как меня сюда занесло и чем занимаются наши фронтендеры. Сегодня — про фронтовый стек, откуда там React и куда делся БЭМ.
Спойлер: БЭМ пока никуда не делся ¯_(ツ)_/¯. Погнали!
Внимание: высокая концентрация фронтенда. Много текста, картинок и кода, как обещала.
Читать полностью »
В разработке существует множество ситуаций, когда вам надо выразить что-то с помощью "optional" — объекта, который может содержать какое-либо значение, а может и не содержать. Вы можете реализовать опциональный тип с помощью нескольких вариантов, но с помощью C++17 вы сможете реализовать это с помощью наиболее удобного варианта: std::optional.
Сегодня я приготовил для вас одну задачу по рефакторингу, на который вы сможете научиться тому, как применять новую возможность C++17.
Давайте быстро погрузимся в код.
Представим, что есть функция, которая принимает объект ObjSelection, представляющий из себя, например, текущую позицию указателя мыши. Функция сканирует выделение и находит количество анимированных объектов, есть ли там гражданские юниты и есть ли там военные юниты.
Все думают, что программист большую часть своего рабочего времени пишет код. Кроме самих программистов. Они знают, что большую часть времени они этот код читают. Читают, силясь понять, как же он работает, зачем он здесь написан и что с ним теперь делать.
Дольше всего приходится вычитывать не хитрые алгоритмы, и не решения с алгебраическими типами данных и монадами, а огромные куски простого кода: методы на 500 строк, скрипты на 1000 строк, классы на 1500 строк. Все они доставляют индустрии проблем не меньше, чем печально известное NullPointerException.
Каждому разработчику знакома ситуация, когда реализация новой возможности в системе занимает большое количество времени, но релиз уже близко, а тимлид или менеджер проекта пятый раз за день задают уже надоевший вопрос: “Ну когда будет готово?”. И тогда встает непростой выбор — сделать все правильно и не уложиться в сроки релиза или реализовать минимально работающий, но не идеальный с точки зрения технического решения, функционал. Очевидно, что в большинстве случаев будет выбран второй вариант, так как релиз и предоставление результата клиентам здесь и сейчас важнее чистоты кода и архитектуры системы. Но проходит несколько месяцев, и вот уже старое не идеальное техническое решение мешает реализации другого функционала. И дальше такие решения будут накапливаться в огромный ком. Разбираясь с этой проблемой, очень важно сделать правильные выводы и выбрать нужное решение. От этого решения будет зависеть дальнейшая судьба всего проекта. В данной статье мы постараемся разобраться с природой технического долга и посоветовать пути его устранения.
Читать полностью »
В прошлом посте я рассказывал, как мы с удивлением обнаружили, что стали большой такой жирной компанией, и при этом хапнули все особенности бюрократизма. Нужно было срочно рефакториться и становиться обратно эффективными. Ниже — что мы делали в рознице. Сразу скажу, у многих пост вызовет желание поспорить, потому что я буду предельно циничен.
Начнём вот с этой картинки. На Курской около точки завелись бомжи. И стали на несколько дней лицом компании. Старший не знал, что делать, и хотел проконсультироваться с юристом. В нашей «старой доброй» модели он бы сначала что-то с ними сделал, а потом бы рассказал.
Бомжи жили около магазина пару недель. Это прямо выход из метро, поэтому им там было тепло и уютно. Решилось тем, что как только открывалась дверь, сотрудник брал толстые резиновые перчатки, и либо прямо выносил их на улицу, либо вёл с ним беседу по поводу, почему они мешают. Если они успевали полежать хотя бы 2 минуты — это вполне их устраивало. А когда и 10 секунд не давали — ну, направление миграции сместилось.
На деле, конечно, это была меньшая из проблем. И самая легкорешаемая.
Читать полностью »
Прошлый год был фееричный. Конкретно — полная задница, и вот только сейчас, когда мы хорошо отбарабанили сезон, я чувствую, что можно немного выдохнуть.
Дело в том, что мы внезапно для себя стали большой компанией со всеми вытекающими недостатками. Раньше мы думали, что жирение — это часть процесса, и надо просто расслабиится и получать удовольствие. Не- а. Заодно при поймали хвост кризиса и хорошо на нём прокатились.
А знаете, что такое большая компания? Это когда ты не знаешь в лицо кого-то. Когда в команде есть люди, которые работают по должностным обязанностям без понимания, для чего нужна их работа. Когда простая задача «напечатайте табличку с текстом в магазин» начинает гулять по согласованиям и решается за 22 дня. Реальный случай. Это когда договор подписывается 4 месяца. И куча других приколов звериного оскала бюрократизма.
Разгребать всё это… хм, ну, скажем, увлекательно.
Читать полностью »
Как-то я сказал своему коллеге, что в Rust имеются макросы, ему показалось, что это плохо. Раньше у меня была такая же реакция, но Rust показал мне, что макросы не обязательно плохи.
Где и как их уместно применять? Смотрите под катом.
К одной из моих статей прозвучали комментарии, в которых собрано так много предубеждений касательно статического анализа кода, что я решил оформить ответ в виде отдельной публикации. Надеюсь, ответ позволит автору комментариев и всем сомневающимся программистам по-новому взглянуть на инструменты статического анализа вообще, и PVS-Studio в частности.
Комментарии написаны к статье "Передаю привет разработчикам компании Yandex". Первый находится здесь. Процитирую его:
| Все эти анализаторы кроме пользы добавляют гемор в виде замедления билда, ложных срабатываний, информационного шума и ложного чувства безопасности. Для себя я решил, что профессионалам чем меньше таких тулзов тем лучше — гемор легко перевешивает пользу. А нубасам такое тоже особо не поможет — им бы учиться писать юнит тесты, а не тратить время на затыкание варнингов. Возможно, в Яндексе думают так же. Хотя если тесты гонять перед релизом, то гемор будет меньше, и можно будет выцедить нормальное соотношение время/ошибки, так что хз. Дисклеймер: PVS-Studio я не пробовал. |
К одной из моих статей прозвучали комментарии, в которых собрано так много предубеждений касательно статического анализа кода, что я решил оформить ответ в виде отдельной публикации. Надеюсь, ответ позволит автору комментариев и всем сомневающимся программистам по-новому взглянуть на инструменты статического анализа вообще, и PVS-Studio в частности.
Комментарии написаны к статье "Передаю привет разработчикам компании Yandex". Первый находится здесь. Процитирую его:
| Все эти анализаторы кроме пользы добавляют гемор в виде замедления билда, ложных срабатываний, информационного шума и ложного чувства безопасности. Для себя я решил, что профессионалам чем меньше таких тулзов тем лучше — гемор легко перевешивает пользу. А нубасам такое тоже особо не поможет — им бы учиться писать юнит тесты, а не тратить время на затыкание варнингов. Возможно, в Яндексе думают так же. Хотя если тесты гонять перед релизом, то гемор будет меньше, и можно будет выцедить нормальное соотношение время/ошибки, так что хз. Дисклеймер: PVS-Studio я не пробовал. |
Как-то раз моему коллеге в беклог упала задача «хотим организовать взаимодействие с внутренним REST-api так, чтобы любое изменение контракта сразу приводило к ошибке компиляции». Что может быть проще? – подумал я, однако работа с получившимся кактусом вынудила заняться многочасовым курениям документации, спуску от привычных концепций оверинжинеринга «налепим побольше интерфейсов, добавим максимум косвенности, и приправим всё это DI» до переезда на .Net Core, ручной кодогенерации промежуточного ассемблера и изучения нового компилятора C#. Лично я для себя открыл много интересного как в рантайме, так и в структуре самого компилятора. Думаю, некоторые вещие уже знают, а некоторые станут полезной пищей для размышления.
