Информация об изменениях

Сообщение Re[11]: Функции должны быть компактными от 27.04.2016 12:09

Изменено 27.04.2016 12:59 __kot2

Здравствуйте, WolfHound, Вы писали:
__>>нужно не пробовать подход с маленькими ф-иями, а подход с написанием юнит-тестов. вы быстро выясните, что при привычном подходе вам тестов придется писать еще и больше кода и, постепенно поймете, как разбить все на маленькие назависимые, скомпонованные между собой модули, чтобы изменения в одном не тянули изменений в другом.
WH>А вот скажи мне как писать тесты до кода если задача ставится так:
WH>Сделай хрень, которая должна делать примерно то-то. Возможны небольшие отклонения от идеального решения, ибо идеальное решение будет работать дольше жизни вселенной.
WH>При этом нужно уложится в 50 миллисекунд. А лучше в 10.
вот меня кстати удивляет когда люди пишут такие задачи без юнит тестов, по крайней мере на сам алгоритм.
потом чего-нить поломается, они "ща" и как слесарь с сигареткой в зубах, лезут в щиток, там что-то подогнут и "ну все, заводи заново"
разумеется все типичные и переломные точки обработки должны собираться в коллекцию и тестироваться.

WH>Имей в виду что при решении таких задач весь код несколько раз переписывается.

вы мне просто мою работу описываете. если кто-то придет и скажет "я пеерписал весь код, теперь он работает правильно и быстро", я скажу — "докажи!". учитывайте, что даже x264 кодек знаменит тем, что дает битые кадры периодически, хотя вроде бы тысячи людей постоянно гоняют на нем какие-то свои тесты.

вы считаете, что если "на большом тесте все проходит", то и ошибок более низкого уровня нет? да полно багов было обнаружено в результате юнит-тестов даже в современных процессорах, я как-то отчет видел от компании, которая это делала у нас на этаже. им, собн-о, за эти тесты и платили.

__>>но скорее всего вы плюнете на эту задумку и оставите только функциональные тесты, время выполнения которых постепенно докатится до 4 часов на коммит и вы, наконец, поймете, в чем разница между юнит тестами и функциональными.

WH>Запускать все тесты на каждый коммит весьма странная затея.
WH>Полностью тестировать нужно только перед отправкой кода в главную ветку. А рабочие ветки могут даже не компилироваться. И ничего плохого в этом нет.
и отправда в главную ветку это целое эпохальное событие с неожиданной развязкой? батюшку приглашаете для освящения сервера, дабы повысить шансы, что ничего не сломается? никаких других вариантов пока не придумали?
Re[11]: Функции должны быть компактными
Здравствуйте, WolfHound, Вы писали:
__>>нужно не пробовать подход с маленькими ф-иями, а подход с написанием юнит-тестов. вы быстро выясните, что при привычном подходе вам тестов придется писать еще и больше кода и, постепенно поймете, как разбить все на маленькие назависимые, скомпонованные между собой модули, чтобы изменения в одном не тянули изменений в другом.
WH>А вот скажи мне как писать тесты до кода если задача ставится так:
WH>Сделай хрень, которая должна делать примерно то-то. Возможны небольшие отклонения от идеального решения, ибо идеальное решение будет работать дольше жизни вселенной.
WH>При этом нужно уложится в 50 миллисекунд. А лучше в 10.
вот меня кстати удивляет когда люди пишут такие задачи без юнит тестов, по крайней мере на сам алгоритм.
потом чего-нить поломается, они "ща" и как слесарь с сигареткой в зубах, лезут в щиток, там что-то подогнут и "ну все, заводи заново"
разумеется все типичные и переломные точки обработки должны собираться в коллекцию и тестироваться.

WH>Имей в виду что при решении таких задач весь код несколько раз переписывается.

вы мне просто мою работу описываете. если кто-то придет и скажет "я пеерписал весь код, теперь он работает правильно и быстро", я скажу — "докажи!". учитывайте, что даже x264 кодек знаменит тем, что дает битые кадры периодически, хотя вроде бы тысячи людей постоянно гоняют на нем какие-то свои тесты.

вы считаете, что если "на большом тесте все проходит", то и ошибок более низкого уровня нет? да полно багов было обнаружено в результате юнит-тестов даже в современных процессорах, я как-то отчет видел от компании, которая это делала у нас на этаже. им, собн-о, за эти тесты и платили.

даже в процессорах находят баги после мега-тестирования. то с делением, то с кэшем, то с транзакционной памятью. и это только самые громкие случае, на самом деле даже в вашем проце с десяток багов-то наберется, просто они проявляются не часто и не так явно. подумаешь, там, программка повиснет. а вы мне рассказываете про некое Васино поделие, которое он только что переписал и у себя на компе на своем наборе тестов проверил и терерь думает, что там все правильно. да неправильно оно. вопрос только где и как мы это будем локализовать.

__>>но скорее всего вы плюнете на эту задумку и оставите только функциональные тесты, время выполнения которых постепенно докатится до 4 часов на коммит и вы, наконец, поймете, в чем разница между юнит тестами и функциональными.

WH>Запускать все тесты на каждый коммит весьма странная затея.
WH>Полностью тестировать нужно только перед отправкой кода в главную ветку. А рабочие ветки могут даже не компилироваться. И ничего плохого в этом нет.
и отправда в главную ветку это целое эпохальное событие с неожиданной развязкой? батюшку приглашаете для освящения сервера, дабы повысить шансы, что ничего не сломается? никаких других вариантов пока не придумали?