Всех с праздником!
Вчера Delphi исполнилось 17 лет
Можно сказать, это ещё один наш профессиональный праздник! Нельзя не заметить, что благодаря Delphi большинство из нас стали программистами. Не "кодерами", а именно профессионалами, способными справляться с задачами разработки систем, необходимых людям. Давайте поговорим о разработке ПО через призму максимального удовлетворения требований заказчика.
Нам нужен механизм
выявления требований заказчика к функционалу приложений. Такой принцип должен быть:
- понятен заказчику;
- понятен программисту;
- легко конвертируем из выбранных терминов в элементы проекта Delphi.
Прототипирование
RAD-средства позволяют очень быстро и легко сделать нужное количество форм и в пилотном варианте показать заказчику, каков будет функционал приложения.
У меня был успешный проект, когда, работая в ценностях Agile, мы с заказчиком разбирались в функционале разрабатываемого приложения (предметная БД), рисуя окошки на бумажке. Решил опять "поднять" тему в свете двух последних событий.
Первое - победа в конкурсе проектов уважаемого мужчины, которого зовут Андрей Цысарь (ударение на первый слог). Кто смотрел ролик - можно освежить с 07:17 до 10:09.
По количеству ценных мыслей Андрей давно уже в моём понимании находится в разряде идеологов практического применения Delphi, но блог он свой пока не завёл.
Второе событие - обсуждение текущих дел в другом проекте (система обработки данных), мониторингом которого я занимаюсь в рамках служебных обязанностей и по велению души.
Феноменология
дискуссий на тему "что должен делать проект" известна. Я полагаю, достаточно часто разработчикам, которые занимаются сопровождением и улучшением сделанных ими приложений, приходится слышать "а не мог бы ты, уважаемый (я), добавить еще пару окошек, в которых мы сможем…". Обращаем внимание на слова "мы сможем". Это означает, что функциональность приложения заказчики трактуют в терминах "окошек" Delphi. RAD-средства здесь оказывают нам неоценимую услугу, позволяя прям в режиме реального времени накидать форм и явить их критическому взору потребителя.
В 17-ый день рождения Delphi
особенно хочется отметить ценность нашей любимой технологии (и C++Builder как братского продукта), которая есть не просто способ делать быстрее приложения под Windows и уже под Mac OS, а механизм кристаллизации требований заказчика путём прототипирования приложения с определением функционала будущей системы.
Ещё раз хотелось поблагодарить Андрея за очень оригинальную идею и её воплощение средствами Delphi XE2 с FireMonkey!
Posted by Vsevolod Leonov on February 15th, 2012 under public |
RSS Feed
February 15th, 2012 at 11:09 am
О… спасибо за теплые слова. Я уже начал хвастаться перед знакомыми…
>>но блог он свой пока не завёл
ну да, не готов я еще этим заниматься..
February 15th, 2012 at 11:49 pm
>>- легко конвертируем из выбранных терминов в элементы проекта
Как идеолог могу посоветовать изучить следующий труд http://www.williamspublishing.com/Books/978-5-8459-1597-9.html, где в достаточно малом объеме (~420 страниц) описана хорошая методика проектирования. Цена конечно не демократическая, но аналогов по содержание наверно нет. В сети можно найти электронный вариант.
Покупал у них последнюю книгу Фаулера (про DSL), напечатана какой-то загадочной краской со стойким неприятным запахом. Читать было крайне проблематично (меня даже посетила мысль, что это заговор с целью ликвидации специалистов на территории нашего государства..). На озоне комментарий не прошел цензуру. Посему решил обзавестись этим летом ридером.
February 16th, 2012 at 2:13 am
Фаулер, конечно, ум, честь и совесть.
Понятно дело, как в случае с любыми авто-генерируемыми диаграммами после разбрасывания "квадратиков" их руками можно двигать.
Но я спокойно бы сменял 420 страниц "обобщенного программирования", на 1 пост на тему как и когда твой кейс использовался/планируется использовать.
И можно ли сделать авто-генерацию твоих диаграмм?
Но вот так - скормил утиле проект, а она отгенерировала диаграмму.
February 16th, 2012 at 5:20 am
@Vsevolod Leonov
Есть что-то типа дорожной карты с планами выпуска обновлений раз в 2-3 месяца, содержит следующие этапы: уменьшить количество вводимого кода до 0 за счет использования экспертов (жду соответствующий хотфикс), автоматизировать создание проекта за счет текстового DSL, заменить текстовый DSL на графическую схему, заменить использование цельных картинок на составные.
Проект использую для себя (пока в рамках склерозника). Цель создания - облегчить создание макетов исходя из имеющегося опыта использования сторонних продуктов (ниже об этом немного написано).
@IL Says
Я рисовал окошки в Balsamiq Mockups. Но в моем проекте можно использовать любые рисунки. Основной минус существующих решений в том. что они предоставляют некоторый функционал интерактивности. Но когда начинаешь развивать эту идею с целью получения более интерактивных макетом, сталкиваешься с тем, что реализацию очень утомительная. Исходя из текстов книжек кажется, что это излишне, т.к. макет - это "неформальное описание проекта, у клиента не создается впечатления, что перед ним работающая программа и он спокойно переживает процесс кодирования…", но на практике возникает необходимость обсуждения макета с программистами и дополнительная интерактивность помогает лучше понять, что же на самом деле собирается сделать человек и соответственно так можно отсеять больше глупых идей на стадии проектирования.
February 16th, 2012 at 8:16 am
@Андрей
Багфиксы выходят тогда, когда они готовы. Нет смысла гоняться за дешевой популярностью и клепать "лёгкие" апдейты чисто имиджевого характера. Собственно, любой разработчик это знает. Конечно, под раздачу годовых бонусов можно выкинуть обновление, что и делают программисты. Но, вероятно, это не есть путь честных людей.
Баги требуют своевременного репортинга, а дальше работает система приоритетов, что определяется востребованностью.
February 16th, 2012 at 9:46 am
Я не против и никуда не спешу, просто описал особенность одной ветки развития проекта.