Здравствуйте! Система категоризации Живого Журнала посчитала, что вашу запись можно отнести к категориям: История, Технологии. Если вы считаете, что система ошиблась - напишите об этом в ответе на этот комментарий. Ваша обратная связь поможет сделать систему точнее. Фрэнк, команда ЖЖ.
Чисто для статистики - в вашем окружении отрефлексировано то, что тесты имеют и очевидные отрицательные стороны? Ну простейшие, например, что это код, который нужно поддерживать.
Про то, что вы всё знаете, я знаю уже лет 5. Вопрос - окружающие вас погроммисты и начальники - они-то знают?
Кроме того речь не только о пропущенных ошибках. Речь о том, что вот вы получаете на рецензирование 10 строк кода и 45 строк тестов к нему. Это как в старой шутке про бочку мёда - 55 строк кода.
Их проверять в 5 раз дольше, чем 10. И если можно обойтись 10ю, поставив просто сигнатуру, то получается сильно проще.
По идее, тесты должны проверять функции, желательно, наблюдаемые пользователем, то есть, требования. Однако, пользователи могут варьироваться - что для одного программист, для другого пользователь, для выполнения задачи программистом он выдвигает требования к наличию готового функционала ("без сортировки за O(1/n!) алгоритм разложения на множители будет работать слишком медленно!"). Именно поэтому и тесты, на (минимально) разумное соответствие требованиям.
Ну управление требованиями как-то завязано на развитие кода. То есть, да, после и в процессе добавления "некоего функционала" требования будут слегка пересмотрены.
Но git не отслеживает размышления в архитектурной фазе, когда мы тоже меняем требования. Git, всё-таки, естественным образом протоколирует лишь стадию кодирования, да и то не всю.
Точки слияния, скорее, относятся к functional points. Собственно, есть инъекция из functional points в merge commits, но это ни в коем случае не биекция. То есть, из истории git с помощью фильтрации можно получить "сетевой график" (project network).
Кстати, интересно было бы иметь "иерархическую историю" git - когда вместо squash&merge мы оставляем коммиты разделёнными (фарш ведь невозможно провернуть назад), но показываем лишь ключевые точки слияния.
Comments 12
Система категоризации Живого Журнала посчитала, что вашу запись можно отнести к категориям: История, Технологии.
Если вы считаете, что система ошиблась - напишите об этом в ответе на этот комментарий. Ваша обратная связь поможет сделать систему точнее.
Фрэнк,
команда ЖЖ.
Reply
Reply
Reply
Кроме того речь не только о пропущенных ошибках. Речь о том, что вот вы получаете на рецензирование 10 строк кода и 45 строк тестов к нему. Это как в старой шутке про бочку мёда - 55 строк кода.
Их проверять в 5 раз дольше, чем 10. И если можно обойтись 10ю, поставив просто сигнатуру, то получается сильно проще.
Reply
По идее, тесты должны проверять функции, желательно, наблюдаемые пользователем, то есть, требования. Однако, пользователи могут варьироваться - что для одного программист, для другого пользователь, для выполнения задачи программистом он выдвигает требования к наличию готового функционала ("без сортировки за O(1/n!) алгоритм разложения на множители будет работать слишком медленно!"). Именно поэтому и тесты, на (минимально) разумное соответствие требованиям.
Reply
Но git не отслеживает размышления в архитектурной фазе, когда мы тоже меняем требования. Git, всё-таки, естественным образом протоколирует лишь стадию кодирования, да и то не всю.
Точки слияния, скорее, относятся к functional points. Собственно, есть инъекция из functional points в merge commits, но это ни в коем случае не биекция. То есть, из истории git с помощью фильтрации можно получить "сетевой график" (project network).
Кстати, интересно было бы иметь "иерархическую историю" git - когда вместо squash&merge мы оставляем коммиты разделёнными (фарш ведь невозможно провернуть назад), но показываем лишь ключевые точки слияния.
Reply
ТРЕ-БО-ВА-НИЙ
Требования отвечают на вопрос "почему надо" и именно они позволяют отсекать то, что (пока) делать не стоит (сложно или не нужно).
Можно запланировать граф веток и их слияний, опираясь на требования. И тогда состояние git будет показывать текущий прогресс.
Reply
Требования же меняются из-за, скажем, прототипов, которые в основной репозиторий не попадают.
Reply
Reply
Главное здесь - слияние веток и ациклический граф слияний, как граф выполнения требований.
Тесты довольно вторичны.
Reply
Reply
Reply
Leave a comment