Комментарии 5
Цветовые маркеры вещь очень полезная, но и как любой другой инструмент нужно применять с головой чтобы документация не превращалось в разноцветное марево, потому что цвета как могут привлекать внимание, так и отвлекать.
Абсолютно точно!
Я в этой статье вопросов о том, как подбирать цвета, чтобы не рябило в глазах, глубоко не касался. В целом это тема отдельного разговора, но тут можно рекомендовать придерживаться хотя бы базовых идей, а именно: выбирать цвета
так, чтобы они сочетались, контрастировали, где надо (не делать тёмно-зелёные подписи на синем фоне, например), и преимущественно не были сильно насыщенными (таблицу, в которой строки окрашены в глубокие тона будет тяжко смотреть);
экономно (условно, если 4-х цветов достаточно для представления информации и расстановки нужных акцентов, то и хватит);
сообразно культурному контексту и сложившимся практикам (пример: не надо сигнальный красный цвет использовать для выделения нормального поведения, а успокаивающий зелёный -- для сбойных ситуаций; другой пример: если есть корпоративные правила, согласно которым синий цвет в архитектурных артефактах обозначает системы, находящиеся за периметром компании, то не стоит этот цвет использовать в собственном кодировании для иных целей, чтобы не сбивать с толку).
Меня немного позабавил маркер "Удалено"...
Как пометить цветом элемент, который ты удалил?
Для себя я определил что элементы/требовании из базовой реализации, которые необходимо удалить для проекта, я их зачеркиваю:
#Проектно Какое-то требование.
Так же на проектных элементах ставлю тэг #Проектно который показывает отличии от базовых реализаций.
Простое удаление не всегда подходит, и иногда лучше зачеркнуть и пометь что оно неактуально, а не гадать почему этого нет.
Меня немного позабавил маркер "Удалено"
Если я правильно понял, ремарка касалась раздела "Изменение текста требований". Поясню на примере.
Определённые положения НФТ у нас принято представлять в табличном виде (к примеру, метрики прикладного мониторинга, которые следует отбрасывать в той или иной точке). Если в очередном релизе происходит изменение, которое предполагает удалить это требование (в нашем примере это будет какая-то определённая метрика, потребность в которой отпала), то соответствующая строка заливается цветом.
Зачем это. Есть договорённость с согласующими экспертами о том, что сразу бесследно требования не удаляются; надо в релизе, в котором это требование следует удалить, в явном виде показать. Фактически требование прошлого релиза цветом помечается красной заливкой как удаляемое. Этот подход позволяет ускорить прохождение экспертизы, да и разработчикам и QA такой подход кажется удобным (глазами пробежал, увидел заливку — значит надо в этом месте что-то сделать).
Наконец, дошли руки до того, чтобы более развёрнуто сформулировать основные подходы к выбору цвета, которых придерживаюсь сам. https://telegra.ph/7-rekomendacij-po-vyboru-cveta-02-05. Надеюсь, будет полезно.
Использование цвета при анализе и проектировании систем. Часть 3