Спасибо за статью! Это просто кладезь информации - подано без воды, концентрированно и с примером. Одна из немногих действительно полезных статей, особенно для людей, далеких от продвижения и маркетинга
Подход «плохо комментировал - отвечай устно» вполне имеет место быть, не спорю.
А базовое знание языка в сложном продукте вместе с навыком работы в IDE - поможет в любом случае, даже если придётся разбираться в различных фреймворках.
Действительно, профильные разработчики должны помочь разобраться в кодовой базе. Но если постоянно их отвлекать вопросами - можно пролететь со сроками.
Плюс знание ЯП я считаю необходимым условием профессионального развития СА.
Если коротко - погромистом можешь ты не быть, но язык погроммирования ты знать обязан должен :)
Не совсем соглашусь с вами - базовое знание хотя бы одного языка программирования, на мой взгляд и является одним из векторов «прокачки» себя как аналитика и в дальнейшем архитектора.
Купить курс по программированию не предлагаю ни в коем случае, скорее наоборот - считаю, что в интернете или книжных магазинах сейчас в избытке материала, который позволит сделать это самостоятельно.
А с подспудным желанием вы угадали на 100% - я начинал свой путь как раз бэкенд-разработчиком :)
Иногда бывает, что аналитик приходит в команду, где по тем или иным причинам не велась должным образом документация (актуально для стартапов, да и вообще свойственно Scrum-командам, ведь даже один из принципов скрама гласит, что работающий функционал важнее исчерпывающей документации).
Я лично с таким не один раз сталкивался, и могу выделить отличную статью с Хабра, как восстанавливать документацию в таких случаях.
Менеджер нажимает кнопку перехода на следующую страницу и... ему отобразится что?
Вы абсолютно правы, в моем примере я и указал, что offset-based пагинация может приводить к неконсистентности часто обновляемых данных и лучше использовать курсоры, так как они вернут результаты, существующие в базе на момент начала транзакции.
Целью статьи вообще было показать, как можно спроектировать простой API-метод, описав его с помощью двух разных подходов, не углубляясь в тонкости реализации логики на бэке или фронте, так как в начале материала я даже отметил, что он ориентирован на начинающих аналитиков.
Ну и вишенкой на торте: а на кой чёрт здесь вообще аналитик?
Последние лет пять большом энтерпрайзе (во всяком случае там, где работал я и где работали мои знакомые) переходят к api first. В связи с этим - огромный спрос на аналитиков, и одна из их задач - это отдать готовую спецификацию разработчику, чтобы тот не тратил своё время на написание и поддержание документации. Бюджет хоть и расходуется, но time to market продукта получает неплохой прирост.
Косвенно, это подтверждается огромнейшим спросом на рынке РФ (возьмите хотя бы hh - там количество вакансий SA уже второе по количеству после разработчиков).
Спасибо за подробный комментарий и, что как и пользователь выше, обратили внимание на необходимость наличия ключа total для корректной отрисовки UI, отредактировал статью.
Про ленточную пагинацию изначально не планировал писать в статье, но сейчас привел краткий пример.
По вопросу возвращения количества записей в ответе согласен, я изначально ввел всех в заблуждение, т.к. рассказывал про получение записей на UI, а в голове держал взаимодействие back2back, когда нет смысла передавать этот параметр. Чтобы не городить костыли, действительно целесообразно получать в ответе totalCount. Но если записей слишком много, то смысла пользоваться offset-пагинацией нет, и целесообразнее перейти к реализации с помощью, например, keyset-пагинации. Спасибо, что внимательно прочитали и обратили внимание, статью отредактировал.
Достаточно сделать по одной кнопочке вперёд-назад, на крайний случай третью - двойное вперед >> (к самой последней записи).
Запрашивать из БД общее количество записей и затем делить на количество записей на страницу для подсчёта количество страниц - не самое оптимальное решение, потому что SELECT COUNT(*) это одна из самых «тяжелых» операций.
Мне нравится ваша идея внедрения гибких подходов в ITSM, прежде всего потому, что нужно сокращать/автоматизировать бюрократические операции.
Как вы ранжируете и обозначаете приоритеты задач в канбан-доске (особенно, если это инциденты)?
И ещё мнение - я бы в этом подходе выделял отдельно run-команду и change-команду, если позволяет бюджет. Если нет, то можно брать в спринты run/change задачи в определенном фиксированном соотношении.
В какой то степени вы правы - целью обзорной статьи и является своеобразный ликбез для людей, мало знакомых с IT, поэтому я постарался изложить теоретические выкладки максимально доступно и с иллюстрациями :-)
Системная аналитика возможна только когда человек является экспертом в каком то домене, а не вся эта хрень с бесполезным Rest и тупыми вопросами про Кафку.
Абсолютно не согласен. Во-первых экспертиза не возникает на пустом месте, а во-вторых основы функционирования и принципы проектирования информационных систем универсальны и плюс-минус едины относительно любого домена.
Судя по статье никто не понимает что за хрень вся эта системная аналитика. В 80% случаях вообще ничего из описанного не пригодится.
В заголовке статьи указано, что она является обзорной и вводной статьей из запланированной мной серии, поэтому ваши реакционные выводы слишком поспешны, на мой взгляд.
Спасибо за статью! Это просто кладезь информации - подано без воды, концентрированно и с примером. Одна из немногих действительно полезных статей, особенно для людей, далеких от продвижения и маркетинга
Подход «плохо комментировал - отвечай устно» вполне имеет место быть, не спорю.
А базовое знание языка в сложном продукте вместе с навыком работы в IDE - поможет в любом случае, даже если придётся разбираться в различных фреймворках.
Действительно, профильные разработчики должны помочь разобраться в кодовой базе. Но если постоянно их отвлекать вопросами - можно пролететь со сроками.
Плюс знание ЯП я считаю необходимым условием профессионального развития СА.
Если коротко - погромистом можешь ты не быть, но язык погроммирования ты знать
обязандолжен :)Спасибо за подробный и обстоятельный комментарий!
К сожалению не знаю таких курсов, но могу порекомендовать посмотреть в сторону обувающих видео на ютубе по тому фреймворку, который интересует.
Если своими руками повторить любой туториал по написанию даже небольшого сервиса, уверен, многое станет гораздо прозрачнее.
Не совсем соглашусь с вами - базовое знание хотя бы одного языка программирования, на мой взгляд и является одним из векторов «прокачки» себя как аналитика и в дальнейшем архитектора.
Купить курс по программированию не предлагаю ни в коем случае, скорее наоборот - считаю, что в интернете или книжных магазинах сейчас в избытке материала, который позволит сделать это самостоятельно.
А с подспудным желанием вы угадали на 100% - я начинал свой путь как раз бэкенд-разработчиком :)
Иногда бывает, что аналитик приходит в команду, где по тем или иным причинам не велась должным образом документация (актуально для стартапов, да и вообще свойственно Scrum-командам, ведь даже один из принципов скрама гласит, что работающий функционал важнее исчерпывающей документации).
Я лично с таким не один раз сталкивался, и могу выделить отличную статью с Хабра, как восстанавливать документацию в таких случаях.
Спасибо за статью, последовательно и понятно изложен материал. Хочется почитать в таком же стиле что-нибудь про спуфинг или MITM.
Вы абсолютно правы, в моем примере я и указал, что offset-based пагинация может приводить к неконсистентности часто обновляемых данных и лучше использовать курсоры, так как они вернут результаты, существующие в базе на момент начала транзакции.
Целью статьи вообще было показать, как можно спроектировать простой API-метод, описав его с помощью двух разных подходов, не углубляясь в тонкости реализации логики на бэке или фронте, так как в начале материала я даже отметил, что он ориентирован на начинающих аналитиков.
Последние лет пять большом энтерпрайзе (во всяком случае там, где работал я и где работали мои знакомые) переходят к api first. В связи с этим - огромный спрос на аналитиков, и одна из их задач - это отдать готовую спецификацию разработчику, чтобы тот не тратил своё время на написание и поддержание документации. Бюджет хоть и расходуется, но time to market продукта получает неплохой прирост.
Косвенно, это подтверждается огромнейшим спросом на рынке РФ (возьмите хотя бы hh - там количество вакансий SA уже второе по количеству после разработчиков).
Спасибо за подробный комментарий и, что как и пользователь выше, обратили внимание на необходимость наличия ключа total для корректной отрисовки UI, отредактировал статью.
Про ленточную пагинацию изначально не планировал писать в статье, но сейчас привел краткий пример.
По вопросу возвращения количества записей в ответе согласен, я изначально ввел всех в заблуждение, т.к. рассказывал про получение записей на UI, а в голове держал взаимодействие back2back, когда нет смысла передавать этот параметр.
Чтобы не городить костыли, действительно целесообразно получать в ответе totalCount. Но если записей слишком много, то смысла пользоваться offset-пагинацией нет, и целесообразнее перейти к реализации с помощью, например, keyset-пагинации.
Спасибо, что внимательно прочитали и обратили внимание, статью отредактировал.
Достаточно сделать по одной кнопочке вперёд-назад, на крайний случай третью - двойное вперед >> (к самой последней записи).
Запрашивать из БД общее количество записей и затем делить на количество записей на страницу для подсчёта количество страниц - не самое оптимальное решение, потому что SELECT COUNT(*) это одна из самых «тяжелых» операций.
Спасибо, обновил!
Добавил :)
Мне нравится ваша идея внедрения гибких подходов в ITSM, прежде всего потому, что нужно сокращать/автоматизировать бюрократические операции.
Как вы ранжируете и обозначаете приоритеты задач в канбан-доске (особенно, если это инциденты)?
И ещё мнение - я бы в этом подходе выделял отдельно run-команду и change-команду, если позволяет бюджет. Если нет, то можно брать в спринты run/change задачи в определенном фиксированном соотношении.
Случайно попало сюда, когда составлял скелет статьи :)
Планировал рассказать об этом в следующих частях про интеграции.
Большое спасибо, что обратили внимание! Статью поправил.
Спасибо за конструктивный совет!
Дополнил статью в соответствии с вашими предложениями.
Спасибо :)
Шрифт - Virgil
В какой то степени вы правы - целью обзорной статьи и является своеобразный ликбез для людей, мало знакомых с IT, поэтому я постарался изложить теоретические выкладки максимально доступно и с иллюстрациями :-)
Абсолютно не согласен. Во-первых экспертиза не возникает на пустом месте, а во-вторых основы функционирования и принципы проектирования информационных систем универсальны и плюс-минус едины относительно любого домена.
В заголовке статьи указано, что она является обзорной и вводной статьей из запланированной мной серии, поэтому ваши реакционные выводы слишком поспешны, на мой взгляд.