Почему дизайн должен быть функциональным?

Нередко разработчик проектирует систему, ориентируясь на что угодно, но только не на удобство её дальнейшего использования. Часто он даже не задумывается, что проектируемая система должна выполнять определённые обязанности.

Чтобы подчеркнуть мысль о том, что дизайн системы должен быть прежде всего функциональным, приведу три примера. Они взяты из разных областей человеческой деятельности, в том числе, и из software design'а.

Пример 1. Панель управления лифтом

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

Чтобы устранить проблему, сообразительные жильцы наклеили рядом с кнопками бумажки с номерами этажей.

Термины и понты: как оценивать опыт специалиста?

Один мой коллега, перейдя на работу в другую компанию, как-то с сожалением констатировал, что чувствует себя в новой команде "полным нубом". Далее между нами произошёл такой диалог:

Я: Что заставляет тебя оценивать себя так скромно?

Коллега: Меня окружают очень опытные люди.

Я: Почему ты так решил?

Коллега: По их разговорам и используемым терминам. Многие из терминов я просто не знаю...

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

Предыдущие публикации и обсуждения смотрите здесь:

Первая публикация

Вторая публикация

Обсуждение

Зададимся вопросом: А как инженеры оценивают квалификацию других инженеров?

Кейс "Проектирование графического редактора"

Решил объединить свои посты, посвященные вопросам проектирования графического редактора, в отдельный кейс.

1. Общий взгляд на процесс проектирования.

Не смотря на то, что эта заметка описывает подход к собеседованию архитектора, она дает представление и о методике проектирования, изложенной далее.

2. Постановка задачи, декомпозиция задачи на части.

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

3. Проектирование модуля редактирования.

Серия постов, посвященная проектированию ядра графического редактора, отвечающего за создание и редактирования векторного рисунка:

3.1. Создание функциональной модели.

3.2. Проверка и расширение функциональной модели.

3.3. Проектирование классов.

3.4. Проектирование реализации.

4. Проектирование взаимодействия с пользователем.

Несколько заметок, посвященных вопросам проектирования пользовательского интерфейса и механизма взаимодействия с пользователем.

4.1. Рисование фигур.

4.2. Редактирование фигур.