Вообще, кодинг задача это не просто решил/не решил — это как решил, как рассуждал, какие вопросы задавал, насколько было понятно то, что он хочет сказать, что забыл упомянуть, понял ли после напоминания о чем идет речь и так далее.
Пример с машиной некорректен потому, что в нем просят продемонстрировать вождение, то есть то, что и будет делать водитель.
Он не будет водить на площадке и не будет парковаться с вешками. И вообще на любом испытании можно найти разницу с тем что будет на работе.
Чтобы абсолютно точно провести испытание, надо нанять пробно на работу на год, допустим, потом на машине времени вернуться назад и принять решение — нанимать или нет.
Моё рабочее место — бывшая детская с желтоватыми обоями и полным отсутствием естественного света.
Т.е. вообще комната без окон?
В офисе я сконцентрирован и энергичен, нахожусь в постоянном движении: перебежки из одной части опенспейса в другую, лифты, коридоры, кухня.
Дома тоже есть кухня, но всего остального нет.
Нету лифтов и коридоров? Вообще, можно сходить поесть в ближайшую кафешку или за продуктами или на спортплощадку или погулять.
Для меня единственное препятствие которое бы мне серьезно это маленькие дети дома. Или отсутствие отдельно комнаты или домашние которые не ценят сосредоточенность. Но с последними можно договориться
Юнит тесты это нечеткоепонятие. Обычно на уровне функций, но не всех функций (например, если надо протестировать приватный метод класса используют его публичный интерфейс).
Определения, на которые я ссылаюсь, я уже раз 20 повторил — сущность, модель, бизнес-логика.
Как ссылаясь только на эти понятия ответить на вопрос является ли х денормализацией y не используя определения слова "денормализация"?
Вот у вас есть треугольник и квадрат. Я хочу узнать квыклоупен ли треугольник квадрату или нет. Определение, что такое "квыклоупен" я вам не дам (существущие меня не устраивают, а своего я не буду описывать так как новые понятия я не вводил).
Нет, не значит. Еще 4-й вариант есть — я не вводил новых понятий, которым нужны определения.
Если вас не устраивает существующее определение, значит вы вводите какой-то другой способ соотносить объекты cо словом. Не является ли это введением нового понятия?
Если модель моделирует сущности предметной области без избыточности, значит неправильно говорить, что в модели есть избыточность.
Для этого надо понять что такое избыточность. В данном случае избыточностью я называю то, что можно не делать и получить тот же самый результат. Например можно не хранить складские остатки а вычислять их по документам. Значит избыточность есть. По крайней мере, пока есть ограничение. Нет?
Я считаю, что "брать" их в данном случае неправильно, так как они относятся к другому контексту.
Т.е. существующие определения вас не устраивают в применении к какому то контексту, правильно?
Значит:
Либо есть какие-то более правильные определения на которые вы можете сослаться.
Либо у вас есть свое определение (может быть неосознанное).
Либо вас будет трудно понимать.
Нет? Судя по вашему общению здесь получается третий пункт. Причем вы ссылаетесь на какие-то факты, как будто у нас есть еще какое-то определение денормализованности которым они противоречат.
Противоречит утверждению "Для целей моделирования — избыточно". Цель это то чего мы хотим.
Не противоречит. То, чего мы хотим изменилось. Так же как и в остатках "И если в предметной области появится правило, ...." — есть гипотетическая возможность изменения того, что мы моделируем.
Если бы у нас не было в предметной области понятия "остатки на складе", а было только "документы", тогда да, два элемента модели для моделирования суммы по документам это избыточность.
Тут от меня ускользает мысль. Если какие-то числа по тем ограничениям, о которых мы условились могут быть вычислены из других чисел, то их хранение избыточно. Потому, что их можно вычислить. Избыточно, это то, что можно не хранить и получить тот же результат. Если условия изменятся, мы можем хранить как-то по-другому. Например, вес и масса отличаются по определению и в каких-то случаях это может стать важным. Но пока мы условились работать на Земле хранение веса и массы избыточно.
Я считаю, что "брать" их в данном случае неправильно, так как они относятся к другому контексту.
Давайте тогда определим контекст явно, чтобы понимать друг друга. Желательно тогда дать определение денормализованности явно в этом другом контексте.
Я не считаю, что это денормализованность. И всё. Здесь нечего доопределять.
О! С этого и надо было начинать :D
Напомнило
— Когда я беру слово, оно означает то, что я хочу, не больше и не
меньше, — сказал Шалтай презрительно.
— Вопрос в том, подчинится ли оно вам, — сказала Алиса.
— Вопрос в том, кто из нас здесь хозяин, — сказал Шалтай-Болтай. — Вот в чем вопрос!
Нет, что он не получится постепенным продвижением по порядку тестов от самого простого к полному.
Я встречал рекомендации писать code spike если работа исследовательская, а потом писать prod код смотря в этот spike по TDD. Т.е. вся эта дисциплина типа pair programming относится к prod коду.
В этом примере избыточность другого рода на том же уровне абстракции.
Я про уровень абстракции на котором вы сравниваете две избыточности.
Если бы оно было избыточно, нам не надо было бы ни считать сумму по документам, ни хранить их отдельно. ]
НФ они про хранение а не про расчет. Хранение суммы с точки зрения декларированных ограничений избыточно. Оно нужно либо для быстродействия либо для того, чтобы, в дальнейшем проще мигрировать на другую схему без этого ограничения.
Так же как в примере с самолетом сиденья не нужны ни в каком виде.
Допустим мы хотим использовать ту же модель для демонстрации заказчикам или как игрушку. Фактически как вы проектируете навырост для модели когда возможен непосредственный ввод остатков.
данные по остаткам могут расходиться с документами в пределах какого-то времени, например пока не будет проведена полная инвентаризация,
Тогда встанет вопрос, надо ли допускать ввод непосредственно остатков в таблицу, или это должно быть что-то под номером, возможно кем-то утвержденное с какими-то статусами и так далее. Т.е. документ.
Кстати, я встречал системы, где водился дополнительный уровень "складские движения" которые были просто записью инкремента остатка на складе со ссылкой на источник.
наподобие поля "Поставщик" или "Клиент" для документов о краже материалов.
Оно всегда так будет в какой-то степени, потому, что обычно базы денормализованы. Это нормально. То, что у части документов будут заполнены какие-то поля а какие-то нет может быть на инфологической модели и в виде бизнес правил.
Вообще уровень абстракции реляционной модели он более низкий по сравнению с инфологической моделью и описывает в основном логику хранения.
Он не обязан 1:1 соответствовать бизнес сущностям.
Я говорил только о том, что (должно быть) неправильно говорить, что в описанной ситуации в модели есть денормализованность.
Если вы считаете что это та же денормализованность, про которую говорили Кодд и Дейт, то просто возьмем их определения. Если вы считаете, что это не та же денормализованность, то доопределите. У вас получается что вы сначала вводите ограничение в скопе моделирования, а потом сами же расширяете скоп чтобы от него отказаться.
Если б я видел какие-то такие организованные системы документации, я б сказал с уверенностью. Самое навороченное, что я видел был RUP, но это было сто лет назад и не знаю, чем там дело кончилось с ним. Есть какой-то Open UP эклипсовски.
На практике, я вижу инкрементность документации — т.е. кто-то описывает текущий инкремент, а потом он устаревает и через год надо ходить по истории и собирать эти икременты и применять их друг к другу, чтобы получить целостное представление.
В результате практичный способ оказывается конгломератом из кода, тестов, тасок и мозгов сотрудников которые дополняются только основными концепциями написанными в вики (потому, что основные концепции меняются редко и их не в лом поддерживать).
Детальное проектирование проще держать в коде и тестах.
Если у кого-то есть другой опыт, я бы с удовольствием про него почитал.
Но мы же достаточно интеллектуальны для того, чтобы отличить такое кодинг интервью от боле осмысленного
Вообще, кодинг задача это не просто решил/не решил — это как решил, как рассуждал, какие вопросы задавал, насколько было понятно то, что он хочет сказать, что забыл упомянуть, понял ли после напоминания о чем идет речь и так далее.
Я честно говоря, не знаю, что раздражает синьора. Простой кодинг с простым анализом алгоритмов?
По крайней мере он может проверит что кандидат не слабее его.
Он не будет водить на площадке и не будет парковаться с вешками. И вообще на любом испытании можно найти разницу с тем что будет на работе.
Чтобы абсолютно точно провести испытание, надо нанять пробно на работу на год, допустим, потом на машине времени вернуться назад и принять решение — нанимать или нет.
Т.е. вообще комната без окон?
Нету лифтов и коридоров? Вообще, можно сходить поесть в ближайшую кафешку или за продуктами или на спортплощадку или погулять.
Для меня единственное препятствие которое бы мне серьезно это маленькие дети дома. Или отсутствие отдельно комнаты или домашние которые не ценят сосредоточенность. Но с последними можно договориться
Юнит тесты это нечеткоепонятие. Обычно на уровне функций, но не всех функций (например, если надо протестировать приватный метод класса используют его публичный интерфейс).
Как ссылаясь только на эти понятия ответить на вопрос является ли х денормализацией y не используя определения слова "денормализация"?
Вот у вас есть треугольник и квадрат. Я хочу узнать квыклоупен ли треугольник квадрату или нет. Определение, что такое "квыклоупен" я вам не дам (существущие меня не устраивают, а своего я не буду описывать так как новые понятия я не вводил).
Если вас не устраивает существующее определение, значит вы вводите какой-то другой способ соотносить объекты cо словом. Не является ли это введением нового понятия?
Для этого надо понять что такое избыточность. В данном случае избыточностью я называю то, что можно не делать и получить тот же самый результат. Например можно не хранить складские остатки а вычислять их по документам. Значит избыточность есть. По крайней мере, пока есть ограничение. Нет?
Я просто вас совершенно не понимаю.
Вот тут вы пишете:
Т.е. существующие определения вас не устраивают в применении к какому то контексту, правильно?
Значит:
Нет? Судя по вашему общению здесь получается третий пункт. Причем вы ссылаетесь на какие-то факты, как будто у нас есть еще какое-то определение денормализованности которым они противоречат.
Не противоречит. То, чего мы хотим изменилось. Так же как и в остатках "И если в предметной области появится правило, ...." — есть гипотетическая возможность изменения того, что мы моделируем.
Тут от меня ускользает мысль. Если какие-то числа по тем ограничениям, о которых мы условились могут быть вычислены из других чисел, то их хранение избыточно. Потому, что их можно вычислить. Избыточно, это то, что можно не хранить и получить тот же результат. Если условия изменятся, мы можем хранить как-то по-другому. Например, вес и масса отличаются по определению и в каких-то случаях это может стать важным. Но пока мы условились работать на Земле хранение веса и массы избыточно.
Давайте тогда определим контекст явно, чтобы понимать друг друга. Желательно тогда дать определение денормализованности явно в этом другом контексте.
О! С этого и надо было начинать :D
— Когда я беру слово, оно означает то, что я хочу, не больше и не
меньше, — сказал Шалтай презрительно.
— Вопрос в том, подчинится ли оно вам, — сказала Алиса.
— Вопрос в том, кто из нас здесь хозяин, — сказал Шалтай-Болтай. — Вот в чем вопрос!
https://stackoverflow.com/questions/53761664/should-i-write-tests-first-following-tdd-for-the-view-layer-or-only-do-only-ma
Я встречал рекомендации писать code spike если работа исследовательская, а потом писать prod код смотря в этот spike по TDD. Т.е. вся эта дисциплина типа pair programming относится к prod коду.
Это вы просто вы предпочитаете смотреть на говно.
Прикиньте, сможет ли ваша организация разработать хром, например, с таким же уровнем надежности и скорости обновлений.
Я про уровень абстракции на котором вы сравниваете две избыточности.
НФ они про хранение а не про расчет. Хранение суммы с точки зрения декларированных ограничений избыточно. Оно нужно либо для быстродействия либо для того, чтобы, в дальнейшем проще мигрировать на другую схему без этого ограничения.
Допустим мы хотим использовать ту же модель для демонстрации заказчикам или как игрушку. Фактически как вы проектируете навырост для модели когда возможен непосредственный ввод остатков.
Тогда встанет вопрос, надо ли допускать ввод непосредственно остатков в таблицу, или это должно быть что-то под номером, возможно кем-то утвержденное с какими-то статусами и так далее. Т.е. документ.
Кстати, я встречал системы, где водился дополнительный уровень "складские движения" которые были просто записью инкремента остатка на складе со ссылкой на источник.
Оно всегда так будет в какой-то степени, потому, что обычно базы денормализованы. Это нормально. То, что у части документов будут заполнены какие-то поля а какие-то нет может быть на инфологической модели и в виде бизнес правил.
Вообще уровень абстракции реляционной модели он более низкий по сравнению с инфологической моделью и описывает в основном логику хранения.
Он не обязан 1:1 соответствовать бизнес сущностям.
Если вы считаете что это та же денормализованность, про которую говорили Кодд и Дейт, то просто возьмем их определения. Если вы считаете, что это не та же денормализованность, то доопределите. У вас получается что вы сначала вводите ограничение в скопе моделирования, а потом сами же расширяете скоп чтобы от него отказаться.
В гугле пишут тесты. Есть даже такая книжка "How Google Tests Software". То, что есть какие-то баги не значит, что тестов не пишут.
Кому-то дают, кому-то не дают. Те, кому не дают, обычно в итоге тратят больше времени на фикс багов.
Не знаю. Попробуйте погуглить.
Если б я видел какие-то такие организованные системы документации, я б сказал с уверенностью. Самое навороченное, что я видел был RUP, но это было сто лет назад и не знаю, чем там дело кончилось с ним. Есть какой-то Open UP эклипсовски.
На практике, я вижу инкрементность документации — т.е. кто-то описывает текущий инкремент, а потом он устаревает и через год надо ходить по истории и собирать эти икременты и применять их друг к другу, чтобы получить целостное представление.
В результате практичный способ оказывается конгломератом из кода, тестов, тасок и мозгов сотрудников которые дополняются только основными концепциями написанными в вики (потому, что основные концепции меняются редко и их не в лом поддерживать).
Детальное проектирование проще держать в коде и тестах.
Если у кого-то есть другой опыт, я бы с удовольствием про него почитал.
Можно посмотреть на книжку Эванса про DDD — там как раз рассматриваются агрегаты.
Тут не про то, как проще, а про то, как прикольнее