Друзья, Вы видимо не в курсе, как у них устроена веб-часть. Там не SPA типа Ember или Angular, там TurboLinks. Который в целом «есть» не просит. Отсюда и решение, которое им подошло.
Ну а идея думать наперед в плане новых возможностей хороша, жизненный цикл продуктов как правило больше 3х лет. Разумеется без крайностей, соблюдая баланс, как и везде.
Во-первых точно фиксировать в ТЗ изменения (всегда иметь актуальную версию того, что реально делают/сделали) + вести историю изменений(кто, на каком этапе, что и почему изменил) + вести трассировку с другими требованиями + следить за трудозатратами. Требования в целом вещь живая…
Разумеется меняем ТЗ если изменения разумны и состав менеджеров/клиентов это не вгонит в депрессию. Изменения согласуем с участниками, оглядываясь на трудозатраты и текущие правила игры.
И я вообще не верю, что в средней/большой задаче нужно прям 100% всего разжевать, это может быть не рационально по времени. В процессе реализации задачи на языке программирования в конкретном проекте всегда имеют место быть нюансы, которые «дешевле» бывает подогнать на месте глядя в текущий код. Разумеется речь не о фатальных промахах ;)
Регулярно воюю на тему первого пункта. Сценарий космос, а назвать команду/меню/раздел требуется одним/двумя словами, да еще уникальными в проекте. И выдумывать слова нельзя ;)
Если идти далее про интерфейс — «Вот гугл, как все просто, одна кнопка Найти». На что каждый раз вздыхаю, ну как они могли сочинить поисковик с двумя кнопками «Найти»…
А мы в данный момент осуществляем интеграцию нашего учетного софта с оборудованием с поддержкой изменений по ФЗ-54. И что то пока не очень идет (причем с прошлого года начали ^^)… Сначала долго ждали девайс с накопителем для разработчиков. Затем сервис ОФД для разработчиков, где надо «набивать руку», упал… Потом поддержка девайсов отправляет в руководство для программиста, где длинным списком идут новые методы драйвера, но не расписана картина сверху, на уровне процессов.
Может кто то поделится опытом, можно в личку (хотя с виду всем интересно будет)?
Больше всего волнует вопрос стадий печати чеков: аванс, выдача в счет аванса + возвраты и т.д., т.е. предполагается печатать несколько чеков на один заказ. Я уже молчу про обработку ошибок связи и не только.
Согласен, но быстродействие и потребление ресурсов (а я не думаю, что уж так много лишний «груз» кушает, конкретно в рельсах) это лишь пара критериев. Да, оба показатели будут хуже заточенных решений, вопрос насколько.
Зато, например, какая хорошая утилизация железа. Есть 10 серверов, раскатываем монолит на все сервера и гоним через балансировщик запросы. А в случае с микросервисами придется решать задачку — какой сервис на какую/какие машины раскинуть. В итоге часть железа простаивает, ибо заложили под пики нагрузки. Это можно победить, но ценою усложнения системы.
Все правильно, но сама задача «Разбить проект на слабосвязанные компоненты с жесткими контрактами на взаимодействие между ним» очень непростая, особенно если надо заглянуть в будущее. И по идее уже не так важно, внутри монолита дробить или между сервисами.
Мне кажется оптимальным начать с монолита, а походу смотреть и находить линии «разреза». Так не только я считаю, и другие видят в этом нормальную стратегию.
Обсуждая микросервисы vs монолиты, нужно договориться, о каком монолите речь.
Просто у кого-то в голове возникает образ некого скомпилированного исполняемого файла, который при всем желании невозможно масштабировать количеством запущенных копий и балансировщиком перед ними.
А если представить RAILS-приложение(и подобные), которое вроде как монолит, то там прекрасно всё масштабируется. Тут единственный существенный минус — это выкатка новых версий подсистем монолита.
Именно об этом я и написал выше. Но это нормально. Что то из обращения пойдет в ТЗ на реализацию, что то «забреется». Не вижу проблем, оно так устроено и в других отраслях.
Это выдает в вас сторонника теории рационального поведения экономических субьектов.
Нет не выдает ^^ Условно половину обращений я закрываю, мол «нет проблем», «переложить на других», «в данных условиях/формулировках/требованиях не решаются», «решаются штатными средствами», «решаются организационно/юридически/другое».
Для меня обращение бизнеса — это входящая задача. Решением задачи может быть в итоге ТЗ. Именно может быть, а не обязано.
1. Вот это зря. Бизнес прекрасно понимает, где у него жмет. Иначе бы не началось телодвижение. Да, сформулировано может быть как в старом анекдоте. Но аналитик должен докопаться до истины с приемлемыми затратами, ну работа такая.
2. В любых договоренностях так может быть, очевидно.
3 и 4. А никто и не говорит что требования в камне. Они живые. Один разок я полгода писал ТЗ для лаборатории, а как подписали все шишки, смена законодательства и ТЗ в утиль. Я не расстроился ;)
Везет мне как всем, вопрос в постановке задачи/роли аналитика ;)
Ребят, тут ведь все прозрачно. У клиента «проблема/желание». С нас выслушать его и «родить решение». А затем зафиксировать его в ТЗ. Я бы сразу разделил и не смешивал эти направления.
Когда клиент сам пытается родить именно решение — все упирается в его скилл. Как правило он никакой, оттуда и решения никакие (то розовую кнопку по центру экрана попросит, то еще что). Но это не отменяет наличия у него проблемы или потребности.
Если клиент пришел и говорит: «Хочу, что бы вы мне голову отрубили», то надо на автомате уточнить: «А исходя из чего Вы приняли такое решение? Какую жизненную задачу мы закроем? Какие еще решение рассматривали?» и т.д. т.п. Финансово частенько выгодно сказать: «Так точно! Будет сделано!», а потом на возражение клиента выдавать: «ВСЁ ПО ТЗ!». Но это не по «нашему» =)
Мне пока везет и клиенты с большим пониманием и доверием относятся к тому, что с них проблема/окружение/пожелания, а с меня поиск решения. Так не с первой встречи, но в процессе данный подход очевидно побеждает «Сделайте нам вот сюда вот именно вот так! Сколько стоит?» (если речь про долгосрочные отношения).
У нас крайне разный взгляд на деятельность архитектора.
Лично я таких, как Вы пишете, не видел. Но охотно верю, что кого то из менеджеров начали называть «архитектором» со всеми вытекающими =)
По мне не надо «травмировать» архитектора общением с бизнесом (как и программиста, тестировщика и ряд других «внутренних» специалистов). Для этого есть закаленные аналитики/менеджера, они узнают и спокойно донесут концентрат знаний до архитектора. А архитектор в случае чего попросит уточнений у аналитика, который снова спокойно выудит их у бизнеса/его окружения/других источников. Случай, когда архитектор не смог получить от аналитика ответы или сомневается в них, да так, что пошел сам к бизнесу — по мне не нормальный.
А я ничего не имею против. Сам по табелю системный аналитик, а ролей выполняю вокруг огого ;)
Просто зайдет в статью человек «далекий» от ИТ и кааак прочитает, что оказывается ИТ-Архитектор должен с бизнесом на его языке говорить.
У меня сложилось впечатление, что в статье описана специальность ИТ-архитектора не в широком смысле, а в конкретной компании/команде. В одном человеке, Анне, была замешана не только роль архитектора, но и тимлида, менеджера продукта, проекта, бизнес/системного аналитика и тд. И история получилась соответствующая.
Что первый Ваш ответ, что второй — желчь какая-то. Считаю не заслужил ;) И причем тут велосипеды, я не понял… Искусственный потолок — так же плохо, как и пушкой по воробьям. Почти всегда, начиная с простого скрипта-хелпера — затем приходит аппетит ;)
PS а 7 пунктов это «пять» ;)
И чем его содержимое в простейшем случае будет отличаться от Вашего однострочника? \\Вопрос риторический
Я решал подобные задачи через скрипты (и вообще скрипты иногда пишу) — все быстро и славненько получается. Без «потолка» в развитии инструмента, в отличии от однострочников.
Ну а идея думать наперед в плане новых возможностей хороша, жизненный цикл продуктов как правило больше 3х лет. Разумеется без крайностей, соблюдая баланс, как и везде.
Разумеется меняем ТЗ если изменения разумны и состав менеджеров/клиентов это не вгонит в депрессию. Изменения согласуем с участниками, оглядываясь на трудозатраты и текущие правила игры.
И я вообще не верю, что в средней/большой задаче нужно прям 100% всего разжевать, это может быть не рационально по времени. В процессе реализации задачи на языке программирования в конкретном проекте всегда имеют место быть нюансы, которые «дешевле» бывает подогнать на месте глядя в текущий код. Разумеется речь не о фатальных промахах ;)
Если идти далее про интерфейс — «Вот гугл, как все просто, одна кнопка Найти». На что каждый раз вздыхаю, ну как они могли сочинить поисковик с двумя кнопками «Найти»…
Может кто то поделится опытом, можно в личку (хотя с виду всем интересно будет)?
Больше всего волнует вопрос стадий печати чеков: аванс, выдача в счет аванса + возвраты и т.д., т.е. предполагается печатать несколько чеков на один заказ. Я уже молчу про обработку ошибок связи и не только.
Зато, например, какая хорошая утилизация железа. Есть 10 серверов, раскатываем монолит на все сервера и гоним через балансировщик запросы. А в случае с микросервисами придется решать задачку — какой сервис на какую/какие машины раскинуть. В итоге часть железа простаивает, ибо заложили под пики нагрузки. Это можно победить, но ценою усложнения системы.
Мне кажется оптимальным начать с монолита, а походу смотреть и находить линии «разреза». Так не только я считаю, и другие видят в этом нормальную стратегию.
Просто у кого-то в голове возникает образ некого скомпилированного исполняемого файла, который при всем желании невозможно масштабировать количеством запущенных копий и балансировщиком перед ними.
А если представить RAILS-приложение(и подобные), которое вроде как монолит, то там прекрасно всё масштабируется. Тут единственный существенный минус — это выкатка новых версий подсистем монолита.
Нет не выдает ^^ Условно половину обращений я закрываю, мол «нет проблем», «переложить на других», «в данных условиях/формулировках/требованиях не решаются», «решаются штатными средствами», «решаются организационно/юридически/другое».
Для меня обращение бизнеса — это входящая задача. Решением задачи может быть в итоге ТЗ. Именно может быть, а не обязано.
2. В любых договоренностях так может быть, очевидно.
3 и 4. А никто и не говорит что требования в камне. Они живые. Один разок я полгода писал ТЗ для лаборатории, а как подписали все шишки, смена законодательства и ТЗ в утиль. Я не расстроился ;)
Везет мне как всем, вопрос в постановке задачи/роли аналитика ;)
Когда клиент сам пытается родить именно решение — все упирается в его скилл. Как правило он никакой, оттуда и решения никакие (то розовую кнопку по центру экрана попросит, то еще что). Но это не отменяет наличия у него проблемы или потребности.
Если клиент пришел и говорит: «Хочу, что бы вы мне голову отрубили», то надо на автомате уточнить: «А исходя из чего Вы приняли такое решение? Какую жизненную задачу мы закроем? Какие еще решение рассматривали?» и т.д. т.п. Финансово частенько выгодно сказать: «Так точно! Будет сделано!», а потом на возражение клиента выдавать: «ВСЁ ПО ТЗ!». Но это не по «нашему» =)
Мне пока везет и клиенты с большим пониманием и доверием относятся к тому, что с них проблема/окружение/пожелания, а с меня поиск решения. Так не с первой встречи, но в процессе данный подход очевидно побеждает «Сделайте нам вот сюда вот именно вот так! Сколько стоит?» (если речь про долгосрочные отношения).
Лично я таких, как Вы пишете, не видел. Но охотно верю, что кого то из менеджеров начали называть «архитектором» со всеми вытекающими =)
Просто зайдет в статью человек «далекий» от ИТ и кааак прочитает, что оказывается ИТ-Архитектор должен с бизнесом на его языке говорить.
PS а 7 пунктов это «пять» ;)
Я решал подобные задачи через скрипты (и вообще скрипты иногда пишу) — все быстро и славненько получается. Без «потолка» в развитии инструмента, в отличии от однострочников.