На самом деле существует множество типов программистов. Классифицировать их можно по бесконечному числу параметров, но сегодня я хочу рассказать о делении программистов по одному конкретному признаку, который считаю очень важным. Итак...
Что первично, Архитектура или Код?
Несколько лет назад в диалоге с коллегой я встретил такой аргумент: "да что ты сделал, всего то проект написал, а я написал код!" Безусловно этот довод совершенно бесспорный, ведь без кода результата работы нет. Но и я в свою очередь мог бы ответить, что в процесс развертывания этого результата работы был очень болезненным - два или три раза приходилось откатывать и исправлять работу. А все потому, что в процессе выполнения работы были допущены отступления от проекта, который я подготовил.
Некоторые программисты считают архитектуру проекта вторичным аспектом, ставя во главу угла реализацию, т.е. код, который они пишут. Чего греха таить, с десяток лет назад я и не подозревал о том, что есть такая штука как архитектура. Вернее, я понимал, что у каждого проекта есть своя архитектура, что-то можно сделать так, а что-то иначе, но я не подозревал, что это целый аспект. Что в архитектуре существуют определенные подходы и практики и об этом написано множество книг. Ну а уж о том, что все эти практики действительно работают я узнал намного позже.
Но вот какая история. Мы можем сначала спроектировать наше приложение, а потом написать код. Или наоборот - мы сначала напишем код, а потом опишем, какая получилась архитектура приложения, какие у него зависимости, интерфейсы и прочее. Так ли важен проект, если наше приложение маленькое? Так ли важен проект, если наше маленькое приложение является частью большой системы? Имеет ли смысл документация проекта или она только отнимает время?
Задача
Кажется, вы ожидаете, что я скажу "да, проект важен даже для маленьких приложений и бла-бла...". Но нет, я не буду становиться ни на чью сторону, я просто попробую описать несколько ситуаций с разных ракурсов. Но сначала я опишу подходы, которые будут применяться в моем исследовании.
Сначала напишем код - разработчики просто пишут код, возможно есть документация: техническое задание, какие то принятые конвенции и фреймворки, но не более чем просто понимание, что нужно делать.
Вперед документация - сначала мы описываем классы, которые будем применять, их взаимодействие. Взвешиваем все за и против и выбираем фреймворк и язык программирования, собираем консилиум и обсуждаем это в команде, а затем согласовываем и подписываем документы.
Гибкая разработка - этот подход может быть известен, как Object Oriented Agile Design или экстремальное программирование, или просто гибкий дизайн. Не смотря на то, что в основу него ложатся принципы SOLID, подход не требует проектирования архитектуры приложения перед разработкой, однако требует соблюдения определенных правил.
А теперь рассмотрим ситуацию разработки программного обеспечения с учетом применения каждого их этих трех подходов. Будем считать, что программное обеспечение создается с нуля и мы не имеем технического долга в самом начале.
Сначала пишем код
Итак, программист-разработчик Андрей приступает к написанию кода. Проекта нет, но техническая документация присутствует. У него на руках техническое задание с описанием бизнес-правил и инвариантов. Со временем он замечает, что в некоторых функциях недостаточно входных данных и он прокидывает в них нужные объекты изменяя сигнатуру функции. Иногда после таких преобразований обнаруживается циклическая зависимость и если его язык программирования не умеет разрешать проблемы подобного рода, ему придется переносить объекты зависимостей из одного файла в другой. Если его код уже достиг высокого зацепления (т.е. многие элементы кода одного модуля знают и используют многие элементы из другого модуля), то такие изменения могут приводить к необходимости расщепления объектов или перемещения других связанных объектов.
Возможно, в какой то момент он решает, что имеет большие участки с дублированием кода. Не полным дублированием, но с какими-нибудь небольшими вариантами, он пытается сделать небольшой рефакторинг, но не может - т.к. не контролирует архитектуру проекта - зацепление вышло слишком сильным. База данных тесно переплетается со всеми уровнями абстракции и любой компонент системы практически невозможно заменить на что-то другое.
В конце концов, он обнаруживает, что иногда программа работает не так как нужно - в ней большое количество багов и отсутствуют модульные тесты, потому что Андрей не использовал лучшие практики и не знает принципов проектирования. И вообще было бы лучше, если бы он выбрал другую базу данных. Кроме того возникли проблемы интеграции со смежными приложениями, которые вообще не понятно как решать и кто в них виноват.
Бесконечные попытки отловить все ошибки программы во время производственной эксплуатации полностью блокируют возможность развития продукта. Какова стоимость такого продукта и отношение этой стоимости к величине полезного значения продукта? Стоимость очень высока, ведь трудозатраты на работу с таким кодом превосходят все разумные границы. А отношение стоимости к полезности вряд ли понравится бизнес-заказчику.
Это не эмпирический пример. Я был таким Андреем с десяток лет назад. Я написал такое приложение и заказчику было очень дорого его поддерживать. Однако мне повезло со значимостью продукта - внутренние особенности бизнеса и отсутствие альтернативы сработали мне на руку.
Вперед документация
Владимир спешит на совещание по новому проекту, в его руках карандаш и блокнот. В разработке задействованы два отдела, поэтому для урегулирования вопросов интеграции нужно проработать техническое решение, варианты которого следует обсудить.
Через час совещание было окончено, в голове сложилась картина. Вдохновленный идеями наш разработчик приступает к оформлению технических документов. Сверяясь с техническим заданием он формирует описание бизнес-моделей и их ограничений, переносит их на технические модели (описывает структуру моделей в базе данных), расписывает движение потоков данных и разную другую фигню...
Пришлось основательно попотеть, чтобы выбрать базу данных - тут не обошлось без детального анализа зависимостей бизнес-моделей между собой. И даже пришлось напрограммировать макет приложения, чтобы попробовать какой-то вариант базы данных. И т.к. документация требует описания всех зависимостей, т.е. всех компонентов системы, пришлось изрядно погуглить, чтобы собрать много технической информации.
Он отправляет документацию на рассмотрение совету старших разработчиков и ждет их вердикта, через несколько часов появляются комментарии. Кое-что удалось аргументировать, кое-что пришлось изменить. За какой то конкретный момент пришлось сильно пропотеть - даже сходил на другой этаж, чтобы посовещаться с архитектором. Через боль и кровь согласования получены и теперь наступает самое интересное!
В процессе разработки выяснилось, что со стороны бизнеса допустили ошибку в описании вариантов использования, а это значит, что в модели данных нужно внести изменение. Внесение в документацию исправлений и объяснение необходимости таких изменений другим участникам процесса заняло какое то время. Однако, в конце концов проект был готов, затем протестирован и, возможно, во время тестирования не было выявлено каких-то архитектурных недочетов, которые снова потребовали внесения изменения в документацию. Возможно.
Проект был запущен успешно и бизнес-пользователи уже пришли с новыми идеями о том, как нам его улучшить. Что ж, Владимир берет карандаш и свой блокнот и отправляется на следующее совещание. Какова стоимость разработки такого проекта? Учитывая то, что в совещании участвует несколько человек, затем несколько человек должны рассмотреть документацию и согласовать или задать вопросы. И так каждый раз, как только возникли серьезные изменения в проекте... Довольно дорого, но среднее отношение стоимости к полезности устраивает бизнес. Иначе они бы не проводили эти совещания.
И я там был, мед-пиво пил... И кровью под себя ходил...
Гибкая разработка
Иван нашел интересную таску в жире... Да ладно шучу. Но если без шуток, то рассмотрев техническое задание он первым делом посоветовался с архитектором в чате и они вместе приняли решение, что пока можно разрабатывать приложение без учета базы данных. Небольшой анализ бизнес-сущностей и Иван начинает разрабатывать ядро системы и сразу покрывает его тестами. Полная компиляция и запуск проекта еще далеко впереди, но разработчик уже вовремя обнаруживает ошибки кодирования с помощью модульных тестов.
В качестве временного решения он быстренько разрабатывает im-memory хранилище, предоставляя его интерфейсы (с помощью инверсии зависимостей) модулям хранящим бизнес-логику. Каждый отдельный компонент интеграции разрабатывается, как отдельный модуль, предоставляющий свои интерфейсы, а уровни абстракции не смешиваются вместе. И это абсолютно ничего не стоит, ведь Иван уже привык так программировать.
И конечно же в процессе разработки не обошлось без изменения в техническом задании, но проблем это не принесло - базу данных на тот момент еще не выбрали, а изоляция бизнес-логики от технического кода дала почти нулевую стоимость внесения изменения.
Вот почти весь проект уже готов. В процессе разработки Иван нашел неплохое решение для базы данных. Внедрить это было несложно - потребовалось просто реализовать интерфейсы хранилища за которыми стояли коннекторы и SQL запросы.
Есть ли документация к такому проекту? Конечно есть - посмотрите на код - каждая папка с исходным кодом буквально кричит о том, что внутри нее реализовано. Каждая переменная красноречиво говорит о том, для чего она служит. Каждое название функции или метода глаголит истину. И весь код описывает целую историю. Стоимость такого проекта будет более, чем адекватной, а отношение стоимости к полезности будет 1 к 1.
Правда? Да. Хотите доказательств - читайте книги.
Итог
Я все сказал. Решать вам.
Но, если вы решите в сторону архитектуры, то я подскажу кого читать:
- Роберт Мартин
- Мартин Фаулер
- Эрик Брюер
- Эрик Эванс
- Крис Ричардсон
- Кент Бек
- Банда Четырех
- и другие...
