В индустрии ИТ сложилась парадоксальная ситуация. С одной стороны мы мотивированы автоматизировать всё вокруг. С другой стороны, это же стремление по отношению к намим самим продвигается с тяжёлым и громким скрипом.
Десятилетия уходят на то, чтобы внедрить автоматизацию тестирования и получить пользу от возросшего качества кода. Понадобились дата-центры на многие тысячи серверов, чтобы автоматизация инфраструктуры начала вызывать интерес. В черепашьем темпе, обращая внимание на отдельные области, где без автоматизации уже наступает коллапс, мы работаем над собой.
Я хочу отправиться в путешествие, чтобы посмотреть на всё это с другой стороны. Попробовать представить весь цикл разработки продукта от самой первой мысли до армии удовлетворённых потребителей, как на результат работы некоторого кода. Когда не хвост мотает собакой, не требования в тех или иных областях вынуждают нас экстренно что-то придумывать, а всё изначально выстроено на фундаменте из кода.
Принцип SSoT (Single Source of Truth) означает, что в системе существует единственный источник для данных определённого типа. И все остальные модели и процессы, которые так или иначе используют данные рассматриваемого типа, должны использовать именно этот источник. В противном случае мы получаем проблемы синхронизации, которые ведут к ошибкам и непредсказуемому поведению.
Это легко объяснить на примере классического жизненного цикла программы. У нас есть её код и есть документация. Если и код и документация редактируюся независимо друг от друга, кто-то описал в документации ещё не реализованную, но запланированную функцию. Другой сделал изменения в коде, но не отразил в документации или не во всех страницах документации, которые отражают это изменение, то через какое-то время различие между ними станет уже критическим.
Код може и должен стать таки единственным источником, но с чего этот источник начинается?
В общем случае, спецификация - это код. Код, который описывает требования к продукту. Но я намеренно ввёл такое сокращённое слово, чтобы через него обозначить кодовое название одного из ключевых компонент концепции. Specs - это приложение, которое отвечает за всё. Приложение, которое в итоге создаст продукт. Вы ещё не начали делать основные программыне модули, но уже можете попробовать запустить Specs и посмотреть, что получится.
Попробую начать с того, чтобы создать приложение MyProduct.Specs на любом привычном языке. Или просто пустую папку specs в каталоге с проектом.
“В начале было слово”. И эти слова могут не иметь никакой формы. Просто выглядеть как черновые заметки первых пришедших в голову мыслей. Но постепенно картины будет вырисовываться, заметки структурироваться и какие-то важные сущности выделяться.
Этот эволюционный процесс очень похож на то, что происходит при использовании языков разметки
(markup languages). Классический пример такого языка, который знаком практически всем - это
язык современного Веба - HTML. Мы можем начать с простого текста. Если в какой-то момент нам
показалось, что появилось определение важного термина, мы можем обрамит сами термин и его
определение тегами <dt> (description term) и <dd> (description definition). Можем начинать
разбивать на секции и структурировать. А можем даже вставлять диаграммы, схемы, добавлять примеры
кода и делать многое другое.
В чем было ещё одно ключевое преимущество языков разметки? Они считались машинно-читаемыми. А значит, наше приложение Specs по мере появления разметки может автоматизировать некоторые операции. Скажем, собрать все определения. А в целом оно может собирать все эти заметки и выстраивать на его основе сайт, который потенциально способен помогать работе с этими заметками, начиная от простого поиска и анализа, а заканчивая использованием искусственного интеллекта.
Таким образом получается первый аспект нашего продукта - то, что можно условно назвать «notes as code».