Две ценности программного обеспечения

Любое программное обеспечение имеет две ценности: поведение и структуру. Зачастую разработчики сосредотачивают свои усилия только на одной из них. И не всегда на самой значимой. В результатете это приводит к обесцениванию системы со временем.

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

Второй ценностью программного обеспечения является структура. Синонимом здесь выступает термин архитектура.

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

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

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

Что ценнее, поведение или архитектура? Что важнее - правильная работа системы или простота ее изменения?

Я полагаю, что большинство из вас выберет ответ - поведение. Но так ли это на самом деле? Давайте рассмотрим два логических умозаключения:

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

Если спросить представителя бизнеса, хотел бы он иметь возможность вносить изменения, он безусловно ответит, что хотел бы. Но тут же он может уточнить, что текущая работоспособность для него важнее гибкости в будущем. Однако, если руководитель в будущем попросит внести изменения, а затраты на эти изменения окажутся несоизмеримо высокими, он почти наверняка будет недоволен тем, что разработчики довели систему до такого плачевного состояния.

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

О том, как выглядит добротная, чистая архитектура, позволяющая разработчикам создавать системы, способные приносить прибыль компаниям долгое время, я рассказываю в своем телеграм-канале solonkov.team. Там же вы сможете задать интересующие вас вопросы и заказать консультацию.