Дефрагментация мозга. Софтостроение изнутри

Ошибка в данном примере снова означает, что книгу вы украли.

Два совпадения. Случайные ли?

В случае явного управления памятью возникнет системная ошибка: библиотека или магазин полезут без спросу в ваше отсутствие в квартиру за объектом и заберут его назад. Придя домой, вы не обнаружите на полке нужной книги.

В случае же со сборщиком мусора факт кражи книги не вызовет внешних проблем. В самом простом случае библиотека просто удалит ссылку на пропавшую книгу из своих каталогов. Сама книга при этом продолжит занимать место на вашей полке. Но может статься, например, без вашего ведома из книги будут удалены подцензурные страницы, ведь ссылка-то известна.

Оба случая являются логической ошибкой проектирования интерфейсов, но сборщик мусора на некоторое время скроет их от вас. В этой ипостаси сборка мусора, позволяющая программистам избавиться от назойливых ошибок обращения к памяти ( access violation ), является лишь фиговым листочком, прикрывающим до некоторого момента всё те же старые проблемы. Искренне всем желаю, чтобы этот момент не проявился во время приёмки.

Журнал хозяйственных операций

Отвлечёмся ненадолго от общих концепций и рассмотрим более конкретные проблемы разработки учётных приложений. Вопросы, подобные «почему нельзя хранить остатки в форме текущих величин», «зачем нужна история операций», «зачем там нужна транзакция в режиме «сериализация» (что такое режим serialized можно прочитать в статье [20]), не раз всплывали в дискуссиях, поэтому я кратко расскажу об этом в рамках отдельной главы, чтобы в следующий раз просто ссылаться.

Довольно сжатое изложение статьи «Как проектировать бухгалтерию»[19] в терминах абстракций может быть не очень понятным начинающим. Напротив, статья «Введение в складской учёт»[18] рискует показаться излишне упрощённой и «заточенной» на складскую бухгалтерию с отраслевой спецификой. И в обоих случаях не хватает конкретики, разъясняющей вышеназванные вопросы.

Начнём с первого антишаблона «Таблица остатков», на которые я вдоволь насмотрелся во времена буйного расцвета торгово-складского софтостроения в 1990-х годах. Начинающий проектировщик рассуждает так: мне нужно текущее количество товара в наличии, а все движения, в результате которых эта цифра и появилась, можно оставить в стороне, а то и прямо в первичных документах.

Представьте, что в документ недельной давности вкралась ошибка. Её исправили, причём пересчитанные текущие остатки по-прежнему неотрицательны. Значит ли, что они неотрицательны и на каждый день прошедшей недели? Разумеется, нет. Приходит клиент и говорит: «Мне выписали 10 штук, а на складе только 8, я на вас, жуликов, в суд подам». Парадокс? Никакого парадокса. За товаром он пришёл сегодня, но продали ему товар вчера. А на состояние «вчера» после корректировки остаток был бы отрицательным. Вот ему и не хватило.

Если не верите, что такое возможно, вот схема движения.

Теперь откорректируем приход 2012-04-01 с 12 утюгов на 10. Получаем, что на сегодня их 0. Вроде бы все в порядке. Всё, да не совсем: сегодняшняя закупка ещё не поступила на реализацию. Поэтому вчерашний «минус 2» пока действителен.

Почесав свой мыслительный орган, проектировщик приходит к неутешительному выводу: даже для фактических операций нужно считать остаток по истории (журналу). Не говоря уже о резервировании товара, где ситуация меняется гораздо быстрее: то тут отменили, то там подтвердили.

Но считать по журналу:

• может быть долго;

• необходимо защитить считанные значения, чтобы при последующей записи не возникло «минусов».