Иногда случается, что система ведет себя как надо не потому что это поведение заложено программистом, а просто потому что повезло. Побочные эффекты от реализации разных компонентов сложились, и все работает. Как, по-вашему, нужно поступить, чтобы в будущем эта особенность не исчезла? Написать компонент, который будет выполнять ненужную работу, чтобы гарантировать результат? Оставить все как есть и добавить юнит-тест?
В качестве иллюстрации приведу пример, который и заставил меня задуматься. Игрался с книжкой SICP. Представляем рациональное число в виде пары целых — числителя и знаменателя, и пишем программы для арифметики над этими числами. Потом серия улучшений — сокращение дроби при конструировании и нормализация знака — чтобы числитель и знаменатель не были отрицательными одновременно, и если дробь отрицательная, знак "минус" должен быть только у числителя. Я обнаружил, что нормализация не понадобилась — при сокращении дроби знак очень удачно оставался только там, где надо, хотя при разработке такой задачи не ставилось. Вот я и вспомнил — в реальном проекте такое тоже случается, и обычно все просто забивают — прислал заказчик ФТ, или мне в голову пришло, что неплохо бы обеспечить — а все уже и так есть. Работает — не трожь. Нутром чую, что плохой подход, а доказать не могу.
Здравствуйте, arv, Вы писали:
arv>Оставить все как есть и добавить юнит-тест?
ИМХО да. Если имеющийся алгоритм автоматически обеспечивает требуемое поведение, то расфигачивать его лишь ради того, чтобы на уровне исходного кода акцентировать факт наличия требования, глупо. Юнит-тест + я бы может в doc-каменты к алгоритму добавил.
arv>Иногда случается, что система ведет себя как надо не потому что это поведение заложено программистом, а просто потому что повезло. Побочные эффекты от реализации разных компонентов сложились, и все работает. Как, по-вашему, нужно поступить, чтобы в будущем эта особенность не исчезла? Написать компонент, который будет выполнять ненужную работу, чтобы гарантировать результат? Оставить все как есть и добавить юнит-тест?
Оставить как есть, и написать юнит тест Тогда точно можно будет узнать, когда эта особенность поломалась.
Здравствуйте, arv, Вы писали: arv>Иногда случается, что система ведет себя как надо не потому что это поведение заложено программистом, а просто потому что повезло. Побочные эффекты от реализации разных компонентов сложились, и все работает. Как, по-вашему, нужно поступить, чтобы в будущем эта особенность не исчезла? Написать компонент, который будет выполнять ненужную работу, чтобы гарантировать результат? Оставить все как есть и добавить юнит-тест?
Думаю, если есть возможность то лучше исследовать причины непредусмотренного поведения и сделать его предусмотренным(дабы потом не аукнолось ), если такой возможности нет — тесты.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, arv, Вы писали:
arv>Иногда случается, что система ведет себя как надо не потому что это поведение заложено программистом, а просто потому что повезло. Побочные эффекты от реализации разных компонентов сложились, и все работает. ...
Давно обнаружил аналогичный эффект, если тестировать (проверять) не свойства модулей, функций, классов и т.п. а инварианты преобразования этих модулей, функций, классов и т.п., то побочные эффекты возникают повсеместно. Даже название придумал – странный эффект самокомпенсации ошибок. Тестирование обычным образом только мешают этому эффекту, т.е. если не знаете что есть инвариант при преобразовании или не знаете как его проверить, то лучше тестировать программу только своими мозгами читая листинг и запрещая себе отлаживать программу устанавливая точки останова и любые другие тесты. При этом эффект возникает систематически, а не пару раз за карьеру программиста.
Сложность тут в необходимости построения полного множества преобразований программы, поскольку это совсем не то, чем занимается программист каждый день. Но зато появляется возможность исследовать этот и другие странные эффекты.
arv>Иногда случается, что система ведет себя как надо не потому что это поведение заложено программистом, а просто потому что повезло.
Гораздо хуже случается когда полезный задуманный эффект или хотя бы отсутствие функциональных проблем получается в результате взаимодействия багов. Потом какой нить Баг фиксят (в процессе рефакторинга или потому что его нашли по какой то мелочи) — вылазят все остальные, "комплементарные" ему — получаем целый букет проблем в продукте. Я думаю стоит поработать над волновой теорией багов. Интерференция, дифракция.. Да и кванты тут применимы: соотношение неопределенности, суперпозиция вероятностей состояний..
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
arv>>Я думаю стоит поработать над волновой теорией багов. Интерференция, дифракция.. Да и кванты тут применимы: соотношение неопределенности, суперпозиция вероятностей состояний..
Неа. Нет закономерностей. Электрон всегда пролетает сразу через две щели, а как вы будете гарантировать постоянное соблюдение соотношение неопределенности, суперпозиция вероятностей состояний для багов?
Ведь главное то как раз в воспроизводимых результатах, а не просто комуто почудилось или красивое слово знает вот и захотелось поиграться с понятиями. Нету в ошибках программиста закономерностей .несмотря на то что нам так хочеться прикрутить сюда неопределенность волновые функции и бог его знает что еще.
arv>>>Я думаю стоит поработать над волновой теорией багов. Интерференция, дифракция.. Да и кванты тут применимы: соотношение неопределенности, суперпозиция вероятностей состояний.. V>Неа. Нет закономерностей. Электрон всегда пролетает сразу через две щели, а как вы будете гарантировать постоянное соблюдение соотношение неопределенности, суперпозиция вероятностей состояний для багов? Ведь главное то как раз в воспроизводимых результатах,
электрона нет, есть лишь поле-облако вероятностей где он _может_быть_, которое описывается волновой функцией де-Бройля, и именно это поле пролетая через две щели, поле-облако меняется, в результате функция вероятности нахождения электрона принимает такой вил, что в конечном итоге он может прилететь в одно из мест на стоящем за ними экране. Может прилететь в одно, а может — в другое. Никакой воспроизводимости понимаешь на малом количестве электронов нету — летят то туда то сюда, а на большом — есть
V>а не просто комуто почудилось или красивое слово знает вот и захотелось поиграться с понятиями. Нету в ошибках программиста закономерностей .несмотря на то что нам так хочеться прикрутить сюда неопределенность волновые функции и бог его знает что еще.
есть-есть любой код среднего полон виртуальных багов как в квантовой пене, просто они тут же взаимодействуют с соседними багами и их не видно :trollface:
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
arv>>>>Я думаю стоит поработать над волновой теорией багов. Интерференция, дифракция.. Да и кванты тут применимы: соотношение неопределенности, суперпозиция вероятностей состояний.. V>>Неа. Нет закономерностей. Электрон всегда пролетает сразу через две щели, а как вы будете гарантировать постоянное соблюдение соотношение неопределенности, суперпозиция вероятностей состояний для багов? Ведь главное то как раз в воспроизводимых результатах, O>электрона нет, есть лишь поле-облако вероятностей где он _может_быть_, которое описывается волновой функцией де-Бройля, и именно это поле пролетая через две щели, поле-облако меняется, в результате функция вероятности нахождения электрона принимает такой вил, что в конечном итоге он может прилететь в одно из мест на стоящем за ними экране. Может прилететь в одно, а может — в другое. Никакой воспроизводимости понимаешь на малом количестве электронов нету — летят то туда то сюда, а на большом — есть
Под воспроизводимостью результатов понимают немного другое. Важно не то, что происходит с электроном, а то, что вы в программировании хотите описать с помощью вероятностей? Возьмите много-много багов и что будет закономерным? Только то, что программисты допускают баги, но на этом теорию не построишь и количественно ничего не измеришь.
V>>а не просто комуто почудилось или красивое слово знает вот и захотелось поиграться с понятиями. Нету в ошибках программиста закономерностей .несмотря на то что нам так хочеться прикрутить сюда неопределенность волновые функции и бог его знает что еще. O>есть-есть любой код среднего полон виртуальных багов как в квантовой пене, просто они тут же взаимодействуют с соседними багами и их не видно :trollface:
А конкретные примеры будут? Или только туманные рассуждения непонятно о чем? Что вы собираетесь измерять? Тем более что если виртуальные (непонятно что это такое) баи самокомпенсируются, то с чего вы взяли что они баги? А вдруг программист так задумал?
Здравствуйте, Vaako, Вы писали:
V>Тем более что если виртуальные (непонятно что это такое) баи самокомпенсируются, то с чего вы взяли что они баги? А вдруг программист так задумал?
(занудство на занудство) Тогда это баг архитектурный.
Здравствуйте, arv, Вы писали:
arv> Я обнаружил, что нормализация не понадобилась — при сокращении дроби знак очень удачно оставался только там, где надо, хотя при разработке такой задачи не ставилось.
Что означает "обнаружил"? Если нет понимания работы алгоритма, то это лишь частное наблюдение. Звучит оно примерно
"На некоторых данных которые я проверял, алгоритм ведет себя вот так". Другими словами , это говорит ровно НИ о чем.
В противном случае вы точно знаете как работает алгоритм или тестируете ВСЕ возможные входные данные. Все остальное лишь ваши фантазии.
Здравствуйте, arv, Вы писали:
arv>Иногда случается, что система ведет себя как надо не потому что это поведение заложено программистом, а просто потому что повезло. Побочные эффекты от реализации разных компонентов сложились, и все работает. Как, по-вашему, нужно поступить, чтобы в будущем эта особенность не исчезла? Написать компонент, который будет выполнять ненужную работу, чтобы гарантировать результат? Оставить все как есть и добавить юнит-тест?
Нужно исследовать свойства функционала, особенно инварианты, и все до единого покрыть юнит тестами. Сдавать в продакшн нужно только в том случае, если понятно, что происходит.
Здравствуйте, minorlogic, Вы писали:
M>Что означает "обнаружил"? Если нет понимания работы алгоритма, то это лишь частное наблюдение. Звучит оно примерно M>"На некоторых данных которые я проверял, алгоритм ведет себя вот так". Другими словами , это говорит ровно НИ о чем.
Нет, конечно. Речь о понятном, изученном и предсказуемом явлении. Какой-то аспект поведения системы обусловлен архитектурой и конкретной реализацией. В таком случае его легко потерять в ходе рефакторинга. Даже комментарий написать негде — функциональность может быть размазана по нескольким компонентам. Получается, единственный вариант, не имеющий очевидных недостатков — добавить юнит-тест. Круто.
M>В противном случае вы точно знаете как работает алгоритм или тестируете ВСЕ возможные входные данные. Все остальное лишь ваши фантазии.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, arv, Вы писали:
arv>> Получается, единственный вариант, не имеющий очевидных недостатков — добавить юнит-тест. Круто.
M>Runtime check можно добавить , или другими словами контракт, или в простанародье assert
assert — лишняя работа в часто используемом коде и не поможет в редко используемом.
Здравствуйте, arv, Вы писали: arv>Нет, конечно. Речь о понятном, изученном и предсказуемом явлении. Какой-то аспект поведения системы обусловлен архитектурой и конкретной реализацией. В таком случае его легко потерять в ходе рефакторинга. Даже комментарий написать негде — функциональность может быть размазана по нескольким компонентам. Получается, единственный вариант, не имеющий очевидных недостатков — добавить юнит-тест. Круто.
Очевидный недостаток теста — он не является решением проблемы "сделать так чтобы багофича не исчезла", он лишь покажет когда она исчезнет. ИМХО лучше сразу перепроектировать программу включив в требования фичю, чем делать это потом когда программа разрастётся в сложности и размере. Необязательно выносить фичю в отделенный компонент, например в вашем случае(с дробями) достаточно до/переписать код сокращения чтобы он, для отрицательных дробей, всегда возвращал минус в числителе.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, arv, Вы писали:
arv>assert — лишняя работа в часто используемом коде
Тут немного не понял, почему лишняя? проверяет внутренний контракт (инвариант) программы. Сразу обнаружит нарушение контракта. Документирует контракт.
arv> и не поможет в редко используемом.
Здравствуйте, arv, Вы писали: arv>Иногда случается, что система ведет себя как надо не потому что это поведение заложено программистом, а просто потому что повезло. Побочные эффекты от реализации разных компонентов сложились, и все работает. Как, по-вашему, нужно поступить, чтобы в будущем эта особенность не исчезла? Написать компонент, который будет выполнять ненужную работу, чтобы гарантировать результат? Оставить все как есть и добавить юнит-тест?
такие вещи часто случаются при частичной инициализации или при корявом изменении состояний обьектов, типа там, поменял только одно поле. нужно просто отходить от корявых методик разработки, везде проставлять дефолтные значения, обьекты инициализировать только в конструкторах и только полностью и состояние их лучше вообще не менять, а создавать на базе его новый.
Тогда точно можно будет узнать, когда эта особенность поломалась.
