Сколько слоев, абстракций, интерфейсов и классов…
Но потом в 9 из 10 случаев выясняется что никто и не планирует никогда менять БД, менять протокол доступа или чтобы то ни было вообще менять, а всё равно через 3 года потребуется переписать.
Честно говоря, тот факт, что в аудитории сидело много людей так или иначе связанных с вебом/бэкендом, а что такое идемпотентность знало лишь трое — меня несколько… смущает.
Странно это, лезть в словарь чтобы посмотреть одно из базовых определений стандарта HTTP (как выше написали к тому же и из математики).
TDD и BDD путают, потому что BDD фреймворки так и норовят сказать что они является эволюционным шагом от TDD. Открываем JBehave:
JBehave is a framework for Behaviour-Driven Development (BDD). BDD is an evolution of test-driven development (TDD)
Не совсем понимаю роль BDD в данном описанном случае, возможно не хватает примеров, но видимо их покажут только на конференции. Автоматизаторы общаются с Бизнесом, синхронизируют понятия, составляют сценарии, а дальше садятся и пишут обычные такие автотесты. Автотесты содержат некоторый код, который что-то вызывает, что-то проверяет, но это код дописанный вручную.
Красивые примеры BDD описаний выглядят красиво в виде сценариев, но в итоге их перегоняют в обычный код автотестов (а иногда очень избыточный и многословный, как пример с Tooling examples).
Сама идея нормального структурированного описания сценариев — полезна, это самый адекватный способ прописать Acceptance Criteria для задачи.
НО перегонку в код всё равно будет выполнять Автоматизатор (с навыками программиста), который довольно быстро (на мой взгляд) упрется в ограничения фреймворков и устанет от еще одного DSL-языка.
При этом, мануальные Тестировщики и Аналитики, как и раньше — не будут смотреть код, оперируя лишь сценариями.
Но тут не забываем про важный момент — сжатие данных. Мощные СУБД умеют оптимизировать хранение данных и сжимать, так что на самом деле разница будет не 4 Тб и 8 Тб, не скажу точно сколько, но всё же не такая.
Например, MS SQL:
All non-East Asian languages and the Thai language store non-Unicode characters in single bytes.
В MS SQL (да и думаю во всех реляционных БД) индексы по полям простого типа (число, гуид) работают значительно лучше/эффективнее чем по строковым. Значит и джойны по простым полям будут работать лучше.
Соглашусь (и обеими руками поддержу) со всем, но по 4му пункту в части логов уточню:
важно хранить логи действий пользователя в течение 1-2х недель на случай, если он обратится в техническую поддержку. Затем эту информацию можно удалить.
Очень зависит от специфики системы. Действительно, важно понимать ЧТО вы логгируете, не стремясь просто набить терабайт побольше и потом хвалиться ими. Но вот у нас бывают случаи разбора проблем и 3х месячной давности, и тогда только детальные логи помогают понять в чем дело. Иные процессы требуют вообще журналирования более чем на год, пусть и довольно поверхностного.
На протяжении всей статьи ждал что речь сведется к Онтологиям и OWL.
Не свелась, слава Тьюрингу.
Вообще правда человек выглядит как лишнее звено, но как и формализация самого процесса разработки ПО — неясно что с этим делать, пока что (подчеркиваю). Но взглянуть хотя бы на стандарт ACORD, который покрывает лишь область Страхования, и становится не по себе от обилия и глубины данных.
Тоже сторонник одного монитора, нравится что меньше вертишь головой, хотя на вкус и цвет.
Но, обратил внимание — много в комментариях говорят про отладку, верстку и т.п.
Если конкретно про разработку говорить — не знаю как у других, но у меня бОльшая часть работы это продумывание. Продумываю код, продумываю отчет, продумываю ТЗ. Специально минимизировал дерганье «давай посмотрим что получится», от дебага вообще почти избавился. Значительно повысило мою производительность и понимание системы.
Безусловно, согласен со вторым абзац. Но, если эти зависимости сложные, то при добавлении каждой новой хардкодом в классе — волей-неволей задумаешься, правильно ли ты делаешь, ведь её еще надо инициализировать правильно. Когда же имеется возможность лишь добавить свойство с нужным контрактом, то задумываться приходится явно меньше.
Не, есть и Property Injection и Constructor Injection.
Тут скорее по смыслу повелось как паттерн — в конструкторе получаем строго обязательные зависимости, в свойствах описываем опциональные.
Однако, это не особо меняет ситуацию — 15 свойств с интерфейсами точно такое же опасное дело, точно такой же God-Object, хоть весь и на DI. Только с DI поддерживается ощущение «тут всего то параметр/свойство добавить».
Как показал мой опыт, основная проблема бездумного использования IoC/DI-контейнеров — за ними прячут чрезмерную сложность системы. Видел системы на 5-7 уровней вложенности зависимостей. Видел по 15 интерфейсов в конструкторе. Но сам по себе IoC/DI не добавляет сложности, она рождается из конкретной реализации.
Прятать сложность всегда опасно, надо вместо этого делать просто.
Хорошая подробная статья, интересно с точки зрения реализации, спасибо. Тем не менее встречный вопрос — а давало ли какие-либо преимущества натягивание ООП модели на реляционную БД?
Ни в коем разе не повторяюсь комментариям выше, именно хочу узнать каков профит получился. Последние тенденции вроде активно призывают минимизировать наследование, а уж внедрять его в реляционные БД совсем выглядит чужеродным.
Их реализация — платно.
Есть порт на базе StackExchange.Redis https://github.com/BoltR/Hangfire.Redis.StackExchange, который можно прикрутить к бесплатной версии.
Подскажете, пожалуйста, еще ссылку на прозрачное описание реализации персистентности заданий в Akka.Net? Пока насколько разобрался это http://getakka.net/docs/persistence/persistent-actors, но из описания следует как будто надо самому заботиться хранением данных по актору.
Инструмент похоже и правда очень мощный, хотя очень забавно смотрится куча вставок в документации http://getakka.net/docs/Fault%20tolerance "!!!TODO: Port sample code" :)
Недавно тоже озадачивался темой запуска фоновых процесс, в контексте организации очереди обработки.
Возможно я не понимаю как готовить Hangfire или Quartz, но ни один из них не позволяет нормальным образом организовать Circuit Breaker на случай аварий.
Hangfire не позволяет практически конфигурировать интервалы между попытками.
Есть Polly, который всё это умеет делать замечательно, но туда никак не вкрутишь адекватно персистентность, он не про это.
Hangfire не позволяет переопределять названия таблиц в БД, так что использовать придется отдельные БД на каждое приложение, либо разделять их по схеме (dbo и т.д.).
Quartz творит с БД какое-то непотребство, гора таблиц в 2000-like стиле.
В итоге — придется писать видимо свой инструмент.
«Вы хотите знать почему мы пропустили версию 3.0? Сейчас сейчас мы расскажем. Вот почти уже рассказали. И вот еще это почитайте и мы расскажем. Всё-таки хотите знать где версия 3.0? Мы ведь используем теперь семантическое версионирование! Сейчас расскажем где версия 3.0. Вот еще чуть-чуть и расскажем. В общем просто отказались потому что внутри там с версиями накосячили ранее. Где же версии 4.1 или 4.2, почему сразу 5.0? Семантическое версионирование! Не видите логики? Мы тоже особо не видим, но так будет проще нам решить наши проблемы с версиями.»
Но потом в 9 из 10 случаев выясняется что никто и не планирует никогда менять БД, менять протокол доступа или чтобы то ни было вообще менять, а всё равно через 3 года потребуется переписать.
Странно это, лезть в словарь чтобы посмотреть одно из базовых определений стандарта HTTP (как выше написали к тому же и из математики).
Не совсем понимаю роль BDD в данном описанном случае, возможно не хватает примеров, но видимо их покажут только на конференции. Автоматизаторы общаются с Бизнесом, синхронизируют понятия, составляют сценарии, а дальше садятся и пишут обычные такие автотесты. Автотесты содержат некоторый код, который что-то вызывает, что-то проверяет, но это код дописанный вручную.
Красивые примеры BDD описаний выглядят красиво в виде сценариев, но в итоге их перегоняют в обычный код автотестов (а иногда очень избыточный и многословный, как пример с Tooling examples).
Сама идея нормального структурированного описания сценариев — полезна, это самый адекватный способ прописать Acceptance Criteria для задачи.
НО перегонку в код всё равно будет выполнять Автоматизатор (с навыками программиста), который довольно быстро (на мой взгляд) упрется в ограничения фреймворков и устанет от еще одного DSL-языка.
При этом, мануальные Тестировщики и Аналитики, как и раньше — не будут смотреть код, оперируя лишь сценариями.
Например, MS SQL:
Очень зависит от специфики системы. Действительно, важно понимать ЧТО вы логгируете, не стремясь просто набить терабайт побольше и потом хвалиться ими. Но вот у нас бывают случаи разбора проблем и 3х месячной давности, и тогда только детальные логи помогают понять в чем дело. Иные процессы требуют вообще журналирования более чем на год, пусть и довольно поверхностного.
Не свелась, слава Тьюрингу.
Вообще правда человек выглядит как лишнее звено, но как и формализация самого процесса разработки ПО — неясно что с этим делать, пока что (подчеркиваю). Но взглянуть хотя бы на стандарт ACORD, который покрывает лишь область Страхования, и становится не по себе от обилия и глубины данных.
Но, обратил внимание — много в комментариях говорят про отладку, верстку и т.п.
Если конкретно про разработку говорить — не знаю как у других, но у меня бОльшая часть работы это продумывание. Продумываю код, продумываю отчет, продумываю ТЗ. Специально минимизировал дерганье «давай посмотрим что получится», от дебага вообще почти избавился. Значительно повысило мою производительность и понимание системы.
Тут скорее по смыслу повелось как паттерн — в конструкторе получаем строго обязательные зависимости, в свойствах описываем опциональные.
Однако, это не особо меняет ситуацию — 15 свойств с интерфейсами точно такое же опасное дело, точно такой же God-Object, хоть весь и на DI. Только с DI поддерживается ощущение «тут всего то параметр/свойство добавить».
Прятать сложность всегда опасно, надо вместо этого делать просто.
Ни в коем разе не повторяюсь комментариям выше, именно хочу узнать каков профит получился. Последние тенденции вроде активно призывают минимизировать наследование, а уж внедрять его в реляционные БД совсем выглядит чужеродным.
Есть порт на базе StackExchange.Redis https://github.com/BoltR/Hangfire.Redis.StackExchange, который можно прикрутить к бесплатной версии.
Возможно я не понимаю как готовить Hangfire или Quartz, но ни один из них не позволяет нормальным образом организовать Circuit Breaker на случай аварий.
Hangfire не позволяет практически конфигурировать интервалы между попытками.
Есть Polly, который всё это умеет делать замечательно, но туда никак не вкрутишь адекватно персистентность, он не про это.
Hangfire не позволяет переопределять названия таблиц в БД, так что использовать придется отдельные БД на каждое приложение, либо разделять их по схеме (dbo и т.д.).
Quartz творит с БД какое-то непотребство, гора таблиц в 2000-like стиле.
В итоге — придется писать видимо свой инструмент.
http://lanyrd.com/topics/javascript/ — past events: 1994.
http://lanyrd.com/topics/ruby/ — past events: 863.
http://lanyrd.com/topics/java/ — past events: 769.
http://lanyrd.com/topics/python/ — past events: 795.
http://lanyrd.com/topics/net/ — past events: 323.