Сообщение 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 ТЫ ВРЁШЬ!!!расрасрас
Как понять — из требований. Например, в код числодробилки иногда приходится узкое место оптимизировать, скажем, при помощью инлайна функции, колбека, компаратора, и тд.
Заинлайнил — есть нужный перформанс, работает. Не заинлайнил — нет перформанса, не работает.
Итого — микроскопические изменения отражены в требованиях? Если да, от ожидания адеватные. Если нет — то ожидания неадекватные.
Аналогичный пример с твоими таймингами. Ожидания адекватные? Тогда красный тест говорит о том, что изменения ломающие. Неадекватные — ничего не говорит.
Теперь добавляем сюда степень соответсвия. Самое главное — внятно обозначить её. Тогда получится не "любое изменение таймингов" а "изменение таймингов выше уровня х"