Сообщение Re[83]: Годами не могу вырваться из некорректных вопросов на от 30.05.2020 10:13
Изменено 30.05.2020 10:32 Pauel
Re[87]: Годами не могу вырваться из некорректных вопросов на
Здравствуйте, Codealot, Вы писали:
I>>У Фаулера нет указания, какие проверки.
C>Зато у тебя есть. Цитирую еще раз, для самых-самых сообразительных: "Любые внешние провеки, в любом количестве."
Ты выдрал фразу из контекста. Проверка, тест это твоё адекватное или не очень ожидание. Вроде бы понятно, что инженерия это именно про адекватные ожидания
Как установить адекватность — используя требования. По моему это настолько очевидно, что упоминать лишний раз необязательно.
Тем не менее, см. пример в конце.
C>А любые — это может включать в себя и такие вещи, как микроскопические изменение в таймингах, например.
Попробуй прочесть целиком, а не только первую фразу.
Степень соответствия качеству никто не отменял. Я уже говорил, что 100% соответствие не существует. Ты продолжаешь это все игнорировать.
Есть исключения — локальные переименования. Все остальное прямо или косвенно влияет на генерируемый код. Это исключение непринципиально, т.к. к нему невозможно свести произвольный рефакторинг. А следовательно в общем случае и у тебя всегда будут изменения на уровне генерируемоего кода.
Всегда будут изменения это значит, что их всегда можно отыскать тем или иным способом. Эта часть понятна?
Тут ты обычно заканчиваешь читать и пишешь очередной опус.
1 См выше — степень соответствия качеству никогда не бывает 100%. Соответственно, граница рафакторинг-нерефакторинг определяется именно этой степенью соответствия.
2 Есть требования — фукнциональные и нефункциональные, в т.ч. неявные.
Пример — ты написал тест, где, скажем, явно проверяется тип аргументов функции sort, и тест явно задает ограничение что де параметр один и это массив.
Изменение в коде — компаратор, который будет дополнительным параметром.
Итого — тест сломан!
КАААААК! ЭТО НЕ РЕФАКТОРИНГ!!!!! ТЫ САМ СКАЗАЛ!!!!!!1111 ТЫ ВРЁШЬ!!!расрасрас
Как понять — из требований. Например, в код числодробилки иногда приходится узкое место оптимизировать, скажем, при помощью инлайна функции, колбека, компаратора, и тд.
Заинлайнил — есть нужный перформанс, работает. Не заинлайнил — нет перформанса, не работает.
Итого — микроскопические изменения отражены в требованиях? Если да, от ожидания адеватные. Если нет — то ожидания неадекватные.
I>>У Фаулера нет указания, какие проверки.
C>Зато у тебя есть. Цитирую еще раз, для самых-самых сообразительных: "Любые внешние провеки, в любом количестве."
Ты выдрал фразу из контекста. Проверка, тест это твоё адекватное или не очень ожидание. Вроде бы понятно, что инженерия это именно про адекватные ожидания
Тем не менее, см. пример в конце.
C>А любые — это может включать в себя и такие вещи, как микроскопические изменение в таймингах, например.
Степень соответствия качеству никто не отменял. Я уже говорил, что 100% соответствие не существует. Ты продолжаешь это все игнорировать.
Есть исключения — локальные переименования. Все остальное прямо или косвенно влияет на генерируемый код. Это исключение непринципиально, т.к. к нему невозможно свести произвольный рефакторинг. А следовательно в общем случае и у тебя всегда будут изменения на уровне генерируемоего кода.
Всегда будут изменения это значит, что их всегда можно отыскать тем или иным способом. Эта часть понятна?
Тут ты обычно заканчиваешь читать и пишешь очередной опус.
1 См выше — степень соответствия качеству никогда не бывает 100%. Соответственно, граница рафакторинг-нерефакторинг определяется именно этой степенью соответствия.
2 Есть требования — фукнциональные и нефункциональные, в т.ч. неявные.
Пример — ты написал тест, где, скажем, явно проверяется тип аргументов функции sort, и тест явно задает ограничение что де параметр один и это массив.
Изменение в коде — компаратор, который будет дополнительным параметром.
Итого — тест сломан!
КАААААК! ЭТО НЕ РЕФАКТОРИНГ!!!!! ТЫ САМ СКАЗАЛ!!!!!!1111 ТЫ ВРЁШЬ!!!расрасрас
Как понять — из требований. Например, в код числодробилки иногда приходится узкое место оптимизировать, скажем, при помощью инлайна функции, колбека, компаратора, и тд.
Заинлайнил — есть нужный перформанс, работает. Не заинлайнил — нет перформанса, не работает.
Итого — микроскопические изменения отражены в требованиях? Если да, от ожидания адеватные. Если нет — то ожидания неадекватные.
Re[83]: Годами не могу вырваться из некорректных вопросов на
Здравствуйте, Codealot, Вы писали:
I>>У Фаулера нет указания, какие проверки.
C>Зато у тебя есть. Цитирую еще раз, для самых-самых сообразительных: "Любые внешние провеки, в любом количестве."
Ты выдрал фразу из контекста. Проверка, тест это твоё адекватное или не очень ожидание. Вроде бы понятно, что инженерия это именно про адекватные ожидания
Как установить адекватность — используя требования. По моему это настолько очевидно, что упоминать лишний раз необязательно.
Тем не менее, см. пример в конце.
C>А любые — это может включать в себя и такие вещи, как микроскопические изменение в таймингах, например.
Попробуй прочесть целиком, а не только первую фразу.
Степень соответствия качеству никто не отменял. Я уже говорил, что 100% соответствие не существует. Ты продолжаешь это все игнорировать.
Есть исключения — локальные переименования и некоторые другие подобного рода. Все остальное прямо или косвенно влияет или на генерируемый код, или на код, который уже написан. Это исключение непринципиально, т.к. к нему невозможно свести произвольный рефакторинг. А следовательно в общем случае и у тебя всегда будут изменения на уровне генерируемоего кода.
Всегда будут изменения это значит, что их всегда можно отыскать тем или иным способом. Эта часть понятна?
Тут ты обычно заканчиваешь читать и пишешь очередной опус.
1 См выше — степень соответствия качеству никогда не бывает 100%. Соответственно, граница рафакторинг-нерефакторинг определяется в т.ч. именно этой степенью соответствия.
2 Есть требования — фукнциональные и нефункциональные, в т.ч. неявные.
Пример — ты написал тест, где, скажем, явно проверяется тип аргументов функции sort, и тест явно задает ограничение что де параметр один и это массив.
Изменение в коде — компаратор, который будет дополнительным параметром.
Итого — тест сломан!
КАААААК! ЭТО НЕ РЕФАКТОРИНГ!!!!! ТЫ САМ СКАЗАЛ!!!!!!1111 ТЫ ВРЁШЬ!!!расрасрас
Как понять — из требований. Например, в код числодробилки иногда приходится узкое место оптимизировать, скажем, при помощью инлайна функции, колбека, компаратора, и тд.
Заинлайнил — есть нужный перформанс, работает. Не заинлайнил — нет перформанса, не работает.
Итого — микроскопические изменения отражены в требованиях? Если да, от ожидания адеватные. Если нет — то ожидания неадекватные.
Аналогичный пример с твоими таймингами. Ожидания адекватные? Тогда красный тест говорит о том, что изменения ломающие. Неадекватные — ничего не говорит.
Теперь добавляем сюда степень соответсвия. Самое главное — внятно обозначить её. Тогда получится не "любое изменение таймингов" а "изменение таймингов выше уровня х"
I>>У Фаулера нет указания, какие проверки.
C>Зато у тебя есть. Цитирую еще раз, для самых-самых сообразительных: "Любые внешние провеки, в любом количестве."
Ты выдрал фразу из контекста. Проверка, тест это твоё адекватное или не очень ожидание. Вроде бы понятно, что инженерия это именно про адекватные ожидания
Тем не менее, см. пример в конце.
C>А любые — это может включать в себя и такие вещи, как микроскопические изменение в таймингах, например.
Степень соответствия качеству никто не отменял. Я уже говорил, что 100% соответствие не существует. Ты продолжаешь это все игнорировать.
Есть исключения — локальные переименования и некоторые другие подобного рода. Все остальное прямо или косвенно влияет или на генерируемый код, или на код, который уже написан. Это исключение непринципиально, т.к. к нему невозможно свести произвольный рефакторинг. А следовательно в общем случае и у тебя всегда будут изменения на уровне генерируемоего кода.
Всегда будут изменения это значит, что их всегда можно отыскать тем или иным способом. Эта часть понятна?
Тут ты обычно заканчиваешь читать и пишешь очередной опус.
1 См выше — степень соответствия качеству никогда не бывает 100%. Соответственно, граница рафакторинг-нерефакторинг определяется в т.ч. именно этой степенью соответствия.
2 Есть требования — фукнциональные и нефункциональные, в т.ч. неявные.
Пример — ты написал тест, где, скажем, явно проверяется тип аргументов функции sort, и тест явно задает ограничение что де параметр один и это массив.
Изменение в коде — компаратор, который будет дополнительным параметром.
Итого — тест сломан!
КАААААК! ЭТО НЕ РЕФАКТОРИНГ!!!!! ТЫ САМ СКАЗАЛ!!!!!!1111 ТЫ ВРЁШЬ!!!расрасрас
Как понять — из требований. Например, в код числодробилки иногда приходится узкое место оптимизировать, скажем, при помощью инлайна функции, колбека, компаратора, и тд.
Заинлайнил — есть нужный перформанс, работает. Не заинлайнил — нет перформанса, не работает.
Итого — микроскопические изменения отражены в требованиях? Если да, от ожидания адеватные. Если нет — то ожидания неадекватные.
Аналогичный пример с твоими таймингами. Ожидания адекватные? Тогда красный тест говорит о том, что изменения ломающие. Неадекватные — ничего не говорит.
Теперь добавляем сюда степень соответсвия. Самое главное — внятно обозначить её. Тогда получится не "любое изменение таймингов" а "изменение таймингов выше уровня х"