Иногда практикую. Диктофон - это лучше, чем ничего, но всё ещё далеко от идеала. Если записывать только голос, то утомляет необходимость потом сидеть и заниматься переводом в текст. Если использовать STT (типа гугл-клавиатуры), то надо постоянно следить за знаками препинания, правильностью трансляции и т.п.
Хотя кажется, что и диктовка "прямо из мозга" будет страдать от схожих проблем. Самое сложное порой - это именно формулировать мысль таким образом, чтобы она была понятна потом, когда контекст уже выветрился. Иначе получается "надо взять ту штуку и провернуть с ней этот приём, как я делал в той задаче не помню про что, и тогда можно будет обойти неприятности с теми шнягами".
Процитировали же учёного: изоэнтропу строят. Т.е., график конкретных характеристик газа в разных условиях. А этот график уже потом можно для любых других целей использовать: технику проектировать, недра планет обсчитывать, и тд и тп.
Если серьёзно, то фраза "сжали молекулу" выглядит крайне странно. Сжать межмолекулярные промежутки в кристалле - это я понимаю. А вот на отдельную молекулу силушков не хватит у учёных, имхо.
Та же история - если используются самописные SQL-запросы, специфичные для конкретной продовой БД, то довольно быстро могут проявиться несовместимости движков. Придётся либо поддерживать две версии запросов, либо отказываться от каких-то полезных/удобных конструкций SQL, либо страдать от расхождений.
Величина этого риска зависит от деталей реализации репозитория. Если типовой набор операций достаточно ограниченный и не часто растёт, то выигрыш в скорости вполне может оправдывать использование фейка. Делается набор тестов на сравнение поведения двух репозиториев. Проводим одинаковый набор манипуляций над сохраняемыми/загружаемыми объектами и проверяем, что репозитории ведут себя одинаково во всех случаях. Если находятся расхождения в поведении - добавляем новый тест, а с его помощью находим и исправляем расхождения.
Такие тесты используют реальную репу и работают медленно, но это ОК. Их число относительно невелико и растёт не очень быстро. Остальные тесты используют быстрый репозиторий (и, возможно, довольно интенсивно), и поэтому их можно создавать много. Они всё равно будут работать быстро и давать профит ко времени выполнения на CI (в сравнении с использованием медленной репы).
Fun fact: я детально разбирал и планировал внедрить подобный подход, когда работал в одной конторе, использующей облачные хранилища. Измерения профайлером показали, что в тестах реально тратилось 99.5% wall time на ожидание взаимодействия с удалённым хранилищем. Т.е., внедрение быстрого фейкового репозитория ускорило бы тесты в десятки раз.
Однако, не стали это внедрять на деле. Ключевая точка риска - слишком широкий набор операций. Мы использовали одновременно и CRUD API, и довольно обширные многотабличные SQL-like запросы (которые ещё и менялись довольно часто). Поэтому внедрить не рискнули.
Т.е., сработал именно тот риск, про который Вы писали. Тем не менее, я думаю, что в других условиях этот подход вполне может быть оправдан. Многое зависит от конкретных нюансов на месте.
UPD: кажется, для одного кейса в той же конторе я всё же смог применить этот подход. Там "типовой набор операций" был умеренно небольшим, поэтому риск расхождения был меньше. Сработало, и правда. Были отдельно быстрые тесты на фейковой репе, отдельно тесты на совместимость двух реализаций репы.
Как проводить ревью? Да как обычно - смотрите коммиты (`git log -p`, `git show`, etc), задаёте вопросы автору через стандартный канал связи, при необходимости что-то вместе дорабатываете. Для этого процесса не обязательно иметь веб-приложение.
Мне-то как раз несложно привести пример собственного кода. Берём пет-проект, который пишется левой пяткой в редкое свободное время, и смотрим на покрытие кода тестами:
Видим чёткое разграничение: все модули покрыты на 90+% за исключением одного, который покрыт на 0%. Почему? Потому что в нём сконцентрирован весь код, касающийся десктопного GUI на Qt. Я не собирался и не собираюсь писать десктопные тесты в своём проекте, потому что мне принципиально важна скорость разработки и стабильность запускаемых тестов. Текущий набор тестов, который обеспечивает покрытие действительно важной логики, отрабатывает на моей машине за 8 секунд и содержит ровно 0 флакающих тестов. Именно такой выбор между "что тестировать" и "что не тестировать" позволял мне держать zero bug policy с самого старта. И даже сейчас, когда я порой захожу в код на 15 минут после 2-месячного перерыва, я могу без опаски проводить любые доработки.
Хотелось бы напомнить, что в каждом софтверном проекте есть свои собственные соотношения между рисками, сроками и возможностями нести расходы. Если в одном проекте нам жизненно важно тестировать абсолютно все краевые варианты, это не значит, что это жизненно важно абсолютно во всех проектах (и наоборот). Если в одном проекте нам жизненно важно завершить работу к определённой дате, это не значит, что каждый другой проект должен иметь дедлайны (и наоборот). Если в одном проекте мы можем себе позволить любые дополнительные траты (больше железа, больше времени на сборку и тестирование, больше разработчиков и т.п.), это не значит, что так можно позволить вести себя в любой ситуации (и наоборот).
Автотесты - это полезный и важный инструмент разработки. Точно так же, как и code review, статический анализ, и т.п. Но это должен быть инструмент, а не объект поклонения. Всегда надо понимать, какую цену приходится платить за его использование.
Бывают ли баги в непокрытом тестами коде из примера выше? Да, случаются раз в год-другой. Сколько времени я трачу на то, чтобы найти и исправить их? Обычно, несколько минут - потому что в гуёвом коде практически нет никакой бизнес-логики. Поэтому я считаю отсутствие гуёвых автотестов в этом проекте вполне оправданным. Это мой пет-проект, где я никому ничего не должен. Стал бы я покрывать GUI тестами, если бы писал коммерческий проект? Практически наверняка да.
Вопрос: понимаете ли Вы наличие этих соотношений и их зависимость от условий проекта? Похоже, что нет. Это лишь делает Ваши аргументы смешными в глазах тех, у кого опыт более широкий и разнообразный.
О, ну так поделитесь покрытием в собственных проектах, а мы посмотрим и посмеёмся. Как насчёт тестов, которые, к примеру:
Настолько длительные, что в разы увеличивают время поставки, или
Требуют специфических внешних условий, которые трудно воспроизвести чисто физически (требуется особое железо, к примеру), или
Требуют для написания радикальной переделки архитектуры проекта
Процесс разработки - это практически всегда путь из сплошных компромиссов между "сделать по-правильному" и "получить результат в обозримое время". В каких-то случаях это может значить и то, что порой лучше написать комментарий, чем автотест. Просто потому что финансовые, вычислительные и умственные ресурсы конечны и ограничены. А раздавать виртуальные звездюли любой дурак сможет, конечно.
Воздушный старт, ага. С парой маааааленьких нюансов:
Надо не просто "запустить ракету с самолёта", а ещё и придать ей достаточно скорости, чтобы она смогла преодолеть притяжение Венеры и добраться до Земли. Ни один нынешний проект воздушного старта дальше нижней орбиты закинуть спутник не может.
Вы видели вообще существующие комплексы воздушного старта? Это всё равно будет дура-ракета длиной в несколько метров, которая подвешена к грузовому боингу. Даже для того, чтобы вывести маленький спутник на низкую орбиту. Как собираетесь доставлять боинг на Венеру?
UPD: окей, нам могло бы хватить и нижней орбиты, если там тусит ещё один аппарат, который прилетел вместе с самолётом и наземным бурильщиком. Получается примерно как в Appolo - стыковка на орбите и стартовый импульс оттуда для возвращения домой. Но тогда возникает закономерный вопрос: зачем вообще во всей этой схеме нужен промежуточный самолёт? :)
UPD2: окей, есть смысл в самолёте. Бурильщик может выдерживать ад совсем недолго, в отличие от планера. Чуть ширше окно по времени выходит.
Может лучше учиться писать более качественный код?! Разбивать на функции, называть их понятным образом, давать вменяемые имена переменным?
Опять же, не вижу здесь противопоставления "или то, или это", как и в случае с тестами. Умение понимать, что в определённом месте надо поставить определённый комментарий, - это такой же составной элемент общего умения писать хороший код, как и всё остальное, что Вы перечислили.
По крайней мере, на Земле.
Вспоминается эпический фейл с пенетратором InSight, который тоже хорошо показал себя в испытаниях, но на Марсе толком не смог ничего пробурить.
Лучший комментарий, спасибо!
Боюсь, это очень старая проблема - см "охлократия".
Иногда практикую. Диктофон - это лучше, чем ничего, но всё ещё далеко от идеала. Если записывать только голос, то утомляет необходимость потом сидеть и заниматься переводом в текст. Если использовать STT (типа гугл-клавиатуры), то надо постоянно следить за знаками препинания, правильностью трансляции и т.п.
Хотя кажется, что и диктовка "прямо из мозга" будет страдать от схожих проблем. Самое сложное порой - это именно формулировать мысль таким образом, чтобы она была понятна потом, когда контекст уже выветрился. Иначе получается "надо взять ту штуку и провернуть с ней этот приём, как я делал в той задаче не помню про что, и тогда можно будет обойти неприятности с теми шнягами".
Простите, не сдержался
Процитировали же учёного: изоэнтропу строят. Т.е., график конкретных характеристик газа в разных условиях. А этот график уже потом можно для любых других целей использовать: технику проектировать, недра планет обсчитывать, и тд и тп.
И теперь это экстра сухой лёд!
Если серьёзно, то фраза "сжали молекулу" выглядит крайне странно. Сжать межмолекулярные промежутки в кристалле - это я понимаю. А вот на отдельную молекулу силушков не хватит у учёных, имхо.
Впрочем, что возьмёшь с пресс-релизёра...
Логично же: кто не курит и не пьёт, тот здоровеньким помрёт!
Кажется, у вас просто 2+ месячные спринты
Ужасающе наивно считать, будто целый мир пишет только небольшие проекты на Node.js + MongoDB, не находите?
Та же история - если используются самописные SQL-запросы, специфичные для конкретной продовой БД, то довольно быстро могут проявиться несовместимости движков. Придётся либо поддерживать две версии запросов, либо отказываться от каких-то полезных/удобных конструкций SQL, либо страдать от расхождений.
Величина этого риска зависит от деталей реализации репозитория. Если типовой набор операций достаточно ограниченный и не часто растёт, то выигрыш в скорости вполне может оправдывать использование фейка. Делается набор тестов на сравнение поведения двух репозиториев. Проводим одинаковый набор манипуляций над сохраняемыми/загружаемыми объектами и проверяем, что репозитории ведут себя одинаково во всех случаях. Если находятся расхождения в поведении - добавляем новый тест, а с его помощью находим и исправляем расхождения.
Такие тесты используют реальную репу и работают медленно, но это ОК. Их число относительно невелико и растёт не очень быстро. Остальные тесты используют быстрый репозиторий (и, возможно, довольно интенсивно), и поэтому их можно создавать много. Они всё равно будут работать быстро и давать профит ко времени выполнения на CI (в сравнении с использованием медленной репы).
Fun fact: я детально разбирал и планировал внедрить подобный подход, когда работал в одной конторе, использующей облачные хранилища. Измерения профайлером показали, что в тестах реально тратилось 99.5% wall time на ожидание взаимодействия с удалённым хранилищем. Т.е., внедрение быстрого фейкового репозитория ускорило бы тесты в десятки раз.
Однако, не стали это внедрять на деле. Ключевая точка риска - слишком широкий набор операций. Мы использовали одновременно и CRUD API, и довольно обширные многотабличные SQL-like запросы (которые ещё и менялись довольно часто). Поэтому внедрить не рискнули.
Т.е., сработал именно тот риск, про который Вы писали. Тем не менее, я думаю, что в других условиях этот подход вполне может быть оправдан. Многое зависит от конкретных нюансов на месте.
UPD: кажется, для одного кейса в той же конторе я всё же смог применить этот подход. Там "типовой набор операций" был умеренно небольшим, поэтому риск расхождения был меньше. Сработало, и правда. Были отдельно быстрые тесты на фейковой репе, отдельно тесты на совместимость двух реализаций репы.
Как проводить ревью? Да как обычно - смотрите коммиты (`git log -p`, `git show`, etc), задаёте вопросы автору через стандартный канал связи, при необходимости что-то вместе дорабатываете. Для этого процесса не обязательно иметь веб-приложение.
Мне-то как раз несложно привести пример собственного кода. Берём пет-проект, который пишется левой пяткой в редкое свободное время, и смотрим на покрытие кода тестами:
Видим чёткое разграничение: все модули покрыты на 90+% за исключением одного, который покрыт на 0%. Почему? Потому что в нём сконцентрирован весь код, касающийся десктопного GUI на Qt. Я не собирался и не собираюсь писать десктопные тесты в своём проекте, потому что мне принципиально важна скорость разработки и стабильность запускаемых тестов. Текущий набор тестов, который обеспечивает покрытие действительно важной логики, отрабатывает на моей машине за 8 секунд и содержит ровно 0 флакающих тестов. Именно такой выбор между "что тестировать" и "что не тестировать" позволял мне держать zero bug policy с самого старта. И даже сейчас, когда я порой захожу в код на 15 минут после 2-месячного перерыва, я могу без опаски проводить любые доработки.
Хотелось бы напомнить, что в каждом софтверном проекте есть свои собственные соотношения между рисками, сроками и возможностями нести расходы. Если в одном проекте нам жизненно важно тестировать абсолютно все краевые варианты, это не значит, что это жизненно важно абсолютно во всех проектах (и наоборот). Если в одном проекте нам жизненно важно завершить работу к определённой дате, это не значит, что каждый другой проект должен иметь дедлайны (и наоборот). Если в одном проекте мы можем себе позволить любые дополнительные траты (больше железа, больше времени на сборку и тестирование, больше разработчиков и т.п.), это не значит, что так можно позволить вести себя в любой ситуации (и наоборот).
Автотесты - это полезный и важный инструмент разработки. Точно так же, как и code review, статический анализ, и т.п. Но это должен быть инструмент, а не объект поклонения. Всегда надо понимать, какую цену приходится платить за его использование.
Бывают ли баги в непокрытом тестами коде из примера выше? Да, случаются раз в год-другой. Сколько времени я трачу на то, чтобы найти и исправить их? Обычно, несколько минут - потому что в гуёвом коде практически нет никакой бизнес-логики. Поэтому я считаю отсутствие гуёвых автотестов в этом проекте вполне оправданным. Это мой пет-проект, где я никому ничего не должен. Стал бы я покрывать GUI тестами, если бы писал коммерческий проект? Практически наверняка да.
Вопрос: понимаете ли Вы наличие этих соотношений и их зависимость от условий проекта? Похоже, что нет. Это лишь делает Ваши аргументы смешными в глазах тех, у кого опыт более широкий и разнообразный.
Не вижу засады. Я бы так сделал:
Составить список отличающихся функций
Сделать обёртки для изменившихся функций, чтобы они соответствовали новому API, а под капотом дёргали старый.
Плавно перейти на использование обёрток вместо старого API
Когда весь код использует обёртки, провести обновление. Т.е., поднять версию либы, а в обёртках заменить вызовы старого API на вызовы нового 1 в 1.
Когда оттестировали новую версию и убедились, что всё работает нормально, избавляемся от обёрток и используем новый API напрямую.
О, ну так поделитесь покрытием в собственных проектах, а мы посмотрим
и посмеёмся. Как насчёт тестов, которые, к примеру:Настолько длительные, что в разы увеличивают время поставки, или
Требуют специфических внешних условий, которые трудно воспроизвести чисто физически (требуется особое железо, к примеру), или
Требуют для написания радикальной переделки архитектуры проекта
Процесс разработки - это практически всегда путь из сплошных компромиссов между "сделать по-правильному" и "получить результат в обозримое время". В каких-то случаях это может значить и то, что порой лучше написать комментарий, чем автотест. Просто потому что финансовые, вычислительные и умственные ресурсы конечны и ограничены. А раздавать виртуальные звездюли любой дурак сможет, конечно.
Надеюсь, что вы и работаете вместе!
Воздушный старт, ага. С парой маааааленьких нюансов:
Надо не просто "запустить ракету с самолёта", а ещё и придать ей достаточно скорости, чтобы она смогла преодолеть притяжение Венеры и добраться до Земли. Ни один нынешний проект воздушного старта дальше нижней орбиты закинуть спутник не может.
Вы видели вообще существующие комплексы воздушного старта? Это всё равно будет дура-ракета длиной в несколько метров, которая подвешена к грузовому боингу. Даже для того, чтобы вывести маленький спутник на низкую орбиту. Как собираетесь доставлять боинг на Венеру?
UPD: окей, нам могло бы хватить и нижней орбиты, если там тусит ещё один аппарат, который прилетел вместе с самолётом и наземным бурильщиком. Получается примерно как в Appolo - стыковка на орбите и стартовый импульс оттуда для возвращения домой. Но тогда возникает закономерный вопрос: зачем вообще во всей этой схеме нужен промежуточный самолёт? :)
UPD2: окей, есть смысл в самолёте. Бурильщик может выдерживать ад совсем недолго, в отличие от планера. Чуть ширше окно по времени выходит.
Чтобы заткнуть портал в ад, достаточно простого
советскогодумгая!Опять же, не вижу здесь противопоставления "или то, или это", как и в случае с тестами. Умение понимать, что в определённом месте надо поставить определённый комментарий, - это такой же составной элемент общего умения писать хороший код, как и всё остальное, что Вы перечислили.