Не трогайте мышь и отойдите от клавиатуры

Скачать 360.39 Kb.

Название	Не трогайте мышь и отойдите от клавиатуры
страница	8/8
Дата публикации	21.08.2013
Размер	360.39 Kb.
Тип	Документы

100-bal.ru > Философия > Документы

1 2 3 4 5 6 7 8

Тестируйте, когда спите (или по выходным)

Раджит Аттапатту (Rajith Attapattu)

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

Доводилось ли вам совершать проступок, сохраняя изменения без прогона всех тестов? Одна из главных причин, по которым программисты не проводят тесты перед сохранением изменений, это их большая продолжительность. Когда горят сроки и в случае крайней необходимости, ~~естественно~~ возникает естественное стремление срезать угол. Одно из решений этой проблемы – разбить набор тестов на два или более профиля. Меньший, обязательный профиль тестов, который быстро отрабатывает, должен гарантировать выполнение тестов перед каждым сохранением. Все остальные профили (и, на всякий случай, обязательный тоже) можно автоматизировать для запуска ночью, чтобы иметь к утру результат.
Было ли у вас достаточно возможностей для проверки стабильности работы вашего продукта? Долго выполняемые тесты полезны для обнаружения утечек памяти и других проблем стабильности. Их редко запускают в дневное время, потому что они отнимают время и ресурсы. Можно автоматически запускать тесты нагрузки в ночное время и в выходные дни. С 6 вечера пятницы до 6 утра понедельника у вас есть 60 часов для тестирования.
Удается ли вам получить время для тестирования производительности в рабочих условиях? Я видел, как команды дерутся друг с другом, чтобы получить время в среде для тестирования производительности. Чаще всего, никто не получает достаточно времени для тестирования качества в рабочие часы, хотя после конца рабочего дня среда практически бездействует. Серверы и сеть не так сильно заняты ночью и по выходным. Это идеальное время для прогона тестов эксплуатационных качеств.
Не слишком ли много у вас разных конфигураций, чтобы тестировать их вручную? Часто продукт рассчитан на работу на нескольких платформах. Например, 32-битовые и 64-битовые версии, для Linux, Solaris и Windows или просто нескольких версий одной операционной системы. Дело осложняется еще более тем, что современные приложения допускают применение множества транспортных механизмов и протоколов (HTTP, AMQP, SOAP, CORBA и т. д.). Проверка всех возможных комбинаций требует очень большого времени и чаще всего делается ближе к выпуску в силу ограниченности ресурсов. Увы, некоторые ужасные ошибки обнаруживаются лишь на этой стадии, когда уже слишком поздно.

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

Тестирование – это инженерная строгость в разработке программного обеспечения

Нил Форд (Neal Ford)

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

В сравнении с «реальной» инженерией разработка программ находится примерно на том уровне, где были строители мостов, когда стандартная практика предполагала, что нужно построить мост, а потом нагрузить его какими-то тяжестями. Если выдержит, значит, это хороший мост. Нет – возвращаемся к чертежной доске. За последние несколько тысяч лет инженеры развили математику и физику в такой мере, что они позволяют найти надежное решение без необходимости строить его, чтобы увидеть, как оно работает. Ничего подобного в программировании нет и, вероятно, не будет, потому что программное обеспечение имеет очень существенные особенности. Классическое исследование разницы между программной и обычной инженерией провел Джек Ривс в статье «What is Software Design?», опубликованной в C++ Journal в 1992 году.^³ Несмотря на то, что статья была написана почти два десятилетия назад, она до сих пор удивительно точна. Ривз нарисовал в своем сравнении мрачную картину, и что отсутствовало в 1992 году, так это сильное моральное побуждение к тестированию программного обеспечения.

Тестировать «реальные» объекты тяжело, потому что прежде чем тестировать, их нужно построить, а это отбивает охоту к рискованным постройкам с целью посмотреть, что из этого получится. Но процесс стройки в программной отрасли смехотворно дешев. Мы создали целую экосистему инструментов, с помощью которых его легко осуществить: блочное тестирование, фиктивные объекты, средства тестирования и многое прочее. Есть инженеры, которые с радостью были бы готовы что-то построить и протестировать в реальных условиях. Мы, разработчики программного обеспечения, должны принять тестирование в качестве главного (но не единственного) механизма верификации для программ. Не нужно ждать появления своего рода дифференциального исчисления для программ, потому что в нашем распоряжении уже есть инструменты, гарантирующие хорошую инженерную практику. В этом смысле у нас есть оружие против менеджеров, которые говорят нам, что «нет времени для тестирования». Тот, кто строит мост, никогда не услышит от своего начальника: «Вот что, не занимайся расчетом прочности этого здания, потому что иначе мы не уложимся в график» (странно, чувак строит мост а босс ему толкует про прочность здания :-). Признание того, что тестирование – это действительно путь к воспроизводимости результатов и качеству в программной отрасли, позволит нам, разработчикам, отвергнуть аргументы против него как профессионально безответственные.

Тестирование требует времени, так же, как его требует расчет прочности. То и другое гарантирует качество конечного продукта. Разработчикам программного обеспечения пора начать нести ответственность за свою продукцию. Одного тестирования недостаточно, но оно необходимо. Тестирование – это инженерная строгость в разработке программного обеспечения.

Подход на основе состояний

Никлас Нилссон (Niclas Nilsson)

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

«У нас абсолютно, совершенно кончились запасы молока».

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

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

Рассмотрим простой интернет-магазин, который принимает в оплату только кредитные карточки и не выписывает клиентам счета. При этом класс Order (заказ) содержит такой метод:

public boolean isComplete() {

return isPaid() && hasShipped();

}

Разумно, правда? Так вот, несмотря на то, что это выражение аккуратно выделено в метод, а не разбросано повсюду путем копирования и вставки, оно вообще не должно существовать. А то, что оно существует, указывает на проблему. Какую? Нельзя поставить заказ, прежде чем он оплачен. Поэтому hasShipped не может возвратить true, пока isPaid не возвратит true, а тогда часть выражения излишня. Возможно, вам все же нужен isComplete для ясности кода, тогда он должен выглядеть как-то так:

public boolean isComplete() {

return hasShipped();

}

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

В процессе формирования: Можно добавлять и удалять товары. Нельзя отправлять.
Оплачен: Нельзя добавлять и удалять товары. Можно отправлять.
Отправлен: Все кончено. Больше никаких изменений.

Это важные состояния, и перед проведением операций нужно проверить, что вы в должном состоянии, и что из текущего состояния вы перейдете в допустимое. Короче, нужно тщательно защищать объекты в правильных местах.

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

Изучите паттерн State. Освоившись с ним, почитайте о программировании по контракту. Оно помогает обеспечить допустимость состояния путем проверки данных и самого объекта на входе и выходе из каждого открытого метода.

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

Одна голова хорошо, но две – часто лучше

Adrian Wible (Эдриан Уибл)

Программирование требует вдумчивости, а вдумчивость нуждается в уединении. Отсюда родился стереотип программиста.

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

Что это означает для разработчиков? Быть экспертом в области технологии программирования долее (?) недостаточно. Вы должны научиться эффективно работать с другими людьми.

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

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

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

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

Какова долгосрочная выгода от того, что вы узнаете «быструю клавишу» на клавиатуре? Какой мерой мы измерим улучшение качества продукта, достигнутое в результате работы в паре? Какой мерой измерить пользу от того, что ваш партнер не дал вам зайти в тупик в решении сложной проблемы? Одно из исследований говорит о 40-процентном увеличении эффективности и скорости.^⁴ А как оценить уменьшение «лотерейного» риска? Большинство положительных сторон работы в паре трудно оценить.

Кто должен работать в паре и с кем? Если вы новичок в команде, то важно, чтобы вашим напарником оказался опытный специалист. Столь же важно, чтобы он обладал хорошими навыками в общении внутри команды и в наставничестве. Если у вас недостаточно знаний в предметной области, работайте в паре с тем, кто ее хорошо знает.

Если нет уверенности, экспериментируйте: сотрудничайте с коллегами. Создавайте пары для решения интересных сложных проблем. Посмотрите, что у вас получится. Повторяйте попытки.

1 Cognitive Psychology (Когнитивная психология) 4: 328-50 (1973)

2 http://www.amazon.com/dp/0135974445/

3 http://www.developerdotstar.com/mag/articles/reeves_design.html

4J. T. Nosek, “The Case for Collaborative Programming,” Communications of the ACM, March 1998