> Бывает такое, что во время реализации всплывают какие-то "несрастушечки", ну вот не работает такая схема и всё.
А часто бывает? В этих случаях надо копать в анализ и его качество, увы. Если вы доведете благодаря хорошему анализу «несрастушечки» до 10%, мне кажется значительно выиграете в предсказуемости.
Сочувствую боли. Бывают такие архитекторы и менеджеры (которые сваливают свою обязанность управлять командой на программистов). Как их бороть — ортогональный вопрос. Но если они загружены фуллтайм записыванием за вами мыслей, то это сильно облегчает им доказательство их полезности. Ведь они вот сколько документов подготовили.
У нас архитекторы не только согласуют документы — на них лежат и планируются задачи по discovery, разработке концепций, больших архитектурных изменений. И мы можем от них это требовать благодаря этому. И на встречи с технарями заказчика или других команд тоже можем попросить сходить их, а не программиста — т.к. они все читаю, верхеуровневая картинка в голове у них есть
3.Какой толк от архитектора? Я видел (в том числе в упомянутых компаниях) с подходом, где каждую задачу берет себе архитектор и по ней пишет такой документ. В целом во многих командах при изначальном внедрении этого подхода так и делают — есть лид, он пишет такую доку по всем задачам.
К чему это приводит? В первую очередь к перегрузке архитектора/лида. Документы начинают писаться формально. Сроки затягиваются, те самые менеджеры заставляют программистов параллельно код писать. Документы становятся бесполезнее, пишутся еще формальнее, программисты прекращают их читать.
Попытка «расшива» этого узкого места приводит к найму в архитекторы людей, кто норм к написанию формальных документов и не обладают глубокими техническими знаниями. Они становятся еще бесполезнее, архитекторов прекращают уважать, принятие реальные архитектурных решений в компаний уходит от архитекторов в неформальную иерархию (обычно в руки тимлидов).
Это неудачная попытка внедрения предлагаемой вами схемы. А удачная приводит вот к чему — программисты при успешном внедрении этой схемы снижают свою роль до манкикодинга. У них нет ответственности за качество своего решения, они демотивированы (хорошие программисты не любят этого).
Тут (как я пишу в статье) программисты реально вовлечены в разработку решений, могут проявить свой креатив. Архитекторы консультируют, согласуют и надзирают, да. Но у них освобождается запас времени от текучки.
Если под ТЗ подразумевать бизнес-требования или функциональные требования, то теханализ пишется на основе этих документов. Работу аналитика это не исключает. Почему аналитик не может сразу писать про технические решения — ответ есть в статье.
Менеджер вообще к ТЗ отношения не имеет. Он может организовать его написание, но сам написать не может. Нужен ли менеджер в принципе — ответ для другого поста.
Но да. В теории могут быть проекты, где эти вопросы, которые обычно обсуждаются в теханализе — поддерживаемость кода, масштабируемость, архитектура — не важны, а важно быстро согласовать и выдать прототип. В этом случае процессы эти вводить не нужно :-) С соответствующими эффектами.
Если есть незначительные изменения, то проще всего поправить теханализ в процессе реализации и уведомить ревьюеров. Или вообще не править теханализ (например, новое строковое поле в сущности может вообще не упоминаться в анализе, если это не меняет никаких публичных API за границами команды).
Если речь идет про кардинальные изменения по итогам прототипирования, это две задачи в пайплайне (сделать прототип, сделать вторую итерацию) и каждая задача претендует на теханализ.
В каких-то случаях можно написать прототип без теханализа — ну типа сделать мокап UI и показать, получить фидбек, уточнить задачу и идти в полноценную задачу
Мы пошли не путем «устная презентация с письменной шпорой», а путем «написать документ, и если нужно его презентовать». По итогам презентации можно поправить документ.
Любая зависимость и любая уязвимость усложняют жизнь. Даже если ими не реально воспользоваться, надо тратить время на ручной или полуручной анализ и обоснование этого. В некоторых отраслях мы это делаем «для себя», а в некоторых это может быть основанием для написания формальных документов и отдельное согласование с ИБ.
Упрощает дело анализ по категориям — отметаем все узявимости, которые имеют вектор атаки в доступом к USB на основании того, что средство контейнеризации и контроль физического доступа исключают этот вектор атаки и т.д., но все равно это время и расходы.
Чем меньше уязвимостей показывает сканер, тем лучше с точки зрения и реальной безопасности, и работы со службами ИБ и их требованиями.
> Бывает такое, что во время реализации всплывают какие-то "несрастушечки", ну вот не работает такая схема и всё.
А часто бывает? В этих случаях надо копать в анализ и его качество, увы. Если вы доведете благодаря хорошему анализу «несрастушечки» до 10%, мне кажется значительно выиграете в предсказуемости.
Сочувствую боли. Бывают такие архитекторы и менеджеры (которые сваливают свою обязанность управлять командой на программистов). Как их бороть — ортогональный вопрос. Но если они загружены фуллтайм записыванием за вами мыслей, то это сильно облегчает им доказательство их полезности. Ведь они вот сколько документов подготовили.
У нас архитекторы не только согласуют документы — на них лежат и планируются задачи по discovery, разработке концепций, больших архитектурных изменений. И мы можем от них это требовать благодаря этому. И на встречи с технарями заказчика или других команд тоже можем попросить сходить их, а не программиста — т.к. они все читаю, верхеуровневая картинка в голове у них есть
Зависит от подхода. Если у нас контрактная разработка, там это придется сделать, но там свои приколы. Я скорее про модную agile продуктовую
Обычно аналитик как раз за предметную область и то, как с ее языка переводить на язык требований
3.Какой толк от архитектора? Я видел (в том числе в упомянутых компаниях) с подходом, где каждую задачу берет себе архитектор и по ней пишет такой документ. В целом во многих командах при изначальном внедрении этого подхода так и делают — есть лид, он пишет такую доку по всем задачам.
К чему это приводит? В первую очередь к перегрузке архитектора/лида. Документы начинают писаться формально. Сроки затягиваются, те самые менеджеры заставляют программистов параллельно код писать. Документы становятся бесполезнее, пишутся еще формальнее, программисты прекращают их читать.
Попытка «расшива» этого узкого места приводит к найму в архитекторы людей, кто норм к написанию формальных документов и не обладают глубокими техническими знаниями. Они становятся еще бесполезнее, архитекторов прекращают уважать, принятие реальные архитектурных решений в компаний уходит от архитекторов в неформальную иерархию (обычно в руки тимлидов).
Это неудачная попытка внедрения предлагаемой вами схемы. А удачная приводит вот к чему — программисты при успешном внедрении этой схемы снижают свою роль до манкикодинга. У них нет ответственности за качество своего решения, они демотивированы (хорошие программисты не любят этого).
Тут (как я пишу в статье) программисты реально вовлечены в разработку решений, могут проявить свой креатив. Архитекторы консультируют, согласуют и надзирают, да. Но у них освобождается запас времени от текучки.
Если под ТЗ подразумевать бизнес-требования или функциональные требования, то теханализ пишется на основе этих документов. Работу аналитика это не исключает. Почему аналитик не может сразу писать про технические решения — ответ есть в статье.
Менеджер вообще к ТЗ отношения не имеет. Он может организовать его написание, но сам написать не может. Нужен ли менеджер в принципе — ответ для другого поста.
Но да. В теории могут быть проекты, где эти вопросы, которые обычно обсуждаются в теханализе — поддерживаемость кода, масштабируемость, архитектура — не важны, а важно быстро согласовать и выдать прототип. В этом случае процессы эти вводить не нужно :-) С соответствующими эффектами.
На самом деле тут у нас есть варианты.
Если есть незначительные изменения, то проще всего поправить теханализ в процессе реализации и уведомить ревьюеров. Или вообще не править теханализ (например, новое строковое поле в сущности может вообще не упоминаться в анализе, если это не меняет никаких публичных API за границами команды).
Если речь идет про кардинальные изменения по итогам прототипирования, это две задачи в пайплайне (сделать прототип, сделать вторую итерацию) и каждая задача претендует на теханализ.
В каких-то случаях можно написать прототип без теханализа — ну типа сделать мокап UI и показать, получить фидбек, уточнить задачу и идти в полноценную задачу
Мы пошли не путем «устная презентация с письменной шпорой», а путем «написать документ, и если нужно его презентовать». По итогам презентации можно поправить документ.
Гарантия есть. Адрес переменной i никогда не брали, она вообще может его не иметь. И кстати и не будет.
Но все ещё непонятно, как это связано с понятием UB и его наличием в языке.
Пример приведите.
Любая зависимость и любая уязвимость усложняют жизнь. Даже если ими не реально воспользоваться, надо тратить время на ручной или полуручной анализ и обоснование этого. В некоторых отраслях мы это делаем «для себя», а в некоторых это может быть основанием для написания формальных документов и отдельное согласование с ИБ.
Упрощает дело анализ по категориям — отметаем все узявимости, которые имеют вектор атаки в доступом к USB на основании того, что средство контейнеризации и контроль физического доступа исключают этот вектор атаки и т.д., но все равно это время и расходы.
Чем меньше уязвимостей показывает сканер, тем лучше с точки зрения и реальной безопасности, и работы со службами ИБ и их требованиями.
Все эти пункты могут быть правдой. Код хороший, в СУБД уперлись.
Это просто значит, что архитектура говно.
А это речь про то НСИ, которое на базе ZIIOT сделано у вас, или другое НСИ?
У нас был опыт с .net вариантом этой либы, кажется iBatis.
В общем кончилось тем, что мы поддерживали свой форк.
Методические рекомендации явно разрешают OpenJDK https://ru-ikt.ru/metodic
Если на испытательном сроке он прочтет книгу про нефтепереработку, то засчитаем.
Сарказм не считался, кажется
Миллениалы изобрели торговлю с плечом.
Интересно, есть ли у торговли с плечом какой-то минус?