Обычно виной тому срочная задача. Бывает, что это внутренняя задача разработчиков — создать недостающий инструмент для цепи разработки. Бывает, что задача внешняя, ориентированная на пользователей, например обходной путь для восполнения отсутствующей функциональности.
В большинстве систем и команд можно найти модуль, который каким-то образом выделяется в системе. Считается, что это черновой вариант, и его нужно будет впоследствии переделать, потому что он не соответствует стандартам и правилам, по которым живет остальной код. Вам обязательно придется услышать жалобы разработчиков по этому поводу. Причины появления такого кода бывают разными, но основная причина появления на свет промежуточных решений — это их полезность.
Однако промежуточные решения обладают инертностью (или моментом инерции, если вам так больше нравится). Временное решение уже есть — крайне полезное и всеми принятое, — так что нет острой необходимости создавать что-то взамен. Решая, какие действия более других повысят ценность продукта, заинтересованный участник проекта найдет множество задач, приоритет которых будет выше, чем доведение до ума временного решения. Почему? Потому что временное решение уже есть, оно работает, и оно принято. Единственный его видимый недостаток — оно не соответствует выбранным стандартам и правилам, но, за исключением некоторых нишевых продуктов, это слабый аргумент в пользу изменений.
Вот так и остается временное решение. Навсегда.
А если временное решение станет источником проблем, маловероятно, что при починке будет также поставлена задача привести его в соответствие с принятыми стандартами качества. Что же делать? Быстрое промежуточное изменение временного решения часто устраняет проблему и всех устраивает. У него те же достоинства, что и у первоначального временного решения, просто оно… новее.
Представляет ли это проблему?
Все зависит от проекта и вашего личного интереса в поддержании стандарта качества готового кода. Если в системе слишком много временных решений, ее энтропия или внутренняя сложность возрастает, а удобство сопровождения снижается. Однако в первую очередь, возможно, следует задавать иной вопрос. Не забывайте, что мы обсуждаем решение. Возможно, вы и сами не рады такому решению — как вряд ли рад ему кто-то другой, — но стимул перерабатывать решение слаб.
Так что же можно сделать, если это для нас проблема?
1. Прежде всего, избегать временных решений.
2. Изменить факторы, влияющие на решение руководителя проекта.
3. Оставить все, как есть.
Рассмотрим эти варианты более подробно:
1. Во многих случаях отказ от временного решения неприемлем. Есть реальная задача, которую необходимо решить, и оказывается, что стандарты слишком жесткие для этого. Можно попробовать изменить стандарты — достойное, хотя и трудоемкое свершение, — но на это уйдет время, а проблему нужно решать прямо сейчас.
2. Эти факторы коренятся в культуре проекта, а она противится насильственным изменениям. Успеха можно достичь лишь в очень маленьких проектах — особенно когда работаешь один — и если удастся навести порядок, не спрашивая разрешения. Успех возможен и тогда, когда в коде проекта такой беспорядок, что это заметно тормозит работу, и все согласны, что нужно потратить некоторое время на наведение порядка.
3. Если предыдущий вариант не действует, положение дел сохраняется автоматически.
Среди множества созданных вами решений некоторые будут временными и в большинстве своем полезными. Лучший способ избавиться от временных решений — это сделать их избыточными, предложив более элегантные и полезные решения. И да пребудет с вами душевный покой, чтобы принять то, что вы не можете изменить, и силы изменить то, что можете, и мудрость, чтобы отличить одно от другого.
Интерфейсы должно быть легко использовать правильно и трудно — неправильноСкотт Мейерс
Одна из наиболее распространенных задач в разработке программного обеспечения — это спецификация интерфейса. Интерфейсы существуют на высшем уровне абстракции (интерфейсы пользователя), на низшем (интерфейсы функций) и на промежуточных уровнях (интерфейсы классов, библиотек и т. д.). Независимо от того, чем вы заняты — согласовываете с конечными пользователями их будущее взаимодействие с системой, сотрудничаете с разработчиками, разрабатывая спецификацию API, или объявляете закрытые функции класса, — проектирование интерфейса составляет важную часть вашей работы. Если вы справитесь с ней хорошо, пользоваться вашими интерфейсами будет сплошное удовольствие, а производительность пользователей возрастет. Если вы справитесь с задачей плохо, ваши интерфейсы станут источником разочарований и ошибок.
Хорошие интерфейсы обладают следующими свойствами:
Их легко использовать правильно
Пользователи хорошо спроектированного интерфейса почти всегда используют его правильно, потому что таков для этого интерфейса путь наименьшего сопротивления. Если это графический интерфейс пользователя, они почти всегда щелкают по нужному значку, кнопке или пункту меню, потому что это действие оказывается наиболее очевидным и простым. Если это интерфейс прикладного программирования, они почти всегда передают вызовам правильные параметры с правильными значениями, делая то, что кажется наиболее естественным. Если интерфейс таков, что им легко пользоваться правильно, все работает само.
Их трудно использовать неправильно
Хорошие интерфейсы учитывают, какие ошибки бывают у пользователей, и мешают их делать, а в идеале вообще этого не позволяют. Например, графический интерфейс пользователя может сделать неактивными или скрыть команды, не имеющие смысла в текущем контексте, а интерфейс прикладного программирования может решить проблему порядка аргументов, разрешив передавать параметры в любой последовательности.
Хороший подход к проектированию интерфейсов, которыми легко пользоваться правильно, — практиковаться в работе с ними до их создания. Создайте макет графического интерфейса пользователя (например, на доске с маркерами или на основе разложенных на столе листков для заметок) и поиграйте с макетом, прежде чем писать код. Напишите обращения к API, прежде чем объявлять функции. Разберите стандартные сценарии применения и определите, какого поведения ожидаете от интерфейса. По каким элементам в конечном итоге хотелось бы щелкнуть? Какие параметры в итоге хотелось бы передавать? Простые в работе интерфейсы естественны, потому что позволяют делать именно то, что вам нужно. Такие интерфейсы чаще удаются, если разрабатывать их с точки зрения пользователя. (Это одна из сильных сторон разработки через тестирование, TDD.) Чтобы затруднить некорректное использование интерфейса, нужны две вещи. Во-первых, следует предугадывать, какие ошибки могут делать пользователи, и находить способы их предотвращать. Во-вторых, следует понаблюдать за ошибками, которые допускают первые пользователи предварительной версии интерфейса, и модифицировать интерфейс — да-да, модифицировать интерфейс! — с целью воспрепятствовать таким ошибкам. Лучший способ предотвратить некорректное использование — это сделать его невозможным. Если пользователи упорно стараются отменить неотменяемое действие, сделайте это действие отменяемым. Если они постоянно передают интерфейсу прикладного программирования неверное значение, постарайтесь модифицировать этот API, чтобы принимать те значения, которые хотят передать пользователи.
А самое главное, помните, что интерфейсы существуют для удобства их пользователей, а не их создателей.
Пусть невидимое станет более видимымДжон Джаггер
Во многих отношениях невидимость справедливо поощряется как принцип разработки качественного программного обеспечения. В нашем профессиональном языке немало метафор невидимости, таких как прозрачность механизма и инкапсуляция. Программное обеспечение и процесс его разработки могут, если перефразировать Дугласа Адамса (Douglas Adams), оказаться в основном невидимыми:[20]
• Исходный код не обладает врожденным присутствием или врожденным поведением и не подчиняется физическим законам. Его можно увидеть, когда он загружен в редактор, но закройте редактор — и он исчезнет. Если долго над этим думать, то начинаешь сомневаться, существует ли он вообще — как дерево, которое упало, но некому было это услышать.
• Работающее приложение обнаруживает свое присутствие и поведение, но ничего не сообщает об исходном коде, на основе которого создано. Домашняя страница Google приятно лаконична, но за кулисами, несомненно, скрыто немало серьезного.
• Если вы сделали 90 % работы и безнадежно увязли в отладке остальных 10 %, то, видимо, нельзя считать, что сделано 90 %? Исправление ошибок — это не движение вперед. Вам не платят за отладку. Отладка — пустая трата времени. Хорошо, если пустая трата времени будет более заметна, чтобы можно было видеть ее реальную цену и, прежде всего, постараться не допускать этого.
• Если кажется, что ваш проект идет по графику, а через неделю обнаруживается, что он опаздывает на полгода, то у вас есть проблемы, главная из которых, возможно, не в том, что он опаздывает на полгода, а в существовании невидимых силовых полей, способных скрыть полугодовую задержку! Отсутствие видимого прогресса — то же самое, что отсутствие прогресса вообще.
Невидимость таит в себе опасность. Рассуждение становится яснее, когда есть конкретный предмет для обдумывания. Легче управлять вещами, которые можно видеть, и видеть в непрерывном изменении:
• При написании модульных тестов вы узнаете, насколько легко проводить модульное тестирование для конкретного модуля кода. Модульное тестирование выявляет присутствие (или отсутствие) качеств, которые желательны для кода, такие