Занимаясь разработкой ПО уже несколько лет, я последнее время стал часто задумываться о том, что влияет на качество разрабатываемого продукта. Внедрение новых практик (тех же составляющих XP/Agile/Scrum) очень быстро показало, что дело совсем не только в организации разработки — ведущими всегда оказываются личные качества разработчиков. Мы не будем сейчас погружаться с головой во все аспекты качества ПО, но рассмотрим только один из них: качество кода.
Типичной практикой является оценка продукта по его внешней составляющей, однако при создании Open Source решений, а также, банально, при модификации существующей бизнес-логики, для программиста именно исходный код является конечным продуктом, с которым ему приходится работать.
Задача этой статьи — не просто перечислить качества хорошего кода, этим занимаются слишком часто, и это было бы не столь интересно. Здесь я просто кратко перечислю найденное. Затем мы посмотрим на некоторые аналогии.
Первое, что называет большинство разработчиков (не знаю, почему :-), — это комментарии к коду (намёк: золотая середина — их не должно быть ни много, ни мало). Затем говорят о соблюдении стиля (coding style) и общей понятности, простоте кода. Я как пользователь продукта — Open Source решения — должен знать, где искать ту функциональность, которую мне надо изменить. Сюда же относится грамотное продумывание структуры объектов (компоновка). Все сейчас используют ООП, и его надо понимать и чувствовать. Совсем немногие называют декомпозицию — в основном, осознанные TDD-шники (Test Driven Development), так как это основа тестирования.
Теперь я хотел бы рассмотреть понятие качества с другой стороны — на примере графического дизайна. Как-то в институте я увидел спецкурс «веб-дизайн». Так как технический курс проходить всё равно было необходимо, я решил записаться — и начал туда ходить. Понятие «веб-дизайн» я знал мало, и немало удивился, когда понял, что нам совершенно не собираются рассказывать HTML. Вместо этого нам начали рассказывать про цвета (первое занятие), про перспективу (основа изображения), логотипы-фирменные-цвета-и-стили, про типографику. Далее пошла компоновка, рассуждения о необходимости/достаточности… Когда мне сказали, что нашим основным рабочим инструментом будет не IDE (среда для написания кода), а… Photoshop, я понял, что это на порядок интереснее, чем то, что я ожидал. Затем мы перелопатили кучу сайтов и рассмотрели их ошибки.
Нет, я не стал профессиональным дизайнером. Я редко рисую что-то в Фотошопе (разве что «для души»). Но всё это, а также десятки прочитанных и просмотренных статей по дизайну, основам рисования, по юзабилити интерфейсов позволили мне стать хорошим дизайнером… кода.
Давайте посмотрим подробнее: что обычно рассматривается как основа ремесла (или, если угодно, искусства) графического дизайна? Остановимся на веб-дизайне и UI.
Простота и прозрачность для пользователя. Удобство пассивных элементов, а также элементов управления (модное сейчас направление больших шрифтов и полей для ввода). Грамотная декомпозиция и компоновка: группировка связанных по функциональности или смыслу элементов в один блок; разумное, воспринимаемое пользователем число элементов в группе (почитайте статью от 37signals «An Introduction to Using Patterns in Web Design»). Дружественность: подсказки там, где это необходимо, но в то же время отсутствие перегруза информацией. Приемлемое глазу цветовое сочетание. Обязательно — аккуратность и продуманные мелочи (пиксель-к-пикселю, ничего не выезжает за отведённые поля, сохранение пропорций, типографика).
Этот список ни в коем случае не полон — но Вы уже видите, что мы перечислили то же самое, что и выше, когда говорили про дизайн кода?
Для комментариев к исходному коду аналогией в графическом дизайне являются различного рода подсказки, информационные тексты и т. п. Компоновка и декомпозиция нужны и там, и там. Стремление убрать повторяющиеся элементы в визуальном дизайне (колонка ссылок «удалить», «редактировать» — это плохо) вполне соответствует стремлению объединить повторяющийся код в какой-то метод или функцию. Аккуратность в дизайн-макете должна быть точно такая же, как и аккуратность кода («Ой, я забыл здесь учесть переполнение переменной…»). И так далее. Это только несколько примеров с поверхности, которые показывают нам наличие аналогии.
Совокупность основных дизайн-качеств кода я называю Code Usability. Ваш код будут использовать (читать, править, использовать повторно) другие люди. Как сделать так, чтобы с ним было приятно работать? А Вы вообще видели такой код? Я — да. Но крайне редко.
Знание принципов дизайна применимо не только к написанию кода. Ни для кого не секрет, что как ни старайся, программистам нет-нет — но всё же приходится видеть и править вёрстку (я знаю, это ужасно). Иногда случается и так, что программисты проектируют интерфейсы. Не то чтобы это заранее планируется — просто разработка зачастую бывает организована так, что сначала пишется движок, а потом уже ничего не изменишь, будь ты хоть самым гениальным дизайнером. Примером такого чуда могут явиться админки Друпала, Джумлы (при всём моём уважении к этим системам). На панели управления блогом LiveInternet только что не написали «сделано программистами».
Не стоит ограничивать дизайн только визуальным дизайном и дизайном кода. Анализ пром-дизайна (по мере того, насколько я в этом разбираюсь), дизайна статей (причём с нескольких сторон: дизайн самого текста; вёрстки; отдельно — дизайн заголовка) и др. показал, что одни и те же составляющие дизайна присутствуют во всех этих областях. Было выделено три группы дизайн-свойств (конечно, достаточно сильно пересекающихся): функциональные требования, удобство использования (юзабилити) и рекламные свойства (способствующие продаваемости). В каждом из этих блоков было выделено по 2-7 основных качества. Здесь я не буду приводить классификацию, — это отдельная статья с отдельным анализом и выводами, — да и не в этом была задача.
Какие же выводы можно сделать из проведённых аналогий — сквозного видения дизайна? Я вижу важность этого в двух аспектах.
Первое — дорогие коллеги, разработчики! Не будьте однобоки! Развивайте не только одно полушарие мозга. Пытайтесь рисовать, компоновать, чувствовать гармонию. Думайте о красоте. Ну, хорошо, я опускаю «играйте на музыкальных инструментах», «пишите не только программы, но и поэмы» — это меня немного занесло. Но — помните, никто ещё не проигрывал от более гармоничного развития.
Если говорить чуть более практично, а не просто бросаться непонятными кому-то лозунгами, есть идея проведения юзабилити-семинаров для разработчиков. Очень интересно, была ли где-то уже такая практика в России, и не только. Если знаете, пожалуйста, обязательно напишите мне.
Вторые выводы более научны. Проведение дизайн-аналогий между различными областями/направлениями позволит нам увидеть интересные закономерности и по-другому взглянуть на привычные паттерны. Несколько примеров было выше. Ещё одно интересное исследование посвящено сравнению принципов проектирования кода, основанного на ООП, и принципов проектирования визуальных интерфейсов. (Ничто не ново под луной — Ларри Константин, помнится, уже в 1993 году писал о недостатках объектных интерфейсов. Мы же сможем увидеть не только недостатки объектного кода, но из аналогий вывести способы решения проблемы.) Чуть позже попробую опубликовать.
Я понимаю, что многое в этой статье осталось за кадром. Возможно, какие-то мысли я не смог внятно передать. Действительно, много написанных примеров пришлось оставить за пределами статьи. Но — невозможно уместить всё, поэтому пока что, наверное, этого хватит. А я попробую попозже ещё что-то добавить.
Типичной практикой является оценка продукта по его внешней составляющей, однако при создании Open Source решений, а также, банально, при модификации существующей бизнес-логики, для программиста именно исходный код является конечным продуктом, с которым ему приходится работать.
Задача этой статьи — не просто перечислить качества хорошего кода, этим занимаются слишком часто, и это было бы не столь интересно. Здесь я просто кратко перечислю найденное. Затем мы посмотрим на некоторые аналогии.
Первое, что называет большинство разработчиков (не знаю, почему :-), — это комментарии к коду (намёк: золотая середина — их не должно быть ни много, ни мало). Затем говорят о соблюдении стиля (coding style) и общей понятности, простоте кода. Я как пользователь продукта — Open Source решения — должен знать, где искать ту функциональность, которую мне надо изменить. Сюда же относится грамотное продумывание структуры объектов (компоновка). Все сейчас используют ООП, и его надо понимать и чувствовать. Совсем немногие называют декомпозицию — в основном, осознанные TDD-шники (Test Driven Development), так как это основа тестирования.
Теперь я хотел бы рассмотреть понятие качества с другой стороны — на примере графического дизайна. Как-то в институте я увидел спецкурс «веб-дизайн». Так как технический курс проходить всё равно было необходимо, я решил записаться — и начал туда ходить. Понятие «веб-дизайн» я знал мало, и немало удивился, когда понял, что нам совершенно не собираются рассказывать HTML. Вместо этого нам начали рассказывать про цвета (первое занятие), про перспективу (основа изображения), логотипы-фирменные-цвета-и-стили, про типографику. Далее пошла компоновка, рассуждения о необходимости/достаточности… Когда мне сказали, что нашим основным рабочим инструментом будет не IDE (среда для написания кода), а… Photoshop, я понял, что это на порядок интереснее, чем то, что я ожидал. Затем мы перелопатили кучу сайтов и рассмотрели их ошибки.
Нет, я не стал профессиональным дизайнером. Я редко рисую что-то в Фотошопе (разве что «для души»). Но всё это, а также десятки прочитанных и просмотренных статей по дизайну, основам рисования, по юзабилити интерфейсов позволили мне стать хорошим дизайнером… кода.
Давайте посмотрим подробнее: что обычно рассматривается как основа ремесла (или, если угодно, искусства) графического дизайна? Остановимся на веб-дизайне и UI.
Простота и прозрачность для пользователя. Удобство пассивных элементов, а также элементов управления (модное сейчас направление больших шрифтов и полей для ввода). Грамотная декомпозиция и компоновка: группировка связанных по функциональности или смыслу элементов в один блок; разумное, воспринимаемое пользователем число элементов в группе (почитайте статью от 37signals «An Introduction to Using Patterns in Web Design»). Дружественность: подсказки там, где это необходимо, но в то же время отсутствие перегруза информацией. Приемлемое глазу цветовое сочетание. Обязательно — аккуратность и продуманные мелочи (пиксель-к-пикселю, ничего не выезжает за отведённые поля, сохранение пропорций, типографика).
Этот список ни в коем случае не полон — но Вы уже видите, что мы перечислили то же самое, что и выше, когда говорили про дизайн кода?
Для комментариев к исходному коду аналогией в графическом дизайне являются различного рода подсказки, информационные тексты и т. п. Компоновка и декомпозиция нужны и там, и там. Стремление убрать повторяющиеся элементы в визуальном дизайне (колонка ссылок «удалить», «редактировать» — это плохо) вполне соответствует стремлению объединить повторяющийся код в какой-то метод или функцию. Аккуратность в дизайн-макете должна быть точно такая же, как и аккуратность кода («Ой, я забыл здесь учесть переполнение переменной…»). И так далее. Это только несколько примеров с поверхности, которые показывают нам наличие аналогии.
Совокупность основных дизайн-качеств кода я называю Code Usability. Ваш код будут использовать (читать, править, использовать повторно) другие люди. Как сделать так, чтобы с ним было приятно работать? А Вы вообще видели такой код? Я — да. Но крайне редко.
Знание принципов дизайна применимо не только к написанию кода. Ни для кого не секрет, что как ни старайся, программистам нет-нет — но всё же приходится видеть и править вёрстку (я знаю, это ужасно). Иногда случается и так, что программисты проектируют интерфейсы. Не то чтобы это заранее планируется — просто разработка зачастую бывает организована так, что сначала пишется движок, а потом уже ничего не изменишь, будь ты хоть самым гениальным дизайнером. Примером такого чуда могут явиться админки Друпала, Джумлы (при всём моём уважении к этим системам). На панели управления блогом LiveInternet только что не написали «сделано программистами».
Не стоит ограничивать дизайн только визуальным дизайном и дизайном кода. Анализ пром-дизайна (по мере того, насколько я в этом разбираюсь), дизайна статей (причём с нескольких сторон: дизайн самого текста; вёрстки; отдельно — дизайн заголовка) и др. показал, что одни и те же составляющие дизайна присутствуют во всех этих областях. Было выделено три группы дизайн-свойств (конечно, достаточно сильно пересекающихся): функциональные требования, удобство использования (юзабилити) и рекламные свойства (способствующие продаваемости). В каждом из этих блоков было выделено по 2-7 основных качества. Здесь я не буду приводить классификацию, — это отдельная статья с отдельным анализом и выводами, — да и не в этом была задача.
Какие же выводы можно сделать из проведённых аналогий — сквозного видения дизайна? Я вижу важность этого в двух аспектах.
Первое — дорогие коллеги, разработчики! Не будьте однобоки! Развивайте не только одно полушарие мозга. Пытайтесь рисовать, компоновать, чувствовать гармонию. Думайте о красоте. Ну, хорошо, я опускаю «играйте на музыкальных инструментах», «пишите не только программы, но и поэмы» — это меня немного занесло. Но — помните, никто ещё не проигрывал от более гармоничного развития.
Если говорить чуть более практично, а не просто бросаться непонятными кому-то лозунгами, есть идея проведения юзабилити-семинаров для разработчиков. Очень интересно, была ли где-то уже такая практика в России, и не только. Если знаете, пожалуйста, обязательно напишите мне.
Вторые выводы более научны. Проведение дизайн-аналогий между различными областями/направлениями позволит нам увидеть интересные закономерности и по-другому взглянуть на привычные паттерны. Несколько примеров было выше. Ещё одно интересное исследование посвящено сравнению принципов проектирования кода, основанного на ООП, и принципов проектирования визуальных интерфейсов. (Ничто не ново под луной — Ларри Константин, помнится, уже в 1993 году писал о недостатках объектных интерфейсов. Мы же сможем увидеть не только недостатки объектного кода, но из аналогий вывести способы решения проблемы.) Чуть позже попробую опубликовать.
Я понимаю, что многое в этой статье осталось за кадром. Возможно, какие-то мысли я не смог внятно передать. Действительно, много написанных примеров пришлось оставить за пределами статьи. Но — невозможно уместить всё, поэтому пока что, наверное, этого хватит. А я попробую попозже ещё что-то добавить.
