Семь красных линий

Если кто давно хотел войти в IT, но не знал как - вход выглядит вот так )

Всем, кто ведет проекты в пространствах атлассиан - ALARM! Напишите, пожалуйста, в комментариях, куда перезжать будете. Может быть полезно всем. Полный текст новости на hi-tech.mail.ru

Я не знаю, чье это, но это прям хорошо

Во времена, когда я уже считал себя крутым и опытным аналитиком, но еще таковым не был, случилось мне закуситься с моим руководителем, который, как раз, был крутым и опытным. Я написал очень подробную спецификацию для какой-то фичи и принес ему на ревью. Он посмотрел, поморщился, сказал: "Я бы сделал так" - и набросал за час свою версию. Я пришел ругаться, мол, у меня все подробно расписано, а ты тут набросал в общих чертах, как разработчик поймет, что именно нужно делать?! На что он мне ответил: "Зато моя спека компилится, а твоя - нет". Я немного завис на этой фразе, а продолжил: "Вот давай по шагам выполнять то, что у тебя написано" - и там выявилось несколько мест, в которых или не было определено поведение для системы, или состояние было противоречивым, или не хватало каких-то данных. Меня эта история задела, но урок я выучил и с тех пор всегда проверял мысленно, "скомпилится" ли моя спецификация. И это - очень хороший прием для самоконтроля: я много раз видел ТЗ, постановки н разработку или спецификации, которые "не компилировались" - как правило, у них были непроработанные ветки алгоритма. Со временем я выделил для себя несколько мест в бизнес приложениях, в которых чаще всего возникают такие "ошибки компиляции". Хочу привести некоторые из них: возможно, начинающим аналитикам будет полезно - если вы видите одну из описанных ниже ситуаций, особенно тщательно проверьте все логические развилки и возможные сценарии. Список, разумеется, не исчерпывающий. 1. Взаимосвязанные поля на форме (например, выбор страны и выбор города или поля для ввода значений какой-нибудь формулы) - всегда нужно исходить из того, что данные на форме могут вводиться и потом изменяться в любом порядке - у вас не должно быть на форме полей, которые не пересчитались или не очистились. 2. Навигация по системе (хлебные крошки, меню и прочее): не должно быть "тупиков" - то есть экранов или состояний, из которых пользователь может выйти только кнопкой "назад" в браузере; любые перемещения по разделам нужно делать только средствами навигации системы. 3. Возможность исправить ошибку ввода. Буквально на прошлой неделе столкнулся с таким кейсом (как пользователь): форма ввода предполагала загрузку вложения; я нажал на кнопку, загрузил файл, кнопка заменилась на какой-то текст, а потом я получил ошибку "файл слишком большой", а кнопка загрузки - так и не появилась. То есть у меня была только одна попытка загрузить правильный файл. Это не совсем пример про "не компилится", но это тоже очень плохое решение. 4. Статусная модель объектов, особенно если у нас более двух атрибутов, определяющих статус или несколько связанных объектов: нужно буквально проверить все возможные сочетания статусов и убедиться, что для каждого из сочетаний определено поведение (или есть проверка на недопустимость статусов). 5. Синхронизация статусов между смежными системами: частый кейс, когда создается объект (например, заявление или платеж) во внешней системе со своей статусной моделью, а вы хотите сделать его отображение в своей. Там тоже нужно матрицу состояний проверять очень тщательно, а также помнить, что во внешней системе может что угодно измениться без вашего ведома и нужно быть к этому готовым. 6. Проверка на пустые/невалидные значения: система всегда должна быть готова к тому, что с формы или через API придут пустые или невалидные данные, верить никому нельзя: нужно всегда предусмотреть поведение системы, если такое случится. 7. В описании любых алгоритмов, на любое "Если" нужно проверить, есть ли ответ на вопрос "А если нет?" - часто описывается только позитивный сценарий, а нужны еще альтернативные/негативные.

Открыл тут для себя один сервис, с которым сижу сейчас, разбираюсь, возможно, вам тоже понравится: icepanel.io - это что-то среднее между редактором диаграмм и репозиторием для учета модулей или инфраструктуры, как они его сами назвают - modelling tool. Посложнее Visio, но его идея в том, что он не просто позволяет нарисовать диаграмму: он позволяет вести учет узлов и их визуализацию. Из того, что я пока знаю: 1. Можно делать менять масштаб узлов, например квадратик "Система А" развернуть, и там будет фронт, бек, база 2. Можно узлам ставить теги и потом подсвечивать, например, все модули на Java или все узлы с каким-то вашим признаком 3. Умеет вести версионность вашей схемы 4. Умеет анимировать очередность вызовов: например, как обрабатывается тот или иной запрос в большой микросервисной архитектуре. Ну и там еще всякое разное. Есть платная версия, есть бесплатная с некоторыми ограничениями. У них на сайте есть демонстрационный видеоролик, посмотрите, вдруг кому будет полезно, потому что у меня прям есть задачи, которые эта штука вроде как может решить. https://www.youtube.com/watch?v=jKdenkqRalI

Бывало у вас такое? У меня - неоднократно, правда не с дизайнерами, а с менеджерами. Сидишь и думаешь: "Что делать-то? На встрече спорить со своими не круто, нужно выступать единым фронтом, иначе не продадим. Промолчать - выстрелить себе же в колено". А потом выясняется, что это не менеджер дурак, а ты не понимаешь, как работают продажи. На встрече сформировалась общая эмоция или принципиальное согласие, а потом уже, в переписке, перед подписанием контракта (а иногда и после) уточняются детали, что что-то будет работать чуть иначе, что это был концепт и прочее. Иногда заказчик недоволен, иногда это теряется в бюрократии, так как решение принимает первое лицо, а разгребают потом его сотрудники. Меня, как инженера, это всегда коробило, но со временем пришло понимание, что технический перфекционизм почти никому не нужен, всем нужен бизнес, а IT это лишь средство и не всегда ключевое. Часто достаточно, чтобы как-то работало, остальное сделает маркетинг. И мне пришлось принять довольно тяжелую, хотя и очевидную мысль, что для того, чтобы бизнес шел хорошо, иногда нужно выключать "хорошего айтишника" и включать "продажного" - не в плане личной выгоды, а в плане поддержки интересов той стороны, которую ты представляешь. Позднее, я несколько раз наблюдал такую картину (особенно в корпорациях): сидят на встрече коллеги из бизнеса, играют в свои "шахматы", пытаясь аккуратно решить свои вопросы. И тут айтишник начинает рубить правду-матку, говорит, что так нельзя, так неправильно, уходить в какие-то детали, а ребята из бизнеса смотрят на него и по лицам видно, что он им вообще не помогает сейчас. И вроде бы ничего страшного, ты же прав, но на самом деле, пока ты не научишься на таких встречах принимать сторону своего бизнеса и не мешать продажам, тебя не будут считать "надежным". А как мы все знаем, карьеру лучше всего делают не самые умные, а те, кто снимает боль начальства и на кого можно положиться и быть уверенным, что он не подставит на встрече.

Иногда на собеседованиях я спрашиваю, чем отличается монолит от микросервисов. Вопрос специально сформулирован нестрого, чтобы было место для дискуссии. Отвечают разное, но чаще всего рассказывают об опыте их организации, которая переводила старинное legacy приложение на новый стек, что не является ответом на вопрос в общем случае. Хочу поделиться с вами своим вариантом ответа на этот вопрос: я подготовил пост, где изложил наиболее важные, на мой взгляд, особенности и различия, а так же советы по выбору решения, если вам на собеседовании или в реальной практике придется его делать, а вы не вполне уверены. https://speca.school/monolit-vs-mikroservisy

В одном из профильных чатов познакомился с Владом (@fenrrr), который тоже ведет канал для системных аналитиков. Пообщались, посмотрели каналы друг друга, решили порекомендовать своим аудиториям. Там приятный такой живой контент, кажется, многим зайдет. Это моя первая такая рекомендация, поэтому я бы хотел подчеркнуть, что это не реклама (наш канал некоммерческий) и если бы мне контент не понравился, я бы рекомендовать не стал. Собственно, канал: https://t.me/godnolytika

Наглядная, хотя и несколько условная диаграмма характеристик различных способов интеграции. Может помочь как на интервью, так и с реальной задачей. Чем дальше точка от центра, тем выше характеристика. Легенда: Синхронные вызовы - показывает, насколько данный способ "удобен" и общепринят для организации синхронных вызовов при отсутствии других ограничений. Асинхронные вызовы - показывает, насколько данный способ "удобен" и общепринят для организации асинхронных вызовов при отсутствии других ограничений. Высокая скорость - общая скорость информационного обмена с учетом времени на сетевое взаимодействие, работу различных планировщиков и других вспомогательных функций Большой объем данных - показывает, насколько данный способ подходит для передачи больших сообщений (десятки и сотни Мб) Безопасность и контроль - показывает, насколько гибко и удобно данный способ позволяет ограничивать права доступа и обеспечивать контроль со стороны служб информационной безопасности (актуально для корпораций) Дешевизна сопроводжения - отражает сопутствующие расходы на вспомогательное ПО, инфраструктуру, сопровождение и стоимость разбора инцидентов Толератность к недоступости - показывает, насколько данный способ нечувствителен к тому, что одна из систем, участвующих в обмене, будет недоступна какое-то время (способность обеспечивать гарантированную доставку и хранить сообщения в промежуточном слое)

Мне тут недавно попался очередной векторный редактор для всяких схем и диаграмм - незатейливый, но очень приятный и с интересной функцией - там можно делать фреймы, рисовать что-то в них и все фигуры будут обрезаться по границам фрейма (и как группировка работает). Хочу поделиться, может кому зайдет: https://excalidraw.com/

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

Должен ли системный аналитик "рисовать UI"? Несколько раз я становился свидетелем дискуссий о том, кто должен рисовать экранные формы, аналитик или дизайнер. Хочу поделиться своим опытом и позицией по этому поводу. Пользовательский интерфейс современного сайта или приложения - это давно не просто красивая картинка, это интерактивный инструмент с кучей функций, с возможностью передавать, принимать и отображать данные с сервера в реальном времени; а раз мы говорим о функциональности, значит у нас появляются функциональные требования, которые надо некоторым образом отразить в документации. Глобально эти можно сделать двумя способами: текстом и графически. Текстовое требование к интерфейсу может быть, например, таким: "При нажатии на кнопку А должен открыться системный диалог открытия файла с диска". К нему, очевидно, никакая иллюстрация не нужна, этот интерфейс отличается в разных операционных системах, разработчик им не управляет. А еще текстовое описание может быть таким: "На форме должны быть элементы управления, позволяющие листать ленту изображений" - мало понятно, что вообще с этим делать. Чтобы стало более понятно, можно написать абзац текста вида "в левом верхнем углу должна быть расположена стрелка, похожая на треугольник с вершиной, направленной...", а можно нарисовать эскиз. Это не дизайн системы, это именно функциональный эскиз. Он не должен быть красивым, в правильных цветах и сверстан по сетке, но он обязательно должен содержать в себе все элементы, которые имеют функциональное значение. Многие ребята (и я в том числе) прям на эскизе проставляют номера для элементов, чтобы затем в тексте на них ссылаться. Функциональный эскиз - это не просто корявы "примерный рисунок" - на нем должны быть отражены все возможные состояния (нет данных, введено столько данных, что все не влезло, и тд). Важно в этот момент к пользовательскому интерфейсу относиться не как к картинке или "задаче для гуманитария", а как полноценной части системы, с функционалом, ограничениями, поведением и возможностями по отображению данных. Теперь про дизайнеров. Дизайнер (в данном случае UI дизайнер) это не просто человек, который умеет красиво рисовать, он не художник. Задача дизайнера - создать работоспособный макет, который будет реализован фронтенд-разработчиком, который будет соответствовать техническим стандартам, не допускать неоднозначного поведения, учитывать особенности восприятия человеком цветов и пропорций, ну и выполненный в определенной корпоративной стилистике. То есть дизайнер в некоторой степени тоже должен владеть инженерными знаниями и может выполнить функцию проектирования интерфейса. Кто же в итоге должен проектировать интерфейс, аналитик или дизайнер? На практике встречаются оба варианта и я видел успешные примеры обоих вариантов: 1. Аналитик готовит эскиз, а дизайнер по нему отрисовывает полноцветный макет: больше подходит для бизнес приложений, где "дизайнерской составляющей" не так много, но есть какие-нибудь сложные таблицы или формы с неочевидным поведением и тесной связью клиентского и серверного функционала. 2. Дизайнер сразу рисует макет, руководствуясь теми же бизнес требованиями, что и аналитик (котрый пишет системные требования к бекенду). Больше подходит для т.н. digital продуктов, где важна эстетическая составляющая, много графики, какого-то чисто фронтального интерактива и не очень много логики. В этом случае такие макеты должны проходить обязательное ревью у аналитика на предмет отсутствия расхождений: если для бекенда описан API, который возвращает таблицу с 5 полями, а на макете нарисовано только 3, значит нужно выяснить и или убрать лишние из API, или добавить еще два на макет. Второй вариант, кажется, более экономный в плане бюджета, но требует более высокого уровня навыков и вовлечения от дизайнера.

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

Иллюстрация к предыдущему посту (телеграм не дает много текста и картинку разом отправлять)

Как объяснить заказчику, зачем в команде аналитик? Как выгляит типовое начало проекта по разработке? Приходит заказчик и говорит, что ему нужна система, автоматизирующая его бизнес процесс; он рассказывает о целях и ценности, описывает пару основных сценариев, иногда приходит с набором требований, которые может себе представить или которые являются важным уточнением, и просит оценить. Но если оценить (и сделать) только то, что было заявлено заказчиком, система будет неудобной и ненадежной, так как требования, озвученные заказчиком не включают обычно целый ряд функций, о которых по той или иной причине не подумали. Я хочу поделиться небольшим списком аспектов или функций, на базе которого можно построить аргументацию в ключе "а об этом кто-нибудь подумал?" Это мой персональный рейтинг пропущенных разделов, у вас в вашем опыте может быть другой. (продолжение в следующем посте) 📍 Пользователи. Одна фраза "пользователь входит в систему" тянет за собой целую гирлянду функций: регистрация, восстановление пароля, подтверждение email, раздел в админ-панели для упрвления пользователями, раздел "Профиль", в котором что-то можно менять, что-то нельзя. 📍Настройка ролей пользователей. Иногда это требует пересмотра предложенного процесса, но как минимум нужен раздел в админ-панели для управления и серия неприятных вопросов вида "как должен выглядеть интерфейс сиситемы, если пользователю назначат две противоположные роли, например, покуптель и продавец?" 📍 Процессы. Если в системе предполагается обработка какого-то протяженного во времени бизнес-процесса (например, рассмотрение заявки на кредит), нужно мысленно пройти по нему, пытаясь на каждом шаге сломать процесс и выяснить, как система себя должна вести. Например, документ на подтвержлении у сотрудника, а сотрудник уволился - как его вернуть обратн в обработку? Механизмы ручного завершения процессов - важная функция в таких системах. 📍 Жизненный цикл объектов, особенно документов. Нужно также в голове пройти по всем возможным состояниям и спросить, что будет в какой-нибудь нетипичной ситуации. 📍Любые эвристические механизмы. Как только вы слышите "Система автоматически предлагает лучший вариант" - нужно выяснить, по каким правилам она будет это определять. Для любого "автоматического определения" чего-нибо нужен строгий формальный алгоритм. 📍 Версионирование. Если нужно хранить историю изменений каких-то данных и потом на основании этого производить вычисления, то нужно будет выяснить детально бизнес-правила для работы с ними. Версионирование коварная шутка, особннно, когда пояаляется "две линии времени" - это когда у нас есть документ, действующий в период времени T1-T2, а есть версия документа, актуальная в период T3-T4, описываающая значения Т1 и Т2. 📍 Аудит, журнал изменений, бизнес логи. Об этом часто не думают, но потом выясняется, что это нужно. 📍 Золотая классика: "Отчеты". Обычно этот пункт в ТЗ описывается буквально одним словом и заказчик просит оценить, сколько займет разработка отчетов. По возможности, не играйте в эту игру, пока вам хотя бы примерно не расскажут, какие отчеты нужно сделать; у меня бывали случаи, когда для реализации отчета приходилось дорабатывать модель данных и функционал, потому что из того, что было в системе, нужный разрез просто не построить.

Я же не один это вижу? Хочу поделиться негодованием ) Выскочила в ленте реклама новой отечественной БД. О, думаю, очередные ребята перекрасили беспланый PostgreSQL и хвастаются импортозамещением. Листаю ниже, а там - форма заявки обратной связи, как для зубных имплантов или семинара по управлению вселенной! Сколько стоит - не написано, но можно получить демо на 30 дней в обмен на контактные данные. И мне чет и смешно и грустно одновременно: ребята из команды разработки старались, что-то делали в рамках перекрашивания, бюджеты, опять же, были освоены нестыдные, а команда маркетинга, вместо того, чтобы посмотреть, как выглядят сайты у других СУБД (включая проприетарные), сделала дешевый лендинг со сбором контактных данных. Не представляю, кого из экспертного сообщества может привлечь такой подход

Картинка к предыдущему посту

"Сказал Б, говори Ц": пресловутая CAP-теорема Еще одна не самая приятная тема, которая иногда всплывает на собеседованиях - к частью, нечасто и, в основном, на высокие позиции, раз уж говорим о распределенных системах, нельзя не упомянуть ее. Забегая вперед, скажу, что это не догма и не высшая истина - есть обоснованные заявления о том, что она недостаточно точна или вовсе не актуальна, но для понимания того, как развивалась компьютерная наука, полезно знать в общих чертах. Итак, CAP-теорема - это утверждение, что в любой распределенной системе возможно обеспечить не более двух характеристик из трех: 🔹Consistency (согласованность) - данные на всех узлах в любой момент времени находятся в согласованном состоянии (грубо говоря, одинаковые) 🔹Availability (доступность) - если узел распределенной системы физически доступен, то чтение и запись возможны в любое время без ограничений 🔹Partition Tolerance (устойчивость к разделению) - если между узлами распределенной системы пропадет связь, то они продолжат работать в условиях такого разделения. У этого утверждения есть формальное доказательство (поэтому оно и называется теоремой), но мы попробуем простыми словами. Представим себе систему, у которой несколько узлов: мы хотим одновременно читать/писать в любой из узлов, при этом все данные должны сразу (ну или близко к "сразу") синхронизироваться между собой по сети и при этом нам надо, чтобы это все работало.. когда между узлами нет сети. Звучит как взаимоисключающие параграфы и это они, в общем-то, и есть, об этом теорема и говорит. На практике для нас это важно может быть в том смысле, что нам полезно знать, какие из два их трех свойств поддерживает наша система, так как от этого зависит реализация тех или иных требований. Какие могут быть варианты? Рассмотрим комбинации характеристик (все они работают в случае, если сами узлы доступны и работают) 🔸CA (только согласованность и доступность) - все работает хорошо, пока между узлами есть связь и возможна репликация и распределенные транзакции. Если узлы разделены - невозможно обеспечить согласованность и сделать распределенную транзакцию. К таким системам относятся MySQL, PostgreSQL и вообще все реляционные СУБД. 🔸CP (только согласованность и устойчивость в разделению) - эти системы гарантируют, что данные останутся согласованными будут работать автономно при разделении, но не дадут сделать запись (теряем Availability), так как запись в автономный узел нельзя будет реплицировать на другие. Классический пример такой системы - MongoDB 🔸AP (только доступность и устойчивость к разделению) - эти системы не гарантируют строгую согласованность в любой момент времени (только согласованность в конечном итоге), каждый узел работает как самостоятельная система и, по возможности, синхронизируется с другими. Яркий пример - система доменных имен (DNS) или Redis. Эти системы доступны для чтения и записи всегда, работают даже в условиях разделения, но нужно иметь ввиду, что данные на разных узлах могут различаться (быть неконсистентными). Еще раз напомню, что CAP-теорема, несмотря на свою известность, считается устаревшей, а на ее основе выведена новая, более строгая, PACELC-теорема. Она является, по сути, расширением и про нее, если вам эта тема интересна и вы хотите углубиться, можно прочитать на википедии, там достаточно понятно написано. #СУБД

"Сказал А, говори Б": от ACID к BASE Ранее мы разбирали принцип ACID, который гарантирует, что базы данных работают надежно и корректно. Но этот принцип применим только к локальным СУБД (то есть когда все данные хранятся в одном инстансе). Но что если у нас распределенная база данных? Для начала, давайте определимся, что это такое. Распределенная БД (или распределенное хранилище) - это два и более экземпляров СУБД, которые установлены на разных узлах сети, но при этом хранят логически связанные данные. Данные на разных узлах такой БД могут дублироваться полностью или частично, иметь разную структуру и назначение, но ключевое в них то, что логически связанные данные хранятся на разных серверах. Пример распределенного хранилища с полным дублированием - система DNS (это та, которая хранит информацию о том, какой IP адрес соответствует тому или иному доменному имени в интернете) или блокчейны: в таких хранилищах могут быть тысячи и тысячи узлов и изменение, которое сделано было в одном из них, должно появиться во всех узлах. Примером частичного дублирования данных могут быть различные сервисы с тяжелым контентом (соцсети, видеохостинги, файловые ресурсы): у них много серверов по всему миру, в разных регионах, но, например, русскоязычный контент копируется только между серверами, стоящими в русскоязычных регионах: там это делается для быстрого доступа: скачивать ролик через весь интернет каждый раз долго и дорого, дешевле его разместить на локальных серверах в каждом регионе; при этом, в австралийском сегменте эти данные не нужны: раз в год можно и по сети запросить. Очевидно, что никакое изменение, сделанное на одном из узлов такого хранилища, не появится на всех узлах сети одновременно: это требует времени на передачу по каналам связи, часть узлов вообще может быть недоступна в это время. Получается, что, строго говоря, такое хранилище не соответствует принципам ACID, причем ни одному их них. Но это не потому что хранилище плохое, а потому что такие системы используются для решения других задач. И для таких распределенных систем сформировался свой набор принципов, который обозначается аббревиатурой BASE. 🔹Basically Available (большей частью доступен) - этот принцип говорит, что распределенная система может быть оставаться в целом доступной даже если часть ее узлов выйдет из строя, так любые данные реплицируются на несколько узлов. Распределенная система жертвует мгновенной консистентностью в угоду высокой доступности. 🔹Soft state (мягко контролируемое состояние) - этот принцип говорит, что состояние системы после сохранения изменений на одном из узлов может меняться в течение какого-то времени (сохраненное изменение постепенно распространяется по узлам) и это само по себе не является вообще проблемой: разработчики должны учитывать это еще на этапе проектирования системы, чтобы быть готовыми к тому, что в какой-то момент времени данные на разных узлах могут различаться. Одни пользователи могут увидеть изменение раньше, чем другие и это нормально, нужно уметь с таким жить. 🔹Eventually consistent (согласованность в конечном итоге) - распределенная система гарантирует, что рано или поздно все изменения распространятся по всем нужным узлам, но при этом не говорит, когда именно. Точнее, сам принцип не устанавливает конкретных ограничений, но разработчик должен об этом как-то позаботиться, чтобы обеспечить вменяемый SLA для своей системы. Например, служба DNS утверждает, что любые изменения в доменных записях будут доставлены на все сервера в течение суток. Понятное дело, что если один из серверов неделю будет выключен, то через сутки там ничего не появится, но система рано или поздно доставит обновление и на этот узел тоже. Главное - обеспечить механизм доставки. В отличие от ACID, соответствие которому обеспечивается разработчиками самой СУБД, реализовывать BASE в крупных системах приходится самим разработчикам, а значит и нам, аналитикам, нужно хорошо понимать эти принципы тоже. #СУБД