Из личного опыта (и той методологии, в которой сейчас работаем) схема немного сложнее.
То, что хочет заказчик, называется BRD - бизнес-требования. Они согласуются с заказчиком. Все, что делается дальше, уже является внутренними документами исполнителя.
На основе BRD сначала разрабатывается архитектурное решение - там уже архитектура, дробление на модули, связь между модулями и т.д. и т.п. Это работа архитектора.
На основе архитектурного решения разрабатывается FSD - это уже ТЗ для конкретного исполнителя (разработчика). Разработкой FSD занимается аналитик (возможно, совместно с разработчиком, если уровень разработчика позволяет). Там уже описываются технические подробности реализации.
Как оформлять каждый из документов - это уже зависит от контекста, предметной области и много чего. Где-то удобнее использовать модель данных, где-то функциональную модель. Но суть примерно такова - есть документ который согласуется с заказчиком, есть внутренние документы исполнителя. И это разные документы, он "на разных языках" пишутся и с разными целями. Заказчику важно получить функционал, закрыть свои потребности. И ему совершенно не важно какие там алгоритмы будут реализованы.
Конечному исполнителю (разработчику) важно не только в каком виде должен быть представлен результат, но и как его получить (например, какие таблицы по каким условиям связать для получения выборки, как обработать полученную выборку и т.п.)
Представлять все это в виде одного документа неудобно никому - ни заказчику (там будет слишком много технических подробностей), ни исполнителю (там будет много того, что ему, в общем-то, не нужно).
Делается некоторая "витрина". Для ее первичного наполнения пишется некоторый модуль с очень жесткими требованиями по производительности (хотя бы потому что оценочно там будет порядка 400млн записей, а запись это не просто что-то выдернутое из другой таблицы, а результат некоторой обработки некоторого объема данных - на то она и витрина).
Изначально были выставлены одни требования. И вроде как все сделали, но тут "концепция поменялась". И стало понятно что базовый алгоритм, дающий хорошую производительность для старых требований, никуда не годится для новых. Т.е. переделать нужно процентов 75-80 написанного... И никакая модульность тут на спасет - это само по себе "модуль" в составе еще более крупной задачи.
А они неотделимы. В той системе суть в том, что на объектах (зданиях) есть некоторое инженерное оборудование. Которое должно мониторится и управляться из диспетчерской. И нужно "железо", которое будет осуществлять сбор информации с оборудования, передачу ее на диспетчерскую (и обратно). И нужен софт, который всю это информацию на диспетчерской собирает и представляет с удобном для человека (диспетчера) виде. Ну и логирование всякое и прочее и прочее.
Сам софт без железа работать не будет. Железо без софта тоже. Так что это, как говорили во времена оные, "аппаратно-программный комплекс". Единый и неделимый.
И в разработке там участвуют и разработчики верхнего уровня и схемотехники (как по цифре, так и по аналогу), разработчики прошивок для контроллеров... И пока они не согласуют между собой все детали (архитектура сети, протоколы обмена, формат адресации устройств и еще кучу вещей), начинать что-то делать бессмысленно - велика вероятность что придется все переделывать (заказывать новые платы, компоненты, все это заново монтировать и т.д. и т.п.).
Ещё неизвестно, что вы вкладываете в понятие ТЗ. Это должен быть талмуд на 1000 страниц, описывающий в деталях взаимодействие фронтенд-бекенд? Или ТЗ всё же, это ожидания заказчика?
Я уже писал ниже (или выше?) - ожидания заказчика - это BRD. ТЗ - FSD. Первое есть согласованный с заказчиком документ (в принципе, с ним можно и в суд если возникнут разногласия на этапе сдачи-приемки-оплаты), второе - чисто внутренняя документация команды в любой удобной ей форме.
Лично я даже "непроектные", технические задачи не делаю без предварительного планирования - понимания как это будет выглядеть, как использоваться, каковы основные сценарии, граничные условия и т.п. Пока всего этого нет, нет понимания что именно нужно делать и как. Потому что переделывать все 10 раз просто потому что изначально чего-то не учел у меня просто времени нет - все техническое-непроектное делается в "свободное от работы время". Которого катастрофически мало.
Ну на самом деле ничего нового вы не открыли. Да, так можно. Но слишком много рисков получить "Франкенштейна" - сначала думали что будет так, по ходу выяснилось что нужно этак, переписывать все времени уже нет, наделали костылей, спихнули заказчику и свалили в даль светлую. А дальше трава не расти...
И с таким, за 30+ лет в разработке сталкивался, увы не раз и не два...
Я не меряюсь. Просто привел масштабы для сравнения.
И да, я и в маленьких проектах работал. Ну как маленьких. Так скажем, система мониторинга инженерного оборудования зданий, которая позволяет охватывать большие территории (удаленность объекта от диспетчерской не играет роли).
И там кроме софта еще и железо свое разрабатывали. И заказчику сразу говорилось - по софтовой части (интерфейсы) можно будет что-то в каких-то пределах корректировать, но вся что связано с железом - если мы вложимся в разработку и изготовление железа, а потом вы что-то поменяете в требованиях, то выкупаете все уже изготовленное и делайте с ним что хотите - на стенку повесьте, на помойку отнесите. А мы делаем новое под ваши новые хотелки и потом вы опять его оплачиваете.
И, знаете, очень дисциплинирует заказчика. Когда он понимает, что любой его каприз будет стоить ему дополнительных денег сверх согласованной суммы.
А подход заказчика "сделай то не знаю что, но чтобы мне понравилось" изначально убыточен для разработчика.
Тут есть небольшая путаница. Заказчик про ТЗ вообще ни слом ни духом. Его документ - BRD - Business Requirements Document. Вот он согласуется с заказчиком. И заказчик тестирует и принимает продукт на соответствие согласованным бизнес-требованиям.
На основе BRD уже строится архитектурное решение и пишется (специально обученными людьми - аналитиками) FSD - Functional Specifications Document. Это уже внутренний документ команды.
Если в двух словах, то BRD - что будем делать, FSD - как будем делать.
Вы забываете постоянно добавлять - "в нашем конкретном случае". Вам уже накидали примеров и аргументов что в других случаях это работать не будет. Более того, попытка так работать почти наверняка приведет к крайне нежелательным последствиям.
Предствбте ситуацию когда заказчик вам называет срок и ставит условие что если вы хоть на день в него не уложитесь, то не только ни копейки не получите, но еще и оплачиваете заказчику штраф в размере полной стоимости проекта. Это то, что у нас на называется "нормативка".
Рискнете в таких условиях работать по вашей схеме? Или просто откажетесь?
В банковской сфере цена ошибки, конечно, не жизни людей, но очень большие цифры. И кроме "упущенной выгоды" есть еще санкции регулятора.
У нас оценка примерно такая:
Час простоя АБС может стоить банку до 24 миллионов рублей прямых финансовых потерь при кратковременной недоступности. Это не учитывая репутационных потерь, которые могут привести к прекращению банковской деятельности в целом.
Нет. ТЗ это во-первых, основа для построения архитектуры и выбора наилучшего алгоритма. Если в процессе бизнес-требования заказчика изменились достаточно сильно, разработчик может вообще отменить задачу и отправить ее на пересогласование (а с учетом того, что у разработчика и аналитика задачи идут потоком, пересогласование означает сдвиг задачи в конец очереди и новое планирование ресурсов, например, на два-три квартала вперед).
Во-вторых - да, ТЗ это документация. И часто бывает так, что изначально аналитик пишет ТЗ "широким мазками" - основные положения, без конкретики реализации. А потом уже дополняет его подробностями конкретной реализации. Правда, такой подход работает только с разработчиками достаточно высокого уровня.
В день изменяется более 1,5 Терабайт информации в БД
За день выполняется более 100 млн. бизнес операций
Одновременно обслуживается более 10 тыс. процессов
За год происходит более 1100 изменений в алгоритмах программ
Подключено более 60 внешних систем, обеспечивающих работу различных бизнес направлений.
Большинство внешних приложений используют систему, как основной источник информации и функциональности
Количество клиентов сейчас - порядка 50млн. С каждым клиентом связано большое количество разных сущностей (счета, клиентские данные, доверенные лица и т.д. и т.п.)
И эта система постоянно развивается и меняется. Изменяются существующие бизнес-процессы, появляются новые. И любое изменение должно быть интегрировано в существующую систему так, что не нарушить ее работу. С учетом того, что бизнес-процессы между собой очень тесно связаны, "задачка со звездочкой".
Вы доказали, что ваш подход работает. Что вам удалось собрать команду и вытроить процесс, где можно работать без ТЗ. Ок. Но это всего лишь частный случай. В других же случаях все будет ровно наоборот - попытка работать без ТЗ просто порушит всю систему.
Лично для меня подход достаточно странный. Вот просто с "моей болотной кочки".
Длительное время работал в обрасти промавтоматизации. Что такое там "без ТЗ". с вероятностью 99% это приведет к тому, что вы потратите деньги на разработку и изготовление "железа" (промконтроллеры, различные модули сопряжения), а потом "концепция поменяется" и все это останется только отправить в помойку и начать все заново. Потерянное время, потерянные деньги. В буквальном смысле слова.
Сейчас банк. Центральные сервера. Где крутится вся бизнес-логика. А он, мягко говоря, не тривиальная. И ее, мягко говоря, слишком много.
На сервере одновременно крутится тысячи, если не десятки тысяч, процессов. И все они так или иначе взаимодействуют друг с другом. Встраивая новый процесс, вы всегда должны думать об интеграции - не скажется ли он отрицательно на всем остальном. В том числе и по потреблению ресурсов - не затормозит ли новый процесс что-то из уже работающего.
Получая требования от заказчика (бизнес-подразделения) вы первым делом выстраиваете архитектуру так, чтобы реализовать их максимально эффективным образом. И если требования начнут меняться по ходу разработки, в скоро убедитесь что изначально выстроенная архитектура летит к чертям и вы своими руками делаете какого-то франкенштейна, неповоротливого и прожорливого. Начинается лютый костылинг результатом которого будет жуткая дендрофекальная конструкция. Или, чтобы этого избежать, вам придется пересмотреть всю архитектуру и начать все с начала. Срывая сроки (а здесь бывает и "нормативка" - жесткий срок к которому процесс должен быть запущен срыв которого чреват санкциями со стороны регулятора). Поэтому практикой выработан жесткий workflow: BRD (бизнес-требования) - архитектурное решение - FSD (ТЗ) - разработка - тестирование -внедрение. Только так и никак иначе. Слишком велика цена ошибок.
Кроме того, ТЗ, это еще и документация по проекту. Нам приходится сопровождать пожизненно все, что мы делаем. Есть некий процесс со своей бизнес-логикой. работает уже 3-5 лет. Писался кем-то когда-то. И приходит вам на доработку - "вот тут поменялись требования регулятора". Или "поменялось законодательство". Или.... Вариантов куча. И чтобы начать доработку вам нужно для начала понять а что там вообще происходит, что и где нужно изменить. И без ТЗ это сделать крайне сложно. Поэтому всегда, по всем проектам хранится архив версий ТЗ. И всегда есть привязка по какой версии ТЗ реализован тот или иной модуль в проекте (в любой поставке есть Release Notes где все ссылки - на задачу в Jira, на ТЗ, на тесты, на коммит в BitBucket...).
И если всю эту "бюрократию" не соблюдать, жизнь станет кратно сложнее.
А можно все тоже самое, но действительно с форматированием?
Ну, например, когда нужно вывести легко читаемую табличку типа
============ VPN ============
Count : 131184
Fill
Average File : 10.542871
Average Idx : 4.629779
Minimum File : 7.000000
Minimum Idx : 0.000000
Maximum File : 783.000000
Maximum Idx : 2584.000000
SQE File : 5.472801
SQE Idx : 20.577609
Dispersion File: 29.951783
Dispersion Idx : 423.441226
Search
Average File : 7.602459
Average Idx : 3.674952
Minimum File : 0.000000
Minimum Idx : 0.000000
Maximum File : 135.000000
Maximum Idx : 128.000000
SQE File : 2.360294
SQE Idx : 4.086529
Dispersion File: 5.571032
Dispersion Idx : 16.699851
Т.е. дополнение нулями, выравнивание по десятичному разделителю и т.п. Насколько для таких операций fmt будет лучше/хуже printf? Возможно ли такое через потоки?
Без иронии, сарказма и подвоха. Действительно интересно.
Там еще мышь Genius была. Такая угловатая, лежала в сейфе т.к. никто не знал что с ней делать - тогда даже Нортона не было еще.. 88-й год, по-моему. Или 89-й...
А с нампадом клавы, по-моему, чуть позже, на AT-шках появились
Ну... Я вот специально купил TKL механику (правда, попроще и проводную). Просто потому, что начинал работать именно с TKL ("полноразмерные появились позже) и за многие годы так и не привык к нампаду.
А как у него обстоят дела с поддержкой всех других смежных областей, для которых требуется взаимодействие с БД?
А никак. Суть этого подхода в том, что из этого языка можно вызывать то, что написано, например, на Java. Или на С/С++
С джавой не пробовал, с С/С++ регулярно так делаем.
Обратно - у нас есть вебсервисы, которые вызываются извне, а сами при этом вызывают что-то, написанное на этом языке. Возврат идет или через возвращаемое значение или через один или несколько result set (sql).
всё равно придётся использовать нечто другое, вместо или вместе с этим БД-языком
Да, именно так. Этот язык - это не просто работа с БД, это реализация всей коммерческой бизнес-логики (банки, страховые и т.п.). Много работы с датами (валидация дат, арифметика с датами, представление даты в разных форматах), все вычисления только с числами с фиксированной точкой (в т.ч. всякая арифметика с округлением). Много работы со строками (поиск, замена, преобразования, разбиение в массив слов, объединение массива слов в строку и т.п.). И все это работает очень быстро (что весьма критично когда на сервере крутится одновременно тысячи различных процессов, перемалывающие огромное количество данных) и пишется очень просто.
Но ведь разница - исключительно синтаксическая, в момент создания. Более того, в вашем примере вы уже имеете сущность записи из БД, которая почти наверняка будет представлена как массив структур-строк с полями-колонками, кто же вам мешает обращаться к полям этих самых структур напрямую, без явного копирования в новые переменные?
Разница вот в чем. Из БД на физическом уровне запись читается в байтовый буфер в котором каждое поле - набор байт по соответствующему смещению и соответствующей длины. Та же "строка" - это просто 100 (например) байт с (например) 50-го по 150-й. Чтобы использовать так, как Вы написали, нужно для этого куска буфера создать объект. А это значит, вызвать конструктор, который внутри себя выделит память и скопирует туда кусок буфера, а по окончанию работы вызвать деструктор (он может вызываться автоматически, но он вызовется), который освободит память.
В результате, если посмотреть PEX статистику (Performance EXplorer - инструмент используемый у нас для исследования эффективности в процессе нагрузочного тестирования), то для задачи, обрабатывающей, скажем, 20млн записей (что для нас дело, в общем-то, обычное) Вы увидите там 20млн вызовов конструктора, 20млн выделений памяти, 20млн операций копирования, 20млн вызовов деструктора и 20млн освобождений памяти. И это не считая собственно логики. И все это в рантайме.
Здесь все проще. Описываем переменную
dcl-ds dsYAR likerec(YAR12LF.YARPFR: *all);
Это структура (DS - Data Structure в этой терминологии) которая повторяет структуру записи YARPFR логического файла YAR12LF. *all - включать все поля (можно *key, тогда будут включены только ключевые поля индекса). Имена полей в ней будут соответствовать именам полей записи.
Переменная будет создана в compile time.
Дальше читаем (не важно как - можно SQL запросом, можно прямым обращением) в эту структуру запись из БД и дальше напрямую работаем с полями. Без создания дополнительных объектов, лишнего выделения/освобождения памяти, вызовов конструкторов/деструкторов, лишних копирований.
Наша основная головная боль - эффективность. Объемы данных достаточно большие. Количество различных процессов, которые с этими данными выполняются - большие. Количество бизнес-операций огромное (сотни миллионов в стуки это достаточно мягкая оценка, в периоды пиковых нагрузок кратно больше). Поэтому лишние конструкторы/деструкторы, выделение/освобождение памяти, копирование - все это паразитная нагрузка на процессор, которую стараемся посильно избегать.
Поэтому каждая часть каждой задачи решается при мощи того инструмента, который дает наилучший результат. Если в рамках задачи требуется работа с какими-то низкоуровневыми системными вещами (сокеты, пайпы, например) - она будет написана на С/С++. Потому что это проще и эффективнее. Та же работа с регулярными выражениями на С делается проще. В принципе, из нашего языка я могу вызывать любую функцию С-шного рантайма просто описав ее прототипа на нашем языке со ссылкой на "внешнюю процедуру".
Ну вот как пример. Нет у нас в языке генератора ПСЧ. зато он есть в С:
int rand(void);
Если мне вдруг потребуется, делаю просто
dcl-pr Random int(10) extproc(*cwiden: 'rand');
end-pr;
Все. Теперь у меня есть функция Random, которая возвращает int32.
Но при этом тут много всякого сахара, особенно в описании структур - неименованные поля (вместо всяких tmp, dummy, reserved в С), частично или полностью перекрывающиеся поля в структуре, задание дефолтных значений полей структуры при описании ее шаблона (шаблон - это типа typedef) при котором любая созданная по этому шаблону структура сразу будет проинициализирована дефолтными значениями (на этапе компиляции, не в рантайме!) Ну и еще много всякого, чего порой не хватает в тех же С/С++.
Из личного опыта (и той методологии, в которой сейчас работаем) схема немного сложнее.
То, что хочет заказчик, называется BRD - бизнес-требования. Они согласуются с заказчиком. Все, что делается дальше, уже является внутренними документами исполнителя.
На основе BRD сначала разрабатывается архитектурное решение - там уже архитектура, дробление на модули, связь между модулями и т.д. и т.п. Это работа архитектора.
На основе архитектурного решения разрабатывается FSD - это уже ТЗ для конкретного исполнителя (разработчика). Разработкой FSD занимается аналитик (возможно, совместно с разработчиком, если уровень разработчика позволяет). Там уже описываются технические подробности реализации.
Как оформлять каждый из документов - это уже зависит от контекста, предметной области и много чего. Где-то удобнее использовать модель данных, где-то функциональную модель. Но суть примерно такова - есть документ который согласуется с заказчиком, есть внутренние документы исполнителя. И это разные документы, он "на разных языках" пишутся и с разными целями. Заказчику важно получить функционал, закрыть свои потребности. И ему совершенно не важно какие там алгоритмы будут реализованы.
Конечному исполнителю (разработчику) важно не только в каком виде должен быть представлен результат, но и как его получить (например, какие таблицы по каким условиям связать для получения выборки, как обработать полученную выборку и т.п.)
Представлять все это в виде одного документа неудобно никому - ни заказчику (там будет слишком много технических подробностей), ни исполнителю (там будет много того, что ему, в общем-то, не нужно).
Простой пример из личного.
Делается некоторая "витрина". Для ее первичного наполнения пишется некоторый модуль с очень жесткими требованиями по производительности (хотя бы потому что оценочно там будет порядка 400млн записей, а запись это не просто что-то выдернутое из другой таблицы, а результат некоторой обработки некоторого объема данных - на то она и витрина).
Изначально были выставлены одни требования. И вроде как все сделали, но тут "концепция поменялась". И стало понятно что базовый алгоритм, дающий хорошую производительность для старых требований, никуда не годится для новых. Т.е. переделать нужно процентов 75-80 написанного... И никакая модульность тут на спасет - это само по себе "модуль" в составе еще более крупной задачи.
А они неотделимы. В той системе суть в том, что на объектах (зданиях) есть некоторое инженерное оборудование. Которое должно мониторится и управляться из диспетчерской. И нужно "железо", которое будет осуществлять сбор информации с оборудования, передачу ее на диспетчерскую (и обратно). И нужен софт, который всю это информацию на диспетчерской собирает и представляет с удобном для человека (диспетчера) виде. Ну и логирование всякое и прочее и прочее.
Сам софт без железа работать не будет. Железо без софта тоже. Так что это, как говорили во времена оные, "аппаратно-программный комплекс". Единый и неделимый.
И в разработке там участвуют и разработчики верхнего уровня и схемотехники (как по цифре, так и по аналогу), разработчики прошивок для контроллеров... И пока они не согласуют между собой все детали (архитектура сети, протоколы обмена, формат адресации устройств и еще кучу вещей), начинать что-то делать бессмысленно - велика вероятность что придется все переделывать (заказывать новые платы, компоненты, все это заново монтировать и т.д. и т.п.).
Я уже писал ниже (или выше?) - ожидания заказчика - это BRD. ТЗ - FSD. Первое есть согласованный с заказчиком документ (в принципе, с ним можно и в суд если возникнут разногласия на этапе сдачи-приемки-оплаты), второе - чисто внутренняя документация команды в любой удобной ей форме.
Лично я даже "непроектные", технические задачи не делаю без предварительного планирования - понимания как это будет выглядеть, как использоваться, каковы основные сценарии, граничные условия и т.п. Пока всего этого нет, нет понимания что именно нужно делать и как. Потому что переделывать все 10 раз просто потому что изначально чего-то не учел у меня просто времени нет - все техническое-непроектное делается в "свободное от работы время". Которого катастрофически мало.
Ну на самом деле ничего нового вы не открыли. Да, так можно. Но слишком много рисков получить "Франкенштейна" - сначала думали что будет так, по ходу выяснилось что нужно этак, переписывать все времени уже нет, наделали костылей, спихнули заказчику и свалили в даль светлую. А дальше трава не расти...
И с таким, за 30+ лет в разработке сталкивался, увы не раз и не два...
Я не меряюсь. Просто привел масштабы для сравнения.
И да, я и в маленьких проектах работал. Ну как маленьких. Так скажем, система мониторинга инженерного оборудования зданий, которая позволяет охватывать большие территории (удаленность объекта от диспетчерской не играет роли).
И там кроме софта еще и железо свое разрабатывали. И заказчику сразу говорилось - по софтовой части (интерфейсы) можно будет что-то в каких-то пределах корректировать, но вся что связано с железом - если мы вложимся в разработку и изготовление железа, а потом вы что-то поменяете в требованиях, то выкупаете все уже изготовленное и делайте с ним что хотите - на стенку повесьте, на помойку отнесите. А мы делаем новое под ваши новые хотелки и потом вы опять его оплачиваете.
И, знаете, очень дисциплинирует заказчика. Когда он понимает, что любой его каприз будет стоить ему дополнительных денег сверх согласованной суммы.
А подход заказчика "сделай то не знаю что, но чтобы мне понравилось" изначально убыточен для разработчика.
Тут есть небольшая путаница. Заказчик про ТЗ вообще ни слом ни духом. Его документ - BRD - Business Requirements Document. Вот он согласуется с заказчиком. И заказчик тестирует и принимает продукт на соответствие согласованным бизнес-требованиям.
На основе BRD уже строится архитектурное решение и пишется (специально обученными людьми - аналитиками) FSD - Functional Specifications Document. Это уже внутренний документ команды.
Если в двух словах, то BRD - что будем делать, FSD - как будем делать.
Вы забываете постоянно добавлять - "в нашем конкретном случае". Вам уже накидали примеров и аргументов что в других случаях это работать не будет. Более того, попытка так работать почти наверняка приведет к крайне нежелательным последствиям.
Предствбте ситуацию когда заказчик вам называет срок и ставит условие что если вы хоть на день в него не уложитесь, то не только ни копейки не получите, но еще и оплачиваете заказчику штраф в размере полной стоимости проекта. Это то, что у нас на называется "нормативка".
Рискнете в таких условиях работать по вашей схеме? Или просто откажетесь?
В банковской сфере цена ошибки, конечно, не жизни людей, но очень большие цифры. И кроме "упущенной выгоды" есть еще санкции регулятора.
У нас оценка примерно такая:
Нет. ТЗ это во-первых, основа для построения архитектуры и выбора наилучшего алгоритма. Если в процессе бизнес-требования заказчика изменились достаточно сильно, разработчик может вообще отменить задачу и отправить ее на пересогласование (а с учетом того, что у разработчика и аналитика задачи идут потоком, пересогласование означает сдвиг задачи в конец очереди и новое планирование ресурсов, например, на два-три квартала вперед).
Во-вторых - да, ТЗ это документация. И часто бывает так, что изначально аналитик пишет ТЗ "широким мазками" - основные положения, без конкретики реализации. А потом уже дополняет его подробностями конкретной реализации. Правда, такой подход работает только с разработчиками достаточно высокого уровня.
И это вы считаете "большим проектом"?
Сравните (АБС- Автоматизированная Банковская Система):
27 тыс. программных объектов
15 тыс. таблиц и индексов базы данных
Более 150 программных комплексов
Занимает более 30 Терабайт дискового пространства
В день изменяется более 1,5 Терабайт информации в БД
За день выполняется более 100 млн. бизнес операций
Одновременно обслуживается более 10 тыс. процессов
За год происходит более 1100 изменений в алгоритмах программ
Подключено более 60 внешних систем, обеспечивающих работу различных бизнес направлений.
Большинство внешних приложений используют систему, как основной источник информации и функциональности
Количество клиентов сейчас - порядка 50млн. С каждым клиентом связано большое количество разных сущностей (счета, клиентские данные, доверенные лица и т.д. и т.п.)
И эта система постоянно развивается и меняется. Изменяются существующие бизнес-процессы, появляются новые. И любое изменение должно быть интегрировано в существующую систему так, что не нарушить ее работу. С учетом того, что бизнес-процессы между собой очень тесно связаны, "задачка со звездочкой".
Вы доказали, что ваш подход работает. Что вам удалось собрать команду и вытроить процесс, где можно работать без ТЗ. Ок. Но это всего лишь частный случай. В других же случаях все будет ровно наоборот - попытка работать без ТЗ просто порушит всю систему.
Лично для меня подход достаточно странный. Вот просто с "моей болотной кочки".
Длительное время работал в обрасти промавтоматизации. Что такое там "без ТЗ". с вероятностью 99% это приведет к тому, что вы потратите деньги на разработку и изготовление "железа" (промконтроллеры, различные модули сопряжения), а потом "концепция поменяется" и все это останется только отправить в помойку и начать все заново. Потерянное время, потерянные деньги. В буквальном смысле слова.
Сейчас банк. Центральные сервера. Где крутится вся бизнес-логика. А он, мягко говоря, не тривиальная. И ее, мягко говоря, слишком много.
На сервере одновременно крутится тысячи, если не десятки тысяч, процессов. И все они так или иначе взаимодействуют друг с другом. Встраивая новый процесс, вы всегда должны думать об интеграции - не скажется ли он отрицательно на всем остальном. В том числе и по потреблению ресурсов - не затормозит ли новый процесс что-то из уже работающего.
Получая требования от заказчика (бизнес-подразделения) вы первым делом выстраиваете архитектуру так, чтобы реализовать их максимально эффективным образом. И если требования начнут меняться по ходу разработки, в скоро убедитесь что изначально выстроенная архитектура летит к чертям и вы своими руками делаете какого-то франкенштейна, неповоротливого и прожорливого. Начинается лютый костылинг результатом которого будет жуткая дендрофекальная конструкция. Или, чтобы этого избежать, вам придется пересмотреть всю архитектуру и начать все с начала. Срывая сроки (а здесь бывает и "нормативка" - жесткий срок к которому процесс должен быть запущен срыв которого чреват санкциями со стороны регулятора). Поэтому практикой выработан жесткий workflow: BRD (бизнес-требования) - архитектурное решение - FSD (ТЗ) - разработка - тестирование -внедрение. Только так и никак иначе. Слишком велика цена ошибок.
Кроме того, ТЗ, это еще и документация по проекту. Нам приходится сопровождать пожизненно все, что мы делаем. Есть некий процесс со своей бизнес-логикой. работает уже 3-5 лет. Писался кем-то когда-то. И приходит вам на доработку - "вот тут поменялись требования регулятора". Или "поменялось законодательство". Или.... Вариантов куча. И чтобы начать доработку вам нужно для начала понять а что там вообще происходит, что и где нужно изменить. И без ТЗ это сделать крайне сложно. Поэтому всегда, по всем проектам хранится архив версий ТЗ. И всегда есть привязка по какой версии ТЗ реализован тот или иной модуль в проекте (в любой поставке есть Release Notes где все ссылки - на задачу в Jira, на ТЗ, на тесты, на коммит в BitBucket...).
И если всю эту "бюрократию" не соблюдать, жизнь станет кратно сложнее.
Спасибо. Давно не работал с подобными вещами на С++. Потому и интересно чего такое стоить будет.
А можно все тоже самое, но действительно с форматированием?
Ну, например, когда нужно вывести легко читаемую табличку типа
Т.е. дополнение нулями, выравнивание по десятичному разделителю и т.п.
Насколько для таких операций fmt будет лучше/хуже printf? Возможно ли такое через потоки?
Без иронии, сарказма и подвоха. Действительно интересно.
Посмотрел - да, вы правы. 83 клавиши тогда и TKL сейчас - разные вещи.
Не... PC/XT 8088/87, CGA, 20Mb HDD 2x360Kb FDD 5.25" :-)
Там еще мышь Genius была. Такая угловатая, лежала в сейфе т.к. никто не знал что с ней делать - тогда даже Нортона не было еще.. 88-й год, по-моему. Или 89-й...
А с нампадом клавы, по-моему, чуть позже, на AT-шках появились
Ну... Я вот специально купил TKL механику (правда, попроще и проводную). Просто потому, что начинал работать именно с TKL ("полноразмерные появились позже) и за многие годы так и не привык к нампаду.
А никак. Суть этого подхода в том, что из этого языка можно вызывать то, что написано, например, на Java. Или на С/С++
С джавой не пробовал, с С/С++ регулярно так делаем.
Обратно - у нас есть вебсервисы, которые вызываются извне, а сами при этом вызывают что-то, написанное на этом языке. Возврат идет или через возвращаемое значение или через один или несколько result set (sql).
Да, именно так. Этот язык - это не просто работа с БД, это реализация всей коммерческой бизнес-логики (банки, страховые и т.п.). Много работы с датами (валидация дат, арифметика с датами, представление даты в разных форматах), все вычисления только с числами с фиксированной точкой (в т.ч. всякая арифметика с округлением). Много работы со строками (поиск, замена, преобразования, разбиение в массив слов, объединение массива слов в строку и т.п.). И все это работает очень быстро (что весьма критично когда на сервере крутится одновременно тысячи различных процессов, перемалывающие огромное количество данных) и пишется очень просто.
Разница вот в чем. Из БД на физическом уровне запись читается в байтовый буфер в котором каждое поле - набор байт по соответствующему смещению и соответствующей длины. Та же "строка" - это просто 100 (например) байт с (например) 50-го по 150-й. Чтобы использовать так, как Вы написали, нужно для этого куска буфера создать объект. А это значит, вызвать конструктор, который внутри себя выделит память и скопирует туда кусок буфера, а по окончанию работы вызвать деструктор (он может вызываться автоматически, но он вызовется), который освободит память.
В результате, если посмотреть PEX статистику (Performance EXplorer - инструмент используемый у нас для исследования эффективности в процессе нагрузочного тестирования), то для задачи, обрабатывающей, скажем, 20млн записей (что для нас дело, в общем-то, обычное) Вы увидите там 20млн вызовов конструктора, 20млн выделений памяти, 20млн операций копирования, 20млн вызовов деструктора и 20млн освобождений памяти. И это не считая собственно логики. И все это в рантайме.
Здесь все проще. Описываем переменную
Это структура (DS - Data Structure в этой терминологии) которая повторяет структуру записи YARPFR логического файла YAR12LF. *all - включать все поля (можно *key, тогда будут включены только ключевые поля индекса). Имена полей в ней будут соответствовать именам полей записи.
Переменная будет создана в compile time.
Дальше читаем (не важно как - можно SQL запросом, можно прямым обращением) в эту структуру запись из БД и дальше напрямую работаем с полями. Без создания дополнительных объектов, лишнего выделения/освобождения памяти, вызовов конструкторов/деструкторов, лишних копирований.
Наша основная головная боль - эффективность. Объемы данных достаточно большие. Количество различных процессов, которые с этими данными выполняются - большие. Количество бизнес-операций огромное (сотни миллионов в стуки это достаточно мягкая оценка, в периоды пиковых нагрузок кратно больше). Поэтому лишние конструкторы/деструкторы, выделение/освобождение памяти, копирование - все это паразитная нагрузка на процессор, которую стараемся посильно избегать.
Поэтому каждая часть каждой задачи решается при мощи того инструмента, который дает наилучший результат. Если в рамках задачи требуется работа с какими-то низкоуровневыми системными вещами (сокеты, пайпы, например) - она будет написана на С/С++. Потому что это проще и эффективнее. Та же работа с регулярными выражениями на С делается проще. В принципе, из нашего языка я могу вызывать любую функцию С-шного рантайма просто описав ее прототипа на нашем языке со ссылкой на "внешнюю процедуру".
Ну вот как пример. Нет у нас в языке генератора ПСЧ. зато он есть в С:
Если мне вдруг потребуется, делаю просто
Все. Теперь у меня есть функция Random, которая возвращает int32.
Но при этом тут много всякого сахара, особенно в описании структур - неименованные поля (вместо всяких tmp, dummy, reserved в С), частично или полностью перекрывающиеся поля в структуре, задание дефолтных значений полей структуры при описании ее шаблона (шаблон - это типа typedef) при котором любая созданная по этому шаблону структура сразу будет проинициализирована дефолтными значениями (на этапе компиляции, не в рантайме!) Ну и еще много всякого, чего порой не хватает в тех же С/С++.
На андроиде нет нужды пользоваться стикерами. Это чисто эпплоовский костыль.
И NFC - это не только платежи, но и метки по которым автоматически запускаются различные сценарии.
С чего бы вдруг? Думаете так сложно реализовать влагозащищенный слот для карточки?
Зависит от. В моей жизни достаточно много ситуаций, когда не то что wi-fi, связи стабильной нет (2, в лучшем случае 3G в течении всего дня).