litceysel.ru
добавить свой файл
  1 ... 3 4 5 6 7 8

54. Долговечность временных решений

Клаус Маркардт (Klaus Marquardt)

Для чего создаются временные решения?

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

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

Промежуточным решениям, однако, свойственна инертность (или инерция, если вам так больше нравится). Благодаря их существованию, пользе и широкому распространению нет прямой необходимости создавать что-то другое. Когда приходится решать, какие действия могут в наибольшей степени повысить ценность продукта, правильная интеграция промежуточного решения обычно не получает высокого приоритета. Почему? Потому что решение есть, работает и признано. Единственный его недостаток в том, что оно не соответствует отдельным стандартам и правилам, но, за исключением немногих особых случаев, это слабый стимул для активных действий.

Таким образом, временное решение остается. Навсегда.

А если временное решение станет источником проблем, то маловероятно, что при его модификации будет также поставлено условие привести его в соответствие с принятыми стандартами качества. Что делать? Быстрое промежуточное изменение промежуточного решения часто устраняет проблему и всех устраивает. У него те же достоинства, что и у первоначального временного решения, просто оно ... новее.

Так в чем проблема?

Все зависит от проекта и вашего личного интереса в поддержании стандарта качества готового кода. Если в системе слишком много временных решений, ее энтропия или внутренняя сложность растет, а возможность сопровождения падает. Однако это, возможно, не самый главный вопрос. Не забывайте, что мы обсуждаем решение. Возможно, вы сами выбрали это решение – едва ли его выбрал кто-то другой, – но мотивы для его переработки слабы.


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

1. Прежде всего, не прибегать к временным решениям.

2. Задействовать силы, влияющие на решение руководителя проекта.

3. Оставить все, как есть.

Рассмотрим эти варианты более подробно:

1. Во многих случаях отказ от временного решения неприемлем. Есть реальная задача, которую нужно решить, а стандарты этому мешают. Можно попробовать изменить стандарты – достойная, хотя и утомительная попытка, – но на это уйдет время, а проблему нужно решать быстро.

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

3. Если предыдущий вариант не действует, все автоматически сохраняется, как есть.

Среди всех ваших будущих решений некоторые окажутся временными и в большинстве своем полезными. Лучший способ избавиться от временных решений – это сделать их лишними, предоставив более красивые и полезные решения. И дай вам Бог душевный покой, чтобы принять то, что вы не можете изменить, дай силы изменить то, что можете, и мудрость, чтобы отличить одно от другого.

55. Интерфейсы должно быть легко использовать правильно и трудно - неправильно


Скотт Мейерс (Scott Meyers)

Одна из наиболее распространенных задач в разработке программного обеспечения – это спецификация интерфейса. Интерфейсы возникают на высшем уровне абстрагирования (интерфейсы пользователя), на низшем (интерфейсы функций) и на промежуточных уровнях (интерфейсы классов, библиотек и т. д.). Независимо от того, чем вы заняты – согласовываете с конечными пользователями способы их взаимодействия с системой, сотрудничаете с разработчиками при спецификации API или объявляете закрытые функции класса, – проектирование интерфейса составляет важную часть вашей работы. Если вы справитесь с ней успешно, вашими интерфейсами будет приятно пользоваться, и благодаря им повысится производительность труда людей. В противном случае, ваши интерфейсы станут источником разочарований и ошибок.


Хорошие интерфейсы должны иметь следующие качества:

Легкость корректного употребления

Если люди используют хорошо спроектированный интерфейс, то почти всегда делают это корректно, потому что следуют путем наименьшего сопротивления. Если это GUI, то они почти всегда щелкают по правильному значку, кнопке или пункту меню, потому что это наиболее очевидные и простые вещи. Если это API, они почти всегда передают правильные параметры с правильными значениями, потому что это самое естественное. Если интерфейс таков, что им легко пользоваться правильно, все работает само.

Трудность некорректного употребления

Хорошие интерфейсы учитывают, какие ошибки бывают у пользователей, и мешают их делать, а в идеале – не позволяют. Например, GUI может дезактивировать или удалить команды, не имеющие смысла в текущем контексте, а API может решить проблему порядка аргументов, разрешив передавать параметры в любой последовательности.

Хороший подход к проектированию интерфейсов, которыми легко пользоваться корректно, это попрактиковаться в работе с ними до того, как они созданы. Смоделируйте GUI – например, на классной доске или с помощью индексных карточек на столе – и поиграйте с ним, прежде чем писать код. Напишите обращения к API, прежде чем объявлять функции. Разберите стандартные случаи применения и определите, какого поведения вы ждете от интерфейса. По каким элементам вам хотелось бы щелкнуть? Какие параметры вам хотелось бы передавать? Простые в работе интерфейсы выглядят естественно, потому что позволяют делать то, что вам нужно. Такие интерфейсы чаще удаются, если разрабатывать их с точки зрения пользователя. (Это одна из сильных сторон программирования на основе тестов.)

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


А самое главное, помните, что интерфейсы существуют для удобства их пользователей, а не их создателей.

56. Пусть невидимое станет более заметным


Джон Джеггер (Jon Jagger)

Во многих отношениях невидимость справедливо поощряется в качестве принципа, которого следует придерживаться в разработке программного обеспечения. В нашей терминологии немало метафор невидимости – упомянем лишь две из них: прозрачность механизма (mechanism transparency) и сокрытие информации (information hiding). Программное обеспечение и процесс его разработки могут, если перефразировать Дугласа Адамса, оказаться самыми невидимыми:

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

  • Работающее приложение обнаруживает свое присутствие и поведение, но ничего не говорит об исходном коде, из которого оно было создано. Домашняя страница Google демонстрирует приятный минимализм; скрытые за ней действия, несомненно, имеют важное значение.

  • Если вы сделали 90% работы и безнадежно увязли в отладке остальных 10%, то, видимо, нельзя считать, что сделано 90%? Исправление ошибок – это не движение вперед. Вам не платят за отладку. Отладка – пустая трата времени. Хорошо, если пустая трата времени будет более заметна, чтобы можно было видеть ее реальную цену и, прежде всего, постараться не допускать.
  • Если кажется, что ваш проект идет по графику, а через неделю обнаруживается, что он опаздывает на полгода, то у вас есть проблемы, главная из которых, возможно, не в том, что он опаздывает на полгода, а в существовании невидимых силовых полей, способных скрыть полугодовую задержку! Отсутствие видимого прогресса тождественно отсутствию прогресса вообще.


Невидимость таит в себе опасность. Рассуждение становится яснее, когда есть конкретный предмет для обдумывания. Легче управлять вещами, которые можно видеть, и видеть в непрерывном изменении:

  • При написании модульных тестов вы узнаете, легко ли модуль кода допускает модульное тестирование. Это поможет выявить присутствие (или отсутствие) качеств, которые желательны для кода, такие как слабая связанность (coupling) и высокое сцепление (cohesion).

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

  • С помощью досок объявлений и карточек можно сделать прогресс наглядным и конкретным. Задачи могут иметь статус «Не начата», «В процессе работы» и «Завершена» без ссылок на скрытый инструмент управления проектом и без необходимости контролировать предоставление программистами фиктивных отчетов о состоянии.

  • Инкрементальная разработка повышает наглядность прогресса разработки (или отсутствия его) в результате увеличения частоты предоставления свидетельств ведущейся разработки. Создание программного обеспечения, готового к выпуску, отражает реальное положение вещей, в отличие от оценок и предположений.

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



<< предыдущая страница   следующая страница >>