спасибо! глубокая гиковская техническая статья - нынче к сожалению редкость на хабре… и хотя многого не понял (сборкой ядра FreeBSD или глубокими копаниями с гипервизорами никогда не занимался), но читать было интересно!
при работе на виртуальной машине с 1 ЦП и 128 МБ оперативной памяти ядро FreeBSD успевает загрузиться менее чем за 20 мс
возникает вопрос, а линукс грузится быстрее или медленнее?
в документации Firecracker видим:
With a microVM configured with a minimal Linux kernel, single-core CPU, and 128 MiB of RAM, Firecracker supports a steady mutation rate of 5 microVMs per host core per second
т.е. загрузка аналогичной Linux VM занимает 200мс. но здесь наверное нельзя сравнивать напрямую, так как процесс загрузки включает также иные шаги, кроме загрузки ядра?
Вопросник очень неполный, там на самом деле гораздо больше нюансов. Например, только по теме mfa можно говорить, наверное, час: как защищаться от leak-ов БД mfa-токенов, как оптимизировать mfa чтобы не надо было посылать платную смс каждый раз, вопросы accessibility, как защищаться от социальной инженерии, что делать если пользователь потерял свой mfa и recovery codes тоже, может ли смс считаться безопасным методом mfa и т д. и т.п. Очень обширная тема.
Но главное не это: по моему опыту, знание аутентификации плохо коррелирует с определением джун/мид/сениор. Я раньше тоже задавал кучу вопросов по безопасности на каждом собеседовании (поскольку сам очень много знаю по теме, приходилось например участвовать в защите крупных систем от ботнет-атак в качестве техлида), но быстро понял, что это плохо работает. И в последнее время сомневаюсь, что это подходит даже как "один из вопросов".
Я вполне могу представить классного сениора, который с этой темой не работал совсем, и как следствие, он её будет знать на уровне джуна. И наоборот, джун, который был в команде которая делала аутентификацию, и он будет знать все эти вещи на хорошем уровне.
Системы аутентификации и авторизации часто либо используются готовые, либо в серьезных конторах типа юникорнов и фаанг - пишутся отдельной командой. Условно у вас есть 50 команд в продукте, и только у одной из них есть серьёзный опыт работы с аутентификацией. Все остальные знают тему шапочно - но это не означает, что они плохие программисты.
Готовые системы тоже не стоит недооценивать, особенно от фаанг. Они сделаны очень хорошо и продуманы до мелочей. Лучше использовать их, чем написать велосипед и завтра получить очередной leak персональных данных людей, которые вам доверились. Плюс, как вы правильно заметили в статье, всегда есть вариант с oidc/saml.
Резюмируя, я бы не стал спрашивать эти вопросы на собеседовании кроме следующих случаев:
когда нанимаете в команду аутентификации
когда нанимаете архитектора по безопасности
когда кандидат заявляет, что знает эту тему хорошо, тогда стоит проверить, насколько хорошо :)
Вы всё правильно говорите (хотя сарказма многовато). У меня даже в привычку уже вошло: как затык - так иду чай пить (и это неспроста, немного отвлечься часто помогает).
Однако вы опускаете тот факт, что всё таки в перерывах между кофе вы пишете и читаете код, и с коллегами тоже обсуждаете наверное не только погоду, но и технические моменты.
Я к тому, что в нашу работу входит множество разных вещей, и требуются знания по множеству разных тем, и плюс к тому для выполнения работы нужна куча различных навыков. На собеседовании пытаются проверить все эти вещи, но наивный подход к проверкам работает плохо, и плюс к тому, умение правильно собеседовать - это тоже навык, и он есть далеко не у каждого программиста/тимлида, в итоге имеем то, что имеем...
Практика автора - несомненно интересна. Очевидно, что она проверяет некоторое подмножество навыков кандидата которые он использует в повседневной работе, но далеко не всё.
Можно ли по подмножеству (у автора - это умение думать, наличие собственного мнения, продуктовое мышление и др.) судить о множестве? С некоторой вероятностью, вполне. Но если так, то можно предположить, что если взять другое подмножество (кодинг-скиллы, или навыки по чтению кода, абстрактное мышление, способность крутить деревья), то точно также можно с некоторой вероятностью судить о полном множестве.
Успешность найма в случае автора может быть объяснена тем, что поскольку способность крутить деревья проверяют чаще, люди которые пытаются хакнуть интервью, скорее будут учить деревья, а не продуктовое мышление. Но можно ли хакнуть точно также тест на продуктовое мышление? Я думаю, без проблем...
не могли бы вы пояснить, что имеется в виду под "правильными (business-faced) автотестами"? acceptance тесты на стороне UI? интеграционные end-to-end тесты? или что-то другое?
при изменении бизнес-требований, обычно меняется всё. в этих условиях, как правило, приходится переписывать солидные куски кода, и соответственно удалять/исправлять тесты, причем на всех уровнях, от юнит-тестов до интеграшек.
как только мы меняем тесты, гарантия работоспособности этой части системы теряется, и её нужно заново подтверждать - т.е. как правило это полная регрессия, причём ручная, и даже она не даёт полной гарантии, потому что тестировщик не факт что полностью понимает, как конкретно должен теперь работать связанный с изменениями функционал.
я был как раз лидом/архитектором, участвовал в первой итерации, но потом меня переключили на другой проект и около года я в проекте не участвовал совсем. вернулся только на третью итерацию.
в консалтинг компаниях это не такая уж редкая ситуация. самые грамотные кадры всегда требуются на самых ответственных проектах - а это как правило новые проекты для новых заказчиков.
похожая ситуация, кстати, и в быстрорастущих стартапах. там просто настолько быстрый рост, что условно говоря 60% всех программистов работают в компании меньше полугода (а для системы с миллионами строк кода, полгода опыта, это уровень "уверенного новичка"). куча совершенно новых команд, где хорошо если один "ветеран", и т.д.
Я кстати согласен с автором касательно того, что многие программисты не представляют, как менять схему данных на живой системе именно с точки зрения процесса выгрузки и программирования. У нас тоже есть такой вопрос в собеседованиях, правда мне больше нравится спрашивать про сплит полей.
А что касается "technicalities", из серии как дропнуть колонку в таблице с 100млн строк "на живую" и не положить мастер при этом, это несколько другая задача, к которой программисты часто не имеют никакого отношения и этот процесс, как вы правильно заметили, лежит в сфере интересов ДБА.
Кстати, вдруг вам поможет, мы для этого использовали gh-ost, очень хорошо работает.
В общем, это две разные темы, и мне кажется, их описывать в одной статье даже может и не стоит, ведь аудитории совершенно разные.
Автору на заметку: может быть имеет смысл уточнить целевую аудиторию статьи.
согласен, в проекте с одним человеком - проще. именно поэтому, в основной части статьи я пишу о проекте, где люди постоянно менялись, как и бизнес-требования. именно в таких условиях приёмы, которые я описываю в статье, очень эффективны.
в простом и понятном коде, сложно сделать ошибку. особенно когда над кодом работает много разных людей.
Вот например, Malte Ubl из Google, пишет, что основной задачей программистов уровня выше Senior, является проектирование codebase таким образом, чтобы в этом codebase было крайне сложно допустить ошибку и чтобы качество кода сохранялось естественным образом.
В статье, я именно про это пишу в пункте "Maintainability Index". Это отличная метрика, которая позволяет не допустить (или, как минимум, замедлить) натуральный процесс деградации качества кода "over time". Конечно, это желательно совмещать с правильно поставленным code review (но это отдельная большая тема).
А вот тесты тут мало помогут, ведь тесты не проверяют качество кода, только его результат. При постоянно изменяющихся бизнес требованиях, тесты придётся менять, а каждый раз, когда меняются тесты, это разрушение гарантий правильности работы кода, т.е. весь тот код, где были тесты, которые поменялись, надо как минимум заново тестить вручную, чтобы восстановить эти гарантии.
как я упоминаю в статье, основной описываемый проект - там постоянно менялись люди, причём полностью, т.е. во второй итерации не было ни одного человека из первой и т.д.
согласен, как я уже писал выше, все методы должны применяться вместе для максимального результата, просто основная масса программистов о том, что есть что-то кроме тестов, даже не подозревает...
Если задача уж прям решить это без тестов, я бы попробовал срефакторить код так, чтобы он стал простым и легко читаемым. Может быть, попытался бы придумать другой подход к решению этой проблемы, в котором вероятность сделать ошибку была бы меньше.
Например, вы смотрели Modelling Time Эрика Эванса? Это же просто удивительный подход "outside of the box", на мой взгляд. И вместе с тем, очень разумный.
Кстати, если бы меня спросили, "назови самую сложную проблему для программиста", я бы без раздумий назвал временные зоны. Любая запутанная бизнес-логика отдыхает по сравнению с взрывом мозга, который происходит, когда работаешь с таймзонами. Даже в тестах легко запутаться с ними.
Кстати, все почему-то забывают, что есть разряд ошибок, которые очень легко совершить. Все же знают про оптические иллюзии (например, вот эти). Неважно, сколько раз смотреть на оптическую иллюзию, всё равно будет казаться неправильно. Человеческий мозг так устроен. Мы не роботы.
Если вы сделали ошибку в программе, вы можете сделать такую же ошибку на code review, и вы можете сделать такую же ошибку в тестах. От этого никто не застрахован, и на моём опыте я такое видел неоднократно. Если код запутанный, то и правильный тест для него - очень сложно написать.
А сколько раз было, что программист уронил тест, а потом подумал, ну да, у меня-то всё правильно, это наверное тест неправильный был, и поправил тест, а не свой код.
Или другой классический случай. Функция с двумя строковыми параметрами. Код полностью покрыт тестами, тесты проходят, всё идеально. Но при вызове функции из реального кода, параметры перепутали местами. У нас был такой баг в продакшене, причём оно не падало, а вело к неверному поведению в некоторых случаях, и отловить эту проблему было просто невероятно сложно. Хотя статическая типизация + линтер с правилом на недопущение параметров одинаковых примитивных типов, решают весь этот класс проблем со стопроцентной вероятностью.
Что я пытаюсь сказать: тесты, это всего лишь один инструмент из множества. Не идеальный. Я не против тестов (наоборот, двумя руками за, и вот прямо сейчас в моей текущей компании я руковожу процессом улучшения покрытия), но мне кажется, что нужно знать и другие приёмы.
Я думаю, любой язык с хорошей типизацией подойдёт. Стартап у меня на Typescript, использую ровно такие же приёмы как в статье, всё прекрасно работает.
Более того, в плане интеллисенса, реализовал полное покрытие - фронтенд (+JSX для темплейтов), бэкенд, ORM (MongoDB запросы в TS полностью покрываются интеллисенсом из коробки), и даже коммуникацию между фронтендом и бэкендом, т.е. нет magic strings в виде "/api/users", и даже можно нажать F12 из фронтенда и прыгнуть в бэкенд. Это очень круто кстати, правда требует, чтобы и бэкенд и фронтенд были написаны на одном языке (ну или нужен какой-то плагин к IDE, что уже сложнее, т.к. разные люди используют разные IDE).
На старте, в те четыре месяца перед первым продакшеном, в команде было, если мне не изменяет память, 6 человек - архитектор и ведущий разработчик (ваш покорный слуга) - отвечал за архитектуру и помогал с разработкой, фронтендер и бэкендер писали веб-морду, ещё один программист - мобильное приложение, которое использовалось водителями, также в команде были дизайнер и менеджер проекта (он же выполнял функции скрам мастера). Где-то на месяц к нам присоединялся тестировщик.
Также, активно учавствовал в процессе представитель заказчика (в качестве Product Owner'а).
Я как архитектор был ответственнен за планирование технической части, в том числе за обеспечение отказоустойчивости. Совместно с Product Owner, мы выделили критический функционал и где-то за месяц до дедлайна я произвёл анализ по модели fault tree analysis и добавил в бэклог задачи призванные повысить отказоустойчивость системы. Мы их приоритизировали и взяли в следующий спринт.
После первого продакшена, размер команды разработки был снижен до двух человек, которые обеспечивали багфиксы, доработку и поддержку внедрения. После успешного внедрения, заказчик оценил бизнес-KPI (которые мы предварительно разработали), запланировал вторую итерацию, и т.д. Впоследствии, команда разработки редко когда переваливала за 2-3 разработчиков, project manager был на проекте part-time и помогал только на Scrum-церемониях. Это довольно типичная ситуация для консалтинг-компаний.
Я пропустил вторую итерацию (был задействован на другом проекте), но учавствовал в третьей, в процессе которой я предложил дальнейшие улучшения по отказоустойчивости, в том числе написание той самой мониторинг-утилиты, которая позволила разобраться в некоторых накопившихся к тому времени проблемах с производительностью. Кроме того, был произведен повторный анализ критического функционала системы по методу fault tree analysis, и, как результат, мы добавили оффлайн режим и ещё кое-какие улучшения.
Если говорить не про консалтинг, а про продуктовую разработку, обеспечение отказоустойчивости в команде - это обычно задача техлида, а практики и рекомендации по улучшению отказоустойчивости разрабатываются архитекторами и/или командой платформы и внедряются через Global Technical Roadmap.
Все перечисленные в статье методы дополняют друг друга, дело далеко не только в мониторинг-утилите. Я бы сказал, Fault tree analysis намного сильнее улучшил для нас надежность кода.
Вот например, допустим у вас есть интеграция с финансовой системой. Вы хотите сделать её надежной. Вы покрыли её тестами, но в один прекрасный день эта финансовая система просто взяла и поменяла формат отдаваемых данных. Или просто упала. Как тесты помогут в этом случае? :)
А вот если был сделан fault tree analysis, архитектор подумал над всеми этими проблемами заранее, использовал например defensive programming для защиты от небольших изменений формата результатов, спроектировал механизм фоллбэка на резервную систему и алертов в случае полного отказа или же критичного изменения формата отдаваемых данных, и т.д.
Люди очень хороши в "pattern matching". Ручной мониторинг во время релиза, визуализация системы хотя бы через стандартные Graphana-дашбоарды - это мне кажется прям очень сильно увеличивает вероятность обнаружить ошибку. Даже если каждый индивидуальный график выглядит "ок", нет резких скачков метрик, и 0 ошибок в логах, человек всё равно может заметить, что что-то не так, по совокупности графиков, на уровне шестого чувства, и начать разбираться.
Как раз полная автоматизация мониторинга, были известные случаи, когда она очень сильно подводила.
Конечно, мы вручную проверяли после выгрузки, что визуально всё работает, но очень поверхностно. По сути, проверялось только несколько основных, самых критических страниц.
Кроме того, мы постоянно показывали систему заказчику на Sprint Demo и даже на daily, но это обычное локальное тестирование разработчиком фичей, которые он разрабатывает.
Тестировщик в команде был вроде около месяца, в самом начале проекта, но от него как-то быстро отказались.
Вы совершенно правы, денормализация является неплохим методом для улучшения производительности 👍
Я почему-то воспринимаю её как частный случай предпросчета (т.е. подготовки данных таким образом, чтобы потом было легко их доставать из БД и они уже в нужном формате), но наверное можно было вынести в отдельный пункт.
Спасибо, что прочитали статью дважды! К сожалению, система проприетарная, всё под NDA, привести скриншоты или совсем детальное описание, не представляется возможным.
Но утилита мониторинга, это просто средство отладки, средство для того, чтобы заглянуть внутрь системы и оценить её работоспособность с точки зрения задач, которые она решает.
В общих чертах, я делал например отображение запросов базы данных, поиск, фильтрацию по пользователям, самплинг, визуализацию компонентов системы и как они друг с другом взаимодействуют в процессе запроса.
Функционально похоже на Honeycomb, но более визуально, с заточкой под нашу конкретную систему.
Похожие (концептуально) вещи очень часто делают в геймдеве. Наверное видели, всевозможные режимы для разработчиков, включаешь, и видишь кучу дополнительных отладочных данных, в шутерах - линии полёта пуль, можешь смотреть через стены и т.д. А в вебдеве такое редко встречается, только в совсем крупных компаниях.
Измеримый, вы имеете в виду покрытие кода тестами?
Ну смотрите, ведь простота кода - тоже в общем-то измеримый показатель, то о чём я пишу в статье под заголовком "Maintainability Index". Так что, всё-таки рискну не согласиться, не единственный измеримый.
И кстати обе эти метрики, они не решают например проблему логических ошибок. В бизнес-приложениях, никто не знает полное количество use-case'ов, и поэтому невозможно оценить, написали ли мы достаточное количество интеграционных тестов.
Даже сам заказчик часто не знает, например, нужна ли та или иная кнопка или нет. Это надо напрямую с конечными пользователями общаться (т.е. с водителями, если брать систему из статьи), и нет никакой гарантии, что все они используют систему одинаково.
Помню, у нас был смешной случай (в другом продукте). Пользователи жалуются: система не работает, всё плохо. Покрытие кода тестами по этой фиче - гордые 100%. Тестируем вручную: всё отлично. Думаем, может это только на продакшене? Создаем тестовый аккаунт, проверяем - да всё нормально же. Ну думаем, наверное проблема в данных + продакшене. Копируем данные на тестовый аккаунт в продакшене, т.е. полная копия, идеально. И всё равно работает!
В конце концов, устраиваем звонок с пользователями, говорим, покажите пожалуйста баг. Они открывают браузер, зажимают Ctrl (я даже не знал, что так можно), и открывают 10 документов со страницы в 10 разных вкладках. К этому моменту у всей команды уже шевелятся волосы на всех частях тела...
В общем, метрики, они могут быть обманчивы. Конечно, лучше с ними, но доверять им стопроцентно, наверное не стоит.
спасибо! глубокая
гиковскаятехническая статья - нынче к сожалению редкость на хабре… и хотя многого не понял (сборкой ядра FreeBSD или глубокими копаниями с гипервизорами никогда не занимался), но читать было интересно!возникает вопрос, а линукс грузится быстрее или медленнее?
в документации Firecracker видим:
т.е. загрузка аналогичной Linux VM занимает 200мс. но здесь наверное нельзя сравнивать напрямую, так как процесс загрузки включает также иные шаги, кроме загрузки ядра?
Яндекс очень грязно ведёт борьбу с конкурентами.
Вопросник очень неполный, там на самом деле гораздо больше нюансов. Например, только по теме mfa можно говорить, наверное, час: как защищаться от leak-ов БД mfa-токенов, как оптимизировать mfa чтобы не надо было посылать платную смс каждый раз, вопросы accessibility, как защищаться от социальной инженерии, что делать если пользователь потерял свой mfa и recovery codes тоже, может ли смс считаться безопасным методом mfa и т д. и т.п. Очень обширная тема.
Но главное не это: по моему опыту, знание аутентификации плохо коррелирует с определением джун/мид/сениор. Я раньше тоже задавал кучу вопросов по безопасности на каждом собеседовании (поскольку сам очень много знаю по теме, приходилось например участвовать в защите крупных систем от ботнет-атак в качестве техлида), но быстро понял, что это плохо работает. И в последнее время сомневаюсь, что это подходит даже как "один из вопросов".
Я вполне могу представить классного сениора, который с этой темой не работал совсем, и как следствие, он её будет знать на уровне джуна. И наоборот, джун, который был в команде которая делала аутентификацию, и он будет знать все эти вещи на хорошем уровне.
Системы аутентификации и авторизации часто либо используются готовые, либо в серьезных конторах типа юникорнов и фаанг - пишутся отдельной командой. Условно у вас есть 50 команд в продукте, и только у одной из них есть серьёзный опыт работы с аутентификацией. Все остальные знают тему шапочно - но это не означает, что они плохие программисты.
Готовые системы тоже не стоит недооценивать, особенно от фаанг. Они сделаны очень хорошо и продуманы до мелочей. Лучше использовать их, чем написать велосипед и завтра получить очередной leak персональных данных людей, которые вам доверились. Плюс, как вы правильно заметили в статье, всегда есть вариант с oidc/saml.
Резюмируя, я бы не стал спрашивать эти вопросы на собеседовании кроме следующих случаев:
когда нанимаете в команду аутентификации
когда нанимаете архитектора по безопасности
когда кандидат заявляет, что знает эту тему хорошо, тогда стоит проверить, насколько хорошо :)
Вы всё правильно говорите (хотя сарказма многовато). У меня даже в привычку уже вошло: как затык - так иду чай пить (и это неспроста, немного отвлечься часто помогает).
Однако вы опускаете тот факт, что всё таки в перерывах между кофе вы пишете и читаете код, и с коллегами тоже обсуждаете наверное не только погоду, но и технические моменты.
Я к тому, что в нашу работу входит множество разных вещей, и требуются знания по множеству разных тем, и плюс к тому для выполнения работы нужна куча различных навыков. На собеседовании пытаются проверить все эти вещи, но наивный подход к проверкам работает плохо, и плюс к тому, умение правильно собеседовать - это тоже навык, и он есть далеко не у каждого программиста/тимлида, в итоге имеем то, что имеем...
Практика автора - несомненно интересна. Очевидно, что она проверяет некоторое подмножество навыков кандидата которые он использует в повседневной работе, но далеко не всё.
Можно ли по подмножеству (у автора - это умение думать, наличие собственного мнения, продуктовое мышление и др.) судить о множестве? С некоторой вероятностью, вполне. Но если так, то можно предположить, что если взять другое подмножество (кодинг-скиллы, или навыки по чтению кода, абстрактное мышление, способность крутить деревья), то точно также можно с некоторой вероятностью судить о полном множестве.
Успешность найма в случае автора может быть объяснена тем, что поскольку способность крутить деревья проверяют чаще, люди которые пытаются хакнуть интервью, скорее будут учить деревья, а не продуктовое мышление. Но можно ли хакнуть точно также тест на продуктовое мышление? Я думаю, без проблем...
не могли бы вы пояснить, что имеется в виду под "правильными (business-faced) автотестами"? acceptance тесты на стороне UI? интеграционные end-to-end тесты? или что-то другое?
при изменении бизнес-требований, обычно меняется всё. в этих условиях, как правило, приходится переписывать солидные куски кода, и соответственно удалять/исправлять тесты, причем на всех уровнях, от юнит-тестов до интеграшек.
как только мы меняем тесты, гарантия работоспособности этой части системы теряется, и её нужно заново подтверждать - т.е. как правило это полная регрессия, причём ручная, и даже она не даёт полной гарантии, потому что тестировщик не факт что полностью понимает, как конкретно должен теперь работать связанный с изменениями функционал.
я был как раз лидом/архитектором, участвовал в первой итерации, но потом меня переключили на другой проект и около года я в проекте не участвовал совсем. вернулся только на третью итерацию.
в консалтинг компаниях это не такая уж редкая ситуация. самые грамотные кадры всегда требуются на самых ответственных проектах - а это как правило новые проекты для новых заказчиков.
похожая ситуация, кстати, и в быстрорастущих стартапах. там просто настолько быстрый рост, что условно говоря 60% всех программистов работают в компании меньше полугода (а для системы с миллионами строк кода, полгода опыта, это уровень "уверенного новичка"). куча совершенно новых команд, где хорошо если один "ветеран", и т.д.
Я кстати согласен с автором касательно того, что многие программисты не представляют, как менять схему данных на живой системе именно с точки зрения процесса выгрузки и программирования. У нас тоже есть такой вопрос в собеседованиях, правда мне больше нравится спрашивать про сплит полей.
А что касается "technicalities", из серии как дропнуть колонку в таблице с 100млн строк "на живую" и не положить мастер при этом, это несколько другая задача, к которой программисты часто не имеют никакого отношения и этот процесс, как вы правильно заметили, лежит в сфере интересов ДБА.
Кстати, вдруг вам поможет, мы для этого использовали gh-ost, очень хорошо работает.
В общем, это две разные темы, и мне кажется, их описывать в одной статье даже может и не стоит, ведь аудитории совершенно разные.
Автору на заметку: может быть имеет смысл уточнить целевую аудиторию статьи.
согласен, в проекте с одним человеком - проще. именно поэтому, в основной части статьи я пишу о проекте, где люди постоянно менялись, как и бизнес-требования. именно в таких условиях приёмы, которые я описываю в статье, очень эффективны.
в простом и понятном коде, сложно сделать ошибку. особенно когда над кодом работает много разных людей.
Вот например, Malte Ubl из Google, пишет, что основной задачей программистов уровня выше Senior, является проектирование codebase таким образом, чтобы в этом codebase было крайне сложно допустить ошибку и чтобы качество кода сохранялось естественным образом.
В статье, я именно про это пишу в пункте "Maintainability Index". Это отличная метрика, которая позволяет не допустить (или, как минимум, замедлить) натуральный процесс деградации качества кода "over time". Конечно, это желательно совмещать с правильно поставленным code review (но это отдельная большая тема).
А вот тесты тут мало помогут, ведь тесты не проверяют качество кода, только его результат. При постоянно изменяющихся бизнес требованиях, тесты придётся менять, а каждый раз, когда меняются тесты, это разрушение гарантий правильности работы кода, т.е. весь тот код, где были тесты, которые поменялись, надо как минимум заново тестить вручную, чтобы восстановить эти гарантии.
"в одиночку" - это про совершенно другой проект.
как я упоминаю в статье, основной описываемый проект - там постоянно менялись люди, причём полностью, т.е. во второй итерации не было ни одного человека из первой и т.д.
согласен, как я уже писал выше, все методы должны применяться вместе для максимального результата, просто основная масса программистов о том, что есть что-то кроме тестов, даже не подозревает...
Если задача уж прям решить это без тестов, я бы попробовал срефакторить код так, чтобы он стал простым и легко читаемым. Может быть, попытался бы придумать другой подход к решению этой проблемы, в котором вероятность сделать ошибку была бы меньше.
Например, вы смотрели Modelling Time Эрика Эванса? Это же просто удивительный подход "outside of the box", на мой взгляд. И вместе с тем, очень разумный.
Кстати, если бы меня спросили, "назови самую сложную проблему для программиста", я бы без раздумий назвал временные зоны. Любая запутанная бизнес-логика отдыхает по сравнению с взрывом мозга, который происходит, когда работаешь с таймзонами. Даже в тестах легко запутаться с ними.
Кстати, все почему-то забывают, что есть разряд ошибок, которые очень легко совершить. Все же знают про оптические иллюзии (например, вот эти). Неважно, сколько раз смотреть на оптическую иллюзию, всё равно будет казаться неправильно. Человеческий мозг так устроен. Мы не роботы.
Если вы сделали ошибку в программе, вы можете сделать такую же ошибку на code review, и вы можете сделать такую же ошибку в тестах. От этого никто не застрахован, и на моём опыте я такое видел неоднократно. Если код запутанный, то и правильный тест для него - очень сложно написать.
А сколько раз было, что программист уронил тест, а потом подумал, ну да, у меня-то всё правильно, это наверное тест неправильный был, и поправил тест, а не свой код.
Или другой классический случай. Функция с двумя строковыми параметрами. Код полностью покрыт тестами, тесты проходят, всё идеально. Но при вызове функции из реального кода, параметры перепутали местами. У нас был такой баг в продакшене, причём оно не падало, а вело к неверному поведению в некоторых случаях, и отловить эту проблему было просто невероятно сложно. Хотя статическая типизация + линтер с правилом на недопущение параметров одинаковых примитивных типов, решают весь этот класс проблем со стопроцентной вероятностью.
Что я пытаюсь сказать: тесты, это всего лишь один инструмент из множества. Не идеальный. Я не против тестов (наоборот, двумя руками за, и вот прямо сейчас в моей текущей компании я руковожу процессом улучшения покрытия), но мне кажется, что нужно знать и другие приёмы.
Спасибо за отзыв!
Я думаю, любой язык с хорошей типизацией подойдёт. Стартап у меня на Typescript, использую ровно такие же приёмы как в статье, всё прекрасно работает.
Более того, в плане интеллисенса, реализовал полное покрытие - фронтенд (+JSX для темплейтов), бэкенд, ORM (MongoDB запросы в TS полностью покрываются интеллисенсом из коробки), и даже коммуникацию между фронтендом и бэкендом, т.е. нет magic strings в виде "/api/users", и даже можно нажать F12 из фронтенда и прыгнуть в бэкенд. Это очень круто кстати, правда требует, чтобы и бэкенд и фронтенд были написаны на одном языке (ну или нужен какой-то плагин к IDE, что уже сложнее, т.к. разные люди используют разные IDE).
На старте, в те четыре месяца перед первым продакшеном, в команде было, если мне не изменяет память, 6 человек - архитектор и ведущий разработчик (ваш покорный слуга) - отвечал за архитектуру и помогал с разработкой, фронтендер и бэкендер писали веб-морду, ещё один программист - мобильное приложение, которое использовалось водителями, также в команде были дизайнер и менеджер проекта (он же выполнял функции скрам мастера). Где-то на месяц к нам присоединялся тестировщик.
Также, активно учавствовал в процессе представитель заказчика (в качестве Product Owner'а).
Я как архитектор был ответственнен за планирование технической части, в том числе за обеспечение отказоустойчивости. Совместно с Product Owner, мы выделили критический функционал и где-то за месяц до дедлайна я произвёл анализ по модели fault tree analysis и добавил в бэклог задачи призванные повысить отказоустойчивость системы. Мы их приоритизировали и взяли в следующий спринт.
После первого продакшена, размер команды разработки был снижен до двух человек, которые обеспечивали багфиксы, доработку и поддержку внедрения. После успешного внедрения, заказчик оценил бизнес-KPI (которые мы предварительно разработали), запланировал вторую итерацию, и т.д. Впоследствии, команда разработки редко когда переваливала за 2-3 разработчиков, project manager был на проекте part-time и помогал только на Scrum-церемониях. Это довольно типичная ситуация для консалтинг-компаний.
Я пропустил вторую итерацию (был задействован на другом проекте), но учавствовал в третьей, в процессе которой я предложил дальнейшие улучшения по отказоустойчивости, в том числе написание той самой мониторинг-утилиты, которая позволила разобраться в некоторых накопившихся к тому времени проблемах с производительностью. Кроме того, был произведен повторный анализ критического функционала системы по методу fault tree analysis, и, как результат, мы добавили оффлайн режим и ещё кое-какие улучшения.
Если говорить не про консалтинг, а про продуктовую разработку, обеспечение отказоустойчивости в команде - это обычно задача техлида, а практики и рекомендации по улучшению отказоустойчивости разрабатываются архитекторами и/или командой платформы и внедряются через Global Technical Roadmap.
Безусловно, в разных проектах - разные особенности, и конкретные решения будут разными.
Но сам факт того, что ситуация была заранее проанализирована и нужные меры были приняты превентивным образом, вот это важно :)
Все перечисленные в статье методы дополняют друг друга, дело далеко не только в мониторинг-утилите. Я бы сказал, Fault tree analysis намного сильнее улучшил для нас надежность кода.
Вот например, допустим у вас есть интеграция с финансовой системой. Вы хотите сделать её надежной. Вы покрыли её тестами, но в один прекрасный день эта финансовая система просто взяла и поменяла формат отдаваемых данных. Или просто упала. Как тесты помогут в этом случае? :)
А вот если был сделан fault tree analysis, архитектор подумал над всеми этими проблемами заранее, использовал например defensive programming для защиты от небольших изменений формата результатов, спроектировал механизм фоллбэка на резервную систему и алертов в случае полного отказа или же критичного изменения формата отдаваемых данных, и т.д.
Люди очень хороши в "pattern matching". Ручной мониторинг во время релиза, визуализация системы хотя бы через стандартные Graphana-дашбоарды - это мне кажется прям очень сильно увеличивает вероятность обнаружить ошибку. Даже если каждый индивидуальный график выглядит "ок", нет резких скачков метрик, и 0 ошибок в логах, человек всё равно может заметить, что что-то не так, по совокупности графиков, на уровне шестого чувства, и начать разбираться.
Как раз полная автоматизация мониторинга, были известные случаи, когда она очень сильно подводила.
Нет, такого человека не было :)
Конечно, мы вручную проверяли после выгрузки, что визуально всё работает, но очень поверхностно. По сути, проверялось только несколько основных, самых критических страниц.
Кроме того, мы постоянно показывали систему заказчику на Sprint Demo и даже на daily, но это обычное локальное тестирование разработчиком фичей, которые он разрабатывает.
Тестировщик в команде был вроде около месяца, в самом начале проекта, но от него как-то быстро отказались.
Вы совершенно правы, денормализация является неплохим методом для улучшения производительности 👍
Я почему-то воспринимаю её как частный случай предпросчета (т.е. подготовки данных таким образом, чтобы потом было легко их доставать из БД и они уже в нужном формате), но наверное можно было вынести в отдельный пункт.
Спасибо, что прочитали статью дважды! К сожалению, система проприетарная, всё под NDA, привести скриншоты или совсем детальное описание, не представляется возможным.
Но утилита мониторинга, это просто средство отладки, средство для того, чтобы заглянуть внутрь системы и оценить её работоспособность с точки зрения задач, которые она решает.
В общих чертах, я делал например отображение запросов базы данных, поиск, фильтрацию по пользователям, самплинг, визуализацию компонентов системы и как они друг с другом взаимодействуют в процессе запроса.
Функционально похоже на Honeycomb, но более визуально, с заточкой под нашу конкретную систему.
Похожие (концептуально) вещи очень часто делают в геймдеве. Наверное видели, всевозможные режимы для разработчиков, включаешь, и видишь кучу дополнительных отладочных данных, в шутерах - линии полёта пуль, можешь смотреть через стены и т.д. А в вебдеве такое редко встречается, только в совсем крупных компаниях.
Измеримый, вы имеете в виду покрытие кода тестами?
Ну смотрите, ведь простота кода - тоже в общем-то измеримый показатель, то о чём я пишу в статье под заголовком "Maintainability Index". Так что, всё-таки рискну не согласиться, не единственный измеримый.
И кстати обе эти метрики, они не решают например проблему логических ошибок. В бизнес-приложениях, никто не знает полное количество use-case'ов, и поэтому невозможно оценить, написали ли мы достаточное количество интеграционных тестов.
Даже сам заказчик часто не знает, например, нужна ли та или иная кнопка или нет. Это надо напрямую с конечными пользователями общаться (т.е. с водителями, если брать систему из статьи), и нет никакой гарантии, что все они используют систему одинаково.
Помню, у нас был смешной случай (в другом продукте). Пользователи жалуются: система не работает, всё плохо. Покрытие кода тестами по этой фиче - гордые 100%. Тестируем вручную: всё отлично. Думаем, может это только на продакшене? Создаем тестовый аккаунт, проверяем - да всё нормально же. Ну думаем, наверное проблема в данных + продакшене. Копируем данные на тестовый аккаунт в продакшене, т.е. полная копия, идеально. И всё равно работает!
В конце концов, устраиваем звонок с пользователями, говорим, покажите пожалуйста баг. Они открывают браузер, зажимают Ctrl (я даже не знал, что так можно), и открывают 10 документов со страницы в 10 разных вкладках. К этому моменту у всей команды уже шевелятся волосы на всех частях тела...
В общем, метрики, они могут быть обманчивы. Конечно, лучше с ними, но доверять им стопроцентно, наверное не стоит.