Pull to refresh
18
0
Микола @nik_man

Консультант по вопросам автоматизации предприятий

Send message

Спасибо за статью. Автор отчетливо говорит, что immutability не должна являться правилом. Єто скорее инструмент, которьій нужно использовать в специальньіх ситуациях. Их не так уж и много, практически всего две:

  1. Отслеживание изменений состояния.

  2. Использование многопоточности.

Кроме того, бьівають различньіе случаи требований бизнес-логики. Скорее исключения из общего правила. Можно упомянуть принцип pure functions. Однако, несмотря на явную схожесть pure functions and immutability -- ето два совершенно разньіх принципа. Pure functions не должньі менять ничего и нигде, независимо от того, нужна ли хоть где-то immutability или нет. Автор правильно и неоднократно упомянул, что immutability -- єто излишняя нагрузка на производительность и память. Его нужно применять осознанно. Но слово красивое и джуньі иногда начинают использовать єтот принцип буквально везде:

function getData() {
  const data = { a: 1 };
  // есть еще одно свойство?
  const data2 = { ...data, b: 2 };
  // еще свойство?
  const data3 = { ...data2, c: 3 };
  // immutability -- ето важно!
  return {
    ...data3,
    d: 4,
  };
}

Увлеченность иммутабельностью часто ходит рядом с приверженностью использовать Array.map(...) при любьіх изменениях данньіх в массиве. Immutability -- хороший принцип, когда он важен, и наоборот. Впрочем как и все в программировании.

Подскажите, пожалуйста, а как с этим в Украине? Признаться, не смог нагуглить ничего внятного.
Стругацкие «Страна багровых туч» — про Венеру. Тропики, рай?
По теме — очередная заявка на проект «не имеющий аналогов», вроде базы на Луне. Ну да, конечно, верим.
Спасибо. Цель понятна. Сделать универсальный доступ к БД любого формата. Ну и снизить порог вхождения. Не нужно знать отдельные СУБД. Для этого создали свой SQL, внутренний.
Но почему такие нечитабельные названия таблиц?
Ваш и предыдущие посты выглядят как возражения, а по факту являются подтверждением. В любом случае «плательщик НДС» не тратит своих денег на этот налог. Даже если он его платит из собственных средств до того как получит возмещение/компенсацию (как это не называй). Это обычная ситуация — возникает «налоговый кредит». Как будто выдает кредит государству, беспроцентный, конечно. И обязательно вернет его, когда получит возмещение/компенсацию от настоящего плательщика НДС — конечного потребителя.
Конечно, он может не создавать «добавленную стоимость» и работать в убыток, тогда да, он будет платить НДС из своих средств… но вряд ли это будет долго продолжаться.
Посредник (налоговый агент, «плательщик НДС») не платит НДС. Вообще. Весь НДС, который он перечисляет государству и другим налоговым агентам, он получает от конечного потребителя. Ни одной своей копейки он не тратит на этот налог. Или есть исключения?
Субконто специально пометил как термин, которого нет в бухгалтерском учете. Хотя на слуху в определенном сообществе. Может получилось неоднозначно?
Спасибо за развернутый ответ. Стало понятно.
Вам не кажется, что в этом случае, вы решаете проблемы, созданные искусственно? Ведь разработчики платформы могли бы создать БД с классическими названиями таблиц: documents, journal, agents и т.д. Могли бы не менять эти названия в обновлениях. С какой целью вообще разработчики так усложняют структуру БД и работу программистов?
Признаться, да.
Бренд 1С — это головная боль. Пользователи уверены, что все должно быть «как в 1с». Хотя интерфейс программы откровенно неудобный. Но еще хуже, когда разработчики программ считают, что должно быть «похоже на 1с». Складывается впечатление, что пользователи искалечены интерфейсом. Программисты искалечены кириллическим ЯП и кириллическим подобием SQL.
Искалеченные люди просят костылей. А мы не понимаем, зачем костыли, когда можно ходить двумя здоровыми ногами без них. Бухучет — это просто. И программы для бухучета можно делать простыми, быстрыми и удобными.
Разработки на 1С так же тесно переплетены с прямыми запросами к MS-SQL,
Подскажите, а что, в 1С можно делать прямые запросы к базе данных? Прям на T-SQL? Насколько я знаю, там нечитабельная структура данных. Кроме как встроенным языком до них трудно добраться.
Разве автор писал что-нибудь про 1С?
Автор занимается украинскими программами.
Но бухгалтерская терминология примерно одинакова для любых бухгалтерских программ. Они же бухгалтерские. Другое дело, что иногда используется как попало. Вперемешку термины из различных отраслей и даже из различных стран.

Кстати, автоматизацией аптек мы тоже занимались. Все довольны. Базы не падают. Никто их не восстанавливает по пол-дня. Никаких пересменок по два часа, чтобы скачать данные в центральный офис.

Украинский аптечный холдинг: 200 аптек, основные БД: 21 млн. и 104 млн. проводок, всего около 10 баз данных, таблица партий около 7 млн записей. Все крутится круглосуточно и непрерывно.
В терминах 1с объяснить бухгалтерию нельзя.

Согласен. Но где вы увидели «термины 1с»?
Надо подумать. Вообще-то цель была — приятное знакомство с бухгалтерскими терминами, чтобы программист/настройщик/продавец-ПО мог более-менее спокойно вести диалог с пользователем-бухгалтером. Да, пожалуй, вы правы. Можно будет расшифровать общие принципы расчета зарплаты. И спрятать под кат, на всякий случай. ))
Добавил уточнение, что примеры из украинского учета.
Уточнение добавил.

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Registered
Activity