В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Архитектура ИТ-решений

2193 membersпожаловаться на группу
2020 June 17

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Если архитектор требует документацию, чтобы сделать ревью дизайна, то предмета для ревью обычно нет. А на вопросы по архитектуре в ответ раздаётся мычание.
источник
02:55пожаловаться#1

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Хорошо, с рефакторингом более менее разобрались. Рефакторить втихую, когда разработчик сам решит или не решит, руководствуясь материалами по ссылкам выше.

А что с дизайном делать? Эту активность трудно скрыть.

А что с документированием (дизайна), с учётом того, что разработчики документацию по своей воле писать не хотят?
источник
03:07пожаловаться#2

r

rokrbek in Архитектура ИТ-решений
Gennadiy Kruglov
Хорошо, с рефакторингом более менее разобрались. Рефакторить втихую, когда разработчик сам решит или не решит, руководствуясь материалами по ссылкам выше.

А что с дизайном делать? Эту активность трудно скрыть.

А что с документированием (дизайна), с учётом того, что разработчики документацию по своей воле писать не хотят?
А что делать, если разработчики по своей воле не хотят фиксить баги, красить кнопки, сидеть на sl3 и прочих "неинтересных" им задачах?
источник
08:47пожаловаться#3

SD

Serg D. in Архитектура ИТ-решений
Шикарный вопрос... а можно координаты работы где можно не делать неинтересные задачи? Куда резюме слать?
источник
09:05пожаловаться#4

r

rokrbek in Архитектура ИТ-решений
Serg D.
Шикарный вопрос... а можно координаты работы где можно не делать неинтересные задачи? Куда резюме слать?
Вы перечитайте оригинальное сообщение, а потом мое
источник
09:17пожаловаться#5

SD

Serg D. in Архитектура ИТ-решений
Перечитал. Ничего не изменилось. Есть трудовой договор, есть должностные инструкции, независимо от того, о ком речь, о разработчике, об архитекторе или грузчике дяде Васе, если человек без объективных причин не делает работу, которую должен и это влияет на процессы и продукт, то есть ряд предусмотренных ТК  мер.
источник
09:22пожаловаться#6

r

rokrbek in Архитектура ИТ-решений
осталось применить это к вопросу из оригинального сообщения
источник
09:50пожаловаться#7

EV

Egor Vershinin in Архитектура ИТ-решений
Gennadiy Kruglov
Хорошо, с рефакторингом более менее разобрались. Рефакторить втихую, когда разработчик сам решит или не решит, руководствуясь материалами по ссылкам выше.

А что с дизайном делать? Эту активность трудно скрыть.

А что с документированием (дизайна), с учётом того, что разработчики документацию по своей воле писать не хотят?
Вносить в рабочий процесс  как первую фазу работ по проекту. В PMI даже специальный артефакт есть для этого Концепция проекта.
источник
11:12пожаловаться#8

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Egor Vershinin
Вносить в рабочий процесс  как первую фазу работ по проекту. В PMI даже специальный артефакт есть для этого Концепция проекта.
Этого не достаточно, потому что дизайн во время разработки меняется.

На первой фазе возможно разработать только высокоуровневый концепт архитектуры.
источник
11:16пожаловаться#9

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Но куда важнее - сделать так, чтобы дизайном просто занимались, думали о нём, обсуждали его и принимали решения, документировали его.
источник
11:17пожаловаться#10

EV

Egor Vershinin in Архитектура ИТ-решений
Gennadiy Kruglov
Этого не достаточно, потому что дизайн во время разработки меняется.

На первой фазе возможно разработать только высокоуровневый концепт архитектуры.
У нас дизайн разбит на несколько фаз: концептуальные решения, HLD, требования к реализации
источник
11:24пожаловаться#11

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Egor Vershinin
У нас дизайн разбит на несколько фаз: концептуальные решения, HLD, требования к реализации
Поделитесь пожалуйста деталями
источник
11:27пожаловаться#12

AM

Artem Mitropolskiy in Архитектура ИТ-решений
Egor Vershinin
У нас дизайн разбит на несколько фаз: концептуальные решения, HLD, требования к реализации
А как же исключения? Мы концептуально решили делать так, но подгорает, поэтому в этой задаче делаем не так
источник
11:37пожаловаться#13

EV

Egor Vershinin in Архитектура ИТ-решений
Artem Mitropolskiy
А как же исключения? Мы концептуально решили делать так, но подгорает, поэтому в этой задаче делаем не так
Значит прорабатывается WorkAround
источник
11:39пожаловаться#14

EV

Egor Vershinin in Архитектура ИТ-решений
Gennadiy Kruglov
Поделитесь пожалуйста деталями
Их очень много. Может что-то конкретно интересует?
источник
11:40пожаловаться#15

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Egor Vershinin
Их очень много. Может что-то конкретно интересует?
Нет, всё нормально
источник
11:41пожаловаться#16

DK

Daria Kaftan in Архитектура ИТ-решений
О, моя любимая тема. Документирование, тех долг. Но почему разговор только про разработку и качество кода/дизайн решений в коде? Там вокруг этого огромное количество вещей, по которым те же самые проблемы. И требования, и тесты, и devops
источник
11:59пожаловаться#17

НХ

Николай Хитров... in Архитектура ИТ-решений
оо, тесты это вообще отдельная тема для холиваров. с девопс как-то попроще
источник
12:00пожаловаться#18

DK

Daria Kaftan in Архитектура ИТ-решений
Например, как вносить изменения даже в самый качественный код, если нигде не зафиксированы требования? Или зафиксированы, но так, что лучше б не были.
источник
12:01пожаловаться#19

DK

Daria Kaftan in Архитектура ИТ-решений
Например, на сопроводе. Команде сопровождения надо отличать, грубо говоря, где у нас баг, а где фича - что соответствует требованиям, что нет. Что-то может "работать" и быть написано в соответствии с требованиями к качеству кода и архитектуре решения, но не соответствовать функциональным требованиям, например.
источник
12:03пожаловаться#20