Это готовое решение, готовая платформа. Как ни крути. Притом концептуально это именно ES, на уровне платформы.
Я думаю лучше брать какие-то примеры по сбору и анализу метрик, например. Не лезть в бизнес и тем более корпоративные решения.
Простой gps-трэкер тоже хороший пример. Накидываем координаты - лог, видим маршрут на карте - вью. А если бы мы просто фиксировали текущие координаты, то маршрут не отследить.
В биллинг системе мы просто фиксируем факт звонка и длительность. А потом мы все это складываем и получаем счет.
Без обид, но штат 25 человек и пример одного кандидата ... Это как случайно споткнуться и выдать исследование о высоте плинтусов. Искренне надеюсь, что самому Вам понравилось и было интересно.
Табличка с заказом это на самом деле 3 таблички. 1 таблица - id заказа и данные о заказчике. 2 таблица - состояния заказов, 3 табличка - содержимое заказа. При оплате заказа, создается задание на отгрузку, которое отражается также тремя таблицами, аналогично. Далее запросом можно уже получать количество и содержимое заказов, оплаты по ним и отгрузки.
Считаем сколько мы заплатили за это программисту, закрываем бизнес пока не дошло до продажи почки.
Кому нужна надежность в оплате и отгрузке заказов, те купят 1С. Ну или битрикс. Ну другое готовое решение. В здравом уме никто не закажет разработку такого.
Пытаться найти что-то новое в платежах и заказах это прекрасно как любое изобретение велосипеда. Найти бы дураков, которые за такое платят.
Если опыт работы соответствует резюме, то скорее всего никаких сюрпризов не будет. В среднем, на прежнем месте работы, у человека был такой же наниматель, как и вы. Это больше про техническую часть, конечно. Специалист по персоналу может сказать как человек поведет себя в коллективе, конфликтен ли, есть лидерские качества и все такое. Но это совсем другое образование и другая специальность, далекая от технарей. И я таких вообще пока не особо видел =)
Можно быть скромнее и браться за менее амбициозные задачи :) Я не настаиваю на абсолюте, в бизнесе всегда приходится балансировать. Но вот так по-человечески, как творческой единице, лучше сначала придумать. Можно упростить немного. Не начинать задач с открытым финалом.
Так она сама по себе архитектурно так устроена, что все действия оформляются документами, которые при "проведении" меняют состояние регистров (остатки запасов, состояния и прочее). Сама платформа так устроена. Журнал документов это "event store", регистры это "query storage". Документы легко переносятся из системы управленческого учета, в систему бух. учета и при проведении там, формируют другую базу для запросов. Собственно она и используется и для логистики и для финансов и вообще для любого бизнеса.
В 7.7 версии был единый журнал для всех событий, что оказалось плохой идеей, так как транзакция записи одного документа, блокировала запись любых остальных.
Это само ничего не закрасит, это создаст для каждой точки список соседей такого же цвета. Далее вы начинаете из любой точки внутри области и обходите по этому графу все точки внутри этой области.
"Особенности национального ИТ" =)) Нужен сюжет с медведем, коровой и талантливыми доярками, смекающими про неверный алгоритм сортировки и утешающих тощего сирого аспиранта. Авось выживет, коли Бог даст.
Победили "скрипты", которые замечательно живут на неизменяемых готовых библиотеках классов. Сам процесс создания класса, должен заставить человека задуматься, что он творит и во что лезет. Это сотни-тысячи часов проектирования, реализации и тестирования, которые до него уже тысячи раз были потрачены.
И я очень надеюсь, что ChatGPT и т.п, наконец избавят человечество от этого обезьяньего труда, делать что-то только потому, что не можешь найти готовую реализацию.
Ну перестали же повсеместно писать свои ДОС и браузеры.
Призвать увеличивать связанность кода для облегчения поддержки ... Ну такое. Поэтому у вас и бывают задачи "перезаписать все функции", вы все не так проектируете.
В данном примере, для уменьшения связанности нужен интерфейс по сериализации и десериализации данных объекта, которые будут передавать в БД, микросервисы, разное.
В каждом слое объект выглядит не так, как в других. Это касается отображения, поведения, хранения и у каждого слоя несколько вариантов и сам он делится на еще несколько.
А так, отправили объект в очередь, оттуда он разлетелся в БД, сайт, прочим партнерам. И вот это уже можно не просто поддерживать, но и развивать и масштабировать.
И мы же позволяем его вызывать только классам произведенным от абстрактного экскаватора. Потому, что копают экскаваторы одинаково, а копается земля везде по-разному.
Каждый объект хранится в БД при этом поддерживается несколько СУБД. Но из всех прелестей ООП остается только инкапсуляция и околополиморфизм =). Т.е. нельзя изменить существующие абстракции никак, потому что нет наследования, как такового.
И управляется это все скриптовым языком.
Наверное можно найти аналогию с Питоном, который можно использовать как скрипт управления набором готовых неизменяемых классов.
Ну такой постООП. Мне кажется на текущий момент уже невозможно написать свой уникальный класс и даже набор абстракций. Берется готовый набор (фреймворк) и связывается процедурными языками, скриптами, разным.
Это готовое решение, готовая платформа. Как ни крути. Притом концептуально это именно ES, на уровне платформы.
Я думаю лучше брать какие-то примеры по сбору и анализу метрик, например. Не лезть в бизнес и тем более корпоративные решения.
Простой gps-трэкер тоже хороший пример. Накидываем координаты - лог, видим маршрут на карте - вью. А если бы мы просто фиксировали текущие координаты, то маршрут не отследить.
В биллинг системе мы просто фиксируем факт звонка и длительность. А потом мы все это складываем и получаем счет.
И главный вопрос возникает - а кто делает иначе?
Про возраст понятнее не стало =)
Без обид, но штат 25 человек и пример одного кандидата ... Это как случайно споткнуться и выдать исследование о высоте плинтусов. Искренне надеюсь, что самому Вам понравилось и было интересно.
Табличка с заказом это на самом деле 3 таблички. 1 таблица - id заказа и данные о заказчике. 2 таблица - состояния заказов, 3 табличка - содержимое заказа. При оплате заказа, создается задание на отгрузку, которое отражается также тремя таблицами, аналогично. Далее запросом можно уже получать количество и содержимое заказов, оплаты по ним и отгрузки.
Считаем сколько мы заплатили за это программисту, закрываем бизнес пока не дошло до продажи почки.
Кому нужна надежность в оплате и отгрузке заказов, те купят 1С. Ну или битрикс. Ну другое готовое решение.
В здравом уме никто не закажет разработку такого.
Пытаться найти что-то новое в платежах и заказах это прекрасно как любое изобретение велосипеда. Найти бы дураков, которые за такое платят.
Я исхожу из нормального хода событий, при котором на резюме без важных Х вы не отвечаете.
Все сделанное, сначала придумано. Это неизбежный процесс. Ни секунды не потеряете, если сначала придумаете.
А в чем проблема продумать до конца?
Если опыт работы соответствует резюме, то скорее всего никаких сюрпризов не будет. В среднем, на прежнем месте работы, у человека был такой же наниматель, как и вы. Это больше про техническую часть, конечно. Специалист по персоналу может сказать как человек поведет себя в коллективе, конфликтен ли, есть лидерские качества и все такое. Но это совсем другое образование и другая специальность, далекая от технарей. И я таких вообще пока не особо видел =)
Я не предлагаю делить N. Вы из Питера чтоль?
Можно быть скромнее и браться за менее амбициозные задачи :) Я не настаиваю на абсолюте, в бизнесе всегда приходится балансировать. Но вот так по-человечески, как творческой единице, лучше сначала придумать. Можно упростить немного. Не начинать задач с открытым финалом.
Не стоит приступать к реализации того, что не придумано до конца.
Сначала сделай как изначально придумал.
В проекте должна быть цифра N. Любая задача, предполагающая больше времени, чем N, должна быть разбита на подзадачи.
Собеседование позволяет просто проверить, что заявленное в резюме верно. Больше, чем из резюме, не узнаете.
Краткие ежедневные митинги по делу и профессионально - хорошее начало дня.
Так она сама по себе архитектурно так устроена, что все действия оформляются документами, которые при "проведении" меняют состояние регистров (остатки запасов, состояния и прочее). Сама платформа так устроена. Журнал документов это "event store", регистры это "query storage". Документы легко переносятся из системы управленческого учета, в систему бух. учета и при проведении там, формируют другую базу для запросов. Собственно она и используется и для логистики и для финансов и вообще для любого бизнеса.
В 7.7 версии был единый журнал для всех событий, что оказалось плохой идеей, так как транзакция записи одного документа, блокировала запись любых остальных.
Решений действительно мало, всё сожрала 1С.
Это само ничего не закрасит, это создаст для каждой точки список соседей такого же цвета. Далее вы начинаете из любой точки внутри области и обходите по этому графу все точки внутри этой области.
"Особенности национального ИТ" =)) Нужен сюжет с медведем, коровой и талантливыми доярками, смекающими про неверный алгоритм сортировки и утешающих тощего сирого аспиранта. Авось выживет, коли Бог даст.
Победили "скрипты", которые замечательно живут на неизменяемых готовых библиотеках классов. Сам процесс создания класса, должен заставить человека задуматься, что он творит и во что лезет. Это сотни-тысячи часов проектирования, реализации и тестирования, которые до него уже тысячи раз были потрачены.
И я очень надеюсь, что ChatGPT и т.п, наконец избавят человечество от этого обезьяньего труда, делать что-то только потому, что не можешь найти готовую реализацию.
Ну перестали же повсеместно писать свои ДОС и браузеры.
Да, невнимательно прочитал.
Но Вы настаиваете на тоталитарной и беспощадной связанности кода, а это путь прямиком в Ад.
В моем понимание все БЛ должны иметь общий интерфейс совместимый с общим интерфейсом БД и тогда с этим можно работать.
Призвать увеличивать связанность кода для облегчения поддержки ... Ну такое.
Поэтому у вас и бывают задачи "перезаписать все функции", вы все не так проектируете.
В данном примере, для уменьшения связанности нужен интерфейс по сериализации и десериализации данных объекта, которые будут передавать в БД, микросервисы, разное.
В каждом слое объект выглядит не так, как в других. Это касается отображения, поведения, хранения и у каждого слоя несколько вариантов и сам он делится на еще несколько.
А так, отправили объект в очередь, оттуда он разлетелся в БД, сайт, прочим партнерам. И вот это уже можно не просто поддерживать, но и развивать и масштабировать.
И мы же позволяем его вызывать только классам произведенным от абстрактного экскаватора. Потому, что копают экскаваторы одинаково, а копается земля везде по-разному.
Каждый объект хранится в БД при этом поддерживается несколько СУБД. Но из всех прелестей ООП остается только инкапсуляция и околополиморфизм =). Т.е. нельзя изменить существующие абстракции никак, потому что нет наследования, как такового.
И управляется это все скриптовым языком.
Наверное можно найти аналогию с Питоном, который можно использовать как скрипт управления набором готовых неизменяемых классов.
Ну такой постООП. Мне кажется на текущий момент уже невозможно написать свой уникальный класс и даже набор абстракций. Берется готовый набор (фреймворк) и связывается процедурными языками, скриптами, разным.