Занимаясь разработкой программного обеспечения уже несколько лет, я в последнее время стал часто задумываться о том, что влияет на качество разрабатываемого продукта.
Внедрение новых практик (те же компоненты XP/Agile/Scrum) очень быстро показало, что дело не только в организации разработки — личные качества разработчиков всегда лидируют. Мы не будем сейчас погружаться во все аспекты качества программного обеспечения, а рассмотрим только один из них: качество кода.
Типичной практикой является оценка продукта по его внешнему компоненту, однако при создании решений с открытым исходным кодом, а также, попросту говоря, при модификации существующей бизнес-логики, для программиста именно исходный код является конечным продуктом, с которым он имеет дело.
работать.
Цель этой статьи — не просто перечислить качества хорошего кода; это делается слишком часто, и это было бы не так интересно.
Здесь я лишь кратко перечислю то, что мне удалось найти.
Затем мы рассмотрим некоторые аналогии.
Первое, что называют большинство разработчиков (не знаю почему :-) — это комментарии к коду (подсказка: золотая середина — их не должно быть ни больше, ни меньше).
Потом говорят о соблюдении стиля кодирования и общей понятности, простоте кода.
Как пользователю продукта — решения с открытым исходным кодом — мне нужно знать, где искать функционал, который мне нужно изменить.
Сюда же относится и грамотное продумывание структуры объектов (планировки).
ООП сейчас используют все, и это нужно понимать и чувствовать.
Декомпозицию мало кто называет — в основном это сознательные люди TDD (Test Driven Development), поскольку это основа тестирования.
Теперь мне хотелось бы взглянуть на понятие качества под другим углом – на примере графического дизайна.
Однажды в институте я увидел спецкурс по «веб-дизайну».
Поскольку нужно было еще пройти технический курс, я решил записаться и начал туда ходить.
Я мало что знал о понятии «веб-дизайн» и был весьма удивлён, когда понял, что HTML нам рассказывать вообще не собираются.
Вместо этого нам начали рассказывать о цветах (первый урок), о перспективе (основа изображения), о логотипах-брендовых цветах и стилях, о типографике.
Дальше шла верстка, рассуждения о необходимости/достаточности.
Когда мне сказали, что нашим основным рабочим инструментом будет не IDE (среда для написания кода), а.
Photoshop, я понял, что это на порядок больше интересно, чем я ожидал.
Потом мы просмотрели кучу сайтов и посмотрели на их ошибки.
Нет, я не стал профессиональным дизайнером.
Я редко что-либо рисую в фотошопе (кроме «для интереса»).
Но все это, а также десятки прочитанных и просмотренных статей по дизайну, основам рисования и удобству интерфейса позволили мне стать хорошим дизайнером.
кода.
Давайте посмотрим поближе: что обычно считается основой ремесла (или искусства, если хотите) графического дизайна? Давайте сосредоточимся на веб-дизайне и пользовательском интерфейсе.
Простота и прозрачность для пользователя.
Удобство пассивных элементов, а также элементов управления (сейчас в моде крупные шрифты и поля ввода).
Грамотная декомпозиция и верстка: группировка связанных по функционалу или смыслу элементов в один блок; разумное, воспринимаемое пользователем количество элементов в группе (читайте статью от 37signals" Введение в использование шаблонов в веб-дизайне Дружелюбность: подсказки там, где это необходимо, но при этом никакой информационной перегрузки.
Приятное глазу цветовое сочетание.
Необходимо - точность и продуманность деталей (пиксель в пиксель, ничего не выходит за пределы обозначенных полей, соблюдение пропорций).
, типография).
Этот список ни в коем случае не является полным — но видите ли вы, что мы перечислили то же самое, что и выше, когда говорили о дизайне кода? Для комментариев к исходному коду аналогией в графическом дизайне являются различного рода всплывающие подсказки, информационные тексты и т. д. В обоих случаях необходима верстка и декомпозиция.
Желание удалить повторяющиеся элементы в визуальном дизайне (колонка ссылок «удалить», «редактировать» — это плохо) вполне соответствует желанию объединить повторяющийся код в какой-то метод или функцию.
Точность в макете дизайна должна быть точно такой же, как точность в коде («Ой, я забыл здесь учесть переполнение переменных…»).
И так далее.
Это всего лишь несколько поверхностных примеров, которые показывают нам существование аналогии.
Я называю набор основных дизайнерских качеств кода Code Usability. Ваш код будет использоваться (читаться, редактироваться, повторно использоваться) другими людьми.
Как это сделать с ним Хороший работа? Вы когда-нибудь видели такой код? Я делаю.
Но крайне редко.
Знание принципов проектирования применимо не только к написанию кода.
Не секрет, что как ни старайся, программисты нет-нет - а видеть и редактировать макет им всё равно приходится (знаю, это ужасно).
Иногда бывает, что программисты проектируют интерфейсы.
Не то чтобы это планировалось заранее — просто разработка зачастую организована так, что сначала пишется движок, а потом уже ничего нельзя изменить, даже если ты самый гениальный дизайнер.
Примером такого чуда могут быть админы Drupal и Joomla (при всём уважении к этим системам).
В панели управления блогом LiveInternet просто не было надписи «сделано программистами».
Не ограничивайте дизайн только визуальным дизайном и дизайном кода.
Анализ промышленного дизайна (насколько я это понимаю), дизайна статьи (причём с нескольких сторон: оформление самого текста; верстки; отдельно — оформление шапки) и т.д. показал, что во всех этих областях присутствуют одни и те же компоненты дизайна.
.
Были выделены три группы конструктивных свойств (конечно, достаточно сильно пересекающихся): функциональные требования , Простота использования (удобство использования) и рекламные свойства (стимулирование продаж).
В каждом из этих блоков было выявлено от 2 до 7 основных качеств.
Я не буду здесь давать классификацию - это отдельная статья с отдельным анализом и выводами - да и не в этом была задача.
Какие выводы можно сделать из этих аналогий — сквозного видения дизайна? Я вижу важность этого в двух отношениях.
Во-первых – уважаемые коллеги-разработчики! Не будьте односторонними! Развивайте больше, чем одно полушарие мозга.
Попробуйте нарисовать, расположить, почувствовать гармонию.
Думайте о красоте.
Ну да ладно, оставляю «играть на музыкальных инструментах», «писать не только программы, но и стихи» — это меня немного увлекло.
Но помните: от более гармоничного развития еще никто не проиграл.
Если говорить чуть более практично, а не просто разбрасываться непонятными некоторым лозунгами, есть идея проводить семинары по юзабилити для разработчиков.
Очень интересно, существовала ли уже такая практика где-нибудь в России, и не только.
Если знаете, обязательно напишите мне.
Второй вывод более научный.
Проведение аналогий дизайна между разными областями/направлениями позволит нам увидеть интересные закономерности и по-другому взглянуть на знакомые закономерности.
Выше было несколько примеров.
Еще одно интересное исследование сравнивает принципы проектирования кода на основе ООП и принципы проектирования визуальных интерфейсов.
(Нет ничего нового под солнцем — Ларри Константин, помнится, уже в 1993 году писал о недостатках объектных интерфейсов.
Мы сможем увидеть не только недостатки объектного кода, но и из аналогий вывести пути решения проблемы.
проблема.
) Постараюсь опубликовать чуть позже.
Я понимаю, что многое в этой статье осталось за кадром.
Возможно, я не смог четко передать некоторые мысли.
Действительно, многие письменные примеры пришлось оставить за пределами статьи.
Но все уместить невозможно, так что пока этого, наверное, будет достаточно.
Позже попробую добавить что-нибудь еще.
Теги: #юзабилити кода #дизайн #дизайн кода #качество от #Chulan
-
Состав Компонентов В React Js
19 Oct, 24 -
Три Задачи
19 Oct, 24 -
Полный Текст Rss
19 Oct, 24 -
Картинки О Компьютерном Мире
19 Oct, 24 -
Иди Туда - Я Не Знаю Куда
19 Oct, 24
