Разработка программного обеспечения — достаточно зрелая индустрия, в которой коллективный опыт зафиксирован в виде эмпирических правил и законов, не раз проверенных на практике. Существуют принципы, связанные с написанием кода, управлением разработкой, контролем качества, многие из которых пришли из других сфер, но обрели вторую жизнь в IT.
В честь череды профессиональных праздников, которые отмечаются в сентябре — день программиста, день системного аналитика и день QA-инженера — мы собрали самые знаменитые законы. В этом материале разберем те, которые говорят о функциональном содержании ПО.
Итак, каким должно быть наполнение системы?
Любая работающая сложная система развивается на базе работающей простой системы. ... Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде
Применимо к разработке, закон Галла говорит, что не следует гнаться за количеством функций и делать ПО, которое сразу решает несколько задач.
Вместо этого, сперва следует разработать продукт, который фокусируется на чем-то одном, что потенциально даст потребителям ценность.
Требования к новой системе не будут окончательно известны, пока ей не начнут пользоваться
Любое первоначальное представление о том, каким должно быть ПО, скорее всего, неверное. Здесь можно вспомнить историю о руководителе института, который велел дождаться, пока студенты сами протопчут тропинки там, где им удобнее ходить, и только потом их асфальтировать. В разработке первая версия продукта часто оказывается черновой, но она позволяет проверить ряд гипотез и учесть полученные знания при создании последующих версий.
ПО, которое имеет ограничения, но простое в использовании, более востребовано пользователем и рынком, чем не имеющее ограничений, но сложное для понимания
В текущей борьбе за внимание пользователь должен как можно быстрее дойти до момента, в котором он понимают всю пользу продукта. Чем сложнее разобраться в приложении, тем выше коэффициент оттока, а люди редко готовы давать второй шанс.
Пользователи проводят большую часть своего времени на других сайтах. Это означает, что пользователи предпочитают, чтобы ваш сайт работал так же, как и все другие сайты, которые им уже знакомы
Закон Нильсена говорит, что при разработке нужно опираться на понятные шаблоны взаимодействия, чтобы пользователь мог сосредоточиться на своей задаче, а не учиться использовать что-то новое. Чтобы влиять на пользовательские привычки, нужна очень лояльная аудитория.
Принципы KISS и YAGNI
О том, что надо быть проще не только в отношении функционального наполнения, но и в подходя к разработке, говорят два забавно-звучащих принципа YAGNI и KISS.
YAGNI (You aren't gonna need it; с англ. — «Вам это не понадобится») — принцип проектирования ПО, направленный на отказ от избыточной функциональности.
Всегда реализуйте функции только тогда, когда они вам реально нужны, а не тогда, когда вам кажется, что они вам понадобятся в будущем
Здесь также речь о том, что разумно разобраться в одной проблеме, которую стремится решить ваш продукт. Чем сильнее вы распыляетесь, тем более неуправляемым и невостребованным станет проект. Прагматизм подхода в том, что он предлагает сосредоточиться на решении самой важной проблемы, а не всех проблем одновременно, сосредоточиться на текущем моменте, а не пытаться предсказывать будущее.
KISS (Keep it simple, stupid, с англ. «Делай проще, глупец») — подход, который предлагает реализовать решение самым простым способом, утверждая, что большинство систем работают лучше, если они остаются простыми, а не усложняются.
Автор подхода американский авиаконструктор Кларенс Джонсон призывал создавать самолеты так, чтобы в боевых условиях их мог починить средний механик с базовым набором инструментов.
KISS намекает на то, что решение всегда должно оставаться достаточно простым, чтобы любой член вашей команды мог легко понять его, не зная, как в настоящее время работает код. Конечно, некоторые сложные проблемы требуют комплексных решений, но часто случается так, что программисты увлекаются новыми инструментами и применяют их в работе, даже если они не соответствуют задаче.
Все вышеперечисленные принципы твердят, что ПО должно быть простым с наименьшим количеством функционала. Но откуда же тогда берутся сложные приложения, супераппы и экосистемы? По этому поводу в индустрии тоже сформулирован ряд законов. Далее рассмотрим их.
Что такое Feature creep и Bloatware
Знаменитый закон Паркинсона о том, что любая работа занимает все время, отведенное на ее выполнение, применительно к IT также говорит, что ПО расширяет функциональность до тех пор, пока не задействует все предоставленные ресурсы. Добавьте сюда закон Мура о том, что количество транзисторов на микросхемах удваивается каждые два года, и вы получите бесконечно расползающуюся функциональность (feature creep) и раздуваемое ПО (bloatware).
Два понятия неразрывно связаны друг с другом — первое обозначает процесс добавления в программный продукт все больше и больше возможностей, а второе — результат этого процесса — более медленное и менее эффективное ПО.
Каждая программа развивается до тех пор, пока не сможет читать почту. Программы, которые не способны так развиться, вытесняются теми, что смогут
Закон Завински указывает на тенденцию программ увеличивать функциональность с течением времени и, как следствие, усложняться. Для примера возьмем Instagram. Изначально это приложение для постинга фотографий с ретро фильтрами, доступное только на iPhone. Сейчас функциональность приложения давно перешагнула фазу обмена сообщениями, и теперь в нем можно вести видеотрансляции, применять AR-эффекты, слушать музыку и продавать товары. И все это также доступно на Android и частично в вебе.
Как показывают исследования, пользователи активно используют только 20% функций цифровых продуктов, а 45% возможностей не используют совсем. Как тогда объяснить раздувание? Вся проблема в том, что для разных групп пользователей эти 20% наиболее востребованного функционала разные, поэтому при отказе от функций сильно сужается круг пользователей.
Что касается простоты решения, то здесь в противовес принципу KISS можно привести закон сохранения сложности Теслера.
У любой системы есть порог сложности, опуститься ниже которого невозможно. Как только вы достигнете этой точки, вы сможете только переложить бремя
Создатель команды Ctrl+C/Ctrl+V указывает на то, что либо разработчику придется усложнять программный код, чтобы упростить взаимодействие для пользователя, или пользователь будет вынужден иметь дело со сложным интерфейсом, чтобы программный код мог оставаться простым.
Индустрия разработки долга шла к тому, чтобы разрабатывать продукт итеративно, мелкими шагами, чтобы постепенно представлять функционал и быстро собирать обратную связь от пользователей и вносить на ее основе изменения.
Многие из перечисленных правил нашли отражение во фреймворках и методологиях по управлению разработкой. Они субъективны как для человека, который их применяет, так и для ситуации, в которой они применяются, но если хотя бы принимать их во внимание, то гарантированно получится уменьшить количество неиспользуемого кода, а также усилий и ресурсов на функциональность, не приносящую пользы.
