?

Log in

No account? Create an account
Sprint #5 review - В Северном Ледовитом
June 6th, 2014
09:00

[Link]

Previous Entry Share Next Entry
Sprint #5 review
Закончился пятый спринт работы над нашей программой-нотатором. Этот спринт был плодотворным. Мы улучшили работу предыдущих функций и добавили новых.

Минус на минус даёт плюс
Автоматических тестов много не бывает. Чем больше тестов, тем меньше неожиданностей в конечном продукте. Например, один из новых тестов для пересчёта вёрстки вдруг неожиданно не прошёл. Оказалось, что при клонировании нотоносца в копию не переносилось значение предпочтительной дистанции из оригинала. Когда мы исправили эту ошибку, перестал проходить один из старых тестов. Оказалось, что у нас была ещё одна ошибка — на этот раз в тестовых данных, где значение предпочтительной дистанции для одного из нотоносцев было задано неоправданно большим. Две эти ошибки компенсировали друг друга, и старые тесты их не замечали. Однако новые тесты смотрели на ситуацию под другим углом, и благодаря этому ошибки обнаружились. Сейчас работа программы контролируется 357 автоматическими тестами, которые запускаются по два раза при каждом билде, а также десятки раз в процессе разработки. Каждый тест в автоматическом режиме прокручивает типовые (и экстремальные) сценарии работы с реализованными функциями и контролирует, что они дают ожидаемый результат.

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

Вертикальное форматирование
При вертикальном форматировании допустимая погрешность у нас 5 микрометров. На деле она оказывается примерно 1 микрометр. Это значит, что при растягивании нотных станов на странице нижняя линейка последнего стана может не попасть в нижнее поле страницы на 1 микрометр. (Напомним, что в миллиметре тысяча микрометров, а наименьшая величина, различимая невооружённым глазом, составляет сто микрометров.) Нам не удалось разглядеть погрешность даже при 3000-процентном увеличении.

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

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



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

Удаление стана
Мы ввели в нашу программу вторую команду — удаление стана (первой командой было его добавление).



Вопреки кажущейся простоте, внутренняя реализация этой команды существенно сложнее, чем команды добавления стана. Нужно удалить этот стан из всех систем, где он используется; нужно проследить, чтобы все акколады, начинающиеся и заканчивающиеся на этом стане, либо исчезли, либо перераспределились. И, самое главное, нужно предусмотреть отмену этой операции, при которой из того самого волшебного рукава, который мы упоминали в прошлый раз, вернётся прежнее содержимое удалённого стана. По окончании сеанса работы в «рукаве» накапливается довольно много всякого содержимого, поэтому мы реализовали ещё и своевременную чистку. Однако ничего не исчезает — содержимое стирается только в том случае, если отмена команды становится по логике невозможной (например, если отмена уже совершена и содержимое использовано, или если документ закрыт).

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

(L)-щелчок — перемещает курсор в щёлкнутую позицию
(R)-протаскивание — протаскивание документа
 ⇧ Shift  + (R)-щелчок — увеличение масштаба
 Ctrl  +  ⇧ Shift  + (R)-щелчок — уменьшение масштаба
(RR)-щелчок — возврат к предыдущему масштабу
(R)-щелчок — вызов контекстного меню

Внимательный читатель заметит, что эти команды повторяют клавишно-мышиные комбинации одной известной программы на букву Ф. Это вовсе не потому, что мы её так любим, а потому что считаем, что там эти команды подобраны наиболее удобно, хотя и реализованы топорно. Мы подробно писали об этих недостатках и сравнивали разные варианты навигации. В нашей программе мы исправили упомянутые недостатки, хотя не всегда это было легко. Например, протаскивание и масштабирование у нас работает в любой точке листа — не только в пустой, но и в заполненной нотным текстом, поскольку отличить команду вызова контекстного меню от команды протаскивания или масштабирования довольно просто. А вот как отличить одинарный щелчок от двойного? Ведь двойной — это то же самое, что два одинарных. Как программе понять, что пользователь хочет вернуться к предыдущему масштабу, а не дважды вызвать контекстное меню? Самый простой способ — это после первого щелчка чуть-чуть подождать, и если второго щелчка не последует, то показать контекстное меню, а если последует, то отрабатывать масштабирование. Этот вариант мы, разумеется, реализовали. Однако не всякий пользователь захочет ждать, даже чуть-чуть. Он хочет увидеть меню сразу после отпускания кнопки мыши. Чтобы удовлетворить это (совершенно законное) желание пользователя, мы провели статистическое исследование на мышах. И поняли, что скорость нажатия и отпускания мыши при двойном и одинарном щелчках отличается. При двойном щелчке между нажатием и отпусканием, как правило, проходит меньше 110 миллисекунд, а при одинарном — чуть больше. Возможно, эта величина зависит от конкретного человека, так что в будущем мы сделаем её настраиваемой. Даже если пользователь щёлкает одинаково быстро при двойном и одинарном щелчке, мы покажем ему меню, но с некоторым запозданием (в 500 миллисекунд — это время ожидания второго щелчка).

Правило хорошего тона — это делать одни и те же функции доступными разными способами. Поэтому мы реализовали вызов контекстного меню не только мышью, но и соответствующей клавишей  Menu  на windows-клавиатурах и стандартной комбинацией  ⇧ Shift  +  F10 , о которой во многих программах забывают.

Пока в программе лишь две команды, они обе попадают в контекстное меню. Позже, однако, нам придётся исходя из контекста решать, какие команды предоставлять в меню.


Медленно, но верно наша программа двигается вперёд. Следующее спринт-ревью состоится в этом ЖЖ ровно через две недели, в пятницу, 20 июня, в 9:00 по московскому времени. Приглашаем всех желающих.

Tags: , ,

(Leave a comment)

Powered by LiveJournal.com