Вы таки определитесь, можно ли оценивать best practies в незнакомой среде, или нельзя (вроде ваших откровений о неприемлемости конкатенации в динамическом сиквеле). И если искать логические ошибки в малознакомой среде не сильно сложнее, то в чем вообще проблема - генерируй и ищи.
Буду проще: старый "Жигуль-копейка" с проржавевшим днищем тоже ездит, если его постоянно проверять и чинить. Является ли это авто надежным - вопрос риторический.
Сами же пишете, что генерирует лажу и нужно постоянно присматривать. Но на незнакомом стеке вы просто эту лажу не распознаете и присматривать не можете. Поэтому иллюзия, что "неплохо применять".
...хотя [тестирование] и способствует повышению надежности программного обеспечения, его значение ограниченно. Надежность невозможно внести в программу в результате тестирования, она определяется правильностью этапов проектирования. Наилучшее решение проблемы надежности — с самого начала не допускать ошибок в программе. Однако вероятность того, что удастся безупречно спроектировать большую программу, бесконечно мала. Роль тестирования состоит как раз в том, чтобы определить местонахождение немногочисленных ошибок, оставшихся в хорошо спроектированной программе. Попытки с помощью тестирования достичь надежности плохо спроектированной программы совершенно бесплодны.
приемлемый код генерируется только для обвязки и рутинного кода, однако не упоминается, что существует много детерминированных инструментов класса MDA/MDD/Software factory, также умеющих генерировать его из описаний
ТЗ превращается в подробнейщий псевдокод, но без картинок: диаграммы по прежниему только для людей, а чтобы сгенерировать из них что-то - см. пункт выше
код начинает восприниматься, как "черный ящик". Соответственно, в разы возрастают затраты на тестирование, которое теперь только по методу "черного ящика"
поскольку вместо исправления бага в одной строчке авторам "легче" откатиться и перегенировать всё заново, то тесты тоже придется массивно менять - см. предыдущий пункт
а если еще и тесты генерировать из БЯМ, то остается кропить святой водой сервера перед запуском
юниоры рассматриваются, как "плохие генераторы кода", а не будущие коллеги и смена - это приведет к вымиранию команд, описанных в статье в среднесрочной перспективе
Если модель анемичная, зачем городить весь этот огород? Задача проектировщика - упрощать сложное. "Репозиторий" звучит красиво, но за ширмой - дореляционный подход из 1950-70-х "на каждый запрос пишем программу". "Абстрагирование" от СУБД до уровня "умной файловой системы" в интенсивно использующих долгохранимые данные приложениях - путь к нерешаемым проблемам производительности именно по архитектурным причинам.
Однострочные лямбды экономичнее локальных функций, с этим, я думаю, никто не спорит. Маркером проблемы становится код, где лямбду помещают в локальную переменную, потом вызывают эту переменную. Однако 25 страниц разъяснений по поводу простой языковой конструкции типа auto означает её недостаточную продуманность.
Ваш пример с auto корректен, однако он также просто решается typedef. И не забудем, что Мейерс в "Effective Modern С++" посвятил 25 страниц разъяснениям, когда auto может "выстрелить в ногу"
Лямбды нужны ввиду отсутствия в языке локальных (вложенных) функций, которые гораздо лучше читаемы.
Несколько лет назад я начал писать рецензию "Книга ужасов "Effective Modern С++"", но "забил" на середине. Многие программисты пользуются только некоторым подмножеством стандарта языка и собственными наработками, но это тупик в развитии.
Интересно, что в Раст-сообществе тоже очень ревностно относятся к критике, причем если Си++ совместим с Си, то Раст не совместим ни с чем. Rust, или дожить бы до зрелости
Поведение задаётся реализацией класса (в том числе абстрактного) или интерфейса (интерфейс = чисто абстрактный класс в ООП). Наследование такой реализации - основное преимущество при повторном использовании и расширении функциональности.
ООП на концептуальном уровне это всего два положения:
все моделируемые сущности суть объекты
объекты взаимодействуют пересылкой сообщений
На логическом уровне реализация ООП отличается от других языков только наследованием реализации (извините за тавтологию), остальное в том или ином виде имеется и в других языках.
Создание первых ООП-языков - середина 1960-х годов (Симула-67 - "Алгол с классами"), как следует из названия, они предназначались для имитационного моделирования (объекты активны), а не для пассивных сущностей вроде счетов и накладных. Второе удачное применение - целиком искусственные миры, вроде элементов графического интерфейса пользователя.
Основные критерии эффективности подходов:
степень связности компонентов (модулей)
степень повторного использования кода
По этим пунктам ООП показывает хороший результат, если не впадать в фанатизм "чистой архитектуры" и трезво оценивать метрики, когда объемы превышают хотя бы 100К строк.
"Смешались в кучу кони, люди..." (с) Храните структурированные метаданные в структурированном же виде (таблицы с историей изменений, XML или JSON с подключенной схемой), сравнивайте их (N vs N-1). В маркдаун или еще куда-то выводите результаты, да хоть в Word.
Индекс отделен от данных в куче, а кластерный "индекс" это и есть сами данные, отсортированные по колонке (как правило, ключу). Нет никакой ложки никаких указателей. Если брать аналог с INCLUDE, то это будет индекс со включением в него всех колонок таблицы с соответствующим дублированием размера и данных таблицы.
Строк с автоинкрементным счетчиком недостаточно. Heap и cluster имеют физически разную организацию. В общем случае индекс на heap это дополнительный указатель, по которому нужно пройти, чтобы получить сами данные
Лучше так: "Решай простые задачи"
Ну, и риторическое: "Код, который сложен для одного, может быть простым для другого"
Вы таки определитесь, можно ли оценивать best practies в незнакомой среде, или нельзя (вроде ваших откровений о неприемлемости конкатенации в динамическом сиквеле). И если искать логические ошибки в малознакомой среде не сильно сложнее, то в чем вообще проблема - генерируй и ищи.
Буду проще: старый "Жигуль-копейка" с проржавевшим днищем тоже ездит, если его постоянно проверять и чинить. Является ли это авто надежным - вопрос риторический.
Сами же пишете, что генерирует лажу и нужно постоянно присматривать. Но на незнакомом стеке вы просто эту лажу не распознаете и присматривать не можете. Поэтому иллюзия, что "неплохо применять".
Цитата же про надёжность, а не про отладку "большого кома грязи" прямо в эксплуатации.
И еще процитирую классику
Если подытожить:
приемлемый код генерируется только для обвязки и рутинного кода, однако не упоминается, что существует много детерминированных инструментов класса MDA/MDD/Software factory, также умеющих генерировать его из описаний
ТЗ превращается в подробнейщий псевдокод, но без картинок: диаграммы по прежниему только для людей, а чтобы сгенерировать из них что-то - см. пункт выше
код начинает восприниматься, как "черный ящик". Соответственно, в разы возрастают затраты на тестирование, которое теперь только по методу "черного ящика"
поскольку вместо исправления бага в одной строчке авторам "легче" откатиться и перегенировать всё заново, то тесты тоже придется массивно менять - см. предыдущий пункт
а если еще и тесты генерировать из БЯМ, то остается кропить святой водой сервера перед запуском
юниоры рассматриваются, как "плохие генераторы кода", а не будущие коллеги и смена - это приведет к вымиранию команд, описанных в статье в среднесрочной перспективе
В розничной торговле это называется расфасовка. В универсамах целые отделы занмимаются, рафасовкой сыров и колбас.
Если модель анемичная, зачем городить весь этот огород? Задача проектировщика - упрощать сложное. "Репозиторий" звучит красиво, но за ширмой - дореляционный подход из 1950-70-х "на каждый запрос пишем программу". "Абстрагирование" от СУБД до уровня "умной файловой системы" в интенсивно использующих долгохранимые данные приложениях - путь к нерешаемым проблемам производительности именно по архитектурным причинам.
Чистые архитектуры и вакуум
Как вы стали миллионером? - Всю жизнь работал по 60 часов в неделю, а потом дедушка оставил мне наследство.
Однострочные лямбды экономичнее локальных функций, с этим, я думаю, никто не спорит. Маркером проблемы становится код, где лямбду помещают в локальную переменную, потом вызывают эту переменную.
Однако 25 страниц разъяснений по поводу простой языковой конструкции типа auto означает её недостаточную продуманность.
Ваш пример с auto корректен, однако он также просто решается typedef. И не забудем, что Мейерс в "Effective Modern С++" посвятил 25 страниц разъяснениям, когда auto может "выстрелить в ногу"
Лямбды нужны ввиду отсутствия в языке локальных (вложенных) функций, которые гораздо лучше читаемы.
Недавно было обсуждение, где я было пожаловался на те же проблемы отсутствия в стандартной библиотеке не то что сетевых средств, но даже ведения логов! Тут же получил тучу минусов от блюстителей непонятно чего. Действительно, возникает ощущение стандартизации, как самоцели, при этом процветает практика добавления "сделать то же самое, но по-новому" вместо действительно нужной функциональности.
Несколько лет назад я начал писать рецензию "Книга ужасов "Effective Modern С++"", но "забил" на середине. Многие программисты пользуются только некоторым подмножеством стандарта языка и собственными наработками, но это тупик в развитии.
Интересно, что в Раст-сообществе тоже очень ревностно относятся к критике, причем если Си++ совместим с Си, то Раст не совместим ни с чем. Rust, или дожить бы до зрелости
Поведение задаётся реализацией класса (в том числе абстрактного) или интерфейса (интерфейс = чисто абстрактный класс в ООП). Наследование такой реализации - основное преимущество при повторном использовании и расширении функциональности.
ООП на концептуальном уровне это всего два положения:
все моделируемые сущности суть объекты
объекты взаимодействуют пересылкой сообщений
На логическом уровне реализация ООП отличается от других языков только наследованием реализации (извините за тавтологию), остальное в том или ином виде имеется и в других языках.
Создание первых ООП-языков - середина 1960-х годов (Симула-67 - "Алгол с классами"), как следует из названия, они предназначались для имитационного моделирования (объекты активны), а не для пассивных сущностей вроде счетов и накладных. Второе удачное применение - целиком искусственные миры, вроде элементов графического интерфейса пользователя.
Основные критерии эффективности подходов:
степень связности компонентов (модулей)
степень повторного использования кода
По этим пунктам ООП показывает хороший результат, если не впадать в фанатизм "чистой архитектуры" и трезво оценивать метрики, когда объемы превышают хотя бы 100К строк.
"Смешались в кучу кони, люди..." (с) Храните структурированные метаданные в структурированном же виде (таблицы с историей изменений, XML или JSON с подключенной схемой), сравнивайте их (N vs N-1). В маркдаун или еще куда-то выводите результаты, да хоть в Word.
Индекс отделен от данных в куче, а кластерный "индекс" это и есть сами данные, отсортированные по колонке (как правило, ключу). Нет
никакой ложкиникаких указателей.Если брать аналог с INCLUDE, то это будет индекс со включением в него всех колонок таблицы с соответствующим дублированием размера и данных таблицы.
Строк с автоинкрементным счетчиком недостаточно. Heap и cluster имеют физически разную организацию. В общем случае индекс на heap это дополнительный указатель, по которому нужно пройти, чтобы получить сами данные
Опция INCLUDE существует в SQL Server очень давно. Я бы предложил вам разобраться, в чем отличие кластерных индексов от предлагаемой вами "замены".