эмерджентные свойства функциональной парадигмы созвучны решению задач, возникающих в нашей отрасли в связи с ростом значимости многоядерных архитектур. И хотя данное применение, несомненно, важно, однако не оно является главным основанием для моего наставления познать функциональное программирование.
Овладев парадигмой функционального программирования, программист может значительно повысить качество кода, создаваемого в других контекстах. Глубокое понимание парадигмы функционального программирования и ее применение на практике помогут вам проектировать системы, обладающие гораздо большей степенью ссылочной прозрачности (referential transparency).
Ссылочная прозрачность является качеством очень желательным: она предполагает, что функции неизменно дают одинаковые результаты на одинаковых входных данных независимо от места и времени обращения к этим функциям. Вычисление функции, таким образом, слабо зависит от побочных эффектов изменяющегося (mutable) состояния — в идеале не зависит от них вообще.
Один из главных источников дефектов в коде на императивном языке программирования — изменяемые (mutable) переменные. Каждому читателю наверняка приходилось разбираться, почему в каком-либо конкретном случае некоторое значение не соответствовало ожидаемому. Семантика областей видимости может препятствовать появлению таких коварных ошибок или, по крайней мере, значительно сужать возможную область их появления. Но истинной причиной их возникновения может быть сама концепция проектирования такого кода, который беспорядочно полагается на изменяемость (mutability).
И в этом отношении нам определенно не стоит ждать особой помощи от собственной отрасли. Вводные тексты по объектно-ориентированному программированию скрыто пропагандируют подобные конструкции. В них часто приводятся примеры групп объектов, которые обладают относительно долгим сроком жизни и обмениваются вызовами методов, изменяющих состояние (mutator methods), что небезопасно. Однако грамотное проектирование на основе тестов (test-driven design), особенно если обеспечена «имитация ролей, а не объектов (mock roles, not objects)»,[3] позволяет избавиться от излишеств изменчивости в архитектуре.
В итоге, как правило, получается архитектура с более удачным распределением обязанностей и множеством мелких функций, которые работают с полученными аргументами, а не обращаются напрямую к изменяемым переменным-членам. Дефектов становится меньше, а также упрощается их отладка, ведь легче найти, откуда взялось неверное значение в такой конструкции, чем пытаться выяснить, в каком конкретном контексте появляется ошибочное присваивание. Это значительно повышает ссылочную прозрачность, и решительно ничто не может так способствовать глубокому усвоению этих идей, как изучение функционального языка программирования, где такая модель вычислений является нормой.
Конечно, такой подход оптимален не всегда. Например, зачастую в объектно-ориентированных системах лучшие результаты этот стиль дает при разработке модели предметной области (то есть когда сотрудничество объектов служит снижению сложности бизнес-правил), чем при разработке интерфейса пользователя.
Овладейте парадигмой функционального программирования, чтобы разумно применять полученные знания в других областях. Взять хотя бы ваши иерархии объектов — они станут просто светиться качеством ссылочной прозрачности и окажутся значительно ближе к своим функциональным аналогам, чем можно было бы предположить. На самом деле, некоторые даже высказывают мнение, что в своем высшем проявлении функциональное программирование и объектно-ориентированный подход оказываются лишь отражениями друг друга, своего рода вычислительными инь и ян.
Выясните, как поступит пользователь (и вы — не пользователь)Жиль Колборн
Мы все склонны полагать, что другие люди рассуждают так же, как мы. Но это не так. В психологии это называется эффектом ложного согласия. Если люди думают или поступают иначе, чем мы, мы часто (подсознательно) считаем их в чем-то неполноценными.
Этот эффект объясняет, почему программисту так трудно поставить себя на место пользователя. Пользователи рассуждают иначе, чем программисты. Прежде всего, они значительно меньше времени проводят за компьютером. Они не знают и не хотят знать, как работает компьютер. Это означает, что пользователи не могут прибегать к арсеналу приемов решения проблем, которым в совершенстве овладели программисты. Им не знакомы шаблоны и визуальные приметы, которыми пользуются программисты при работе с интерфейсами, для навигации по ним и для освоения интерфейсов.
Чтобы понять образ мыслей пользователя, лучше всего понаблюдать за ним. Предложите ему выполнить задание с помощью программы, аналогичной той, которую вы разрабатываете. Задача должна быть реальной. «Сложить числа в колонке» — неплохо, но еще лучше: «подсчитать собственные расходы за последний месяц». Не следует брать слишком конкретные задачи, например «Вы не могли бы выделить эти ячейки в таблице и ввести ниже формулу суммирования?» — в этом вопросе содержится слишком явная подсказка. Предложите пользователю рассказывать о своих действиях по ходу работы. Не перебивайте его. Не пытайтесь помочь. Спрашивайте себя: «Почему он делает так?» и «Почему она не делает этого?».
Прежде всего, вы обнаружите, что есть ряд действий, которые все пользователи выполняют схожим образом. Они пытаются выполнять задачи в одном и том же порядке и делают одинаковые ошибки в одних и тех же местах. Такое базовое поведение нужно класть в основу проектирования. Сравните данный подход с тем, что обычно происходит на встречах по проектированию системы, когда собравшиеся прислушиваются к вопросам вроде такого: «А вдруг пользователь захочет…». Так в приложении появляются многочисленные функции и возникает путаница в отношении того, что нужно пользователям. Если наблюдать за пользователями, такой путаницы не будет.
Вы можете столкнуться с тем, что пользователь где-то застрял. Когда вы сами застреваете, то осматриваетесь по сторонам. Когда застревает пользователь, его область внимания, напротив, сужается. Ему становится сложнее увидеть решение в другой области экрана. Вот одна из причин, почему вспомогательный текст — плохое решение для плохого пользовательского интерфейса. Если необходимо дать инструкции или сопроводительный текст, размещать их нужно в непосредственной близости от проблемной области. Именно сужение поля внимания пользователя служит причиной тому, что всплывающие подсказки более полезны, чем встроенная справка.
Обычно пользователи находят способ с грехом пополам довести дело до конца. Если они находят какой-то путь к цели, то будут идти по нему и впредь, каким бы запутанным он ни был. Лучше дать им один действительно очевидный способ решения задачи вместо двух или трех неочевидных (но более быстрых).
Вы также обнаружите большое расхождение между тем, чего пользователь, по его словам, хочет, и тем, что он делает в действительности. Это тревожный факт, ведь обычно требования пользователей собираются путем их опроса. Вот почему лучший способ собирать требования — наблюдать за пользователями. Час наблюдений за пользователями даст вам больше информации, чем день гаданий о том, что им нужно.
Автоматизируйте свой стандарт форматирования кодаФилип ван Лаенен
Вероятно, вы тоже через это проходили. В начале проекта у всех полно благих замыслов — назовем их «новопроектными обещаниями».[4] Довольно часто многие из этих обещаний фиксируются документально. Обещания, связанные с кодом, попадают в стандарт оформления кода данного проекта. На первом собрании проекта ведущий разработчик оглашает этот документ, и в идеале все соглашаются старательно соблюдать предложенные требования. Однако по ходу работы над проектом все эти благие намерения одно за другим забываются. Когда проект наконец завершен, код выглядит весьма запутанно, и, похоже, никто не понимает, как так получилось.
Когда же все пошло наперекосяк? Вполне вероятно, что как раз на том первом собрании. Некоторые его участники были невнимательны. Другие не поняли, в чем смысл стандарта. Хуже того, кое-кто был против предложенного и прямо на собрании затевал против стандарта восстание. И даже те, кто понял и согласился, в какой-то момент работы на проекте были вынуждены под давлением обстоятельств упростить себе жизнь. Ведь хорошо отформатированный код не будет оценен клиентом, которому нужны новые функции в приложении. Кроме того, соблюдение стандарта оформления кода может оказаться весьма утомительным делом, если его не автоматизировать. Попробуйте расставить отступы в плохо написанном классе, и вы убедитесь в этом сами.
Но если это так трудно, зачем нам вообще создавать стандарт оформления кода? Одна из целей единообразного форматирования кода — не позволить никому «приватизировать» код путем форматирования его своим особым способом. Также не следует допускать применения разработчиками определенных антипаттернов, чтобы избежать ряда известных ошибок. В целом стандарт оформления должен облегчать работу над проектом и поддерживать постоянную скорость разработки от начала до конца. Отсюда следует, что поддержка стандарта должна быть единогласной: плохо, если один разработчик делает отступы размером в три пробела, а другой — в четыре.
Существует множество инструментов, с помощью которых можно создавать отчеты о качестве кода, а также документировать и поддерживать стандарт форматирования кода, но это только часть решения. Стандарт следует автоматизировать и внедрять принудительно там, где это возможно. Вот некоторые примеры:
• Сделайте форматирование кода частью процедуры сборки, чтобы оно происходило автоматически при каждой компиляции кода.
• Применяйте средства статического анализа кода для поиска нежелательных антипаттернов. Прерывайте сборку при их обнаружении.