Возможно если вы генерируете текст, а для тестирования вам хочется использовать ast, то стоит подумать о том чтобы генерировать текст через ast? — тестирование распадётся на две фазы — проверка корректности ast и проверка корректности генерации кусков текста из кусков ast.
Другое дело что надо ещё проверять что СУБД интерпретирует все это вместе так как надо — но это можно сделать на других уровнях тестовой пирамиды
Я тут не о том, что их нет, а скорее про то, что если вы каждый день будете две минуты про них рассказывать тем, кто все равно не в теме (и никогда в ней не будет) — ничего не изменится.
В скраме предполагается что команда в течение спринта работает над общей целью.
"Никогда в ней не будет" подразумевает, что либо есть жесткое разделение ролей и в каждой роли ровно один человек либо работа над постоянными разными участками (т.е. фактически разные команды или индивидуальное владение кодом) или еще что-то что я не знаю.
Так то же хорошо, но по моему опыту часто люди ничего не говорят, пока не задашь вопрос, хорошо, что есть время когда все уже отвлечены и можно привлечь внимание команды, а не тыкать всех в произвольный момент времени, можно увидеть какая проблема остается, а какая нет — т.е. относительная важность очевидна.
Я имею ввиду ежедневный ритм а не буквальное вставание в кружок
Интересно, как так получается — обычно у тех, кто работает над одним и тем же есть некоторые общие интересы, некоторый общий набор проблем — коллега может подсказать решение или он может зависеть от твоей работы.
Адские ухищрения и использование дырок в системе вместо планирования, приоритезации и закрытия низкоприоритетных и неактуальных задач.
Кстати,
что поставлены недавно, а всякая тухлая просрочка, «пожелание записано» и т.п.
я не увидел в ваших поцедурах какой-то процесс, который бы отличал просрочку и "те, что поставлены недавно" — списывается все, что накопилось. Получается, при наступлении момента "индульгенции" авторы задач должны актуальное поставить еще раз, если им нужно?
Кроссфункциональость часто понимают как владение всеми навыками всеми членами команды.
Это кроссфункциональность команды состоящей из одного человека. Мне кажется, это совсем неверное понимание термина — он просто совсем не то означает (см. доступные определения)
Это применимо только для некоторых дженериков. Хотя вы и сами это знаете. Фактически по самому факту, что T подтип T1 нельзя сказать что X является подтипом для X и конкретно для List это не так.
Some kids go trick-or-treating for Halloween. They all have Bags of Candy. It's safe for them to eat anything that gets put in their Bag of Candy, because the only thing inside, by definition, is Candy.
But when they get to the end of the block, a grumpy old man who hates children begrudgingly opens the door. He looks down and sees the children all have Bags of Candy. But a Bag of Candy, he reasons, is also a Bag of Things. And the evil old man grabs a handful of RazorBlades — which are also Things — and puts them in the Bag of Things the children are holding.
Субъект — это тот, кто делает, объект — это тот над чем делают. Так как pedals это то, чем делают и объект на на нем, то метод относится у меня к объекту, а у вас к субъекту.
Машина для гонщика и машина для инженера обслуживания, это две разные модели одной и той же реальной сущности.
Для меня это противоположность Ubiquotous Language в DDD
class DrivingStart < LunaPark::Interactors::Sequence
def call! Service::CheckEngine.call Service::StartUpTheIgnition.call car, with: key Service::ChangeGear.call car.gear_box, to: :drive Service::StepOnTheGas.call car.pedals[:right]
end
end
В моей мысленной картине мира двигатель часть машины и никаких сервисов нет и я думаю как-то так:
car.engine.check
car.ignintion.startUp with:key
car.gear.change to: :drive
car.pedals.gas.press
Вопрос — зачем эти прослойки?
Вернее
сервис ответов на вопросы:: задать вопрос.сказать
сервис ответов на вопросы:: зачем.сказать
сервис ответов на вопросы:: эти.сказать
сервис ответов на вопросы:: прослойки.сказать
Возможно если вы генерируете текст, а для тестирования вам хочется использовать ast, то стоит подумать о том чтобы генерировать текст через ast? — тестирование распадётся на две фазы — проверка корректности ast и проверка корректности генерации кусков текста из кусков ast.
Другое дело что надо ещё проверять что СУБД интерпретирует все это вместе так как надо — но это можно сделать на других уровнях тестовой пирамиды
В скраме предполагается что команда в течение спринта работает над общей целью.
"Никогда в ней не будет" подразумевает, что либо есть жесткое разделение ролей и в каждой роли ровно один человек либо работа над постоянными разными участками (т.е. фактически разные команды или индивидуальное владение кодом) или еще что-то что я не знаю.
Так то же хорошо, но по моему опыту часто люди ничего не говорят, пока не задашь вопрос, хорошо, что есть время когда все уже отвлечены и можно привлечь внимание команды, а не тыкать всех в произвольный момент времени, можно увидеть какая проблема остается, а какая нет — т.е. относительная важность очевидна.
Я имею ввиду ежедневный ритм а не буквальное вставание в кружок
Интересно, как так получается — обычно у тех, кто работает над одним и тем же есть некоторые общие интересы, некоторый общий набор проблем — коллега может подсказать решение или он может зависеть от твоей работы.
Чувствовать или не чувствовать вину — ваш выбор.
Большие задачи обычно можно разбить на подзадачи.
Да, выкатка не value, но его содержит. Так же как канистра не является молоком, например, но может его содержать.
А можно ссылочку на MSA? Я попробовал найти, но не получилось
Адские ухищрения и использование дырок в системе вместо планирования, приоритезации и закрытия низкоприоритетных и неактуальных задач.
Кстати,
я не увидел в ваших поцедурах какой-то процесс, который бы отличал просрочку и "те, что поставлены недавно" — списывается все, что накопилось. Получается, при наступлении момента "индульгенции" авторы задач должны актуальное поставить еще раз, если им нужно?
Могу поделиться только тем, что читал:
https://en.wikipedia.org/wiki/Agile_contracts
https://martinfowler.com/bliki/ScopeLimbering.html
https://www.scaledagileframework.com/agile-contracts/
Это кроссфункциональность команды состоящей из одного человека. Мне кажется, это совсем неверное понимание термина — он просто совсем не то означает (см. доступные определения)
Т.е. бизнесу пофиг выкатят релиз или нет — никакого value нет?
Бывает не только джава
Объекты можно видеть по разному. Например "вычисление" тоже может быть объектом.
Это применимо только для некоторых дженериков. Хотя вы и сами это знаете. Фактически по самому факту, что T подтип T1 нельзя сказать что X является подтипом для X и конкретно для List это не так.
А кто из этих конкретных типов относится друг к другу как подтип?
(эта может быть та же самая ситуация, как с мутабельными кваратом и прямоугольником)
Субъект — это тот, кто делает, объект — это тот над чем делают. Так как pedals это то, чем делают и объект на на нем, то метод относится у меня к объекту, а у вас к субъекту.
Interface segregation principle?
Для меня это противоположность Ubiquotous Language в DDD
class DrivingStart < LunaPark::Interactors::Sequence
def call!
Service::CheckEngine.call
Service::StartUpTheIgnition.call car, with: key
Service::ChangeGear.call car.gear_box, to: :drive
Service::StepOnTheGas.call car.pedals[:right]
end
end
В моей мысленной картине мира двигатель часть машины и никаких сервисов нет и я думаю как-то так:
Вопрос — зачем эти прослойки?
Вернее
сервис ответов на вопросы:: задать вопрос.сказать
сервис ответов на вопросы:: зачем.сказать
сервис ответов на вопросы:: эти.сказать
сервис ответов на вопросы:: прослойки.сказать
Ну, а для ссылочных типов null есть. Фактически для них только Option был до 8.0
Чем именно вот это https://github.com/microsoft/referencesource/blob/master/mscorlib/system/nullable.cs отличается от option?
F#