Информационные системы — это моделирование. Модель это нечто, что отвечает на вопросе о некотором аспекте реального мира вместо реального мира. Информационная система должна отвечать на вопрос "какое имя абонента" вместо того чтобы каждый раз спрашивать у абонента. Именно поэтому как только мы немножко пошевелил ваш пример про телефонную книжку, чтобы сделать его более реальным оттуда вылез абонент. Неважно будет это отношение или класс — человеку удобно думать в в этих терминах. Просто у каждой среды моделирования есть свои ограничения.
Какого типа колонка "имя абонента"? Есть ли у абонента что-то кроме имени и телефонов? Что происходит если в имени абонента нашли опечатку или его надо переименовать?
Я так понял что оно будет проходить через 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.
Автор, к сожалению, почти не приводит ссылки на источники даже там, где мог бы по крайней мере попытаться.
Мне кажется что коммент тут компенсирует не отражающее значение название константы CashDiscount.
И судя по всему тут не проценты как написано в комменте а доли (нет деления на 100)
А если их название не полностью отражает того, что они делают?
Почему длинное название функции для вас абсурдно?
Информационные системы — это моделирование. Модель это нечто, что отвечает на вопросе о некотором аспекте реального мира вместо реального мира. Информационная система должна отвечать на вопрос "какое имя абонента" вместо того чтобы каждый раз спрашивать у абонента. Именно поэтому как только мы немножко пошевелил ваш пример про телефонную книжку, чтобы сделать его более реальным оттуда вылез абонент. Неважно будет это отношение или класс — человеку удобно думать в в этих терминах. Просто у каждой среды моделирования есть свои ограничения.
Насколько мне известно, это далеко не всегда так
Если я сделаю фреймворк, который не откажется, почему его нельзя будет назвать ORM?
Обычно мы вообще сохраняем состояние. Далее в ОЗУ состояние лежит отдельно, а проведение — отдельно.
Конкретное 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.
Автор, к сожалению, почти не приводит ссылки на источники даже там, где мог бы по крайней мере попытаться.
*тз пишется
Обычно из придётся в терминах предметной области. Юниты бизнес логики должны быть тоже в терминах предметной области.