Task-Domain Navigation
24.06.2008
Я весьма ревностно отношусь к организации своего основного рабочего пространства – экрана персонального компьютера (я обожаю новую рекламу ноутбуков HP за их слоган “Компьютер стал вновь персональным”). Первые свои мысли и наработки я сформулировал в небольшом цикле статей, которые с некоторыми корректировками вскоре будут перенесены в этот блог. Stay tuned. Но сейчас я продолжу своеобразную “летопись” создания своего первого web-проекта.
Как я уже говорил, был сделан выбор в пользу платформы Ruby On Rails. И, разумеется, далее стояла задача выбора подходящей среды разработки. Но не о конкретном сделанном выборе я хочу в первую очередь поговорить (о нём – лишь вскользь и в самом конце), а вот о чём…
При работе над программным кодом разработчик бесчисленное число раз вынужден метаться от одной части кода к другой, расположенной часто в другом файле. Какие средства навигации предлагают вам IDE всех мастей? На 99% это переключение между файлами с той или иной степенью удобства (быстроты) этих переходов. Как правило, степень этого удобства зависит в том числе и от привычек пользователя, а также требует от него непрерывного удержания в оперативной мозговой памяти текущего состояния окружения (какие файлы открыты? какой файл я редактировал перед этим? нужный мне файл ближе к началу или к концу списка открытых? и т.п.). Плюс к тому – переход внутри файла к конкретным типам, методам… тоже, в общем, требующий дополнительных действий по поиску нужной сущности.
Это не просто неудобно. Это излишне низкоуровневый, примитивный подход к решаемой задаче. Подумайте вот над чем: какой основной сущностью вы при этом оперируете? Очевидно, файлом. А разве есть такой термин, такая сущность, как файл, в решаемой вами задаче? Или в архитектуре, в соответствии с которой вы строите свою систему? Навигация по файлам и каталогам – это так называемая computer domain navigation. Это использование сущностей, навязываемых вам компьютером, т.е. тем инструментом, который призван быть вашим беспрекословным рабом. Наличие такой возможности обязательно. Всегда должна быть под рукой лестница, по которой можно спуститься в машинный отсек. Но управлять скоростью теплохода стоя у печки с лопатой в руках?
Альтернатива данному подходу лежит, очевидно, уровнем выше. В одном из вариантов (возможно, существуют и другие варианты абстракции) – это термины той архитектуры, тесно связанные с используемой технологической платформой, на которых вы основываетесь в своей разработке. Этот принцип можно назвать task domain navigation, поскольку основополагающими сущностями в нём являются те, которые присутствуют в вашей предметной области (в данном случае – в той архитектурной модели, которой вы следуете).
И за примером, раз уж я упомянул про Ruby On Rails, далеко ходить не придётся. Поговорим о шаблоне Модель-Вид-Контроллер, практической реализацией которого является фреймворк Ruby On Rails (весьма близкий, кстати, по своим принципам к популярному Apache Struts). Если перед вами стоит задача изменения логики работы некоторой пользовательской формы и изменение логики потребовало внести коррективы и в её представление? Разве логично искать оба (или даже более) нужных вам файла? Сомнительно… А разве не выглядит очевидной необходимость поиска формы (заметьте, это уже скорее термин конкретной технологии, а не шаблона MVC, но я позволю тут себе некоторую вольность раз уж рассуждаю на примере конкретных платформ)? Единократного поиска формы (“дорогой” для пользователя операции) и быстрого переключения между различными её аспектами (логикой обработчиков, представлением, хранимыми объектами)? Для меня ответ очевиден – ДА! И удобными я могу назвать только те инструменты, которые это обеспечат.
PS: Термины computer domain и task domain navigation мною, фактически, не придуманы. Это своеобразная проекция давно известных принципов организации рабочего стола пользователей на специфичную область разработки программных продуктов. В частности, одно из более общих описаний тех принципов, от которых я отталкиваюсь можно найти в этой статье (англ.).
PPS: Итоговый выбор был сделан в пользу связки vim + набор необходимых расширений. Справедливости ради замечу, что соответствующее расширение для GNU Emacs обладает примерно аналогичной функциональностью, чуточку менее эффективной по сравнению с rails.vim. (Лишь в качестве ремарки замечу, что в основной своей деятельности для разработки на Java я использую NetBeans). Если у вас возникнут какие-то дополнительные вопросы по данной теме, я с удовольствием отвечу на них в комментариях.
