Если код не соответствует общепринятым базовым паттернам, то это и не шашечки и не ехать. Это велосипед на костылях и замыкание процессов на себя. Потом проще выкинуть, чем внести изменения.
получается фигня, которая не держит нагрузку, с трудом удерживается DBA в рамках
А откуда гарантия, что ваши кривые SQL-запросы не уложат базу? Неумение пользоваться инструментом — не оправдание. При грамотном использовании оверхед на орм — на уровне статистической погрешности. А сколько оверхед на дублирование одного и того же кода?
можно смело раскладывать в продакшен в пятницы, перед праздниками
Если нет надёжной процедуры отката, у вас проблемы посерьёзнее скорости разработки или обеспечения качества фич
с типами в разы дороже и качество хуже или результат вовсе не достигнут
С типами обычно быстрее и проще. Свежий пример — я делаю библиотеку, которую пользователь (разработчик конечного приложения) должен проинициализировать довольно сложной вложенной структурой данных.
Как гарантировать, что пользователь библиотеки проинициализировал её правильно, заполнив все необходимые поля?
Тесты на код пользователя писать? Заставить его самого писать себе тесты по документации?
Можно конечно в рантайме проверять и бросать ошибки в рантайме вида: "Возраст должен быть числом", "Не знаю поля Nme, возможно вы имели ввиду Name?" Отладка может быть долгой.
А можно просто сделать типизированный конфиг, который просто не позволит собрать билд с неправильными параметрами или опечататься в значении поля.
ТДД и тестировшики не связаны и тем более не взаимозаменяемы, потому что тесты, которые пишут разработчик и QA — разные и предназначены для разных целей.
Ну будет лапша, которая не соответствует SOLID, тормозит разработку (билд занимает часы) и протестирована на единственной версии постгрис.
"а не отправили ли в постгрис ошибочный SQL"
Попробуйте ORM. Даже легковесные ORM предоставляют гарантии на уровне типов, что будет сгенерирован корректный SQL который вызывается на подходящей схеме БД. Остальные редкие случаи поймает приёмочное тестирование
Если упали тесты, которые тестируют код, то билд не мог состоятся, т.к. прогон этих тестов (которые написаны разработчиком) — часть процесса билда.
Если же билд состоялся, то регрессия упала на стороне QA и QA должен завести баг.
И всё это не имеет отношения к ТДД. ТДД — это не про тесты, ТДД — это про процесс написания кода
когда бизнес уже "что-то кому-то продал" и сидят довольные, празднуя с шампанским удачную сделку, но вот теперь IT должен сделать из говна конфетку ровно к сроку Х (который определили даже не проконсультировавшись с IT) или внедрить новую фичу опять же к сроку Х, которую уже продали, чтобы бизнес не выглядели жуликами.
Скрам существует с середины 80х и позволяет с цифрами в руках наглядно показать какое количество функционала может быть готово к определенному сроку. Или наоборот — когда будут готовы все требования.
Если есть риски, их надо озвучить. То что бизнес продал звездолёт без оценки исполнителей и обещает поставить его через неделю — исключительно проблемы бизнес-стороны и ИТ касаться не должны. Статистика — вещь упрямая. Начнёшь подгонять — так ещё и кадры растеряешь
Иск получит компания (на самом деле скорее всего жалобу в HR). Но это позволит (предпишет?) выкинуть такого менеджера с формулировкой Non-Compliance не взирая на заслуги. С таким волчьим билетом, он в ближайшие 10 лет не пройдёт бекграунд-чек практически никуда.
Хотя на самом деле, чтобы такое случилось должна произойти цепь поистине невероятных событий. Человек, не особо знакомый с местными законами должен получить позицию менеджера, проигнорировать корпоративные тренинги, не обсудить "нововведение" ни с кем и нарваться на мудака, который вместо отказа со словами "ты чё, мужик, этож незаконно", всё-таки сделает презентацию и потом пожалуется.
Например имеем какой-то объект. В методе этого объекта производится сохранение каких-то данных в БД.
Ну мы вручную же биты не отправляем по сети, не пишем посекторно сырые данные на диск, верно? Мы ведь не драйвер пишем?
Значит есть какой-то апи для работы с базой данных. Это апи можно (нужно) замокать.
И тестировать исключительно наш код, а не компоненты инфраструктуры.
Cовершенно неправильно считать, что TDD хоть как-то заменяет QA.
QA должен тестировать требования к приложению, а не код отдельно взятых компонентов. К исходному коду у тестировшика (в идеальном случае) вообще доступа быть не должно.
А правильнее будет как раз наоборот. Ну почти что.
TDD — это про юнит-тесты. То есть тесты для компонентов*, которые написаны Вами, и в которых зависимости** замоканы. В них мы прогоняем большое количество различных случаев, в которых убеждаемся, что требования выполняются и программа работает именно так как это ожидается.
Если компонент написан правильно, очень легко покрыть его юнит-тестами на 100%
Сложные тесты с зависимостями — это уже не юнит. Это — интеграционные тесты. В них мы не проверяем все возможные случаи. В интеграционных тестах главный фокус — это проверка, что разные компоненты взаимоинтегрировались между собой правильно. Поэтому программист описывает минимальное количество случаев, которыми старается затронуть вызов всех зависимостей. Покрывать интеграционными тестами чужие компоненты для программиста смысла нет, они должны быть покрыты в цикле своей собственной разработки, а нами рассматриваются исключительно как черные ящики. Тем не менее, QA тестирует приложение целиком, поэтому его тесты обычно покрывают значительную часть зависимостей.
Типичный сценарий написания программы по TDD выглядит примерно так:
1. Получаем требования, дизайним контракт вызовов. Получаем документ с описанием API.
2. Пишем юнит-тесты согласно контракту. Получаем примеры использования API
3. Пишем имплементацию. Наши юнит-тесты начинают проходить.
4. Делаем интеграционные тесты с реальными зависимостями, убеждаемся что они проходят. Если нет — чиним инициализацию, DI, инфраструктуру и т.д.
*компонент — элемент кода, который мы тестируем или который представляет собой отдельную зависимость. Обычно это класс или функция.
**зависимость (чужой компонент) — компонент, которому делегируется часть функций компонента, который мы разрабатываем. Может быть частью фреймворка, который мы используем, или написан нами, но вне рамок текущей задачи.
2. Installation and Use Rights.
a. License. The software is licensed, not sold. Under this agreement, we grant you the right to install and run one instance of the software on your device (the licensed device), for use by one person at a time, so long as you comply with all the terms of this agreement.
Это ПО лицензировано, а не продано. (...) В соответствии с этим соглашением мы гарантируем вам право установить и использовать одну копию ПО на вашем устройстве (...) до тех пор пока вы соблюдаете все условия этого соглашения
6. Updates. The software periodically checks for system and app updates, and downloads and installs them for you. You may obtain updates only from Microsoft or authorized sources, and Microsoft may need to update your system to provide you with those updates. By accepting this agreement, you agree to receive these types of automatic updates without any additional notice.
(...) Microsoft может понадобится обновить Вашу систему. Принимая это соглашение, вы соглашаетесь получать автоматические обновления без вашего уведомления.
Нет, заходить нужно с другой стороны — лоббировать законодательные ограничения на сбор данных и обновления без явного согласия пользователя (никаких opt-out, только суровый opt-in с подписью кровью и отпечатком головного мозга).
Есть достаточно много способов это обойти. Например, что мешает при установке требовать этот самый opt-in со всеми анализами в обязательном порядке?
Прежде чем говорить, что это не сработает, вспомните, как 20 лет назад ввели обязательную активацию продукта — тоже тогда казалось немыслимым
В пользовательском соглашении написано только, что если вы не согласны с условиями использования, то вам запрещено пользоваться продуктом.
К слову сказать, на электрическом фене тоже не написано, что будет если нарушать условия эксплуатации и например бросить его в ванную наполненную водой. Но по факту в случае серьёзных последствий будет как минимум "нанесение вреда по неосторожности".
ну вот опять — некомпетентность бизнеса привела к нарушениям процессов в угоду скорости и отсюда повылезали все проблемы.
Не удивлюсь, что в итоге разработчики и оказались виноваты во всех факапах, вызванных нехваткой времени.
Моя позиция — я следую процессам и деливерю с предсказуемым качеством. На иных условиях я не работаю, потому что не могу отвечать за продукт.
"Горе-бизнесмены", пообещавшие звездолёт за неделю сдаются сразу в топ-менеджмент (было 1 раз всего)
Будет ошибка десериализации очевидно, а не стектрейс в случайном месте.
И сколько же раз надо запустить программу, чтобы понять что конфиг корректный?
Ошибка в рантайме обходится гораздо дороже чем в компайл-тайме. Потому что может быть причиной отката релиза.
Если код не соответствует общепринятым базовым паттернам, то это и не шашечки и не ехать. Это велосипед на костылях и замыкание процессов на себя. Потом проще выкинуть, чем внести изменения.
А откуда гарантия, что ваши кривые SQL-запросы не уложат базу? Неумение пользоваться инструментом — не оправдание. При грамотном использовании оверхед на орм — на уровне статистической погрешности. А сколько оверхед на дублирование одного и того же кода?
Возможность легко понять что делает код, возможность его модифицировать и легко локализовать ошибку — довольно ценные в разработке, не так ли?
Для того, чтобы достичь этого, существуют определенные практики. Самые базовые — это SOLID.
Несомненно, даже используя лучшие практики при определенном старании можно сделать дерьмо. Но когда им не следуешь, то даже стараться не надо.
Если нет надёжной процедуры отката, у вас проблемы посерьёзнее скорости разработки или обеспечения качества фич
С типами обычно быстрее и проще. Свежий пример — я делаю библиотеку, которую пользователь (разработчик конечного приложения) должен проинициализировать довольно сложной вложенной структурой данных.
Как гарантировать, что пользователь библиотеки проинициализировал её правильно, заполнив все необходимые поля?
Тесты на код пользователя писать? Заставить его самого писать себе тесты по документации?
Можно конечно в рантайме проверять и бросать ошибки в рантайме вида: "Возраст должен быть числом", "Не знаю поля Nme, возможно вы имели ввиду Name?" Отладка может быть долгой.
А можно просто сделать типизированный конфиг, который просто не позволит собрать билд с неправильными параметрами или опечататься в значении поля.
Еще раз. ТДД — это способ написания кода
Когда код уже написан, нет никакого тдд.
ТДД и тестировшики не связаны и тем более не взаимозаменяемы, потому что тесты, которые пишут разработчик и QA — разные и предназначены для разных целей.
Ну будет лапша, которая не соответствует SOLID, тормозит разработку (билд занимает часы) и протестирована на единственной версии постгрис.
Это называется регрессионный тест.
Если упали тесты, которые тестируют код, то билд не мог состоятся, т.к. прогон этих тестов (которые написаны разработчиком) — часть процесса билда.
Если же билд состоялся, то регрессия упала на стороне QA и QA должен завести баг.
И всё это не имеет отношения к ТДД. ТДД — это не про тесты, ТДД — это про процесс написания кода
Скрам существует с середины 80х и позволяет с цифрами в руках наглядно показать какое количество функционала может быть готово к определенному сроку. Или наоборот — когда будут готовы все требования.
Если есть риски, их надо озвучить. То что бизнес продал звездолёт без оценки исполнителей и обещает поставить его через неделю — исключительно проблемы бизнес-стороны и ИТ касаться не должны. Статистика — вещь упрямая. Начнёшь подгонять — так ещё и кадры растеряешь
Конечно же можно автоматизировать QA, но к TDD это отношения не имеет.
Иск получит компания (на самом деле скорее всего жалобу в HR). Но это позволит (предпишет?) выкинуть такого менеджера с формулировкой Non-Compliance не взирая на заслуги. С таким волчьим билетом, он в ближайшие 10 лет не пройдёт бекграунд-чек практически никуда.
Хотя на самом деле, чтобы такое случилось должна произойти цепь поистине невероятных событий. Человек, не особо знакомый с местными законами должен получить позицию менеджера, проигнорировать корпоративные тренинги, не обсудить "нововведение" ни с кем и нарваться на мудака, который вместо отказа со словами "ты чё, мужик, этож незаконно", всё-таки сделает презентацию и потом пожалуется.
Ну мы вручную же биты не отправляем по сети, не пишем посекторно сырые данные на диск, верно? Мы ведь не драйвер пишем?
Значит есть какой-то апи для работы с базой данных. Это апи можно (нужно) замокать.
И тестировать исключительно наш код, а не компоненты инфраструктуры.
Бухгалтерия же не считает только дебет, чтобы быстрее было.
QA должен тестировать требования к приложению, а не код отдельно взятых компонентов. К исходному коду у тестировшика (в идеальном случае) вообще доступа быть не должно.
TDD — это про юнит-тесты. То есть тесты для компонентов*, которые написаны Вами, и в которых зависимости** замоканы. В них мы прогоняем большое количество различных случаев, в которых убеждаемся, что требования выполняются и программа работает именно так как это ожидается.
Если компонент написан правильно, очень легко покрыть его юнит-тестами на 100%
Сложные тесты с зависимостями — это уже не юнит. Это — интеграционные тесты. В них мы не проверяем все возможные случаи. В интеграционных тестах главный фокус — это проверка, что разные компоненты взаимоинтегрировались между собой правильно. Поэтому программист описывает минимальное количество случаев, которыми старается затронуть вызов всех зависимостей. Покрывать интеграционными тестами чужие компоненты для программиста смысла нет, они должны быть покрыты в цикле своей собственной разработки, а нами рассматриваются исключительно как черные ящики. Тем не менее, QA тестирует приложение целиком, поэтому его тесты обычно покрывают значительную часть зависимостей.
Типичный сценарий написания программы по TDD выглядит примерно так:
1. Получаем требования, дизайним контракт вызовов. Получаем документ с описанием API.
2. Пишем юнит-тесты согласно контракту. Получаем примеры использования API
3. Пишем имплементацию. Наши юнит-тесты начинают проходить.
4. Делаем интеграционные тесты с реальными зависимостями, убеждаемся что они проходят. Если нет — чиним инициализацию, DI, инфраструктуру и т.д.
*компонент — элемент кода, который мы тестируем или который представляет собой отдельную зависимость. Обычно это класс или функция.
**зависимость (чужой компонент) — компонент, которому делегируется часть функций компонента, который мы разрабатываем. Может быть частью фреймворка, который мы используем, или написан нами, но вне рамок текущей задачи.
Например, если сделать траффик с mobile.facebook.com — полностью бесплатным, то это поставит все остальные соцсети в невыгодное положение
www.microsoft.com/en-us/Useterms/Retail/Windows/10/UseTerms_Retail_Windows_10_English.htm
2. Installation and Use Rights.
a. License. The software is licensed, not sold. Under this agreement, we grant you the right to install and run one instance of the software on your device (the licensed device), for use by one person at a time, so long as you comply with all the terms of this agreement.
Это ПО лицензировано, а не продано. (...) В соответствии с этим соглашением мы гарантируем вам право установить и использовать одну копию ПО на вашем устройстве (...) до тех пор пока вы соблюдаете все условия этого соглашения
6. Updates. The software periodically checks for system and app updates, and downloads and installs them for you. You may obtain updates only from Microsoft or authorized sources, and Microsoft may need to update your system to provide you with those updates. By accepting this agreement, you agree to receive these types of automatic updates without any additional notice.
(...) Microsoft может понадобится обновить Вашу систему. Принимая это соглашение, вы соглашаетесь получать автоматические обновления без вашего уведомления.
Есть достаточно много способов это обойти. Например, что мешает при установке требовать этот самый opt-in со всеми анализами в обязательном порядке?
Прежде чем говорить, что это не сработает, вспомните, как 20 лет назад ввели обязательную активацию продукта — тоже тогда казалось немыслимым
В пользовательском соглашении написано только, что если вы не согласны с условиями использования, то вам запрещено пользоваться продуктом.
К слову сказать, на электрическом фене тоже не написано, что будет если нарушать условия эксплуатации и например бросить его в ванную наполненную водой. Но по факту в случае серьёзных последствий будет как минимум "нанесение вреда по неосторожности".