Ну так я и говорю - список в разных странах разный. В Колумбии за изготовление дома незначительного количества порошка из листьев местных растений тоже наверное не посадят. Местный колорит везде присутствует.
Тут как минимум серая зона. УК предусматривает ответственность за изготовление средств совершения преступления. Если вы конструктор оружия, но не работаете на государство (или компанию имеющую лицензию), то да - посадят.
Можно обсуждать насколько это хорошо или плохо. Но происходит по факту простая штука - государство расширило перечень средств которые как оно считает относятся к орудия совершения преступления.
Как всегда никого не предупредив, внезапно.
PS: не то чтобы я это одобрял, но так государства устроены.
У меня так. Все равно двигаться надо. после 47-и и короновирусного карантина таки 5 кг пуза отросло. Я к тому, что магии нет, но некоторым действительно много проще. Обычно это идет в комплекте с врожденным гастритом.
ну я скажу и да и и нет. С одной стороны действительно всего не угадаешь. Хотя и надо стараться учесть все, что можно учесть. С другой стороны внезапно все системы довольно похожи друг на друга и большая часть проектов укладывается в несколько десятков типовых архитектур с типовыми же проблемами. По крайней мере это верно для новых проектов.
При рефакторинге старых систем все несколько сложнее. Там в коде 10-20 летней давности может быть зарыто что-то очень экзотическое.
Но повторюсь - с новыми системам набор типовых архитектур не так уж велик.
Скажем говорит заказчик - я хочу mobile-only соц сеть где пользователи будут постить картинки с геолокацией и назначать календарные события к будущим эвентам. Список вопросов по NFR и ключевых элементов решения можно за час нарисовать. И за несколько дней дообсуждать до состояния когда можно прям начинать кодить. 95% граблей на этой тропинке за нас уже собрано.
UPD т..е понятно, что какая-то дичь все равно всплывет, но надо стараться на этапе проектирования процент дичи минимизировать.
У меня было ровно обратно. Узд правления всегда заметно больше чем хочется и приходится часть из этих рычагов акуратно выдвать людям которые более или менее в адеквате.
Но я понимаю, что это сильно зависит от рабочего контекста. Подозреваю, что как раз в больших копорациях роль архитектора может быть сильно лимитирована.
Хотя я видел как это сделано в одном из проектов и там вроде как архитектор вполне обладал исполнительной властью.
Блин да что там говоить. В прошлом проекте я "уволил" тим лида одной из команд заказчика за некомпетентность.
Именно так. К счастью пока мне удавалось работать в проектах где говорят "Ну нам надо спроектировать арихитектуру и надо чтобы ты потом 2-3 месяца с нами был и потом хотя бы 2 часа в день присматривал".
Но я понимаю, что это далеко не вся наблюдаемая вселенная.
Или вот 30 мин назад - смотрю в чате разработчики планируют использовать спринговую аннотацию @DependsOn - это прям плохой знак. Звонюсь с командой, выясняю для чего они хотят это сделать, объясняю как работат в этом месте спринг, надобность в @DependsOn отпадает.
Если бы я их за руку не поймал бы, то это бы всплыло только в процессе ревью PR, а учитывая, что не каждый PR я просмотриваю, все же это работа лида - это могло всплыть через значительное время какой-то странной проблемой.
Мне кажется тут сильно зависит от компании. В моей практике всегда было так, что роль архитектора ходит по краю с ролью engineering менеджера, который отвественен вообще за все.
Ну просто не понятно - вот я чувак с 25+ годами опыта, нарисовал архитектуру которая не может сфэлится и спокойно сижу и смотрю как группа товарищией упорно ведет проект на кладбище.
Можно конечно сказать, что к архитектуре вопросов нет, я весь в белом. Но пофакту граница очень размыта.
>Нас всех учат не выносить сор из избы. В текущем мире, если будешь рассказывать о проблемах, то тебя запишут в токсики.
Построение архитектуры решения практически единственное место, где можно говорить о проблемах. Ну и потом, я же не для западного ресурса статью пишу. На английский язык проблема переводится как challenge
>А где техлиды, старшие и ведущие разработчики, которые и отвечают за качество реализации?
Вот и у меня такой же вопрос. Если серьезно на него есть два ответа, выбирайте какой больше нравится
в FAANG-ах
На самом деле, когда система достаточно большая, невозможно объять ее всю и если у тебя в руках молоток, то много какие части системы видятся как гвоздь. Перефразируя из разных ролей картинка немного разная и задача архитектора смотреть на задачу широко. У тех лидов и старших разработчиков задачи другие и взгляд несколько другой
Опишу случай из предыдущего проекта. Приложение в числе прочего может редактировать контакты, денормализованые данные должны асинхронно посылаться через Кафку в другой сервис который делает другая команда. Мы с ними вроде как это проговаривали и все должно быть норм.
Делаю кусок в 40 строк кода который обогащает поля контакта перед сохранением. Начинаю тестировать. Выясняется, что соседняя команда которая это делала полный цикл end-to-end не прогоняла. Хотя по идее должна бы, но их это почему-то не беспокоит и вообще им некогда. Начинаю выяснять почему так и как мне end-to-end сделать, выясняется, что конктракт на формат записи постоянно мутирует, контракт живет в библиотеке и она меняется два раза на день, разработчики это знают, но наверх это не идет, иду выяснять, отчего все мутирует, выясняется, что данные там лежат в Элесадре (https://www.elassandra.io) и там "есть проблемы".
Дальше в общем начинается нормальная работа с выяснением где искрит и вообще что за фигня. Но до момента, пока я не залез в код - все упорно молчали по разным причинам.
>А если вас наняли "клепать формочки", то в такой ситуации не особо хорошая идея "улучшать" вещи, которые вас не просили улучшать
Это довольно сильно противоречит современным понятиям о том как должна работать команда. Прям начиная с Agile Manifesto и далее пол best practices.
Но как я сказал если работа проекта устроена по лекалам конца 20-го века, то да. Но тут уже надо решать с кем вам больше по пути
Дома два Synology - из коробки закрывает все вопросы с облаком. Тихий.
Интересно, бывает так, что печень меняет больше одного хоязина?
покрытие с магнитной пленки имеет свойство "осыпаться"
блин, вторую задачу я так наизусть без IDE и доки по спрингу решать реально не просто. Есть ряд вещей которые вот так на поверхности памяти не лежат
Интересно сколько ускорителей помещается в одну фуру?
Вот прямо готового одним куском у меня нет. Я когда-то начинал писать про это статью, но получается объемно и все как-то руки не доходят.
Наверное лучший ответ это полистать Хабр тут регулярно пробегают описание типовых архитектур.
UPD: Можно еще сюда заглянуть https://github.com/donnemartin/system-design-primer
Ну так я и говорю - список в разных странах разный. В Колумбии за изготовление дома незначительного количества порошка из листьев местных растений тоже наверное не посадят. Местный колорит везде присутствует.
Тут как минимум серая зона. УК предусматривает ответственность за изготовление средств совершения преступления. Если вы конструктор оружия, но не работаете на государство (или компанию имеющую лицензию), то да - посадят.
Можно обсуждать насколько это хорошо или плохо. Но происходит по факту простая штука - государство расширило перечень средств которые как оно считает относятся к орудия совершения преступления.
Как всегда никого не предупредив, внезапно.
PS: не то чтобы я это одобрял, но так государства устроены.
PPS: Вот например как это устроено с отмычками https://denis589.livejournal.com/3202.html
У меня так. Все равно двигаться надо. после 47-и и короновирусного карантина таки 5 кг пуза отросло. Я к тому, что магии нет, но некоторым действительно много проще. Обычно это идет в комплекте с врожденным гастритом.
Я прочитал как "надо стараться не помогает", а надо умно построить систему мотивации которая бы убрала из похудения элемент превознемогания.
ну я скажу и да и и нет. С одной стороны действительно всего не угадаешь. Хотя и надо стараться учесть все, что можно учесть. С другой стороны внезапно все системы довольно похожи друг на друга и большая часть проектов укладывается в несколько десятков типовых архитектур с типовыми же проблемами. По крайней мере это верно для новых проектов.
При рефакторинге старых систем все несколько сложнее. Там в коде 10-20 летней давности может быть зарыто что-то очень экзотическое.
Но повторюсь - с новыми системам набор типовых архитектур не так уж велик.
Скажем говорит заказчик - я хочу mobile-only соц сеть где пользователи будут постить картинки с геолокацией и назначать календарные события к будущим эвентам. Список вопросов по NFR и ключевых элементов решения можно за час нарисовать. И за несколько дней дообсуждать до состояния когда можно прям начинать кодить. 95% граблей на этой тропинке за нас уже собрано.
UPD т..е понятно, что какая-то дичь все равно всплывет, но надо стараться на этапе проектирования процент дичи минимизировать.
У меня было ровно обратно. Узд правления всегда заметно больше чем хочется и приходится часть из этих рычагов акуратно выдвать людям которые более или менее в адеквате.
Но я понимаю, что это сильно зависит от рабочего контекста. Подозреваю, что как раз в больших копорациях роль архитектора может быть сильно лимитирована.
Хотя я видел как это сделано в одном из проектов и там вроде как архитектор вполне обладал исполнительной властью.
Блин да что там говоить. В прошлом проекте я "уволил" тим лида одной из команд заказчика за некомпетентность.
Именно так. К счастью пока мне удавалось работать в проектах где говорят "Ну нам надо спроектировать арихитектуру и надо чтобы ты потом 2-3 месяца с нами был и потом хотя бы 2 часа в день присматривал".
Но я понимаю, что это далеко не вся наблюдаемая вселенная.
Или вот 30 мин назад - смотрю в чате разработчики планируют использовать спринговую аннотацию @DependsOn - это прям плохой знак. Звонюсь с командой, выясняю для чего они хотят это сделать, объясняю как работат в этом месте спринг, надобность в @DependsOn отпадает.
Если бы я их за руку не поймал бы, то это бы всплыло только в процессе ревью PR, а учитывая, что не каждый PR я просмотриваю, все же это работа лида - это могло всплыть через значительное время какой-то странной проблемой.
Мне кажется тут сильно зависит от компании. В моей практике всегда было так, что роль архитектора ходит по краю с ролью engineering менеджера, который отвественен вообще за все.
Ну просто не понятно - вот я чувак с 25+ годами опыта, нарисовал архитектуру которая не может сфэлится и спокойно сижу и смотрю как группа товарищией упорно ведет проект на кладбище.
Можно конечно сказать, что к архитектуре вопросов нет, я весь в белом. Но пофакту граница очень размыта.
Не знаю, мой опыт говорит, что когда что-то пошло не так, не важно кто предложил и как оно там все было политически сделано. Фэйл есть фэйл.
Спасибо
>Нас всех учат не выносить сор из избы. В текущем мире, если будешь рассказывать о проблемах, то тебя запишут в токсики.
Построение архитектуры решения практически единственное место, где можно говорить о проблемах. Ну и потом, я же не для западного ресурса статью пишу. На английский язык проблема переводится как challenge
>А где техлиды, старшие и ведущие разработчики, которые и отвечают за качество реализации?
Вот и у меня такой же вопрос. Если серьезно на него есть два ответа, выбирайте какой больше нравится
в FAANG-ах
На самом деле, когда система достаточно большая, невозможно объять ее всю и если у тебя в руках молоток, то много какие части системы видятся как гвоздь. Перефразируя из разных ролей картинка немного разная и задача архитектора смотреть на задачу широко. У тех лидов и старших разработчиков задачи другие и взгляд несколько другой
Опишу случай из предыдущего проекта. Приложение в числе прочего может редактировать контакты, денормализованые данные должны асинхронно посылаться через Кафку в другой сервис который делает другая команда. Мы с ними вроде как это проговаривали и все должно быть норм.
Делаю кусок в 40 строк кода который обогащает поля контакта перед сохранением. Начинаю тестировать. Выясняется, что соседняя команда которая это делала полный цикл end-to-end не прогоняла. Хотя по идее должна бы, но их это почему-то не беспокоит и вообще им некогда. Начинаю выяснять почему так и как мне end-to-end сделать, выясняется, что конктракт на формат записи постоянно мутирует, контракт живет в библиотеке и она меняется два раза на день, разработчики это знают, но наверх это не идет, иду выяснять, отчего все мутирует, выясняется, что данные там лежат в Элесадре (https://www.elassandra.io) и там "есть проблемы".
Дальше в общем начинается нормальная работа с выяснением где искрит и вообще что за фигня. Но до момента, пока я не залез в код - все упорно молчали по разным причинам.