При чем тут документация? Речь о спецификации результата и код тут единственно возможный вариант. Точно так же как из чертежа бывает сложно понять, что это за деталь и зачем она нужна, так же и из кода бывает сложно понять что он делает и зачем. Это нормально.
Во-первых, все очень просто. Если код непонятен — это либо хреновый код, либо неподготовленный читатель. Понятный код — это внятные абстракции и простые связи между ними. Если это соблюдается — любой код читать относительно просто, если нет — проблема в консерватории. Бывают исключения, связанные с теми или иными ограничениями (перфоманс, недостатки инструментов и языков etc), но никакие UML диаграммы тут не помогут. Тот же "визитор" — это лишь всего-лишь костыль, обходящий недостаточную выразительность языка, который на уровень проектирования совершенно непонятно зачем выносить.
Во-вторых, контекст — это бизнес-требования. UML — всего лишь графическое отображение принятых на основе этих требований в какой-то момент решений и сам по себе несет не больше (а меньше) контекста, чем написанный программный код. В UML еще труднее вписать зачем и почему, чем непосредственно в код. В коде можно хоть на два листа комментариев написать, а в диаграммах длинные комментарии превратятся в совершенно нечитаемую хрень.
На самом деле повсеместно встречаются отели, пытающиеся нагнуть таким образом букинг. Встречались и в России, и в Турции, и в Латинской Америке, и даже в Европе. Обычно небольшие, конечно.
То, что современный продукт ради того, чтобы показать анимацию, поле ввода и кнопочку тянет в себя гигабайт разнообразных фреймворков, не делает его сложным.
Ну если у вас продукт только и делает, что показывает кнопочку, то, конечно, да. Впрочем 20 лет назад и показать кнопочку с анимацией было не то чтобы просто, кажется.
Почитайте, например, документацию на Реакт, а потом поройтесь в его исходниках. Уверен, вы почувствуете разницу.
Нет никакой деградации. Типичный современный продукт на порядки сложнее и технологичнее, чем 20 лет назад.
Нас разбаловало то, что в нашем уютном мирке инфотеха мы можем нажать кнопочку, и заплатка разлетится миллионам пользователей. В "большом" мире всё сложнее. Отзыв миллиона автомобилей это капец как муторно и дорого. Проще лишний человекомесяц потратить на проектирование, а потом ещё один на испытания.
Что-то криво раскатав в каком-нибудь гугле-фейсбуке можно "при удаче" за час потерять денег куда больше, чем в любой компании по отзыву автомобилей.
Это как если бы в материальном производстве ушли чертежи. Петровичу не нужны ни кульман, ни САПР. У него опыт и сварочный аппарат.
Чертеж в материальном производстве — это часть спецификации. У нас основная спецификация — это код. Любые диаграммы — не больше, чем пояснительные записки. Код никуда не ушел. Инструменты работы с кодом стали на порядки лучше и оказалось, что "пояснительные записки" стали гораздо менее нужны. В материальном производстве то же самое. Работать с САПР удобнее, чем с бумажными чертежами
Нет, конечно. Так не делают. В любой нормально спроектированной инженерной системе, неважно софтварной или хардварной, есть изоляция сущностей инкапсуляция. Изменение в креплении глушителя, если машина нормально спроектирована, потребует минимума расчетов в районе точек крепления и все. Причем сейчас 99% этих расчетов будут сделаны автоматизированно в каком-нибудь сапре и в железо пойдет уже готовое или почти готовое изделие, с которым придется пройти только минимальный набор тестов. Никто и никогда при небольших изменениях требований не переделывает весь проект.
Это тоже, ну такое… дорогой в ад попахивает, в 2000-ые у нас уже были, например, perl и cpan, где были пакеты для чего угодно. Но это другой вопрос.
UML, когда он используется без фанатизма и излишней формализации, не плох как универсальный язык для общения, записи каких-то идей, но проектировать систему от и до — это явный перебор.
Легаси ад будет в любом случае, тк диаграмки перестают соответствовать реальности еще на этапе их имплементации. А к моменту, когда они действительно понадобились, через X лет, они представляют исключительно исторических интерес и к действительности не имеют ни малейшего отношения. Наблюдал неоднократно. Тут комментарии в коде мгновенно становятся не актуальными и теряют смысл, а вы хотите, чтобы артефакт лежащие отдельно от кода и никак с ним не верифицируемые, были хоть зачем-то полезны.
Пример про рисование диаграмок на протяжении нескольких лет без создания реального продукта — это не голые слова, а печальные реалии многочисленных проектов периода расцвета uml (~2000-ые). Все движение в аджайл возникло не на пустом месте. Людям нужен был продукт, а не набор артефактов в розе и тп продуктах
Вместо того, чтобы продумывать процессы в системе, её набрасывают в общих чертах (так, нам нужна БД, резервная БД, бэк на ноде, потому что мы её умеем, и редиску не забыть) — и сразу бросаются делать MVP. А поскольку все компоненты из проекта в проект одинаковые, то это всё «само собой» соединяется.
Точно, раньше же круче было. Можно было два года рисовать диаграмки, только для того, чтобы понять, что требования давно изменились, да и сам продукт потерял актуальность.
Мины и ракеты с автоматической с селекцией целей разрабатывали и, возможно, применяли еще с 80-ых годов. Принципиальной разницы между пульнуть ракету в сторону, где предположительно находятся корабли противника, чтобы она выбрала там цель пожирнее, и дроном, висящем над полем боя и высматривающим цели подходящие под определенные параметры, кажется нет.
Ага, давайте еще женщин на работу не брать, а то вдруг в декрет уйдут.
Я видел довольно много людей в возрасте и с лишним весом, которые были гораздо производительнее молодых и подтянутых. Да меня и самого кто-то может в такую категорию запихнуть.
Любой криво заданный вопрос может стать юридической проблемой. Не говоря уж о духе закона и общепринятой этике, которые одназначно говорят о недопустимости дискриминации по вышеупомянутым факторам.
Вы не со мной спорите, а с трудовым кодексом. Задавая такие вопросы вы рискуете получить юридически проблемы различной степени серьезности, причем далеко не только в России.
После найма уже. Семейное положение, раса, пол, здоровье, образ жизни, отношение к воинской обязанности и все остальное, что напрямую не влияет на способность человека выполнять работу, никак не должны влиять на принятие решений о найме со стороны работодателя. Дискриминация по этим признакам прямо нарушает ТК РФ.
Если компания российская, то вместо контракта достаточно, чтобы она нормально соблюдала ТК РФ. Другое дело, что во многих айтишных компаниях время работы никто не считает и может сложиться как культура переработок, так и культура "недоработок". Причем даже в рамках одной компании все может быть по-разному в разных командах.
Я в этом практически ничего не понимаю, но вот этот фрагмент из вики (и статьи на которых он основан) меня немного смущают https://en.wikipedia.org/wiki/Viral_vector#Challenges_in_application
"Once used, the viral vector cannot be effectively used in the patient again because it will be recognized by the body. If the vaccine or gene therapy fails in clinical trials, the virus can't be used again in the patient for a different vaccine or gene therapy in the future."
У меня вот вопрос к используемым аденовирусам. Не является ли подобный подход к конструированию вакцин одноразовым? Прививки ведь получается, по идее, формируют иммунитет не только относительно коронавируса, но и используемого вектора? И тогда, когда в следующий раз понадобится вакцина, возможно от чего-нибудь более опасного, чем коронавирус, не окажется ли, что мы все хорошо исследованные и безопасные векторы растратили?
Я со всем согласен, кроме пожалуй ощущения про разницу в ЗП
Ну пожалуй наверное индивидуально, да. Но для меня было ровно так.
Возможно потому, что большая часть перечисленного уже есть, возможно потому, что когда живешь семьей, все такие вещи амортизируются и считаешь уже от совокупного семейного дохода.
ну то что маркет это ад это давно изветсно. это не значит что везде АД
А в чем ад то? Ну вот у меня первые впечатления (за чуть более полугода), что не соответствует ожиданиям в каких-то вещах. Но это скорее проблемы с моими личными ожиданиями. А в остальном — нормальная компания. Есть с чем сравнивать за 20+ лет карьеры.
При чем тут документация? Речь о спецификации результата и код тут единственно возможный вариант. Точно так же как из чертежа бывает сложно понять, что это за деталь и зачем она нужна, так же и из кода бывает сложно понять что он делает и зачем. Это нормально.
Во-первых, все очень просто. Если код непонятен — это либо хреновый код, либо неподготовленный читатель. Понятный код — это внятные абстракции и простые связи между ними. Если это соблюдается — любой код читать относительно просто, если нет — проблема в консерватории. Бывают исключения, связанные с теми или иными ограничениями (перфоманс, недостатки инструментов и языков etc), но никакие UML диаграммы тут не помогут. Тот же "визитор" — это лишь всего-лишь костыль, обходящий недостаточную выразительность языка, который на уровень проектирования совершенно непонятно зачем выносить.
Во-вторых, контекст — это бизнес-требования. UML — всего лишь графическое отображение принятых на основе этих требований в какой-то момент решений и сам по себе несет не больше (а меньше) контекста, чем написанный программный код. В UML еще труднее вписать зачем и почему, чем непосредственно в код. В коде можно хоть на два листа комментариев написать, а в диаграммах длинные комментарии превратятся в совершенно нечитаемую хрень.
На самом деле повсеместно встречаются отели, пытающиеся нагнуть таким образом букинг. Встречались и в России, и в Турции, и в Латинской Америке, и даже в Европе. Обычно небольшие, конечно.
Ну если у вас продукт только и делает, что показывает кнопочку, то, конечно, да. Впрочем 20 лет назад и показать кнопочку с анимацией было не то чтобы просто, кажется.
Может быть это просто плохой пример?
Нет никакой деградации. Типичный современный продукт на порядки сложнее и технологичнее, чем 20 лет назад.
Что-то криво раскатав в каком-нибудь гугле-фейсбуке можно "при удаче" за час потерять денег куда больше, чем в любой компании по отзыву автомобилей.
Чертеж в материальном производстве — это часть спецификации. У нас основная спецификация — это код. Любые диаграммы — не больше, чем пояснительные записки. Код никуда не ушел. Инструменты работы с кодом стали на порядки лучше и оказалось, что "пояснительные записки" стали гораздо менее нужны. В материальном производстве то же самое. Работать с САПР удобнее, чем с бумажными чертежами
Нет, конечно. Так не делают. В любой нормально спроектированной инженерной системе, неважно софтварной или хардварной, есть
изоляция сущностейинкапсуляция. Изменение в креплении глушителя, если машина нормально спроектирована, потребует минимума расчетов в районе точек крепления и все. Причем сейчас 99% этих расчетов будут сделаны автоматизированно в каком-нибудь сапре и в железо пойдет уже готовое или почти готовое изделие, с которым придется пройти только минимальный набор тестов. Никто и никогда при небольших изменениях требований не переделывает весь проект.Это тоже, ну такое… дорогой в ад попахивает, в 2000-ые у нас уже были, например, perl и cpan, где были пакеты для чего угодно. Но это другой вопрос.
UML, когда он используется без фанатизма и излишней формализации, не плох как универсальный язык для общения, записи каких-то идей, но проектировать систему от и до — это явный перебор.
Легаси ад будет в любом случае, тк диаграмки перестают соответствовать реальности еще на этапе их имплементации. А к моменту, когда они действительно понадобились, через X лет, они представляют исключительно исторических интерес и к действительности не имеют ни малейшего отношения. Наблюдал неоднократно. Тут комментарии в коде мгновенно становятся не актуальными и теряют смысл, а вы хотите, чтобы артефакт лежащие отдельно от кода и никак с ним не верифицируемые, были хоть зачем-то полезны.
Пример про рисование диаграмок на протяжении нескольких лет без создания реального продукта — это не голые слова, а печальные реалии многочисленных проектов периода расцвета uml (~2000-ые). Все движение в аджайл возникло не на пустом месте. Людям нужен был продукт, а не набор артефактов в розе и тп продуктах
Точно, раньше же круче было. Можно было два года рисовать диаграмки, только для того, чтобы понять, что требования давно изменились, да и сам продукт потерял актуальность.
Мины и ракеты с автоматической с селекцией целей разрабатывали и, возможно, применяли еще с 80-ых годов. Принципиальной разницы между пульнуть ракету в сторону, где предположительно находятся корабли противника, чтобы она выбрала там цель пожирнее, и дроном, висящем над полем боя и высматривающим цели подходящие под определенные параметры, кажется нет.
Ага, давайте еще женщин на работу не брать, а то вдруг в декрет уйдут.
Я видел довольно много людей в возрасте и с лишним весом, которые были гораздо производительнее молодых и подтянутых. Да меня и самого кто-то может в такую категорию запихнуть.
Любой криво заданный вопрос может стать юридической проблемой. Не говоря уж о духе закона и общепринятой этике, которые одназначно говорят о недопустимости дискриминации по вышеупомянутым факторам.
Вы не со мной спорите, а с трудовым кодексом. Задавая такие вопросы вы рискуете получить юридически проблемы различной степени серьезности, причем далеко не только в России.
Выгорать не обязательно — мало ли еще какие причины для посещения могут быть.
Ну я не ходил, но там прям с нормальным медицинским образованием вроде. Еще в ДМС психолог тоже включен, если почему-то офисные не устраивают.
После найма уже. Семейное положение, раса, пол, здоровье, образ жизни, отношение к воинской обязанности и все остальное, что напрямую не влияет на способность человека выполнять работу, никак не должны влиять на принятие решений о найме со стороны работодателя. Дискриминация по этим признакам прямо нарушает ТК РФ.
В Яндексе, например, есть штатные психологи. Да и в Мейле кажется тоже.
Если компания российская, то вместо контракта достаточно, чтобы она нормально соблюдала ТК РФ. Другое дело, что во многих айтишных компаниях время работы никто не считает и может сложиться как культура переработок, так и культура "недоработок". Причем даже в рамках одной компании все может быть по-разному в разных командах.
Я в этом практически ничего не понимаю, но вот этот фрагмент из вики (и статьи на которых он основан) меня немного смущают https://en.wikipedia.org/wiki/Viral_vector#Challenges_in_application
"Once used, the viral vector cannot be effectively used in the patient again because it will be recognized by the body. If the vaccine or gene therapy fails in clinical trials, the virus can't be used again in the patient for a different vaccine or gene therapy in the future."
У меня вот вопрос к используемым аденовирусам. Не является ли подобный подход к конструированию вакцин одноразовым? Прививки ведь получается, по идее, формируют иммунитет не только относительно коронавируса, но и используемого вектора? И тогда, когда в следующий раз понадобится вакцина, возможно от чего-нибудь более опасного, чем коронавирус, не окажется ли, что мы все хорошо исследованные и безопасные векторы растратили?
Ну пожалуй наверное индивидуально, да. Но для меня было ровно так.
Возможно потому, что большая часть перечисленного уже есть, возможно потому, что когда живешь семьей, все такие вещи амортизируются и считаешь уже от совокупного семейного дохода.
А в чем ад то? Ну вот у меня первые впечатления (за чуть более полугода), что не соответствует ожиданиям в каких-то вещах. Но это скорее проблемы с моими личными ожиданиями. А в остальном — нормальная компания. Есть с чем сравнивать за 20+ лет карьеры.