Какого типа колонка "имя абонента"? Есть ли у абонента что-то кроме имени и телефонов? Что происходит если в имени абонента нашли опечатку или его надо переименовать?
Я так понял что оно будет проходить через convert и делиться на два варианта (either) — либо оно конвертится в число или нет. Если конвертится то система типов дальше сможет использовать тот факт что строка конвертится. Но при этом непонятно какой в этом прок — что мы дальше будем делать с этой строкой если число уже получили
Приведите пример кусочка спеки на компилятор, пожалуйста. Насколько я знаю обычно язык описывается отдельно, а кодогенерация — отдельно.
Не "a + b должно приводить к генерации add ax, bx, а "a + b это сложение, сложение должно приводить г генерации add ax, bx". Человеку неудобно будет работать со спекой, где грамматика и кодогенерация будет в одной большой куче.
Мы это с ним уже обсуждали. Модульных тестов не бывает. А так как их не бывает то и модулей не бывает (см его статью — модуль это то что можно протестировать отдельно). Ссылки на Фаулера с sociable unit tests не катят.
"Три года назад я пришел в Dodo Pizza в качестве Chief Agile Officer"
А какая квалификация у человека который претендует на роль chief agile officer? Т.е. получается кто-то пришел на громкую должность в компании потом начал учиться методом проб и ошибок и помолом только начал применять самые известные инженерные практики? Или я как-то не так понимаю статью?
В моем представлении на роль chief нужен человек который уже знает как это работает или по крайней мере теоретически как должно, и взятие инженерного долга должно быть просчитанным решением (типа на данном этапе развития нам не надо быстродействия но зато потом мы это наверстаем) но тогда это не стыд и позор.
Yes. This is a link to a study by Boby George and Laurie Williams at NCST and a another by Nagappan et al. I'm sure there are more. Dr. Williams publications on testing may provide a good starting point for finding them.
[EDIT] The two papers above specifically reference TDD and show 15-35% increase in initial development time after adopting TDD, but a 40-90% decrease in pre-release defects. If you can't get at the full text versions, I suggest using Google Scholar to see if you can find a publicly available version.
Автор, к сожалению, почти не приводит ссылки на источники даже там, где мог бы по крайней мере попытаться.
Возможно если вы генерируете текст, а для тестирования вам хочется использовать ast, то стоит подумать о том чтобы генерировать текст через ast? — тестирование распадётся на две фазы — проверка корректности ast и проверка корректности генерации кусков текста из кусков ast.
Другое дело что надо ещё проверять что СУБД интерпретирует все это вместе так как надо — но это можно сделать на других уровнях тестовой пирамиды
Я тут не о том, что их нет, а скорее про то, что если вы каждый день будете две минуты про них рассказывать тем, кто все равно не в теме (и никогда в ней не будет) — ничего не изменится.
В скраме предполагается что команда в течение спринта работает над общей целью.
"Никогда в ней не будет" подразумевает, что либо есть жесткое разделение ролей и в каждой роли ровно один человек либо работа над постоянными разными участками (т.е. фактически разные команды или индивидуальное владение кодом) или еще что-то что я не знаю.
Так то же хорошо, но по моему опыту часто люди ничего не говорят, пока не задашь вопрос, хорошо, что есть время когда все уже отвлечены и можно привлечь внимание команды, а не тыкать всех в произвольный момент времени, можно увидеть какая проблема остается, а какая нет — т.е. относительная важность очевидна.
Я имею ввиду ежедневный ритм а не буквальное вставание в кружок
Интересно, как так получается — обычно у тех, кто работает над одним и тем же есть некоторые общие интересы, некоторый общий набор проблем — коллега может подсказать решение или он может зависеть от твоей работы.
Обычно мы вообще сохраняем состояние. Далее в ОЗУ состояние лежит отдельно, а проведение — отдельно.
Конкретное ORM требует, чтобы соответствовало, все существующие ORM требует чтобы соответствовало или само понятие ORM требует, чтобы соответствовало?
Какого типа колонка "имя абонента"? Есть ли у абонента что-то кроме имени и телефонов? Что происходит если в имени абонента нашли опечатку или его надо переименовать?
А это не не значит, что сведения, например, об имени абонента будет в нескольких записях таблицы? Как там будет с нормализацией?
Я так понял что оно будет проходить через convert и делиться на два варианта (either) — либо оно конвертится в число или нет. Если конвертится то система типов дальше сможет использовать тот факт что строка конвертится. Но при этом непонятно какой в этом прок — что мы дальше будем делать с этой строкой если число уже получили
Да, наверное надо было погуглить. Помню, что в uml на deployment diagram именно компоненты.
Откуда вы взяли про уровни?
Возьмём определение отсюда?
https://en.m.wikipedia.org/wiki/Component-based_software_engineering#Software_component
Приведите пример кусочка спеки на компилятор, пожалуйста. Насколько я знаю обычно язык описывается отдельно, а кодогенерация — отдельно.
Не "a + b должно приводить к генерации add ax, bx, а "a + b это сложение, сложение должно приводить г генерации add ax, bx". Человеку неудобно будет работать со спекой, где грамматика и кодогенерация будет в одной большой куче.
У вас свое собственное определение компонентов. Обычно это — единица развертывания
Мы это с ним уже обсуждали. Модульных тестов не бывает. А так как их не бывает то и модулей не бывает (см его статью — модуль это то что можно протестировать отдельно). Ссылки на Фаулера с sociable unit tests не катят.
Так это он про "без них" (хотя я не понимаю почему просил не восстановить базу из бекапа)
А какая квалификация у человека который претендует на роль chief agile officer? Т.е. получается кто-то пришел на громкую должность в компании потом начал учиться методом проб и ошибок и помолом только начал применять самые известные инженерные практики? Или я как-то не так понимаю статью?
В моем представлении на роль chief нужен человек который уже знает как это работает или по крайней мере теоретически как должно, и взятие инженерного долга должно быть просчитанным решением (типа на данном этапе развития нам не надо быстродействия но зато потом мы это наверстаем) но тогда это не стыд и позор.
Почему? По проведенной информации нельзя сказать был это юниттест или интеграционный
Это надо мерять
Вот что нашел по быстрому https://stackoverflow.com/questions/237000/is-there-hard-evidence-of-the-roi-of-unit-testing
Yes. This is a link to a study by Boby George and Laurie Williams at NCST and a another by Nagappan et al. I'm sure there are more. Dr. Williams publications on testing may provide a good starting point for finding them.
[EDIT] The two papers above specifically reference TDD and show 15-35% increase in initial development time after adopting TDD, but a 40-90% decrease in pre-release defects. If you can't get at the full text versions, I suggest using Google Scholar to see if you can find a publicly available version.
Автор, к сожалению, почти не приводит ссылки на источники даже там, где мог бы по крайней мере попытаться.
*тз пишется
Обычно из придётся в терминах предметной области. Юниты бизнес логики должны быть тоже в терминах предметной области.
Возможно если вы генерируете текст, а для тестирования вам хочется использовать ast, то стоит подумать о том чтобы генерировать текст через ast? — тестирование распадётся на две фазы — проверка корректности ast и проверка корректности генерации кусков текста из кусков ast.
Другое дело что надо ещё проверять что СУБД интерпретирует все это вместе так как надо — но это можно сделать на других уровнях тестовой пирамиды
В скраме предполагается что команда в течение спринта работает над общей целью.
"Никогда в ней не будет" подразумевает, что либо есть жесткое разделение ролей и в каждой роли ровно один человек либо работа над постоянными разными участками (т.е. фактически разные команды или индивидуальное владение кодом) или еще что-то что я не знаю.
Так то же хорошо, но по моему опыту часто люди ничего не говорят, пока не задашь вопрос, хорошо, что есть время когда все уже отвлечены и можно привлечь внимание команды, а не тыкать всех в произвольный момент времени, можно увидеть какая проблема остается, а какая нет — т.е. относительная важность очевидна.
Я имею ввиду ежедневный ритм а не буквальное вставание в кружок
Интересно, как так получается — обычно у тех, кто работает над одним и тем же есть некоторые общие интересы, некоторый общий набор проблем — коллега может подсказать решение или он может зависеть от твоей работы.
Чувствовать или не чувствовать вину — ваш выбор.
Большие задачи обычно можно разбить на подзадачи.