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

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

Обычно пользователи находят способ с грехом пополам довести дело до конца. Если они находят какой-то путь к цели, то будут идти по нему и впредь, каким бы запутанным он ни был. Лучше дать им один действительно очевидный способ решения задачи вместо двух или трех неочевидных (но более быстрых).

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

Автоматизируйте свой стандарт форматирования кода

Филип ван Лаенен

Вероятно, вы тоже через это проходили. В начале проекта у всех полно благих замыслов — назовем их «новопроектными обещаниями».[4] Довольно часто многие из этих обещаний фиксируются документально. Обещания, связанные с кодом, попадают в стандарт оформления кода данного проекта. На первом собрании проекта ведущий разработчик оглашает этот документ, и в идеале все соглашаются старательно соблюдать предложенные требования. Однако по ходу работы над проектом все эти благие намерения одно за другим забываются. Когда проект наконец завершен, код выглядит весьма запутанно, и, похоже, никто не понимает, как так получилось.

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

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

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

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

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

• Научитесь настраивать эти инструменты, что поможет находить антипаттерны, специфические для вашего проекта.

• Не просто замеряйте процент покрытия тестами, но и делайте автоматическую оценку результатов. Прерывайте сборку, если процент покрытия тестами недопустимо низкий.

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

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

Красота — следствие простоты

Йорн Ольмхейм

У Платона есть одно высказывание, которое, как мне кажется, особенно полезно было бы знать и принимать близко к сердцу всем разработчикам программного обеспечения:

Красота стиля, гармония, изящество и хороший ритм основываются на простоте.

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

Есть ряд вещей, которых мы стремимся достичь в нашем коде:

• Читаемость

• Простота сопровождения

• Скорость разработки

• Неуловимая красота

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

Поразмышляйте об исходном коде всех программ, которые вам доводилось встречать. Если вы никогда не занимались изучением кода, написанного другими людьми, прямо сейчас отложите чтение, найдите какой-нибудь открытый исходный код и изучите его. Я серьезно! Поищите в Интернете код на вашем любимом языке, написанный известным и признанным специалистом.

Вы вернулись?