Всем привет. Мой предыдущий пост, как мне кажется, получил огромный отклик. Его добавили в сохраненное только на Пикабу более 5000 человек, более 1500 репостов в ВК и более 750 комментариев, которые разворачивались в дискуссии. А также на меня подписалось около 300 человек. Тема, как выяснилось, оказалась актуальной, и интересной людям.

Я обещал ответить на вопросы, дать комментарии и поделиться ссылками и материалами, которые помогли именно мне. Обещал – отвечаю и делюсь :)

Ещё раз хочу подчеркнуть, всё что будет ниже - является сугубо моим личным мнением и опытом. Это не будет являться гайдом «как войти в айти с двух ног за 3 месяца». Моё мнение + возможно, рекомендации. Я могу быть где-то не прав, буду рад если более опытные коллеги меня поправят.

Курсы

Весь мой негатив в сторону курсов был направлен на распиаренные и разрекламированные курсы на всем известных площадках. Те самые, которые пестрят лозунгами «Легче всего попасть в IT через тестирование, мозгов не надо, 10 месяцев и мы тебя устроим на работу». Есть определенный процент людей, которые успешно заканчивают такие курсы и находят работу, повторюсь, среди моих друзей и знакомых таких людей нет.

В самом начале пути я почти купил курс на ЯП за ~75к на системного аналитика. Но ознакомившись с программой курса я понял, что 70% из предлагаемого я уже знаю и делал, остальные 30% смогу добить в бесплатных источниках. Около двух месяцев мне настырно названивали и пытались впарить (другого слова не подобрал) этот курс. Агрессивный маркетинг только усилил мою негативную позицию.

Я ничего не имею против платных и полезных курсов, и мне не жалко заплатить за повышение своей квалификации, часть таких курсов также оплачивает мой работодатель. Но они не имеют ничего общего с ЯП, ГБ и прочими. Рекламировать платные узконаправленные курсы не вижу смысла, когда они вам понадобятся – вас или на работе отправят учиться или вы уже сами будете знать чему и где вы хотите подучиться.

Образование.

Высшее образование (ВО) по моему мнению не является обязательным фактором при устройстве на работу, за исключением, наверное, сферы информационной безопасности, госконтор, и личного желания отдельных личностей видеть кандидатов с ВО. Бизнесу нужно чтобы твои знания превращались в его деньги. Если ты сможешь сделать это без корочки – работодателя не будет волновать её наличие. Я знаю людей, которые с зарплатами от 200 до 400 работают в IT-блоках крупных банков и не имеют высшего образования.

Про качество образования можно много рассуждать, но все мои знакомые кто заканчивал профильные ВУЗы отмечали лишь то, что полученные знания им не пригодились. Всему, чему нужно было научиться – они научились на работе. У кого-то уже был диплом, кто-то специально пошел получать ВО для того, чтобы иметь возможность уехать на ПМЖ в другую страну.

Про то что ВО бесполезно, я не говорю. Некоторые работодатели более лояльно относятся к кандидатам с ВО. В Университетах мы учимся учиться и выполнять бестолковые задачи в сжатые сроки. Но поступать в ВУЗ и учиться там 5 лет только для того, чтобы сменить сферу деятельности на IT – сомнительная затея.

Материалы, книги, курсы и полезные ссылки

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

Для того чтобы погрузиться в мир единичек и ноликов, было бы очень полезно понять почему именно 1, почему именно 0, и как оно всё работает. В этом помогает разобраться книга Чарльза Петцольда «Код: Тайный язык информатики». Купил бумажное издание, прочитал 2 раза. Мне очень нравится. https://www.litres.ru/book/charlz-petcold/kod-taynyy-yazyk-informatiki-48447357/

Стоит обратить внимание на канал Kontur Academy. Половину курсов на канале я точно просмотрел. Есть как базовые вещи, так и продвинутые @konturacademy1485/

По сетям мне понравился курс Андрея Созыкина. На канале также каждый сможет найти для себя что-то полезное @AndreySozykin/playlists

Перечень ссылок на общие темы хотелось бы закончить одной из самых полезных для меня ссылок. Букварь по дизайну систем - https://github.com/donnemartin/system-design-primer . Там и про сети, и про балансировку, и про микросервисную архитектуру и еще про много чего полезного.

Я не владею английским на достаточно хорошем уровне, который позволял бы мне читать всю техническую документацию и статьи без переводчика, поэтому пользуюсь расширением для Chrome “DeepL”.

Программирование

Для начала нужно для себя понять, чем вам хотелось бы заниматься. Писать мобильные приложения? Игры? Делать сайты? От этого будет зависеть выбор первого языка. Я начал со Swift. Даже купил б/у макбук для этих целей.

Swift. Книга Василия Усова «SWIFT. Основы разработки приложений под iOS, iPad OS, MacOS» - https://www.litres.ru/book/vasiliy-usov/swift-osnovy-razrabotki-prilozheniy-pod-ios-ipados-i-macos-pd-24426226/

HTML, CSS, JavaScript. Мне понравился канал Богдана Станчука. Почему-то именно он вызвал у меня доверие. Прошел видеокурсы HTML – 3 часа, JS – 11 часов. Есть информация и про Git и про Docker и 10 часовой курс по Python. Да и в целом достаточно большая концентрация полезностей на одном канале @Bogdan_Stashchuk

Python. Прошел курс https://stepik.org/course/58852/promo .

Советы, которые мне давали опытные разработчики примерно были одинаковыми:

• Практики должно быть больше, чем теории, не нужно пытаться всё сразу выучить

• Стараться постепенно изучать и само программирование. ООП, алгоритмы и т.д.

• Пет-проект обязателен. Не нужно писать калькулятор в качестве пет-проекта. Ваш проект должен быть полезным. Если это приложение для мобилок – напишите то, чем будете пользоваться сами или порекомендуете друзьям. Планировщик заданий, менеджер паролей, может быть даже интернет-магазин. По мере обучения вы будете дорабатывать и улучшать свой проект. Я до пет-проекта так и не дошел.

Тестирование

Чтобы поступить на курс по тестированию (о нём в конце) мне хватило книги Романа Савина «Тестирование ДОТ КОМ». Кто-то считает эту книгу достаточно сомнительной, но мне хватило. Плюс смотрел канал Лёши Маршала, там есть отдельный плейлист «Тестировщик с нуля» @leshamarshal/playlists . В целом, на ютубе достаточно много такого контента, не думаю, что когда вам будут рассказывать о базовых вещах информация будет кардинально различаться. Выбирайте того, кого вам будет непротивно слушать.

Одним из лучших бесплатных курсов для QA я считаю The 100-Year QA-Textbook https://mentorpiece.education/textbook/ Узнал о нём примерно через год после того как нашёл работу, прошел большую часть для интереса и расширения кругозора. Есть версия на русском, но она неполная, дополняется по мере перевода. Это полностью структурированная информация начиная с базы (сети, sql, linux, HTTP, REST, API) заканчивая техниками тест-дизайна и работой с Docker. Создатели этой книги где-то даже говорили, что «всю эту информацию можно брать и продавать на своих курсах, только указывайте автора». Не исключено, что на курсах за 100+ тысяч вы будете учиться именно по этой книге.

Аналитика

Так как я рассматривал только системную аналитику – книга Карла Виггерса и Джой Битти «Разработка требования к программному обеспечению» https://www.chitai-gorod.ru/product/razrabotka-trebovaniy-k-programmnomu-obespecheniyu-2427772

BPMN https://habr.com/ru/companies/auriga/articles/667084/

UML https://habr.com/ru/articles/738428/ https://habr.com/ru/companies/alfa/articles/740518/

Просто были сохранены в закладках эти ссылки про BPMN и UML. Поиск информации на эти темы не должен у вас вызвать трудности.

Техническое писательство

Не сильно много информации в интернете на эту тему, выделить могу только Семёна Факторовича. Канал на ютуб @documentatio/streams

Платные курсы я пока не проходил, но планирую https://documentat.io/courses/advanced-techwriting/  

Бесплатные курсы

Я сам заканчивал курс QA: https://team.cft.ru/start/school

Вам на выбор: JAVA, ML, Support, QA, Android, ИБ, Аналитика, автотестирование и другие курсы.

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

10 из 40 учеников нашли работу. Причем половина из них – в других компаниях и городах. Лично знаю нескольких разработчиков, закончивших эти курсы и получивших работу в других компаниях. И это было абсолютно бесплатно и супер полезно.

Знаю существуют подобные бесплатные школы и от ВК, и от OZON, и в Альфа-Банке что-то есть. Но я ничего про них не знаю, поэтому и рассказывать не буду.

Простыня текста, по-моему, получилась еще длиннее, чем в прошлый раз, что-то наверняка упустил, о чем-то забыл рассказать, а что-то рассказал, но криво. Мог бы еще поделиться положительным опытом в создании резюме, если это будет кому-то интересно. Если вы хотите, чтобы именно я ответил вам в комментариях, пожалуйста тегайте через @. В прошлый раз я заблудился в сотнях комментариев и, к сожалению, не всем смог ответить :(

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

Самое главное, но не самое первое, что должен сделать для себя падаван, - это изучить академисческую теорию. Да, сука, без нее ника и никуда, если вы, конечно же, хотите что-то там зарабатывать:

• Если вы идете менеджеры, то тут общая литература - менеджмент проектов (но и разработку бы хорошо изучить хотя бы на уровне "чайника", дабы не возникало вопросов в стиле "Хули 4 дня на изменгение цвета кнопки?!".

• Если идете в аналитики, то тут хорошо автор предыдущего поста описал, но аналитика бывает двух вариантов:

  • Аналитика данных - тут, да, БД учить, OLAP/OLTP, СУБД и тд. Хорошо бы еще теорию данных в целом подучить.

  • Аналитика проектов - это следующий этап развития PO/PM:

    • Бизнес-аналитка - вы думаете, как сделать систему лучше.

    • Системный анализ - вы думаете, как заставить системы лучше взаимодействовать.

• Если идете в QA, то:

  • Есть ручное тестирование - с этого нужно начинать, т.к. это позволит въехать в область впринципе: кейзы, сценарии, уровни тестирования и тд.

  • Автотестирование - это уже разработка, ибо нужно писать код для автотестов разного уровня: функциональные, интеграционные, приемочные, и тд.

• Есть еще целая сфера DevOps:

  • DBA - это специализация на конкретных БД, причем, не только на ее администрировании, но и на использовании, поэтому нужно не только знать саму СУБД, но и теории данных, SQL/noSQL нотации конкретной СУБД, механизмы отказоустойчивости и масштабирования.

  • Просто DevOps, которые раньше назывались "админами": тут нужно знать теории сетей и операционных систем, знать современные технологии базирования проектов: контейнеры, оркестраторы, CI/CD системы (для них, кстати, тоже нужен хотя бы один язык, часто: Питон или Ruby).

  • Т.н. "сетевики": персонал, специализирующийся на работе с сетями передачи данных. Тут, имхо, вряд ли можно попасть "после 30-ти".

• Разработка. Тут нужно начинать с изучения компилируемых и интерпретируемых языков, их разницы. Почему-то сейчас считается, что "войти в Питон" или "войти во фронт" за полгода реально. Реально, на позицию стажера. А где вы видели позиции стажера? Я видел один раз в жизни. Поэтому нужно выбирать специализацию в ней развиваться, затарившись тонной литературы, начиная с теории данных, заканчивая, например, в случае C/C++ теорией компиляторов.

  • Бекенд. Это "прослойка" между системами хранения данных и фронтами (мобильным приложение, сайтом или другим бекендом). Тут - оболие всего и вся: РНР, Питон, Go, Rust, Ruby и тд. В обоих видах языков свои плюсы и минусы. Суть бека состоит в том, что нужно знать часто минимум два языка. Например: PHP + Go, Python + Rust и тд. Т.е. связка интерпретируемого и компилируемого языка.

  • Прикладная разработка. Тут выбор меньше: C/C++, .Net, может, что-то еще. Хотя современные приложения могут быть написаны и на Питоне.

  • ERP-разработка: 1С, SAP, Axapta и тд. Обычно в такие сферы приходят случайно. Никто в здравом уме "после 30-ти" не сунется в ту же SAP или 1С.

  • Game Dev. Тут все понятно: берете навыки, полученные ранее, в C++, например, и изучаете какой-нибудь Unreal Engine 4/5. Сложно, долго, но можно приятно устроиться. К сожалению, в Game Dev не зайти просто на знании языка, ибо нужны специализированные знания.

  • Embeded-разработка. Тут выбор еще меньше: в основном, только C/C++. Очень узкая, но очень хорошо оплачиваемая сфера. Более не скажу ничего.

  • AI-системы. Тут просто. Есть Питон с Keras/PyTorch, построенные на TensorFlow, и есть всякие интерпретации в других языках для использования. Тут - кроме разработки нужна еще, как минимум, линейная алгебра. НО! Это очень перспективная сфера, куда можно и "после 40" зайти.

• SRE. Отдельная каста супер высокооплачиваемых инженеров. Попасть "после 30" и тд - невозможно, ибо нужен огромный опыт и знания во всех областях сразу.

Так вот, самое главное - нужно учить теорию. Параллельно ли, изначально ли - неважно. Без теории 3/4 перечисленного выше - просто закрыто будет. Остальная четверть ограничится уровнем стажера. Теория написания кода, теория данных, теория информации, теория сетей, комплияторов, тестирования, анализа данных, теория баз данных - огромная сфера знаний.

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

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

P.S. На моем личном опыте есть печальная статистика: чем страше человек есть, пытаясь "войти", тем хуже из него спец при прочих равных. К сожалению, это так.

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

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

Первое я уже успел попробовать (находил сам), прохожу в текущий момент.
Stepik - python для начинающих

Далее пойдут те, до которых я еще не дошел:
Лучшие бесплатные курсы по DevOps [2023]
Командная строка для разработчиков – cli-for-dev
Отдельно ютуб:
Python Kivy (разработка для мобильных устройств)
Python
Длинный нудный курс по Системному администрированию (азы)
Администрирование Windows Server
Ультра-позитивный Олег о python

Если что-то хотите предложить - пишите в комментарии.

UPD: даже в начале написал, что я не в курсе ни о какой рекламе на тех ресурсах. И первый же начал разводить вонь о том, что я продажный и сайт вообще мой. Ууух я конечно злой гений.

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

UPD2: я без понятия почему "это" вылетело в горячие. Не бейте блин тапком.

Всем привет.

Небольшое предисловие. Я осознаю, что этим постом я вступаю на охрененно тонкий лёд. Если уж к моему предыдущему посту были претензии за то, что я посмел использовать HTTP 404, то уже интересно, какие комментарии последуют после выхода этого поста, в любом случае - you are welcome!

Но тут стоит уточнить, что все те подходы (разные), по которым мы проектируем сервисы - они разные как раз потому, что нет единых mandatory правил к архитектуре приложений, которым если не следуешь - твоя система ломается и больше никогда в жизни не заработает, даже если ты исправишь ее. Есть лишь РЕКОМЕНДАЦИИ, а их многие интерпретируют по-разному и это тоже нормально. Для кого-то свойственно не использовать коды ошибок вообще и передавать их в теле ответа с HTTP 200, для кого-то нет. Ни один из этих подходов не является не правильным.

И нет никаких технических ограничений в принципе. Ты можешь спокойно использовать метод GET для удаления объекта, если ты его так напишешь (не делайте так) или использовать метод PUT, вместо POST, для создания объекта (так уже можно, если понимаешь почему). Главное, чтобы ты понимал как эти тонкости реализации правильно применять. Если сомневаешься - используй методы по классике, хуже от этого он работать не будет.

Да, можно уже прям сейчас кидать тапками.

Теперь уже к основному телу сабжа. Сейчас расскажу про ряд лучших практик, которые можно применять. @VRock, ты как раз спрашивал по поводу конвенции о наименовании ресурсов, тут про это тоже будет.

1. Имя endpoint'а - это существительное, а не глагол. Это одна из самых распространенных ошибок, которые я когда либо встречал (и сам совершал, естественно). Например, было в моей практике и такое - POST /generateMultipleDocument.

Тут важно понимать, что метод - это уже глагол и еще раз дублировать его в наименовании эндпоинта не нужно.

В идеале, в данном варианте будет POST /documents

Не везде от этого можно избавиться, но в большинстве случаев всё-таки можно, если потратить время на придумыванием вариантов (опять же - по факту нейминг ни на что, кроме красоты и структурированности вашего проекта не влияет. А на сколько это важно - решать вам или вашей команде).

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

Если же нужно указать, что из всего массива экземпляров ресурса вам нужно получить\обновить\удалить какой-то конкретный, то помещайте идентификатор этого ресурса в URL, передавая его в path.

Например, вот так:

/documents

/documents/

Вместо:

/document

/document/

1.2. Используйте "/" для обозначения иерархии и в принципе используйте вложенность ресурсов.

Например, если мы именуем наш ресурс, как users//playlists//songs - это значит у мы хотим работать со всеми песнями, конкретного плейлиста конкретного пользователя. И сразу понятна иерархичность этих ресурсов.

1.3. Не используйте "/" как закрывающий символ вашего URI.

Вариант users//playlists//songs сильно лучше, чем users//playlists//songs/

1.4. Используйте "-" для разделения составных слов.

Заглавные буквы использовать нельзя, поэтому привычный lowCamelCase нам не подойдет. Если писать всё слитно - очень не читабельно.

Поэтому вместо /applications//creditcardhistory, куда лучше использовать /applications//credit-card-history.

2. Не забывайте про версионирование микросервиса. Почти любой сервис с течением времени развивается и обрастает все большим количеством функций. Если сервис при создании получил версию 1.0.0, то при добавлении какой-нибудь логики в него, добавлении нового метода или полного рефакторинга - версия должна измениться.

Например:

host/v2/documents вместо host/v1/documents после внесения мажорной доработки.

Основные правила версионирования - в случае, если меняется логика незначительно, не добавляется/изменяется обязательность атрибутов, то инкрементируется минорная версия.

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

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

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

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

3. Используйте пагинацию.

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

Поэтому принято выполнять пагинацию таких данных (от слова page - страница), т.е. возвращать ему часть всей коллекции в каждом запросе. Например - 15, 30, 50 элементов + информацию о текущем положении полученной информации в общей выборке. Почитать про это можно более подробно где-нибудь тут (первая попавшаяся ссылка, я не вчитывался, не реклама).

4. Используйте коды ответов HTTP правильно и эффективно.
Их достаточно много (https://developer.mozilla.org/ru/docs/Web/HTTP/Status) и их можно использовать по назначению. Все знать и использовать не обязательно, но вот примеры их использования

Использовать 201 "Created", вместо 200 "OK", в случае если вы в POST действительно создаете какой-то ресурс. Используется только в POST (ну и в PUT, в ряде частных случаев).

Использовать 204 "No Content", вместо 200 "OK" для DELETE. Это ответ на успешный запрос и он не будет возвращать тело, что и не нужно для данного метода.

Не забывайте использовать 401 "Unauthorized", 403 "Forbidden" и 404 "Not found" вместо безликого 400 "Bad Request", когда это уместно. Как правило 400 кодом пользуются когда нужно ответить на какую-то ошибку валидации или в случае возникновения бизнесовой ошибки, которую вы заранее можете предсказать (очень настоятельно рекомендую хотя бы дополнять код ответа еще и кодом бизнесовой ошибки в этом случае и желательно ее текстом (error.code и error.message соответственно).

Для валидации желательно тоже).

А для всего остального можно и специальные коды использовать.

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.

Пришла пора поговорить за бекенд, а именно, за всеми старый "любимый" РНР и иже с ним (почему "иже с ним"?, потому что сейчас часто этот язык идет в паре с Golang).

Был недалече период необходимости прохождения собеседований. Были несколько интересных случаев, правда, конторы вряд ли известные широкой аудитории, поэтому называть не буду. Штатная разработка мне давно не интересна, поэтому я искал нечто выше, типа архитектора, techlead, либо, на край, teamlead. З/п разная, но я искал 400+ (да, "Знающие" скажут, что это мало для таких позиций - я в курсе).

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

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

Мне еще ниразу не попадались с их стороны серьезно подготовленные в техническом плане люди. Вас легко могут спросить, чем int8 от int32 отличается.

Средние конторы, до 1000 человек. Вот, тут бывают самые интересные собеседования. Тут и компетенция интервьювером бывает самой разной. Кто-то вас может гонять по типам данных и "что выведет скрипт?", а так же сдобрив это кодингом в стиле "отрефакторите код", кто-то может попросить вас проработать абстрактную архитектуру чего-то, поспрашивать про способы ускорения и оптимизации приложений (репликации, шардинг, балансинг, кеширование и тд). Не редко просят оптимизировать таблицу и запросы к ней.

Один раз я наткнулся на очень сильного интервьювера. Мы обсуждали не просто тонкости интепретатора, но и различные возмжные последствия от его нюансов, а так же способы диагностики и устранения неполадок сервисов и приложений в "боевом режиме". Различные другие аспекты языка, типа "настоящей" параллелизации выполнения приложения.

Большие конторы. Тут основная, имхо, проблема в том, что они четко знают (действительно знают), как собеседоваать junior-разрабов, но часто совершенно не понимают, как это делать с более серьезными позициями. Я считаю, что это выходит из-за сильной корреляции ответственности между сотрудниками: в таких конторах крайне редко бывают сотрудники с экспертизой, а чаще те, кто пришел и сидит на одном месте в одной области.

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

Я считаю это проблемой потому, что на практике не бывает ничего "бесконечного", особенно на позиции артихектора или techlead: у любой задачи есть в 100% случаем граничные условия, от которых зависит решение (в любой, даже np-полной задаче, решение меняется в зависимости от количества элементов). Года 3 назад я еще пытался доносить это до интервьюверов, но теперь просто кидаю ссылку на профиль leetcode, если начинается "алгоритмистика" - сильно время экономит.

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

Еще почему-то меня часто спрашивали под "подкапотное" устройство http/http2 протоколов, модель OSI (sic!) и чем UPD лучше/хуже TCP. Пару раз были вопросы про OLTP/OLAP механизмы, и чем одно лучше/хуже другого.

Честно говоря, я ниразу не проходил первый этап из-за своей неприязни к подобному (что человек может нагуглить за 1 минуту), поэтому что там дальше, я не знаю :) Может, что-то действительно стоящее и интересное.

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

И чутка про забугорные конторы. В них часто потенциально невысокий уровень экспертизы интервьювера усугубляется наличием потенциальных индусов и всяких AWS/Azure сервисов, которые сильно разгружают (не в финансовом плане, конечно же) конторы. Так что знание этих сервисов даже, если вы идете на простую разработку, обязательны. Каждая вторая контора обязательно даст вам тестовое задание, и не потому, что "вас таких за забором дофига", а просто так.

Английский - естественно. Часто говорят про минимум В2, но на практике нужен С1, не меньше: если вам говорят, что собеседование будет на аглицком, это значит, что там будет либо native, либо fluent speaker.

Будет огромным плюсом, если вы познакомитесь с компанией заранее и проработаете свою мотивацию не в стиле "свалить из РФ".

Вообще, при собеседовании в забугорные конторы крайне важны soft skills. На столько важны, что вы обязаны научиться улыбаться, если еще не умеете. Я сейчас говорю про конторы, где HR сидит в каком-нибудь Кипре или Испании, а не те, что нанимают аутсорс рекрутеров в РФ.

Почему-то до сих пор часто конторы из заграницы уверены, что даже на лидирующие позиции достаточно 4000-4500$/мес gross, если вы из РФ. С учетом того, сколько придется на налоги и комиссии отдать, это очень мало.

Всем привет.

UPD. Опять получился длиннопост с большим количеством текста в формате моих пояснений - простите, но не представляю как по-другому можно что-то объяснить, вроде стараюсь не графоманить.

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

Шаблонов, на самом деле много и от команды к команде отличаются. Где-то СА просто пишут, что "метод должен получать объект User из базы Users и дальше отдавать его вызывающей стороне" - и это вся постановка. В каких-то командах упарываются и пишут ТЗ на микросервис целиком, в связке статьи в git в формате asciidoc + swagger (yes, I like it и отдельно про это тоже расскажу).

Но в большинстве случаев принято что-то среднее между этими крайностями - системному аналитику важно описать следующее:

1. То, какие данные метод получит на вход и правила валидации для них;

2. То, что метод должен сделать с этими данными, т.е. какую бизнес-логику выполнить;

3. То, что метод должен вернуть в ответ вызывающей стороне.

Допустим, нам нужно описать какой-нибудь метод, который получает любую бизнес-сущность по ее идентификатору.

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

Если кто хочет посмотреть "вживую" или попользовать шаблон - вот ссылка на страницу моего конфлю (вроде должна работать).

Теперь по шагам:

1. Описание метода. Что он делает, для чего предназначен. Можно описать что-то конкретное, если сервис работает как-то специфично, такую краткую выжимку, что сторонним людям не приходилось анализировать его целиком;

2. URI или URL метода. Состоит из одного из типовых глаголов плюс сам путь, по которому данный метод будет доступен. Про всякие best practices нейминга расскажу отдельно, в комментариях под предыдущим постом спрашивали;

3. Разрешения или Permissions. Если у вас есть ролевая модель и вам нужно разграничить доступ к каким-либо ресурсам среди пользователей с разными ролями - то вступает в дело данная строка таблицы. В ней нужно перечислить те роли, у которых есть доступ до данного метода;

4. Параметры запроса, который должны (или могут) быть переданы на вход данного метода. Т.к. у нас очень простой метод, то у нас их нет. Единственный атрибут в виде идентификатора пользователя ( ) передается напрямую в ссылке. Т.е. пример запроса будет просто выглядеть вот так: GET /users/22 - дай мне пользователя с идентификатором 22.

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

6. Параметры ответа. Все варианты того, что ваш метод вернет вызывающей стороне после выполнения своей внутренней логики. Перечисляем как успешные коды ответа и всё их содержимое, так и ошибочные.

7. Непосредственно описание бизнес-логики метода. Т.е. что метод должен сделать с атрибутами, переданными на вход, и что должен вернуть.

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

На этом примере - у вас стоит бизнесовая задача (например): есть админка со списком пользователей, администратор нажимает на какую-то конкретную карточку пользователя, с целью просмотреть всю информацию по нему - в этот момент, как раз фронт откроет отдельную экранную форму и вызывает наш метод, передавая туда идентификатор искомого пользователя (который он ранее получил из другого метода, который получает массив пользователей, что-то вроде GET /users), чтобы получить всю нужную информацию для отображения.

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

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

Ну и всегда (по моему мнению), во всех методах нам нужно валидировать входящий запрос до того, как начать основную бизнес логику. Потому что зачем нам это делать и тратить драгоценное время и ресурсы, если мы заранее знаем, что запрос не валиден? Т.е. как минимум нам нужно проверить rq на соответствие контракту, что все обязательные атрибуты пришли и пришли в корректном формате. Как максимум выполнить еще всякие кастомные валидации, по типу тех же проверок на роли.

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

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

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.

Что сподвигло меня сделать это курс по Ворду? Ведь я вместо этого мог бы сыграть в 3-4 шахматных турнирах с тщательной предварительной подготовкой. Или, вообще, плюнуть на все и уехать на дачу, копать червей для рыбалки... Дело не в том, какие дороги мы выбираем. Дело в том, что такое в нас самих заставляет нас выбрать ту или иную дорогу... Когда-то давным-давно, лет 5 тому назад, один наш программист сделал для бухгалтерии функционал, который периодически рассылал сотрудникам предупреждения о разных событиях, типа неожиданных премий и т.п. Функционал основан на шаблонах Ворда и по неизвестной причине перестал работать. Надо ремонтировать! А это оказалось не так просто, как показалось сначала.

Вызывает меня как-то зам главного бухгалтера (милая приятная женщина) и говорит трагическим голосом.

- Все пропало!

- Клиент уезжает, гипс снимают? - уточнил я.

Выяснилось следующее.

Когда-то давным-давно, лет 5 тому назад, один наш программист сделал для бухгалтерии функционал, который периодически рассылал сотрудникам предупреждения о разных событиях, типа неожиданных премий и т.п.

Примерно вот такого содержания.

"Сообщение о премии".

...

Уважаемый Иванов Иван Иванович! По итогам работы за квартал вам будет выплачена дополнительная премия в размере 30 тысяч рублей. Спасибо за отличную работу.

...

Программист, сделавший этот функционал, давно уволился, никто эту программу не поддерживал, да и потребности в этом вроде как не было. Бухгалтера нажимали нужные кнопки и все работало.

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

Один раз бухгалтера это сделали, но это им сильно не понравилось. Они хорошо помнили те славные времена, когда процесс проходил за несколько минут без всяких ошибок. Теперь они ковырялись с этими файлами больше недели, да еще сделали одну нелепую ошибку. Одному сотруднику приписали лишний ноль, т.е. 400 тысяч вместо 40. Сотрудник сначала сильно обрадовался, заранее потратил кучу денег, залез в кредит. А потом еще более сильно огорчился, когда получил реальные деньги, а не просто сообщение.

Бухгалтера поняли, что программу надо чинить и обратились к нам.

Зачем вообще нужны эти извещения? Ведь все равно получатель премии узнает о ней по факту прихода денег на карту.

Ответ простой. Это старая добрая корпоративная традиция, и не нам, разработчикам и бухгалтерам, ее ломать. Народу нравится! И этим все сказано.

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

Позвал на помощь товарищей по работе, устроили мозговой штурм. Залезли в жуткие вордовские дебри и с огромным трудом поймали за хвост истину.

Выяснилось следующие.

В Ворде есть переменные "старого" типа, а есть "нового" типа. Программист широко использовал и те и другие. Но они совсем разные, эти переменные. И косяки у них тоже разные. У "новых" переменных есть такая жесткая особенность, нельзя их исправлять прямо в тексте. Визуально такие исправления вроде как срабатывают, но по факту это не так. Внутри все стало работать неправильно. А чтобы увидеть дефект и исправить, надо разархивировать файл docx (а это обычный zip архив, в котором несколько файлов xml) и там уже править дефектный xml. Это уже задача не для новичков!

Или, что проще, просто с нуля аккуратно переделать файл docx непосредственно в Ворде.

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

После того как я убедился, что этот функционал успешно работает, (я сам получил сообщение о премии), я решил сделать небольшой курс по Ворду.

Хотелось, чтобы если кто-то еще столкнется с подобными проблемами, то смог бы быстро их решить.

У меня уже был успешный опыт создания подобных курсов, например: курс по Экселю.

Почему бы не сделать еще один?

Тут я уже двигался по проторенной дорожке: текстовый курс с картинками, тщательное тестирование, путем многократного выполнения нужных действий курсанта по заданному плану, видео материалы.

Я решил подробно расписать все эти особенности, "ловушки" Ворда, чтобы сделать работу с этой программой максимально комфортной.

В итоге получилось: один длинный текст с картинками, а к нему еще примыкают 3 видео.

Идея такая. Кто-то больше любит читать тексты (как я, например), кто-то больше любит, чтобы ему показывали в видео формате.

Вот в таком виде, во всех форматах курс подойдет всем, никто не останется без нужных знаний.

Вот краткие описания основных составных частей курса.

Часть 1 - Подготовка. Запуск.

Что такое Word и кому он нужен. Запуск. Наш первый файл "Hello, Word" или "Привет, Ворд". Разметка страницы. Шрифты, настройка. Вставка картинки. Гиперссылка.

Часть 2 - Переменные "старые" и "новые". Макрос VBA.

Переменные "старого типа" и переменные "нового типа". Наш первый макрос в Ворде. Ключевые моменты макроса. Устанавливаем значения переменных.

Часть 3 - Автоматизация.

Как создать 99999 однотипных документов Ворда для приглашений на праздник клиентов и/или сотрудников, расписок работников о согласии на что-то, резюме искателя работы с указанием разных работодателей и т.п. Заключение. Лайфхаки. Ссылки. Пожелания. Развлечения.

Если есть у вас интерес быстро усвоить Word (или альтернативный редактор текстов), то добро пожаловать сюда:

Microsoft Word. Майкрософт Ворд. Курс для новичков.

https://wpvi.ru/pages/soft/word/

Там все материалы в интуитивно понятной форме. Не требуется никакой регистрации и прочего. Просто сразу получаете нужную информацию и выполняете на практике нужные действия. Информация представлена как в виде текстов с картинками, так и в формате видео с озвучкой голосом на русском языке.

Успехов!

Полная авторская версия истории "Как я сделал курс по Ворду для новичков" здесь:

https://wpvi.ru/pages/story/00009/

#############

### Конец ###

#############

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

И вот, за три года до финала головокружительной карьеры дизайнера, к нам в отдел заглянул местный директор со словами: "В Московской головной конторе доели очередного дизайнера сейчас дизайнера нет, просят из наших кого-нибудь. Матёрого и с опытом отсюда и до горизонта." Дизайнеров в Москве изводили со страшной скоростью и в промышленных масштабах. Эдакий расходный материал, за круговоротом которого мы из нашего Новосибирска наблюдали со спортивным интересом.

Начальник дизайнерского отдела задумчиво смотрел на меня, остальные дизайнеры пригнулись за мониторы. Попытка прикинуться уборщицей провалилась с треском, и со словами "это на месяц, пока нового не найдут" меня назначили дистанционно любимой женой в Москву. Выдыхаться как дизайнер я уже начинала, но отказываться от приятной зарплаты ещё была не готова. Головной офис сразу приступил к воспитанию, объяснив кто тут главный, а у кого ручки из жопки и вместо головы глиняный горшок.

Месяц превратился в два и плавно растянулся на три года. Одной рукой верстая полиграфию, второй отдизайнивая соцсети, третьей разрабатывая интерфейсы и немного залезая в 3D моделирование, я радовалась что дистанционно откусывать голову дизайнеру получается не очень эффективно. Москва кипела трудовым энтузиазмом как после окончания нашего рабочего дня, так и по выходным. Появляться на работе в чётко установленное время было не обязательно, но иное не одобрялось, отбой мог наступить уже вместе с головной конторой, разница во времени составляла четыре часа. Постепенно поверх уже накопившегося выгорания накрывало глобальным отвращением к IT в целом. Тошнило от мониторов, векторов и прочих фотошопов в сумме, но два уже не мелких, но ещё слегка несовершеннолетних дитятки дома хотели кушать и учиться.

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

"Хорошие аналитики на дороге не валяются, мы готовы вложиться в обучение." - с этими словами меня ждали на собеседовании. Времени на подумать давалось неделя, осознавая размеры зарплаты в Сбере, одновременно я понимала, что в офисе за монитором повешусь за любую зарплату и очень быстро. Логически взвешивать "за" и "против" не имело смысла - такие предложения с неба пачками не падают и на дороге не валяются. Отловив бывшего мужа, работающего в Сбере начальником одного из IT-отделов, я крепко взяла его за пуговицу пиджака и изложила факты. Он не удивился, времени привыкнуть к неожиданным манёврам в моей жизни у него было предостаточно.

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

Только идиоты отказываются от таких предложений, я была идиотом и сделала шаг от тёплого и очень сытного офиса в никуда. Понимала ли я от чего отказываюсь? Однозначно да. Знала ли, что ждёт впереди? Нет. Там ждали пара-тройка лет с местами полуголодным существованием, дети выросли окончательно и отправились искать своё пастбище, а я пыталась найти своё место вне IT, абсолютно не представляя где оно. Пожалела ли о принятом тогда решении? Ни разу. Я фрилансила, варила пиво, сыр, делала конфеты, и даже работала продавцом в разливайке, пока не наткнулась на кратко промелькнувшее "требуются продавцы-консультанты в секс-шоп".

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

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

С момента запуска проекта FreeBSD прошло 30 лет. Официальный портал данной инициативы напомнил, что 19 июня 1993 года в Калифорнийском университете в Беркли представили операционную систему с открытым кодом, которая стала основой для многих некоммерческих и бизнес-решений.

Отсчёт идёт с момента создания форка 4.3BSD на основе неофициального набора исправлений к 386BSD, который был предназначен для разработки быстрой и устойчивой к безопасности операционной системы для машин с процессорами i386.

В своих прошлых и нынешних итерациях FreeBSD может похвастаться множеством дополнительных библиотек и инструментов, которые постоянно улучшаются на протяжении долгих лет. Специалисты уверены, что долговечность FreeBSD обеспечивается благодаря BSD license (Berkeley Software Distribution license) — лицензией с открытым кодом, которая позволяет свободно распространять программное обеспечение.

via

Всем привет.

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

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

REST

Representational State Transfer (REST) в переводе — это передача состояния представления.

Сам по себе REST – это архитектурный стиль взаимодействия компонентов распределённого приложения в сети. Архитектурный стиль – это набор согласованных ограничений и принципов проектирования, позволяющий добиться определённых свойств системы.

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

1. Client-Server (клиент-серверная архитектура)

В рамках данного принципа самое важное - это отделение клиента и сервера. Клиент - это интерфейсная часть (уровень представления), сервер - это центральное звено системы, на котором реализованы все основные функции системы (наш backend). Более подробно рассмотрено в части 6 этой серии.

2. Stateless. Без состояния

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

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

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

3. Единообразие интерфейса

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

Это достигается через несколько субограничений:

1. Идентификация ресурсов

В терминологии REST что угодно может быть ресурсом — HTML-документ, изображение, информация о конкретном пользователе - то, чему можно дать имя. Каждый ресурс должен быть уникально обозначен постоянным идентификатором. «Постоянный» означает, что идентификатор не изменится за время обмена данными, и даже когда изменится состояние ресурса. Если ресурсу присваивается другой идентификатор, сервер должен сообщить клиенту, что запрос был неудачным и дать ссылку на новый адрес.

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

2. Управление ресурсами через представления

Второе субограничение «унифицированного интерфейса» говорит, что клиент управляет ресурсами, направляя серверу представления, обычно в виде JSON-объекта, содержащего контент, который он хотел бы добавить, удалить или изменить. В REST у сервера полный контроль над ресурсами, и он отвечает за любые изменения.

Когда клиент хочет внести изменения в ресурсы, он посылает серверу представление того, каким он видит итоговый ресурс (а для этого, сервер сначала должен предоставить эту информацию клиенту). Сервер принимает запрос как предложение, но за ним всё так же остаётся полный контроль.

3. Самодостаточные сообщения

Самодостаточные сообщения — это ещё одно ограничение, которое гарантирует унифицированность интерфейса у клиентов и серверов. Только самодостаточное сообщение содержит всю информацию, которая необходима для понимания его получателем. В отдельной документации или другом сообщении не должно быть дополнительной информации.

4. Кэширование

В данных запроса должно быть указано, нужно ли кэшировать данные (сохранять в специальном буфере для частых запросов). Если такое указание есть, клиент получит право обращаться к этому буферу при необходимости.

Это нужно для того, что максимально ускорить обработку запроса от клиента. Для примера, если нам нужно часто получать информацию о пользователе (а сама информация о пользователе меняется достаточно редко, что важно), то мы можем закэшировать эту информацию.

Т.е. стандартный запрос выглядит условно так: Фронт -> микросервис адаптер к фронту -> какой-нибудь микросервис MDM системы пользователей -> база где лежат пользователи и потом обратный путь. Это не прям мгновенно всё происходит. Что мы делаем - например, наш фронт прислал запрос GET /user/121, мы проделали этот путь, описанный выше, но еще и сохранили эти данные в кэше на уровне микросервиса-адаптера. В следующий раз, когда фронт вызовет метод GET /user/121, наш путь будет намного короче и быстрее - всего лишь от фронта к нашему же микросервису в кэш и сразу обратно.

Тут есть множество нюансов, которые нужно учесть - но в целом полезный инструмент.

5. Система слоев

Система слоев предполагает наличие большего количества компонентов, чем клиент и сервер. В системе может быть больше одного слоя. Тем не менее, каждый компонент ограничен способностью видеть только соседний слой и взаимодействовать только с ним.

Но что самое замечательное, при добавлении новых слоев между клиентом и сервером - их не нужно дорабатывать. Т.е. не важно, если у нас архитектура выглядит как просто "Клиент" -> "Сервер", или "Клиент" -> "Прокси" -> "Балансировщик" -> "Несколько серверов" - их логика не меняется (тут разработчики могут меня поправить или дополнить, буду благодарен).

Что-то вроде того:

Еще есть отдельный принцип "Код по требованию", который подразумевает то, что клиент может получить с сервера прям "кусок кода" (условно), который ему необходимо выполнить у себя.

Звучит интересно, но честно, ни разу не сталкивался, поэтому не могу что-то детальное рассказать.

P.S.: В следующих постах расскажу про best practices, связанных с именованием эндпоинтов и прочими полезными штуками для проектирования своих апишек.

По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.

Всем привет.

В прошлом посте рассказал про HTTP в целом и много раз упоминал различные методы, но еще не рассказал что это такое - разбираемся.

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

Их всего 6 основных:

GET

Метод GET предназначен для получения информации о каком-то конкретном ресурсе или массиве ресурсов. Он никак не изменяет эту информацию.

HEAD

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

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

Условно, можно вызвать HEAD /users/127 - мы получим в ответе HTTP 200, в том случае, если этот пользователь с идентификатором = 127 существует. И 404 - если нет.

Если же вызвать GET /users/127 - то мы получим HTTP 200 + тело ответа, в котором будет содержаться вся информации о пользователе с идентификатором 127 (ну тут смотря как реализовать, но по дефолту будет так).

POST

Создает новый ресурс из переданных данных в запросе. Но это лишь по дефолту.

На самом деле POST самый универсальный метод и им возможно делать всё - и получать информацию, и создавать, и редактировать, и удалять, и запускать какие-то процессы. Тут важно понимать - почему именно так.

Например, мы можем использовать POST для поиска в том случае, если нам нужно зашифровать поисковые параметры в теле запроса, а не оставлять их в открытом виде в query-параметрах (прям в строке запроса). Либо использовать для поиска в том случае, если поисковых параметров слишком много и строка запроса получается слишком огромной - а у нее есть определенное ограничение по длине (очень больше, но всё-таки есть).

Можно использовать для запуска различных команд в оркеструющих микросервисах или коммандерах. Т.е. напрямую у нас никакой объект не создается, физических и лежащий в БД - но у нас создается (запускается) какой-нибудь бизнес-процесс.

Применений у этого метода очень много.

PUT

Изменяет содержимое ресурса по-указанному URI. PUT полностью заменяет существующую сущность.

PATCH

Похож на PUT, но применяется только к фрагменту ресурса (заменяет точечно только часть ресурса)

Для понимания: Например, у вас есть объект user, у которого 5 атрибутов - Ф, И, О, дата рождения и пол. Если у вас поменялась информация о пользователе №5, например изменилась фамилия - и вы вызовете метод PUT /users/5, и передадите в теле запроса только фамилию, то на выходе у вас останется объект user с id = 5, и фамилией = тому, что вы передали в запросе. Все остальные атрибуты затрутся. Поэтому для обновления необходимо передавать все объект целиком, включая те атрибуты, которые не менялись.

Если же вы вызовете метод PATCH /users/5 с таким же запросом, то у вас обновится только фамилия, остальной объект останется не тронутым.

Логичный вопрос - а зачем тогда вообще использовать PUT? Ответ достаточно простой - он намного проще в реализации. Куда проще передать объект целиком ценой нескольких байт трафика и подменить его, чем обновлять каждый атрибут по отдельности, маппить их и т.д. Особенно если у вас какой-нибудь огромный объект, типа "Заявка на кредит", у которой под тысячу атрибутов, а вам нужно обновить 200 из них.

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

DELETE

Удаляет конкретный ресурс по-указанному URI.

Интересное: на самом деле нет никаких проблем с тем, чтобы заставить метод GET создавать какой-нибудь ресурс или заставить метод DELETE обновлять. Т.е. это не технические ограничение, это "лишь" концептуальная идеология того, как правильно (и для чего) использовать различные методы.

Чтобы на всех проектах, все участники разработки были в едином контексте. И когда вы будете видеть какой-нибудь метод, типа POST /loanApplication//offers - вы явно поймете, что это метод предназначенный для добавления новых офферов конкретной заявке на кредит.

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.

Всем привет.

Сегодня рассмотрим такой важный протокол, как HTTP. Важный потому, что именно его используют в качестве протокола передачи данных современные технологии интеграции (REST, gRPC).

HTTP

HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». Изначально этот протокол использовался для передачи гипертекстовых документов в формате HTML. Сегодня он используется для передачи произвольных данных - c помощью него можно передавать хоть JSON, хоть XML.

В основе HTTP - клиент-серверная структура передачи данных․ Клиент формирует запрос (request) и отправляет на сервер; на сервере запрос обрабатывается, формируется ответ (response) и передается клиенту.

HTTP не шифрует передаваемую информацию. Для защиты передаваемых данных используется расширение HTTPS (Hyper Text Transfer Protocol Secure), которое “упаковывает” передаваемые данные в криптографический протокол SSL или TLS. Но это совсем другая история)

Структура HTTP запроса

HTTP запрос состоит из трех основных частей: строка запроса (request line), заголовок (message header) и тело сообщения (entity body). Тело сообщения не является обязательным параметром. Между заголовком и телом есть пустая разделительная строка.

Строка запроса

В строке запроса указывается:

• Метод – название запроса (определяет действие), одно слово из стандартного списка, заглавными буквами;

• URI определяет путь к запрашиваемому ресурсу;

• Версия – пара разделённых точкой цифр. Например: 1.0.

Пример HTTP запроса:

Заголовок запроса

Заголовок запроса добавляет некоторую дополнительную информацию к сообщению запроса, которое состоит из пар «имя / значение», по одной паре на строку, а имя и значение разделяются двоеточием.

Обычно в заголовках передается какая-либо мета информация. Например, токен.

Тело запроса

Последней частью запроса является его тело. Оно бывает не у всех запросов: запросы, собирающие (fetching) ресурсы, такие как GET, HEAD, DELETE, или OPTIONS, в нем обычно не нуждаются и тела запроса у них быть не должно (так реализовать метод можно, но это не правильно).

В то же время для методов POST, PUT, PATCH - тело использовать можно и нужно.

Структура ответа HTTP

Структура ответа, в целом, идентична структуре запроса. Также есть строка статуса, заголовок и тело.

Строка статуса (Status line)

Стартовая строка ответа HTTP, называемая строкой статуса, содержит следующую информацию:

1. Версию протокола, обычно HTTP/1.1.

2. Код состояния (status code), показывающая, был ли запрос успешным. Примеры: 200, 404 или 302

3. Пояснение (status text). Краткое текстовое описание кода состояния, помогающее пользователю понять сообщение HTTP..

Пример строки статуса: HTTP/1.1 404 Not Found.

Более подробно про коды состояния и как их использовать расскажу как-нибудь в другой раз.

Пример ответа:

Заголовок

Заголовки ответов HTTP имеют ту же структуру, что и все остальные заголовки: не зависящая от регистра строка, завершаемая двоеточием (':') и значение, структура которого определяется типом заголовка. Весь заголовок, включая значение, представляет собой одну строку.

Тело

Тело присутствует не у всех ответов. Например, если мы вызываем метод DELETE, чтобы удалить какую-либо сущность, то в ответ нам вернется лишь строка статуса с HTTP-кодом 204.

Как правило тело ответа используется в том случае, когда нам нужно вернуть вызывающей стороне информацию о ресурсе. Например, если мы вызываем метод GET /users/25, то в ответе вернется полная информация о пользователе с идентификатором = 25.

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.

Всем привет.

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

Перед тем как начать изучать REST, API и все что с этим связано - нужно изучить, хотя бы верхнеуровнево, архитектуру, на базе которой строятся все современные приложения. Для этого рассмотрим клиент-серверную архитектуру.

Архитектура «клиент-сервер» определяет общие принципы организации взаимодействия в сети, где имеются серверы, узлы-поставщики некоторых специфичных функций (сервисов) и клиенты, потребители этих функций.

В клиент-серверной архитектуре одним из основных вопросов является вопрос о том, как разделить клиентов и серверы. Так, приложения типа клиент-сервер разделяют на три уровня:

• уровень представления - на уровне представления обеспечивается взаимодействие с пользователем приложения с помощью пользовательского интерфейса. Его основное предназначение состоит в отображении информации (все формочки, кнопочки и т.д.) и получении информации от пользователя. Этот уровень может работать в веб-браузере или как графический пользовательский интерфейс компьютерного или мобильного приложения.

• уровень бизнес-логики - центральное звено приложения, на котором реализованы все основные функции системы. Обрабатывается вся информация, собранная на уровне представления согласно бизнес-правилам для выполнения конкретных бизнес-целей системы. Кроме того, уровень приложения может добавлять, изменять и удалять данные, расположенные на уровне данных;

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

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

Клиент-серверная архитектура делится на двухзвенную и трехзвенную.

Двухзвенная архитектура

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

В двухзвенной клиент-серверной архитектуре используется так называемый «толстый» клиент, который выполняет отображение информации и обработку всех данных (порядка 80 % всех работ). Сервер осуществляет только хранение и предоставление данных (порядка 20 % работ).

Толстый клиент - это когда приложение напрямую запущено через условный .exe файл на вашем компьютере и работает в отдельном окне (всякие ERP\WMS системы, те же клиенты 1С и пр. не облачные штуки). Собственно их основной минус в том, что т.к. нет выделенного сервера - все функции реализуются на уровне клиента, который потребляет только те ресурсы, которые доступны компьютеру, на котором это приложение установлено.

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

Трехзвенная архитектура

Собственно именно эти недостатки в большей степени послужили толчком к появлению трёхзвенной клиент-серверной архитектуры с отдельно выделенным сервером приложений.

Выглядит это всё схематично следующим образом:

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

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

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

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.S. Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.

Всем привет.

Сегодня вернемся немного назад. Если про сами требования мы уже поговорили, про то, что это вообще такое, какими они бывают и какими качествами обладают, то вот про то, а как вообще их собирать - еще не проговорили.

Для этого придумали и сформулировали не мало методологий - давайте в них разберемся.

Интервьюирование

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

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

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

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

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

Другой подход может быть, если вы внедряете какую-нибудь ERP\WMS систему на какое-нибудь предприятие, в этом случае я готов поверить, что та самая базовая теория будет актуальна для такого случая.

Пара важных моментов:

1. Всегда готовьтесь к интервью. Я не знаю почему, но даже опытные аналитики это не всегда делают, к моему сожалению. Не должно быть такого, что вы приходите на встречу, вам предлагают начать диалог и задавать вопросы, а вы такой: "Ой, да я даже не знаю, давайте вы расскажете просто что вам нужно". Очень желательно, заранее подготовить список вопросов или просто понять концепцию разговора, т.к. именно вы должны быть его драйвером.

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

Прототипирование

Еще один распространенный и интересный подход - это первичное создание прототипов системы. Прототип - это модель, позволяющая продемонстрировать интерфейс или поведение проектируемой системы. Сбор и уточнение требований прототипированием гораздо эффективнее проводить после выявления первичных требований любым другим способом, как минимум потому, что люди в большинстве своём визуалы и не особо готовы воспринимать большие полотна текста (как этот пост), но достаточно легко готовы идти на контакт и общаться, если вы показываете им картинки.

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

Прототип может быть:

• Статическим, показывающим положение элементов в интерфейсе или структуры данных;

• Динамическим - с возможностью демонстрации поведения системы по наступлению определенных событий;

• Интерактивным - позволяющим пользователям и участникам заинтересованных сторон выполнять реальные действия так, как это будет работать в разрабатываемой системе.

Но у такого подхода есть и ряд минусов:

• Сильно увеличивает трудозатраты, особенно если не удастся переиспользовать интерфейс для экономии времени разработки, т.к. стоит понимать, что сам процесс прототипирования отнимает достаточно большое количество времени, если это не на салфетке на встрече нарисованный макет интерфейса;

• Заказчики могут акцентировать фокус своего внимания на красоту и дизайн прототипа их системы вместо обсуждения действительно важных вопросов реализации. Поэтому важно постоянно уводить нить их рассуждения от "Блин, тут кнопка не в наших корпоративных цветах, надо это поправить", к обсуждению того, как эта кнопка должна работать и что должно происходить по ее нажатию.

Анализ документации

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

Данный подход выполняет сразу несколько целей:

• Сократит время последующего анализа потребностей и проблем заказчика. Кроме этого облегчит взаимодействие с заказчиком и другими членами команды разработки, т.к. вы больше вникните в процесс и будете разговаривать на одном языке;

• Возможно вы сможете получить ту информацию, которой уже (или еще) из представителей заказчика не обладает.

Для начала требуется определить с какой документацией необходимо и желательно работать. Это можно сделать у представителя заказчика, который может предоставить нам список необходимой “литературы”, релевантной относительно текущих процессов. Либо, если вам предоставили доступ к каким-либо информационным ресурсам заказчика - поискать такие документы самостоятельно.

Мозговой штурм

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

Такой формат не позволит вам выбрать что-то наилучшее или оптимальное, однако позволит по накопившимся идеям получить быструю обратную связь, отследить реакцию заказчика на них, выбрать несколько наиболее подходящих и далее “копать” в том направлении, развивая эти идеи.

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

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

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

Анализ конкурентных продуктов

Кроме всех вышеперечисленных способов - можно применить еще один, достаточно интересный. Если вы не разрабатываете что-то совсем новое и уникальное, не делаете “rocket science”, то скорее всего у вашего продукта или системы уже есть аналоги. И очень не глупой идеей будет проанализировать их, посмотреть на отзывы пользователей, самому попользоваться данной системой (если это возможно) и сделать на основании этого выводы о преимуществах и недостатках данного продукта.

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

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.S. Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.

Всем привет.

Сегодня продолжим наш экскурс в глубины системного анализа. Перед тем, как мы перейдем к интеграциям - логично было бы поговорить об XML\JSON.

XML

XML, в переводе с англ eXtensible Markup Language — расширяемый язык разметки. Используется для хранения и передачи данных. Отличается простотой синтаксиса и универсальностью. XML позволяет описывать документы с помощью тегов, которые можно задавать самостоятельно. Так что увидеть его использование можно и в API в том числе (хотя и намного реже, чем JSON).

XML позволяет:

• записывать иерархию — «один подчиняется другому»;

• размечать текст по смыслу от важного к второстепенному;

• хранить типовые данные — скрипты, настройки программ, названия чего-либо;

• размечать текст для машинного обучения;

• хранить результаты работы текстовых редакторов.

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

Теги

В XML каждый элемент должен быть заключен в теги. Тег — это некий текст, обернутый в угловые скобки:

<tag>

Текст внутри угловых скобок — название тега.

Тега всегда два:

• Открывающий — текст внутри угловых скобок

• <tag>

• Закрывающий — тот же текст (это важно!), но добавляется символ «/»

• </tag>

С помощью тегов мы показываем системе «вот тут начинается элемент, а вот тут заканчивается».

В любом XML-документе есть корневой элемент. Это тег, с которого документ начинается, и которым заканчивается. Он показывает начало и конец нашего запроса, не более того. А вот внутри уже идет тело документа.

Для примера давайте опишем объект Task нашей системы (см. первую практику) в формате XML.

<task type="issue"> (открывающий тег и корневой элемент заодно)

<topic> Не работает принтер</topic>

<priority> high</priority>

<isMass> false </isMass>

<description> Сломался принятер. Выключился ибольше не включается. Нужно срочно распечатать много документов, а не получается. Что делать? Просьба помочь</description>

</task> (закрывающая тег)

Пара особенностей, помимо перечисленных:

• Все теги являются регистро-чувствительными. Это значит, что если, например, тег <user> закрыт </User>, документ будет оформлен некорректно;

• Значения атрибутов должны быть заключены в кавычки. Атрибут — характеристика тега. Любые теги могут иметь атрибуты;

• Вложенность тегов контролируется, поэтому важно следить за порядком открывающих и закрывающих тегов.

JSON

JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript. Но при этом формат независим от JS и может использоваться в любом языке программирования.

JSON обладает рядом преимуществ. К ним относят:

• компактность;

• простое чтение предложений, написанных подобным образом – актуально и для машины, и для человека;

• легкость преобразования в структуры данных для разнообразных языков программирования;

• наличие у большинства языков программирования функций и библиотек, которые помогут создавать и читать структуры JSON.

JSON-объект — это неупорядоченное множество пар «ключ:значение», которые разделены ",".

Давайте теперь тот же объект Task опишем в формате JSON и я думаю, что на этом примере сразу станет понятна структура, потому что она намного более простая и наглядная, чем XML

{ (открывающая скобка - начало объекта, закрывающая скобка - конец объекта)

"type" : "issue", (Слева - ключ, справа - значение)

"topic" : "Не работает принтер",

"priority" : "high",

"isMass" : "false",

"description" : "Сломался принятер. Выключился ибольше не включается. Нужно срочно распечатать много документов, а не получается. Что делать? Просьба помочь"

}

JSON на данный момент наиболее распространен и повсеместно используется в REST, например.

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

В следующей части расскажу базовую теорию про интеграцию и начнем плавно переходить к REST'у.

Мужчина 33 года

— Я хочу, чтобы вы подобрали мне возлюбленную!

— Что сделала, простите?

— Я читал что психологи могут провести ряд тестов, выявить мои когнитивные и умственные флаги и исходя из них, а также моих особых пожеланий, создать портрет идеальной пары. А то я уже устал от бесконечных проб и ошибок - хочется так: чтобы раз и навсегда. Но мне нужно идеальное совпадение по всем пунктам, я правда не знаю по каким - но с этим вы мне как раз и поможете.

— Извините, но я не оказываю услуги подобного ро…

— Как это — не оказываете?! Я же видел, у вас написано — семейный психолог, а мне как раз семью и нужно создать!

Женщина 56 лет

— Я пристрастилась к компьютерным играм, просто невозможно оторваться, - призналась клиентка. - При этом скрываюсь, боюсь кому-то сказать, чтобы помощи попросить.

— Боитесь осуждения?

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

— Не волнуйтесь, я никому не расскажу.

— Хорошо, - выдохнула женщина, а потом подозрительно посмотрела на меня и спросила, - А в какой школе вы учились, дорогая моя?

Женщина 28 лет

— От меня сбегают мужчины - держатся максимум полгода, а потом все: ни ответа, ни привета, телефон выключен или номер заблокирован, плюс удаление из друзей и черный список.

— Довольно радикальный подход - как думаете, с чем он связан?

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

— Почему вы так думаете?

— Я просто встала на их место и поглядела на эту ситуацию — ну что они могут мне предложить? Подвезти до работы на своем авто? Так у меня офис через квартал. Зарабатывать так, чтобы хватало на нас двоих, плюс хотя бы на одного ребенка? Сложновато это в наше время - да и тянуть эту лямку достаточно долго нынешние мужики уже не могут или хотят. Причиндалами своими меня радовать? Да я и сама неплохо справляюсь, в крайнем случае можно найти кого-нибудь без особых претензий на серьезные отношения.

— Если все так, то зачем продолжать искать себе мужчину?

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

Мужчина 32 года

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

— Вы имеете ввиду что начали ложиться спать и просыпаться тогда, когда этого захочет сам организм?

— Не только это, - довольно улыбнулся он. – Еще питаться, гулять и разговаривать лишь когда мне этого хотелось. И вы знаете что? Мое тело преобразилось – я стал намного здоровее и лучше выглядеть, как по волшебству исчезли болячки, донимавшие меня многие годы, плюс к этому пропали признаки тревожности, на которые мне указывала предыдущий психолог.

— Вы почувствовали себя счастливым?

— Как никогда раньше, вот только… - тут клиент уже перестал улыбаться. – Мне пора снова выходить на работу, а я не могу себя заставить опять вернуться в режим. Планирую, ставлю будильники, принудительно сажусь и ем, но организм будто смеется мне в лицо: отказывается есть, выворачивая желудок наизнанку и не хочет бодрствовать – меня может вырубить прямо посреди рабочего дня. Что делать – не знаю! Это вообще можно исправить?

Всем привет.

Сегодня поговорим о таком прикладном инструменте системного аналитика, как UML.

Зачастую у многих возникает вопрос - а зачем вообще рисовать любые диаграммы и схемы? Мы все такие замечательные, уже научились писать требования, оформлять разными способами (даже красивыми) - в общем-то, по этим требованиям же и так всё понятно?

И отчасти это так. Глобально - качественно собранных и поставленных требований к системе за глаза хватает для того, чтобы система была нормально разработана, без каких-либо проблем. Но зачем останавливать себя в желании "прибраться" в голове или наглядно объяснить что-нибудь команде - ведь наличие наглядной схемы позволяет решить все эти задачи и заметно упрощает жизнь.

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

UML

UML – унифицированный язык моделирования (Unified Modeling Language) – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. Его можно использовать для визуализации, спецификации, конструирования и документирования систем.

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

Основные цели дизайна UML:

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

• Быть независимым от конкретных языков программирования и процессов разработки (важно);

• Обеспечить формальную основу для понимания языка моделирования;

• Поддержка высокоуровневых концепций разработки, таких как совместная работа, структуры, шаблоны и компоненты.

Преимущества и недостатки проектирования диаграмм:

Начнем с недостатков:

• Дополнительная трата времени, которого может и не быть;

• Необходимость знать и понимать различные нотации.

Преимущества:

• Возможность посмотреть на задачу с разных точек зрения;

• Другим членам команды (включая заказчиков) легче понять суть задачи и способ ее реализации;

• Диаграммы сравнительно просты для чтения после достаточно быстрого ознакомления с их синтаксисом.

В UML диаграммы подразделяют на два типа — это структурные диаграммы и диаграммы поведения.

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

• Диаграмма составной структуры

• Диаграмма развертывания

• Диаграмма пакетов

• Диаграмма профилей

• Диаграмма классов

• Диаграмма объектов

• Диаграмма компонентов

Диаграммы поведения показывают динамическое поведение объектов в системе, которое можно описать, как серию изменений в системе с течением времени. А к диаграммам поведения относятся:

• Диаграмма деятельности

• Диаграмма прецедентов

• Диаграмма состояний

• Диаграмма последовательности

• Диаграмма коммуникаций

• Диаграмма обзора взаимодействия

• Временная диаграмма

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

Диаграмма классов

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

Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:

• Ассоциация - представляет отношения между экземплярами типов. Например, человек работает на компанию, у компании есть несколько  офисов;

• Зависимость — это форма отношения использования, при которой изменение в одном классе - влечёт за собой изменение другого, причём обратное не обязательно.

• Агрегация - это ассоциация типа «целое-часть». При этом обе части могут жить отдельно друг от друга (машина - колесо).

• Композиция – это такая агрегация, где объекты-части не могут существовать сами по себе (дом - комната).

Пример:

Стоит еще рассказать про такую вещь как "Кратность". По сути между объектами может быть всего 3 типа кратности, которые уже могут варьироваться:

• 1 к 1. Это значит, что ровно одному объекту соответствует ровно один объект. Например - у одного человека может быть только один паспорт (не берем загранник);

• 1 ко многим. Одному объекту может соответствовать множество объектов (множество это может быть и 0). Например - один автор написал много книг;

• Многие ко многим. Множеству объектов может соответствовать множество других объектов. Например - много поставщиков поставляют много товаров (в том числе пересекающихся).

При этом могут быть частные варианты, такие как, как 1 : 0..* (1 объекту соответствует множество объектов или ни одного. Например, у одного покупателя может быть множество заказов, но их может и не быть совсем). Или 1 : 3..*, т.е. одному объекту соответствует минимум три других и в целом любые возможные комбинации.

Диаграмма прецедентов

Диаграмма прецедентов - описывает функциональные требования системы с точки зрения того, как она будет использоваться людьми и/или взаимодействовать с другими системами.

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

Актер - если упростить, то это какой-то конкретный пользователь или роль, или другая система, подсистема или класс.

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

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

Пример диаграммы:

В языке UML несколько стандартизированных видов отношений между актерами и вариантами использования:

Отношение ассоциации - самая обычная закрашенная стрелочка, которой можно соединять только актера и варианты использования. Она означает, что актер может выполнять действия, описанные вариантом использования.

Отношения обобщения - показывает, что определенный актёр или вариант использования может быть обобщён до другого актёра или варианта использования. Как на примере выше - UC "открытие счета ФЛ" и "открытие счета ФЛ" обобщены в UC "Открыть счет".

Отношение включения - показывает, что включенный UC должен быть обязательно выполнен, при выполнении другого варианта использования, в который он входит.

Например, при предоставлении кредита в банке всегда происходит проверка платежеспособности клиента.

Отношение расширения - показывает, что расширенный UC может быть выполнен в составе того UC, в который он входит, а может и не выполняться. Обязательности уже нет.

Например, при предоставлении кредита в банке может происходить с предоставлением налоговых льгот, при определенных условиях, но это не обязательно.

Диаграмма состояний

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

Другими словами - такая диаграмма показывает то, как сущность переходит из одного состояния в другое.

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

Если рассматривать схему из примера, то это работает примерно так:

Стартовый статус нашей системы = "Бездействие". Дальше, если срабатывает триггер (допустим, получаем сообщение от датчика температуры, что она превысила установленную норму) - то система начинает переходить к общему статусу "Охлаждение". Он в свою очередь состоит из нескольких процессов - запуск компрессора, готовность и работа вентилятора.

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

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

Послесловие.

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

Плюс, многие разработчики очень просят, чтобы диаграммы добавлялись в ТЗ, потому что им так намного проще осознавать что нужно сделать и что за чем идет (особенно актуально для интеграций). Да и в целом большинство людей визуалы.

P.S. Про UML это еще не всё, но пост получается очень большим, поэтому разобью на две части и добью остаток про UML в следующей. Заодно там же начну рассказывать про BPMN.

P.P.S: Завтра (25.02.2023 в 12.00 московского времени) у меня в телеграмме пройдет эфир где я буду отвечать на разные вопросы про карьеру/профессию/перспективы/развитие и т.д. В общем на все вопросы, которые мне будут задавать участники эфира.

Ничего продавать не буду, поэтому если хотите поболтать\послушать или даже есть какие-то вопросы на указанные темы - приходите, буду рад всем. Ссылка на телеграмм в моем профиле.