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

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

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

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

Общие законы

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

Джон Галл, Исследователь в области общей теории систем и системного анализа

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

Требования к новой системе не будут окончательно известны, пока ей не начнут пользоваться

Уоттс Хамфри, Пионер в области программной инженерии прозванный «отцом качества программного обеспечения»

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

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

Ричард П. Габриэль, Ученый в области информатики известный за вклад в развитие LISP

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

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

Якоб Нильсен, Доктор наук, обладатель 38 патентов США в области юзабилити

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

Принципы YAGNI и KISS

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

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

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

Рон Джеффрис, Соавтор методологии Extreme Programming и Agile-манифеста

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

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

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

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

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

Что такое Feature creep и Bloatware

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

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

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

Джейми Завински, IT-предприниматель, программист и блоггер, участвовал в разработке Netscape Navigator

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

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

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

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

Ларри Теслер, Информатик, работал в Xerox, Apple Computer, Amazon.com и Yahoo!

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

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

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

Спасибо, что дочитали до конца! Это блог IT-продакшна Work Solutions.

Мы занимаемся аутсорсингом и аутстаффингом: создаем веб-приложения на заказ и усиливаем штат наемных специалистов.

Будем очень рады вашим:

⭐ на GitHub;

➕ на Хабре;

👍 в Facebook.

0
Комментарии
-3 комментариев
Раскрывать всегда