Если кто давно хотел войти в 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

YouTube

IcePanel Demo - Overview

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

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

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

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

Хочу поделиться с вами своим вариантом ответа на этот вопрос: я подготовил пост, где изложил наиболее важные, на мой взгляд, особенности и различия, а так же советы по выбору решения, если вам на собеседовании или в реальной практике придется его делать, а вы не вполне уверены.

https://speca.school/monolit-vs-mikroservisy

speca.school

Монолит vs. Микросервисы

В сознании большого количества людей термины "монолит" и "микросервисы" являются чуть ли не синонимами зла и добра, монолит однозначно плохой, старый и неудобный, а микросервис - хороший, современный и решает все проблемы. Попробуем разобраться, чем они отличаются…

В одном из профильных чатов познакомился с Владом (@fenrrr), который тоже ведет канал для системных аналитиков. Пообщались, посмотрели каналы друг друга, решили порекомендовать своим аудиториям. Там приятный такой живой контент, кажется, многим зайдет.

Это моя первая такая рекомендация, поэтому я бы хотел подчеркнуть, что это не реклама (наш канал некоммерческий) и если бы мне контент не понравился, я бы рекомендовать не стал.

Собственно, канал: https://t.me/godnolytika

Telegram

Влад | аналитик от бога

Честно и смело про карьеру и насмотренность в IT Автор: Владислав Князев Системный аналитик, ex-тимлид, предприниматель Связаться: @fenrrr ***🎓***Готовлю к собеседованиям на системного аналитика: https://godnolytika.ru

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

Легенда:

Синхронные вызовы - показывает, насколько данный способ "удобен" и общепринят для организации синхронных вызовов при отсутствии других ограничений.

Асинхронные вызовы - показывает, насколько данный способ "удобен" и общепринят для организации асинхронных вызовов при отсутствии других ограничений.

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

Большой объем данных - показывает, насколько данный способ подходит для передачи больших сообщений (десятки и сотни Мб)

Безопасность и контроль - показывает, насколько гибко и удобно данный способ позволяет ограничивать права доступа и обеспечивать контроль со стороны служб информационной безопасности (актуально для корпораций)

Дешевизна сопроводжения - отражает сопутствующие расходы на вспомогательное ПО, инфраструктуру, сопровождение и стоимость разбора инцидентов

Толератность к недоступости - показывает, насколько данный способ нечувствителен к тому, что одна из систем, участвующих в обмене, будет недоступна какое-то время (способность обеспечивать гарантированную доставку и хранить сообщения в промежуточном слое)

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

https://excalidraw.com/

Excalidraw

Excalidraw — Collaborative whiteboarding made easy

Excalidraw is a virtual collaborative whiteboard tool that lets you easily sketch diagrams that have a hand-drawn feel to them.