Scott Meyers - Keynote @ Meeting C++ 2014
Интересный, общепознавательный доклад Скотта про то, как он писал свою знаменитую книгу (тут ссылка дляжадных экономных), о том "что" важно говорить людям, когда вы их учите, и "как" это говорить.
Первая часть - это история про главу из книги, посвященную разнице между insert & emplace в STL-контейнерах. На этом примере Скотт показывает важность пунктов из своего списка:
Пункты из правил написания эффективной книги могут помочь и в определении ее эффективности и с позиции читателя. Думаю, многие пункты и для статьи в блоге подойдут.
Вторая часть (ссылка со сдвигом по времени) больше познавательная и тренирующая английский. Разговор идет о том, как доносить информацию правильно. Часть скорее для тех, кто выступает, или хочет выступать. Есть немного и про то, как важно использовать современные технологии при печати книг (например использовать многоцветную печать). Резюме: готовьте доклады и выступления так, чтобы их было удобно смотреть в записи на видео. Пишите так, чтобы было удобно использовать современные гаджеты.
Интересный, общепознавательный доклад Скотта про то, как он писал свою знаменитую книгу (тут ссылка для
Первая часть - это история про главу из книги, посвященную разнице между insert & emplace в STL-контейнерах. На этом примере Скотт показывает важность пунктов из своего списка:
Пункты из правил написания эффективной книги могут помочь и в определении ее эффективности и с позиции читателя. Думаю, многие пункты и для статьи в блоге подойдут.
Вторая часть (ссылка со сдвигом по времени) больше познавательная и тренирующая английский. Разговор идет о том, как доносить информацию правильно. Часть скорее для тех, кто выступает, или хочет выступать. Есть немного и про то, как важно использовать современные технологии при печати книг (например использовать многоцветную печать). Резюме: готовьте доклады и выступления так, чтобы их было удобно смотреть в записи на видео. Пишите так, чтобы было удобно использовать современные гаджеты.
Добавляем докладик про автоматическое тестирование, для остроты вкуса солянки.
Никита в свое время проехался по немутанком легким броневиком. Собственно с тех времен доклад видимо у меня в запасниках и пылился. Пришло и его время.
Помнится был у меня опыт построения тестов, подобных тем, что описывает докладчик. Вспоминаю с ужасом. Мокировали все, что "движется"... Но, возможно тогда мозг еще не был готов и опыта не хватало.
Доклад в первую очередь для разработчиков, потому что у тестировщиков возникают резонные вопросы про проблемы, возникающие в реальном окружении (см. комментарии Никиты). Но разработчикам действительно важнее проверить максимально возможное количество сценариев (пресловутое покрытие) за минимальное время. А это можно сделать только через unit-тесты. Это действительно можно завести, но будет ли это эффективно?
Есть сомнения. Особенно если ваши тестировщики придерживаются legacy-взглядов на тестирование и никакой автоматики у них нет.
Использование юнит-тестов для проверки как раз исключительных ситуаций (обработка ошибок, граничных условий и тп) действительно оправдано. Часто воспроизвести такое в реальном стенде сложно (или приближается к невозможному). Но жизненные и простые ситуации (success path) проще и правильнее проверять на пользовательских сценариях с использованием всего продукта.
Итоговое резюме: классический пример случая "гладко было на бумаге, позабыли про овраги".
Наличие следующего доклада в этой подборке может показаться странным. Но нужно добавить аромата к солянке. Я настойчиво рекомендую его посмотреть всем. Даже тем, кому еще только за 20.
Никита в свое время проехался по нему
Помнится был у меня опыт построения тестов, подобных тем, что описывает докладчик. Вспоминаю с ужасом. Мокировали все, что "движется"... Но, возможно тогда мозг еще не был готов и опыта не хватало.
Доклад в первую очередь для разработчиков, потому что у тестировщиков возникают резонные вопросы про проблемы, возникающие в реальном окружении (см. комментарии Никиты). Но разработчикам действительно важнее проверить максимально возможное количество сценариев (пресловутое покрытие) за минимальное время. А это можно сделать только через unit-тесты. Это действительно можно завести, но будет ли это эффективно?
Есть сомнения. Особенно если ваши тестировщики придерживаются legacy-взглядов на тестирование и никакой автоматики у них нет.
Использование юнит-тестов для проверки как раз исключительных ситуаций (обработка ошибок, граничных условий и тп) действительно оправдано. Часто воспроизвести такое в реальном стенде сложно (или приближается к невозможному). Но жизненные и простые ситуации (success path) проще и правильнее проверять на пользовательских сценариях с использованием всего продукта.
Итоговое резюме: классический пример случая "гладко было на бумаге, позабыли про овраги".
Наличие следующего доклада в этой подборке может показаться странным. Но нужно добавить аромата к солянке. Я настойчиво рекомендую его посмотреть всем. Даже тем, кому еще только за 20.
- 36 или кризис среднего возраста. Вадим Макишвили.
Меня торкнуло.
Комментарии
Отправить комментарий