Архитектура ОС Singularity (отзыв на статью)

Прочитал отчет Microsoft Research «Проект Singularity: обзор». Появился ряд мыслей, которыми хочется поделиться.

А. Singularity – это тестовая операционная система, разработанная исследовательской группой Microsoft. При работе над проектом была поставлена такая задача:

Пример проектирования: шифрующая папка на "рабочем столе"

Приведу пример на «цепочку действий» из моей практики. Думаю, он будет интересен.

Ситуация: Для одного из заказчиков была написана программа – аналог PGP. Она позволяла шифровать и дешифровать файлы, создавать и удалять ключи. Отсутствовала только одна необходимая «фича»: Заказчик хотел иметь на «рабочем столе» папку, в которую он бы мог при помощи мыши перемещать файлы и другие папки. Перемещенные элементы должны были автоматически шифроваться.

Для реализации шифрующей папки к проекту подключили меня.

Идеальный программист

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

Разработка технологической платформы для игр в условиях временного прессинга

Что такое "технологическая платформа"? Многие, знакомые с областью разработки игр, скажут, что это - графический движок. Предполагается, что если есть инструмент для работы с 3D-объектами, текстурами, камерами, 2D-графикой, то написание игры - дело несложное.

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

При разработке одной игры для девочек для консоли Nintendo Wii автор вместе с коллегами разработал довольно простую технологическую платформу. Используя её, обученный программист мог создавать черновой вариант мини-игры за 3 дня. Потом ещё 2 дня уходили на доделку HUD'а и вставку звука. Итого, создание мини-игры занимало 5 человеко-дней.

Полученным в результате данного проекта опытом я поделился на КРИ 2010. Послушать выступление и посмотреть презентацию можно здесь.

Отзыв на книгу "Шаблоны интеграции корпоративных приложений"

Прочитал книгу:

Хоп, Грегор, Вульф, Бобби. Шаблоны интеграции корпоративных приложений. : Пер. с англ. – М.: ООО «И.Д. Вильямс», 2007. – 672 с.: ил.

Книга вышла в серии “A Martin Fowler Signature Book” и посвящена шаблонам интеграции корпоративных приложений.

В настоящее время для интеграции корпоративных приложений используются 4 техники:

1)      Передача файла (File Transfer).

2)      Общая база данных (Shared Database).

3)      Удаленный вызов процедуры (Remote Procedure Invocation).

4)      Обмен сообщениями (Messaging).

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

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

Почему надо проектировать "от обязанностей", или сколько функций выполняет чашка?

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

"У каждой кружки есть своё предназначение. Есть кофейные чашки, есть чашки из чайного сервиза, есть чашки для чайной церемонии, есть походные кружки, кружки офисные, подарочные и т.д. В зависимости от назначения они приобретают нужную форму и размеры, а также - подбирается материал для их изготовления. Если в игру был добавлен объект "смертельно ядовитая трава", то он был добавлен не просто так, а потому что, например, уровень для прохождения без этого объекта - слишком лёгкий. Таким образом, его задача - "усложнить прохождение уровня".

Один из коллег в личной переписке на это возразил:

1. Если задумываться о назначении чашки, то будет сложно налить в чайную чашку кофе, а в кофеную – чай.
2. Гораздо проще снабдить обычную чашку двумя интерфейсами – "налить кофе" и "налить чай".

В качестве возражения на это замечание коллеги мне бы хотелось сказать вот что...

О том, как путают функциональный подход к проектированию с процедурным программированием

Обсуждая с коллегами подходы к проектированию программ, нередко натыкаешься на скепсис по отношению к функциональному подходу. Не смотря на то, что возможности подхода продемонстрированы на конкретных примерах:

Пример 1. Проектирование графического редактора

Пример 2. Проектирование программы для метеостанции

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

Какие же недостатки приписывают функциональному подходу?

Отзыв на книгу Фаулера "Архитектура корпоративных приложений"

Просмотрел сильно разрекламированную книжку Мартина Фаулера «Архитектура корпоративных приложений» (точная ссылка: Фаулер, Мартин. Архитектура корпоративных приложений.: Пер. с англ. – М.: Издательский дом «Вильямс», 2006. – 544 с.: ил.). Книжка описывает архитектурные паттерны, которые можно использовать при разработке корпоративных (как правило, web-based) приложений. Поскольку такие приложения практически не обходятся без использования базы данных, очень много места в книжке уделяется объектно-реляционному отображению.

А. Общие впечатления.

Основные впечатления от книжки:

1)       Книга не содержит описания архитектур, хотя в названии используется слово «архитектура». Книга содержит отдельные частные решения, которые можно использовать при проектировании – и только-то!

2)       Книга не содержит перечня архитектурных задач (хотя бы неполного). Отсутствует какая-либо модель постановки задач при разработке архитектуры. Что такое творческая задача в архитектуре? Автор об этом умалчивает.

3)       Поскольку описание задач отсутствует, нет критерия для отбора паттернов. Паттерны включены в книгу в произвольном порядке. Приведенные решения не разделены на качественные уровни. В результате «слабые» паттерны соседствуют вместе с «сильными».

4)       Многие паттерны образованы по схеме: «преобразование + объект, к которому оно применяется». В результате паттерны дублируются. Хоть преобразования, лежащие в их основе, одинаковые, но вот объекты разные.

Вывод:

Как специалисты по эргономике формулируют задачу по оценке качества интерфейса?

Цитата:

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

Проектирование игр: функциональный подход

Сегодня выкладываю свою презентацию с КРИ 2008. Она освещает вопросы проектирования видео игр, разумеется, не с гейм-дизайнерской, а с технической точки зрения. В презентации изложены ответы на такие вопросы:

1. К каким проблемам приводят слишком большие иерархии классов?
2. Чем можно заменить такие иерархии?
3. Что брать в качестве основы декомпозиции на подсистемы - функции или объекты?
4. Как проектировать AI-водителя для гоночной игры? (Описание примера.)
5. Чем "грешит" паттерн "Цепочка обязанностей"?

В чём различие между объектно-ориентированным и системным подходами? Часть 1

Объектно-ориентированный подход – это подход к разработке программ. Он был изобретён Кристеном Нюгордом и Оле-Йоханом Далем при разработке языка Симула-67. Впоследствии многие его концепции были развиты Аланом Кеем и Дэном Ингалссом при работе над языком Smalltalk.

Объектно-ориентированный подход предполагает, что любую программу можно представить в виде набора взаимодействующих объектов. Сначала предполагалось, что объекты будут взаимодействовать посредством обмена сообщениями. Однако в большинстве существующих языков программирования объекты взаимодействуют при помощи вызова функций.

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

Объектно-ориентированный подход считают развитием структурного подхода к программированию. Основное отличие заключается в том, что объектно-ориентированный подход позволяет объединить данные и методы, обрабатывающие эти данные, в единой сущности – объекте.

Системный подход – это подход к:

Usability GPS-навигатора

30 июня 2008 года на форуме RSDN.RU автором была размещена такая задача...

ЗАДАЧА

Уважаемые Коллеги!

Хотелось бы знать, как можно решить подобную задачу (см. описание ниже). Свои решения имеются. Но хочется, чтобы посмотрели на задачу люди со стороны. Чтобы не навязывать свои решения, я опишу их чуть позже.

Задача: Навигационная система для КПК (с поддержкой GPS и GSM) должна включать модуль "поиск друзей". Функциональность этого модуля достаточно проста: любой пользователь системы может послать своему другу запрос (через СМС) о его местоположении. Получив такой запрос, пользователь может либо подтвердить его (т.е. навигационная система отсылает другу текущие координаты), либо отклонить (запрос остаётся без ответа).

Обязательное условие: Отсылка координат по запросу всегда должна утверждаться пользователем. Т.е. система сама без ведома пользователя не должна никому отсылать его координаты.

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

Другое обязательное условие: Ничто не должно отвлекать внимание пользователя, пока он управляет автомобилем.

Что такое "идеальный код"?

Из обсуждения на форуме RSDN.RU (привожу свои доводы):

Судя по приведенному примеру, Вы предполагаете, что программный код – это набор символов. Но это неправильно! Это все равно, что предполагать, будто дом – набор кирпичей или строительных блоков.

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

0. Символы.

1. Слова (операторы, переменные, константы, типы данных).

2. Функции и функциональные блоки.

3. Типы данных, определяемые пользователем.

4. Иерархии, группы связанных классов.

5. Библиотеки.

6. И т.д. – наверняка что-то пропустил.

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

Блог Software Design проводит опрос своих посетителей

Задача про датчики: проектирование классов. Часть 2

Продолжение серии статей, посвящённой проектированию системы для метеостанции. Предыдущие статьи смотрите здесь:

С чего начать проектирование программы? Часть 1.

С чего начать проектирование программы? Часть 2.

Задача про датчики: построение функциональной архитектуры.

Задача про датчики: проектирование классов. Часть 1.

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

В предыдущей статье я предложил условно разделять классы на 2 категории:

1. классы-сервисы:
2. классы-данные.

Классы-сервисы предназначены для выполнения каких-то особых, специфичных задач. Синонимами понятия класс-сервис являются функциональный модуль или функциональная подсистема.

Классы-данные предназначены для временного или постоянного хранения групп данных, а также – для передачи этих данных от сервиса к сервису. Можно сказать, что классы-сервисы – это обработчики, а классы-данные – это коммуникации между этими обработчиками. У "железячников" есть хороший термин – шина данных. Так вот, проектирование классов-данных сродни прокладке шины данных, соединяющей одни функциональный подсистемы с другими.

Чтобы спроектировать классы-данные, нужно провести анализ потоков данных. Нужно понять, как отдельные функции, выполняемые в рамках процесса, связаны друг с другом по данным. Одним из наглядных инструментов для такого анализа является N-square диаграмма.

Задача про датчики: проектирование классов. Часть 1

Бертран Мейер, один из идеологов объектно-ориентированного подхода, в своей книге "Объектно-ориентированное конструирование программных систем" пишет:

"В формальных и неформальных обсуждениях архитектуры проекта часто задаётся вопрос о роли некоторого класса. И часто можно слышать ответ: "Этот класс печатает результаты" или "Класс разбирает вход" – варианты общего ответа "Этот класс делает...".

Такой ответ обычно указывает на изъяны в проекте. Класс не должен делать одну вещь, он должен предлагать несколько служб в виде компонентов над объектами некоторого типа. Если же он выполняет одну работу, то, скорее всего, имеет место "Большое Заблуждение".

Вполне вероятно, что ошибка не в самом классе, а в способе его описания – использовании операционной фразеологии. Но всё-таки в этой ситуации лучше провести проверку класса".

Мейер, Бертран. Объектно-ориентированное конструирование программных систем / Пер. с англ. – М.: Издательско-торговый дом «Русская редакция», 2005. – стр. 717.

Если подытожить, то Мейер делает два утверждения:

1. Класс должен отвечать за выполнение нескольких функций.
2. О классе не нужно думать, как о чём-то, выполняющем какие-то обязанности.

Если с первым утверждением можно согласиться, а можно и поспорить, то второе – на мой взгляд, просто неверно. Если о классе нельзя ничего сказать в терминах обязанностей, или если он ничего не делает, то зачем он вообще нужен?

[OFF:] "Ваше представление о гениальности и талантливости?"

Отчёт об исследовании TREKO.RU, о котором я писал чуть раньше, опубликован. Его можно посмотреть здесь. 

Задача про датчики: построение функциональной архитектуры

Один из идеологов объектно-ориентированного подхода и один из авторов языка моделирования UML Джеймс Рамбо пишет:

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

Дж. Рамбо, М. Блаха. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд. – СПб.: Питер, 2007, стр. 42.

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

С чего начать проектирование программы? Часть 2

Прежде чем следовать дальше, повторим основные тезисы предыдущей статьи:

1. Любая программа разрабатывается для решения конкретных задач. Эти задачи будем называть полезными функциями или просто функциями.
2. Прежде чем проектировать архитектуру программы, нужно сначала разработать алгоритм выполнения каждой полезной функции. Такой алгоритм в машиностроении называется технологией или технологическим процессом.
3. Технологический процесс представляет собой последовательность операций, которая может быть описана либо в текстовом виде в форме варианта использования, либо в форме блок-схемы, flowchart'а.
4. Порядок проектирования можно описать в виде такой схемы:

Функция --> Технологический процесс --> Архитектура

Сначала нужно сформулировать полезные функции, которые будет выполнять проектируемая программа. Затем – описать технологический процесс для каждой из них. И только после этого можно проектировать архитектуру.

[OFF:] Что вы думаете о таланте?

Мой знакомый попросил меня разместить это сообщение.


Исследование портала TREKO.RU: "Ваше мнение о гениальности и талантливости?"

Запланировано открытие нового портала, посвящённого технологиям творчества и

решению сложных (!) задач.

Одно из направлений нового проекта - изучение талантов и гениев. Поэтому и
проводится исследование: "Ваше мнение о гениальности и талантливости?"

Желающие могут ответить на любое количество вопросов из 10 задать свои
собственные. На ряд заданных Вами вопросов разработчики постараются ответить уже в сентябре 2011 г. Чем сложнее будут Ваши вопросы - тем лучше, именно для этого портал и создаётся.

Для ответов на Ваши вопросы будет использоваться база данных по выдающимся
личностям и творческим коллективам трудолюбиво собираемая разработчиками нового портала с 70-х годов XX века и уже содержащая около 24 000 записей...

Вопросы самого исследования:
http://www.treko.ru/creative_vote

С чего начать проектирование программы? Часть 1

С чего начать проектирование программы? Классический объектно-ориентированный подход даёт нам однозначный ответ на этот вопрос: с выявления ключевых абстракций и построения объектной модели предметной области.

Джеймс Рамбо, один из создателей языка UML и Rational Unified Process'а, в своей книге "UML 2.0. Объектно-ориентированное моделирование и разработка" предлагает нам такой алгоритм проектирования:

1. Изучить предметную область и выделить классы предметной области.
2. Удалить лишние классы (несущественные или избыточные).
3. Связать классы ассоциациями.
4. Выделить в классах атрибуты.
5. Реструктуризовать классы при помощи наследования.
6. Добавить классы приложения.
7. Добавить операции.

Дж. Рамбо, М. Блаха. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд. – СПб.: Питер, 2007, стр. 218 – 285.

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

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

Проблема эллипса и окружности

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

Одной из проблем, которая порождает подобные дискуссии, является проблема эллипса и окружности. Её можно сформулировать так:

Как с точки зрения объектно-ориентированного подхода правильно объединить в единую иерархию два класса - класс Эллипс и класс Окружность:

Унаследовав Эллипс от Окружности?
Или унаследовав Окружность от Эллипса?

Продуктовая компания: Постановка процесса разработки

В эти выходные в Питере прошла конференция для разработчиков CodeCamp 2011. Выступил на ней с докладом, в котором рассказал об основных этапах работы над продуктом (бизнес-приложением, видеоигрой). Фактически был изложен пошаговый алгоритм создания продукта, который включает в себя: маркетинг, дизайн и инженерное проектирование.

Выступление было составлено на базе моего 15-летнего опыта работы в ИТ-индустрии. Для тех, кому оно будет интересно, выложил презентацию:

Code Camp 2011 - Продуктовая копания: Постановка процесса разработки

View more presentations from Kirill Lebedev

УПРАВЛЕНИЕ.РУ и MANAGEMENT.COM

В чём различие западного и отечественного подходов к управлению программными проектами?

Критерий	Управление.ру	Management.com
Задачи	Глобальные, иногда -  грандиозные задачи, выполнение которых подчас требует слаженной работы нескольких специалистов в разных областях знаний. Время выполнения задачи измеряется неделями или даже месяцами. ПРИМЕР. В одной из компаний, занимающийся разработкой GPS-навигационных систем,  менеджер любил давать своим подчинённым глобальные задачи: 1)     разработать модуль роутинга; 2)     разработать модуль поиска координат по адресу; 3)     разработать красивый UI; 4)     и т.д.	Конкретные задачи, измеряемые часами или, в крайнем случае, днями. Любая глобальная и комплексная задача разбивается на серию конкретных подзадач с чёткой формулировкой. Устанавливается порядок их выполнения. ПРИМЕР. Комплексная задача "разработать модуль роутинга" разбивается на серию небольших подзадач: 1)     составить перечень алгоритмов поиска маршрутов и выбрать наиболее подходящий из них; 2)     ознакомиться с документацией по картам и составить список атрибутов, необходимых для корректной работы алгоритма; 3)     расписать интерфейс доступа к картографическим данным; 4)     спроектировать и реализовать структуру для хранения информации о дорожном элементе; 5)     спроектировать и реализовать структуру для хранения всех рассмотренных дорожных элементов; 6)     и т.д.

Проклятие аутсорсинга

Разработка и вывод программного продукта на рынок сильно отличается от программирования на заказ.

Технологии работы аутсорсинговой и продуктовой компаний очень различны.

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

Такая ситуация, на первый взгляд, выглядит странно, потому что в аутсорсинговой компании работают вроде бы опытные люди, грамотные технари.

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

Как правило, в разработке продукта задействованы люди, являющиеся экспертами в разных областях знаний, разных специальностей, разных складов ума (гуманитарии и технари).

Успешная технология разработки продукта организует работу всех этих людей, как единой системы.

Каждый специалист занимается своим делом. Технология предоставляет чёткие критерии качества работы для каждого специалиста.

Попробую привести некоторые типовые ошибки, которые совершает команда, взявшись разрабатывать собственный продукт:

Пластический интерфейс

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

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

А недавно мне попалась на глаза игра для iPad'а, в которой данный подход фактически реализован. Игра называется "Let's create! Pottery", она рассчитана на казуальную (преимущественно, женскую) аудиторию, и её смысл заключается в лепке горшков.

Более полробно смотрите здесь.

Как делать эстимейты? Часть 2

В этой заметке мне хотелось бы снова поднять тему эстимейтов.

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

Данный подход можно использовать двояко:

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

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

Первый случай я условно называю оценкой в "системе координат" пользователя, а второй – оценкой в "системе координат" разработчика.

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

Как делать эстимейты?

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

В этой заметке я расскажу о нескольких подходах к созданию эстимейтов. Надеюсь, изложенная информация будет полезной.

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

Функциональная декомпозиция подходит как для грубой оценки проектов, так и для оценки отдельных задач в рамках конкретного проекта.

В общем случае, хочется дать такие рекомендации:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обсуждение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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