Сколько функций нужно продукту: обзор знаменитых законов программирования

Ко дню IT-аналитика собрали знаменитые законы и принципы, которые говорят о функциональном содержании информационных систем. Что такое KISS, YAGNI, Feature Creep и Bloatware — читайте в материале.

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

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

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

Любое первоначальное представление о том, каким должно быть ПО, скорее всего, неверное. Здесь можно вспомнить историю о руководителе института, который велел дождаться, пока студенты сами протопчут тропинки там, где им удобнее ходить, и только потом их асфальтировать. В разработке первая версия продукта часто оказывается черновой, но она позволяет проверить ряд гипотез и учесть полученные знания при создании последующих версий.

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

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

О том, что надо быть проще не только в отношении функционального наполнения, но и в подходя к разработке, говорят два забавно-звучащих принципа YAGNI и KISS.

YAGNI (You aren't gonna need it; с англ. — «Вам это не понадобится») — принцип проектирования ПО, направленный на отказ от избыточной функциональности.

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

KISS (Keep it simple, stupid, с англ. «Делай проще, глупец») — подход, который предлагает реализовать решение самым простым способом, утверждая, что большинство систем работают лучше, если они остаются простыми, а не усложняются.

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

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

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

Знаменитый закон Паркинсона о том, что любая работа занимает все время, отведенное на ее выполнение, применительно к IT также говорит, что ПО расширяет функциональность до тех пор, пока не задействует все предоставленные ресурсы. Добавьте сюда закон Мура о том, что количество транзисторов на микросхемах удваивается каждые два года, и вы получите бесконечно расползающуюся функциональность (англ. feature creep) и раздуваемое ПО (англ. bloatware).

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

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

Как показывают исследования, пользователи активно используют только 20% функций цифровых продуктов, а 45% возможностей не используют совсем. Как тогда объяснить раздувание? Вся проблема в том, что для разных групп пользователей эти 20% наиболее востребованного функционала разные, поэтому при отказе от функций сильно сужается круг пользователей.

Что касается простоты решения, то здесь в противовес принципу KISS можно привести закон сохранения сложности Теслера.

Создатель команды Ctrl+C/Ctrl+V указывает на то, что либо разработчику придется усложнять программный код, чтобы упростить взаимодействие для пользователя, или пользователь будет вынужден иметь дело со сложным интерфейсом, чтобы программный код мог оставаться простым.

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

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