Дизайн ревю что это
САПР для инженера
Блог Михайлова Андрея о приемах работы и хитростях в САПР
Страницы
четверг, 6 апреля 2017 г.
Design Review умер. Да здравствует Design Review!
Я не просто так перефразировал в заголовке известную фразу. Все мы помним, что Autodesk в какой-то момент перестал обновлять Design Review и последней стала версия Autodesk Design Review 2013. Но вот прошло пять лет и вышла новая версия Design Review.
Правда, видимо для того, чтобы не путать пользователей и не провоцировать лишние вопросы, программа больше не имеет номера, называется просто Autodesk Design Review.
Программа доступна на 11 языках, включая русский (об этом ниже).
Что нового в Autodesk Design Review
Ни интерфейс, ни функциональные возможности программы не поменялись
Что такое Design Review и формат DWF
Бесплатная программа Autodesk Design Review предназначена для просмотра, нанесения пометок, печати и отслеживания изменений в файлах 2D-чертежей и 3D-моделей. Программа позволяет работать с файлами следующих форматов: DWF, DWFx, DWG, DXF, PDF, bmp, jpg, gif, pcx, pct, png, rlc, tga, tif, mil, cal и многими другими.
Текущая версия программа выпускается на 11 языках, но обратите внимание, что дистрибутив русской версии вынесен отдельно
Дело в том, что на русский язык программа была переведена в 2013 году силами активистов Сообщества пользователей Autodesk, во главе этого проекта стоял Илья Глуханюк.
Что такое формат DWF, чем он отличается от DWG и для чего он нужен, лучше всего рассказал все тот же Илья Глуханюк в своем легендарном докладе «От DWG до DWF один шаг», с которым он выступал на всех САПРяжениях-2013. Посмотрите, не пожалеете!
Немного истории. Как появился формат DWF
Формат DWF придумал Брайан Мэтьюс (Brian Mathews), который теперь занимает должность вице президента (VP) и технического директора (CTO) в Autodesk. Первым шагом компании к обмену чертежными данными через интернет стал плагин WHIP! для браузера Netscape Navigator. В то время Internet Explorer еще не отвоевал рынок. Изначально разработчики Autodesk хотели назвать свои файлы для обмена чертежными данными whip (.whp). Но, вице президент по AutoCAD Джон Линч (John Lynch) побоялся, что пользователи не будут ассоциировать эти файлы с Autodesk, поэтому название поменяли на Drawing Web Format (DWF). После того, как стало возможным генерировать такие файлы не только с помощью программ от Autodesk, но и с помощью сторонних приложений, название эволюционировало в привычное Design Web Format (DWF).
Позже в 2012 году Autodesk прекратил развитие продукта и последней версией стал Design Review 2013. Причину закрытия продукта объяснили тем, что вся его функциональность перейдет в «облачный» сервис Autodesk 360.
Однако, полного замещения не случилось, и теперь разработчики возродили продукт, немного обновив его.
При этом совершенно понятно, что это временное «воскрешение из мертвых» и, рано или поздно, этот продукт будет полностью снят с поддержки и разработки, как только «облачный» сервис доведут до ума. А пока пользуемся!
Дизайн ревю что это
Общероссийский журнал для профессионалов дизайнеров, архитекторов, художников, педагогов аспирантов и студентов
Дизайн Ревю имеет свои представительства в Москве, Санкт-Петербурге, Перми, Тюмени, Сочи,Ростове-на-Дону, Красноярске, Калининграде, Хабаровске и др. (более 30 городов России), а также в Бремене (Германия), Торонто (Канада),Хайфе (Израиль), Неаполе (Италия), Цюрихе (Швейцария)
Бесплатная рассылка в аппарат президента и Правительство России и Москвы, в администрации крупнейших городов России, во все архитектурно- художественные вузы, и художественные училища России, во все региональные отделения Союза Дизайнеров России
Целевое распространение на Фестивале Российского Дизайна на Кавминводах (Железноводск), Всероссийском Дизайн-Форуме художников и дизайнеров городов России (Сочи), Общероссийской выставке-кокурсе на лучшую работу года (Москва), Международном смотре-конкурсе дипломных проектов по архитектуре и дизайну,Международной Казанской биеннале по архитектуре и дизайну (Казань), Междунородной биеннале «Модулор» (Санкт Петербург»)Подписка и распространение через центральный офис и представителей журнала
По вопросам размещения логотипа своей фирмы на форзаце журнала, заказных статей, рекламы на сайте журнала, рекламы в иллюстрированном рекламном приложении-вкладке обращаться в отдел маркетинга центрального офиса или к представителям журнала в регионах
3 000 экземпляров 100 страниц формата 70х100 1/16
420043, ул.Зеленая, д.1, г. Казань/тел/факс (843)2360913, Е-mail design-review 
hitv.ru
«Дизайн Ревю» выходит с сентября 1994 года как информационный бюллетень а, с 1995 года как информационный научно-практический журнал Союза Дизайнеров России. В 2006 году после госперерегистрации становится общероссийским. Вышло порядка 30-ти номеров со статьями более 60 авторов. Среди них и такие известные искусствоведы и теоретики дизайна как Никита Воронов и Вячеслав Глазычев, Александр Раппапорт и Галина Курьерова, Сергей Серов и Ирина Коробьина, Юрий Назаров и Владимир Шимко, педагоги Сергей Кузнецов, Владимир Захаров, Ляйля Кулеева, Ринат Мухитов, Николай Новиков, Александр и Марина Сурины. Их статьи стали украшением нашего журнала.Дизайн ревю стал своеобразной школой мастерства для многих аспирантов и молодых ученых. Дизайн ревю стал своеобразной летописью истории российского союза дизайнеров. На его страницах наряду со статьями теоретического и проблемного характера помещались важные информационные и документальные материалы, начиная от программных выступлений для ассамблей союза и заканчивая, Образцовым кодексом (кодекс чести) поведения дизайнера, Положения о главном дизайнере города и Рекомендаций Союза Дизайнеров о величине авторского гонорара за произведения дизайна. Сегодня мы имеем на нашем рынке массу глянцевых журналов, в том числе по архитектуре, интерьерам, графическому дизайну, выпускаемые многотысячными тиражами. Естественно, при таких тиражах они ориентируются, главным образом, на вкусы обывателя. Журнала для серьезного внутрипрофессионального общения, каким в свое время была «Техническая эстетика», у нас к сожалению в настоящее время нет. Попытаться хоть как-то восполнить этот образовавшийся пробел и ставит сегодня своей целью «Дизайн ревю».
Надеюсь, что «Дизан Ревю» станет достойным продолжателем традиций, заложенных журналом «Техническая эстетика» более четырех десятков лет назад, и обретет такую же популярность в кругах профессионалов и всех тех, кто заботятся о людях и стремиться создавать для них предметное окружение, которое радовало бы их дома, на улице и на работе.
Юрий Назаров. Президент Союза Дизайнеров России
AutoCAD
Autodesk® Design Review – это бесплатная программа, используемая для создания и просмотра файлов DWF. DWF — это открытый, публикуемый и защищенный формат файлов, разработанный Autodesk, который позволяет объединять, публиковать и совместно использовать разнообразные данные 2D и 3D проектирования.
Design Review позволяет всем сотрудникам, работающим над проектом или производством, просматривать, печатать, измерять и помечать файлы DWF, DWG, DXF, PDF, а также файлы растровых изображений, содержащие 2D- и 3D-объекты. Программа Design Review полностью интегрирована с AutoCAD®, Inventor® и Revit® и позволяет легко обеспечить совместное использование чертежей, моделей, карт и проектных данных с участниками рабочей группы, клиентами, консультантами, подрядчиками, партнерами, поставщиками и другими заинтересованными лицами, у которых могут отсутствовать программы для проектирования или навыки работы с ними.
Для совместного использования проектных данных в Design Review можно отправить проект по электронной почте, опубликовать на веб-сайте, во внутренней сети или записать на физический носитель, например на DVD-диск. Программу Design Review можно бесплатно загрузить по адресу http://www.autodesk.com/designreview-download. Программу можно распространить по внутренней сети или развернуть в составе образа корпоративного компьютера (при условии, что она распространяется целиком, согласно положениям лицензионного договора).
Файлы DWF и DWFx
Файл DWF можно использовать для организации подшивок, моделей, анимаций, результатов анализа методом конечных элементов (МКЭ) и информации карт, а также других связанных с проектом файлов в одном файле с высокой степенью сжатия. Вместе с Design Review файлы DWF позволяют оптимизировать совместную работу путем четкой передачи информации, такой как изменения или исправления проекта, и при этом сокращают затраты на печать и отправку, связанные с передачей бумажных документов расширенной рабочей группе.
Подобно файлам Adobe® PDF, файлы DWF не подлежат изменению, чем напоминают распечатки. Однако в отличие от файлов PDF файлы DWF сохраняют подробную информацию о проекте и масштаб и поэтому являются более удобными для архитекторов, инженеров и проектировщиков.
Последняя версия формата файлов DWF, т. е. DWFx, разработана на основе спецификации XML Paper Specification (XPS) корпорации Microsoft. DWFx упрощает передачу проектных данных рецензентам, которые не могут установить программное обеспечение.
Файлы DWFx можно быстро открыть и распечатать с помощью бесплатной программы Microsoft XPS Viewer. В отличие от файлов DWF файлы DWFx содержат дополнительную информацию для отображения проектных данных в программе Microsoft XPS Viewer. По этой причине размер файлов DWFx превышает размер соответствующих файлов DWF.
В настоящее время приложение Microsoft XPS Viewer не поддерживает листы, содержащие 3D-объекты, объекты, защищенные паролем, свойства объекта, объекты с ограничениями или координаты карт с привязкой к местности. В программе Microsoft XPS Viewer при попытке просмотра листов файлов DWFx, содержащих любой из этих неподдерживаемых элементов, появляется предупреждение с просьбой загрузить Design Review для просмотра файла DWFx.
Рабочий процесс цифрового проектирования
Как правило, файлы DWF формируются при создании чертежа или модели в таких программах Autodesk, как AutoCAD, Inventor и Revit. Перед публикацией файла DWF автор определяет, какие элементы (модель, листы, слои, блоки, именованные виды и т. п.) включаются в публикуемый файл DWF. Определив содержимое, он публикует исходный файл в формат DWF, а затем отправляет DWF группе рецензентов для проверки цифрового проекта.
Цифровой рабочий процесс можно повторять неограниченное количество раз в соответствии с итеративным характером процесса проектирования и проверки.
Gaperton’s blog
Design Review и его роль
D>>кто-нибудь использует такую процедуру как Code review? Как это происходит? вы реально выделяете час времени в неделю, садитесь с командой и начинаете стебаться друг над другом.
B>3 дня назад мне делали. общий обьем — что-то около 3к строк (всего).
B>человек затратил около 2-х недель, что бы вычитать весь мой код.
B>сидели 2 часа в компании с еще одним, в митингруме с проектором — отвечал на вопросы. вроде отбился.
Нормальный средний темп кодревью, при котором реально найти ошибки — примерно 200 строк кода в час. Плюс-минус, потому, что средний.
3к строк будет примерно 15 часов чистого времени. При условии 4-х часов чистого времени в день (полная загрузка) имеем дня 4, вообще-то. То есть, кодревью выполнялось скорее медленно. Если ревьювер при этом еще и не нашел в коде багов (критерий эффективности ревью, ваще на нем ошибки положено ловить) — это отрицательная работа. От такого code review пользы немного.
Медленно и неэффективно оно может быть по разным причинам. Например:
1) Человек, кто проводит код ревью, не проводил ранее дизайн ревью этого же кода. Лечится либо kick-off meeting перед началом ревью (что считается необходимым для экспертизы материала такого объема), где автор объясняет, что тут ваще происходит, и как оно ваще работает. Либо, что гораздо эффективнее во всех смыслах, введением отдельного дизайн-ревью, где автор докладывает, как он собирается решать задачу, до того, как пишет основную массу кода. Для дизайн ревью в простейшем случае сойдет устный доклад у маркерной доски. И те же люди, кто проводил дизайн ревью, потом выполняют код ревью.
2) Человек вообще не специалист в данной теме — маловероятно, что он найдет какие-либо ошибки кроме пунктуации, эстетики, и соблюдения стандарта кодирования. Подобные ошибки, к слову, ловятся в темпе побыстрее чем 200 строк в час.
3) Давайть на ревью такие большие фрагменты кода — фашызм. Надо стараться бить на части. Опять же, проводя до этого дизайн ревью, чтобы люди были в курсе.
Вообще, дизайн ревью необходимы для того, чтобы сделать code review более эффективными на практике. Почему:
1) Они снижают затраты на code review, и совокупные затраты на все review.
2) Ошибка, которая может быть обнаруженная на дизайн ревью, в исправлении почти бесплатна, и является напротив — наиболее дорогой ошибкой, будучи найденной на код ревью.
3) Надо учесть социальный фактор. Бывает так, что на кодревью выясняется, что весь подход к решению задачи неправильный, и делать по хорошему надо не так. Однако, автор уже написал дохрена кода! Во-первых, ревьюверы чувствуют себя виноватыми, и им тяжело сказать человеку, что надо все выбросить, и переделать. Во-вторых, человеку самому грустно и обидно это делать. Поэтому, такой код имеет все шансы пройти кодревью, и таки оказаться в репозитории. Если не проводить design review, подобная ситуация будет возникать регулярно.
4) Design review позволяют привить культуру предварительного проектирования в масштабе компании, и являются, кроме того, единственным способом как-то контроллировать закрытие задачи «проектирование».
И 5-е. Пожалуй, самое существенное. Введение design review имеет радикальный положительный эффект на сроки разработки и их предсказуемость в условиях наличия новых, неопытных сотрудников, в условиях присутствия значительной базы существующего кода. Проверено.
Подобные сотрудники тратят достаточно много времени на то, чтобы разобраться с существующим кодом, и найти правильный способ решения своих задач. Часто выясняется, что их подходы неверны, что приводит к затягиванию сроков из-за того, что они сами постоянно переделывают свою работу, или молча тупят, либо — к потоку дефектов в соседнем коде, индуцированным их действиями. Они повышают хрупкость кода и вносят баги со странными симптомами, которые потом ловятся опытными сотрудниками.
Введя обязательное design review, вы бьете подход к проблеме на два этапа, проскочить которые нельзя. 1 — «я понимаю, что и как я собираюсь сделать», и 2 — «я делаю». Делая это, вы выносите источник неопределенности в первый этап, который строго ограничиваете временными рамками, и сотрудник делает доклад о выбранном подходе к решению проблемы. Он должен описать изменения с точностью до класса. Его доклад слушают 1-2 опытных разработчика, и ищут ошибки. По показаниям — проводя ликбез в виде кратких лекций по архитектуре и принципам устройства системы, если это необходимо (правильное решение задачи проектирования является как бы практическим заданием к лекции — так автоматически само собой получается).
Ну, и еще это отличный способ, помогающий от отмазок ленивых сотрудников, ссылающихся на сложность своей темы и задач.
Данный способ показал себя как наиболее эффективное комплексное решение для адаптации новых сотрудников. Эффект от одного этого процесса в процентном отношении к прочим мерам настолько велик, что ими можно пренебречь, не тратя зря силы. И все равно будет хорошо.
Design Review vs Design by Committee
Мне в основном очень нравятся архитекторы в Microsoft. Некоторые более, чем другие, а некоторые — совершенно замечательные.
Одного из совершенно замечательных зовут Дэвид Блайс (David Blythe), и он архитект в Windows в области графики. Дядька раньше дизайнил OpenGL в SGI, писал по нему книжку, а сейчас вот работает в том числе над Direct3D. Дядька совершенно монструозный и замечательный. Я с ним говорил минут 20 и просветлился больше, чем за два предыдущих месяца. Читал его гуидлайны про API design и опять же радовался.
Отрывок на сегодня:
«DESIGN BY COMMITTEE. Avoid design by committee. There should be a single person with final say in the design… and this person should have good architectural experience and instincts.»
Я еще не умею писать так лаконично, поэтому придется в многабукф.
Вот мне очень нравится Design Review и я всем его советую. Это когда перед тем как кодать что-то, надо об этом рассказать команде или еще кому, у кого есть время и понимание происходящего. Тебе обязательно наговорят кучу фидбека, вспомнят 10 тонких мест, о которых ты не подумал и предложат альтернатив. И часто окажется, что первая идея дизайна не идеальна, а может и вторая. Или неплоха, но нужно додумывать.
Если их фичи на тебя завязаны, то еще и посмотрят и прикинут как вы будете интегрироваться. Так как Design Review взаимный, то и ты будешь знать о той стороне. Кроме того, и знания людей о проекте расширяются и начинают больше пересекаться, и код твой понимать проще, и Code Review становится гораздо более осмысленным занятием.
Хорошо бы после этого обсуждения еще и записать основные принятые решения и почему. Конечно, с какой вам лично хочется детальностью, от детального Design Spec до коротенькой странички «overview and key decisions».
Точно так же, количество формальности в этом всем может быть совершенно разного порядка. От регулярных митингов до «Мужики, давайте заобсудим мою новую херовину».
Все это крайне полезно и обязательно нужно делать. Коллективный разум заруливает и побеждает.
И у этого всего только один catch — коллективное обсуждение не должно означать коллективных решений. Коллективный разум очень хорошо думает, но очень плохо принимает решения. Всегда должен быть один человек, который имеет право выбрать из предложенных альтернатив и их за и против. Понимая всю картину, осознавая все возможности, сказать «а вот с этим мы будем жить», «мы выбираем вот такой трейдофф», в конце концов, сказать «а вот на это мы положим хер».
Иначе — превратится в коллективную безответственность и бесконечные споры. Я это прямо видел своими глазами, и не я один.
Design Review — это очень хорошая и правильная вещь. Принцип Avoid Design by Committee ее дополняет, а никак не перечеркивает. Отзывы нужно слушать, понимать, и если возникает альтернатива лучше твоей первой идеи, не бояться брать эту альтернативу. То есть — коллективный разум таки действительно рулит. Решение, которое ты примешь не рассказав и не посоветовавшись — будет хуже. Но тем не менее, принимать решение — только тебе самому.