Не очень понятно зачем держать в списке NaN, код построеный на таких допущениях кривой уже на уровне архитектуры. Это надо фиксить не на уровне языка. А есть другие примеры кроме NaN? Иначе это может трактоваться как новый способ отстрела ног, то есть теперь вместо сортировки нога отстрелится на попытке деления или чего подобного.
Ну так и писали бы про управление зависимостями, а не про «SE — ремесло без теории». По крайней мере я бы не отвлекался на столь провокационную фразу. Мне особо нечего сказать про управление зависимостями к сожалению, хотя казалось бы общей теории хватает — графы, конечные автоматы, мультиагентные системы. Подтягивай что надо.
Думаю это связано с тем, что комментаторов качество материала не особо волнует. Статья судя по комметариям работает хорошей затравкой для разговоров «на тему».
Что за странное понимание программной инженерии. Там никто рецептами не пользуется. Каждая система и её стейкхолдеры уникальны. Решение всегда строится исходя из требований и ограничений по ресурсам конкретных лиц. Но есть такое понятие как типовые решения, когда можно не изобретать велосипед а переиспользовать что-то, опять же строго в рамках конкретной ситуации. Не понимаю откуда такое настойчивое утверждение про best practices.
Есть SEMAT если про софт. Но в принципе есть общие подходы к инженерии — системная инженерия, iso 15288, CPS framework. Они вполне применимы к программной инженерии в том числе.
Мне неприятно заявление «Все страхи ГМО это глупость», я считаю глупостью заметать под ковер неизвестные риски, а динамические системы с большим количеством переменных всегда имеют риски. Это исходная позиция. Равновесие в этом контексте это про: вы что-то ковыряете в открытой системе, причем с такими масштабами и скоростью, что все части могут не успевать адаптироваться к изменениям. При слишком больших изменениях система просто перескочит в принципиально другое состояние — как с динозаврами — раз и нет динозавров. Аппелирование к животному миру считаю контр-продуктивным, там все проиходит сугубо локально и медленно, все части локальной системы усепвают адаптироваться, а сама система вцелом не меняется. С человеческой стороны мы повысили себе срок жизни, потребляем как никогда раньше, гадим тоже как никогда раньше, у нас все централизовано, если мы вводим что-то, то глобально, сразу по всему шарику, в этом смысле мы уже можем покушаться на скачкообразные системные преобразования. Так как это все рукотворные действия, то и их системный анализ мы должны делать сами под страхом неизвестности, а не полагаться на физику (эволюцию). Физику нам не победить, а вот себя можно.
Это оптимистичный взгляд. Я более пессемистичен ничего там не прорабатывали на уровне системных эффектов ни раньше, ни сейчас. Инженеры редуцируют эффекты к каким-то измеримым параметрам и контролируют их ограниченый набор. Бизнес потом редуцирует проблему к товарно-денежным измеримым параметрам и контролирует этот ограниченый набор. На системные эффекты всем плевать пока что-то плохое не случиться. Но пока наши силы были малы, то с плохим более менее справлялись. Когда начали взрываться атомные станции, стали думать немного больше, но опять же только в соответствующих отраслях. До какого-то серъезного прецедента по ГМО ничего не изменится, будут увеличивать объемы — выгоды очевидны, риски с точки зрения влияния на измеримые величины из анализов крови/биопсий не выявлены. Но с другой стороны — в этом человек, все наше развитие базируется на подобном поведении, правда с масштабом растет риск, что после очередного сбоя мы не сможем уже оправиться.
Клоните к тому, что все нормально, так и должно быть? Обезьянке можно жить сегодняшним днем, значит и человеку можно? Вопрос не в сравнении с другими видами, вопрос в оценке своих действий с точки зрения долгосрочных системных эффектов.
Да, продолжительность нашей жизни выросла, мы стали продуктивнее и гораздо масштабнее изменяем мир вокруг себя. Мы с планетой далеко не в равновесии, и все еще довольно тупы чтоб осознать как это равновесие обеспечить.
Динамические системы с огромными степенями свободы не просты, даже минимальные изменения могут привести к глобальным последствиям. Но ГМО это лишь малая часть истории — также и кроликов в Австралию завозили. Нам не привыкать жалеть о собственной глупости.
Как вы будете воспроизводить эксперимент, если вы говорите на разных языках. Эксперимент сам по себе уже нагружен теорией, поэтому чтоб его провести у вас должны быть «мосты» от одной парадигмы к другой, либо вы просто работаете в той же что и ваш оппонент. Соотвественно физики уже договорились о рабочих объектах — материи и взаимодействии, поэтому прекрасно читают, подготавливают и воспроизводят эксперименты. Никто не лезет патчить ньютоновскую механику эфиром. Про модельки я не понял что имеется ввиду, мат. модель это дело вкуса — в математике все тоже стандартно относительно рабочих объектов и их взаимодействия. P.S. не все еще отгремело — с гравитацией все еще надо разбираться.
Мой комментарий уже устарел, вы там ответили уже: «ну так то внутреннюю документацию да, не имею права разглашать и подписывала документ». Я имел ввиду любую ссылку/информацию для предметного обсуждения, ежегодник / внутренний документ.
Выдайте ссылку, хочеться посмотреть как человек защищается по существу. У инженеров с этим просто — если нет ссылки на «сакральные знания» значит и знаний никаких нет.
Связь геннетики и биофизических процессов в организме сложна сама по себе. Далее связь биохимических процессов и когнитивной-психологической деятельности тоже не из легких. В обоих пока понимания нет (опустим мелкие изолированые эффекты). Я боюсь в режиме черного ящика китайцам понадобятся миллионы подопытных и твердое намерение продолжать после пары миллионов дегенератов.
Не хочу защищать предыдущего комментатора, однако если бы психиатрия разбиралась в причинах заболеваний, то не понадобилось бы делать RDoC, так ведь. И надо еще понять что подразумевается под «причиной» и не путать ее с механизмом. Например «нарушение обмена нейромедиаторов» может выступать и как причина и как механизм в зависимости от того что бы обсуждаем. Если мы говорим почему человеку плохо — то это причина, а если мы говорим о том как человека лечить — то это уже механизм, а причину нарушения все еще надо искать. Я не знаю как там с психологией, но в гинекологии все как раз на этом уровне, механизмы все понимают, а причины нет, врачи максимум проводят заместительные гормональные терапии и советуют молиться, что организм сам догадается перезапуститься. А мне сдается, что психиатрия это гораздо сложнее, чем гинекология.
Физика уже давно перешла на совершенно другой уровень относительно понимания связи субъект/объект. К примеру, чтобы эксперимент воспринимали серъезно требуется воспроизводимость результатов. Автор же утверждает, что психологам/психиатрам такая серъезность чужда, а значит и качество выводов будет соответсвующим. Мне правда не очень понятно, почему автор атакует попытки выработки единой методики. Если проводить параллель с физикой, то единая парадигма там выступает существенным базисом к обеспечению воспроизводимости результатов, а значит и отделению субъекта от объекта.
Мне кажется пока просто не назрела та самая общая парадигма, которая смогла бы описать большую часть явлений и завладеть умами большинства, то есть дисциплина реально в зачаточном состоянии (относительно физики).
Вы вот про это я так понимаю:
1. Люди и взаимодействие важнее процессов и инструментов
2. Работающий продукт важнее исчерпывающей документации
3. Сотрудничество с заказчиком важнее согласования условий контракта
4. Готовность к изменениям важнее следования первоначальному плану
Да, это гораздо более конкретно, люди попытались вычленить то, что по их мнению приносит пользу конечному заказчику и минимизирует работу производственной системы.
Успех этого манифеста заключается в том, что он весьма неплохо мапится на конкретные объекты и процессы реального мира, например многим знакомо, что после фиксации требований и начала работы, заказчика могут послать лесом и в результате выкатить продукт который ему уже не нужен, а оплачивать надо. Присутствуют нужные объекты, субъекты, контекст некоторой бизнес ситуации.
А в случае автора про «качество важнее скорости», кто объект, кто субъект, какая бизнес ситуация, на каком этапе и почему качество вдруг становится важнее скорости, даже на бытовом уровне мы далеко не всегда выбираем качество предпочитая цену. Нужен контекст и более конкретная формулировка боли.
Хотя вцелом не понравилось. Манифест это же про декларацию конкретных ценностей. Тут скорее какие-то мечты относительно того как достигать ценностей, причем безотносительно каких именно, что уже вцелом провал. «делать как надо» это не ценность (кому надо и что надо?). «качество» это сомнительная ценность, тут отсекаются все сколько-нибудь образованные менеджеры, которые знают про треугольник качество-время-бюджет. И что собраются делать со своим манифестом «жесткие программисты» при отсутствии образованых менеджеров? «концепция» вообще не может быть ценностью для программиста, программа может быть написана только по конкретным требованиям (о чем кстати потом и пишется, но логический переход к ценности некой «концепции» опущен, хотя весьма неочевиден).
Автору хорошо бы почитать хотя бы краткие методички о менеджменте, бизнесе (что-нибудь из бережливого производства для понимания природы изменчивости), инженерии (требования, архитектура, валидация для понимания как сейчас учитывается изменчивость) а потом переработать манифест в соответствии с последними достижениями. Мир уже давно страдает от описанных проблем, но простых решений нет, поэтому и безобразия много — делать «хорошо» нужно учиться.
Думаю ноги тут растут не из «фуллстек» историй. Последнее время agile техники все больше набируют обороты, а там одна из ключевых характеристик, что команда несет коллективную ответственность за продукт и имеет постоянное обсуждение функционального состава продукта. То есть разработчики вникают в истории использования продукта. Это не отменяет специализацию, на уровне разбиения функциональности на задачи, сами задачи уже «улетают» согласно компетенциям.
Нет. Основная задача ТП это выяснить у пользователя все обстоятельства...
Все равно что сказать, что задача повара нарезать травы и залить майонезом. Вроде и правильно, но нет, теряете из рассмотрения суть. Если смотреть конкретно по мейджорам EDA, то сотрудник поддержки отвечает за понимание флоу заказчика и выражение его интересов, он кстати и за внутреннюю приемку отвечает. И если он принял, а заказчик нет, то это его косяк. То есть это именно то о чем я говорю — он носитель интересов заказчика, его цель в том чтоб флоу заказчика работал. И это момент принципиальный, это позволяет компании сохранять связь с реальностью. А уж открытие тикетов, звонки про обстоятельства, согласование сроков это инструменты реализации его позиции, а не самостоятельные действия.
Динамические системы с огромными степенями свободы не просты, даже минимальные изменения могут привести к глобальным последствиям. Но ГМО это лишь малая часть истории — также и кроликов в Австралию завозили. Нам не привыкать жалеть о собственной глупости.
Мне кажется пока просто не назрела та самая общая парадигма, которая смогла бы описать большую часть явлений и завладеть умами большинства, то есть дисциплина реально в зачаточном состоянии (относительно физики).
Вы вот про это я так понимаю:
1. Люди и взаимодействие важнее процессов и инструментов
2. Работающий продукт важнее исчерпывающей документации
3. Сотрудничество с заказчиком важнее согласования условий контракта
4. Готовность к изменениям важнее следования первоначальному плану
Да, это гораздо более конкретно, люди попытались вычленить то, что по их мнению приносит пользу конечному заказчику и минимизирует работу производственной системы.
Успех этого манифеста заключается в том, что он весьма неплохо мапится на конкретные объекты и процессы реального мира, например многим знакомо, что после фиксации требований и начала работы, заказчика могут послать лесом и в результате выкатить продукт который ему уже не нужен, а оплачивать надо. Присутствуют нужные объекты, субъекты, контекст некоторой бизнес ситуации.
А в случае автора про «качество важнее скорости», кто объект, кто субъект, какая бизнес ситуация, на каком этапе и почему качество вдруг становится важнее скорости, даже на бытовом уровне мы далеко не всегда выбираем качество предпочитая цену. Нужен контекст и более конкретная формулировка боли.
Хотя вцелом не понравилось. Манифест это же про декларацию конкретных ценностей. Тут скорее какие-то мечты относительно того как достигать ценностей, причем безотносительно каких именно, что уже вцелом провал. «делать как надо» это не ценность (кому надо и что надо?). «качество» это сомнительная ценность, тут отсекаются все сколько-нибудь образованные менеджеры, которые знают про треугольник качество-время-бюджет. И что собраются делать со своим манифестом «жесткие программисты» при отсутствии образованых менеджеров? «концепция» вообще не может быть ценностью для программиста, программа может быть написана только по конкретным требованиям (о чем кстати потом и пишется, но логический переход к ценности некой «концепции» опущен, хотя весьма неочевиден).
Автору хорошо бы почитать хотя бы краткие методички о менеджменте, бизнесе (что-нибудь из бережливого производства для понимания природы изменчивости), инженерии (требования, архитектура, валидация для понимания как сейчас учитывается изменчивость) а потом переработать манифест в соответствии с последними достижениями. Мир уже давно страдает от описанных проблем, но простых решений нет, поэтому и безобразия много — делать «хорошо» нужно учиться.
Все равно что сказать, что задача повара нарезать травы и залить майонезом. Вроде и правильно, но нет, теряете из рассмотрения суть. Если смотреть конкретно по мейджорам EDA, то сотрудник поддержки отвечает за понимание флоу заказчика и выражение его интересов, он кстати и за внутреннюю приемку отвечает. И если он принял, а заказчик нет, то это его косяк. То есть это именно то о чем я говорю — он носитель интересов заказчика, его цель в том чтоб флоу заказчика работал. И это момент принципиальный, это позволяет компании сохранять связь с реальностью. А уж открытие тикетов, звонки про обстоятельства, согласование сроков это инструменты реализации его позиции, а не самостоятельные действия.