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

Вы когда-нибудь слышали о теории водяного ложа? Я предполагаю, что вы все знакомы с водяными кроватями. Водяные кровати могут быть довольно забавными, но главная проблема (по крайней мере, с недорогими моделями) — их стабильность.

Если вы сидите с одной стороны от него, другая сторона великолепно поднимается, чтобы компенсировать это. Затем вы можете попытаться сбалансировать эту часть, только чтобы наблюдать, как другие части поднимаются вместо нее. Это делает баланс почти невозможным, если вы не держитесь полностью неподвижно. Это, как правило, не очень удобно, и, вероятно, именно поэтому водяные кровати вышли из моды.

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

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

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

SaaS-приложение «Все в одном»

Одним из наиболее распространенных примеров непреднамеренной сложности является приложение All-in-One SaaS. С одной стороны, это универсальный магазин для своих клиентов — все их потребности можно удовлетворить с помощью всего лишь одного приложения. С другой стороны, никто не может использовать его, не потратив тысячи долларов на «академические курсы», которые должным образом предоставляет компания, разработавшая приложение SaaS. Это довольно приличная бизнес-модель для SaaS-компании, но на самом деле она не обеспечивает хорошего опыта для своих клиентов.

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

Приложения для нетехнических пользователей

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

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

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

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

Как избежать проекта водяного ложа?

Честно говоря, вы не всегда можете предвидеть, будет ли проект проектом «водяного ложа». Трудно предвидеть, как снижение сложности может вызвать рост сложности в других частях системы. Как мы убедились в нашем проекте конвейера данных, ожидаемое нами соотношение тривиальных и нетривиальных событий сильно отклонялось. Такие данные трудно найти, пока вы не внедрили решение.

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

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

Также постарайтесь найти людей, у которых был опыт реализации подобных проектов. Они часто могут увести вас от «водяных» решений.

Нижняя линия

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

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