Что такое единый источник истины?

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

Чтобы увидеть это в перспективе, попробуйте вспомнить тот школьный проект, над которым вы работали неделями, который должен был быть выполнен через пару часов. Вы сохраняете файл, находите флешку, кладете на нее и мчитесь в университетский городок только для того, чтобы узнать, что вашим «важным_doc_3_complete_done_final_2» был объем работы, который вы сохранили несколько ночей назад. И в этот момент вам нужно не только объясниться своему учителю, но и попытаться найти последнюю версию проекта из десятков файлов с похожими именами (и молиться, чтобы файл не был сохранен где-либо за пределами рабочего стола).

Помимо воспоминаний, то, что произошло, было упрощенной версией того, с чем борются многие компании и почему существуют ИТ-службы и услуги по оптимизации данных. Отсутствие SSOT может иметь катастрофические последствия для сред, управляемых данными. Хороший пример Forbes описывает, как отсутствие SSOT может негативно повлиять на огромные команды и будущие бизнес-стратегии, когда отсутствие единого подтвержденного источника данных порождает предвзятость и манипулирование данными, делает человеческие ошибки частым явлением и ставит всю корпорацию в беду. недостаток по сравнению с конкурентами.

SSOT и справочник по разработке программного обеспечения

Каждый раз, когда вы отправляете сообщение своему другу через Messenger, ваш разговор сохраняется где-то на сервере Facebook, и если вы попытаетесь получить доступ к истории чата, ваш компьютер отправит запрос к серверу для доступа к тому единственному SSOT, который является вашим разговором, чтобы вы оба видели один и тот же разговор. Ваш браузер направляет вас к истории беседы.

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

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

Пример объектного отношения

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

Теперь у нас есть класс для трех объектов, участвующих в разговоре - для клиента, банковского служащего и банковского счета клиента. SSOT в этом случае, очевидно, является классом BankAccount, который мы назовем соединением.

Теперь, когда у нас есть определения классов, давайте создадим пару экземпляров.

Мы создали экземпляр каждого из 3 классов. Теперь мы можем написать функции, которые смогут получать доступ к информации «на другом конце» через наш единственный источник истины. Давайте извлечем наш файл и запустим его в консоли.

Теперь, чтобы Джессика увидела имя Стива, нам нужно определить метод. Назовем его current_client_name.

Запуск jess.current_client_name в консоли предоставляет нам всю информацию об экземпляре

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

Дополнительное удобство

Если Стив когда-либо решит сменить имя, по закону он должен будет сообщить об этом в банк. Точно так же Джессика не удовлетворена своим именем, и ей нужно будет сообщить своему работодателю (банку), как только она изменит его, и экземпляр банковского счета будет обновлен «автоматически»:

Запуск файла в консоли и ввод команд изменения имени влияет на наш экземпляр банковского счета:

Заключительное слово

Как бы удобно ни было хранить всю информацию в одном месте, иногда ее не нужно собирать в объединенном классе. Например, даже после смены имен наши друзья должны знать обновленную информацию, не идя в банк:

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

Вывод: SSOT - важный принцип не только в Ruby-on-Rails, но и в любом языке программирования, организации, управляемой данными. Крайне важно иметь хорошее понимание принципа при создании приложения, если мы хотим создать надежную, универсальную и гибкую программу.