Stump's Workshop

пятница, февраля 29, 2008

5 инструментов

Эстафета "5 инструментов без которых я не могу работать продуктивно" пришла ко мне от Юрия Волкова (Deepen C++).
Оговорюсь сразу, что, во-первых, я буду говорить только о программных инструментах (без телефона и принтера я тоже не могу работать продуктивно). Во-вторых, речь пойдет не о работе на компьютере вообще, а именно о работе архитектора - проектировщика. Итак:
1. Outlook. C этим инструментом у меня сложные отношения. Outlook мне никогда не нравился, но два с половиной года назад я попал - на новой работе Outlook корпоративный стандарт. Теперь весь мой рабочий день вертится вокруг этой штуки, и со временем я стал находить, что работу свою он делает хорошо. Помимо почты, это еще и организация митингов, резервирование переговорок, интегрированный hrelp desk, система папок проектной переписки и т.д. Кроме того, вся моя личная корреспонденция редиректится на Gmail, а оттуда дублируется на корпоративный Exchange, и в конце концов сваливается в Outlook. После того как я настроил синхронизацию календарей Outlook с телефоном (ActiveSync), стал реже опаздывать на митинги.
2. Virtual PC (до этого был VMWare Workstation, но опять же - корпоративные стандарты). Постоянно использую виртуальные машины, на диске живет целый выводок образов различных ОС и конфигураций. Задачи приходится решать самые разные: тестирование развертывания продуктов на разных окружениях, всевозможные proof of concepts - проверки реализуемости различных решений, тестирование и изучение новых продуктов, и т.д. и т.п.
3. Rational Rose. Пробовал много разных инструментов моделирования, но классика победила :)
4. Notepad. Как это не покажется странным но по частоте использования обычный блокнот вообще вне конкуренции. XML и SQL, конфиги, логи, скрипты и нередко исходники - все читаю и правлю в блокноте. Конечно хорошо было-бы иметь подсветку синтаксиса и спелчекер для борьбы с моей хронической неграмотностью, но невозможно все это таскать за собой от компьютера у компьютеру. А блокнот есть везде...
5. Visual Studio. Одновременно на разных проектах приходится использовать три версии VS2003 VS2005 и VS2008. К сожалению программировать в последнее время приходится все меньше, но все равно считаю студию выдающимся инструментом для программиста, а в VS2008 еще и для архитектора появились неплохие инструменты.

Хотелось бы услышать с чем работают:
not-a-kernel-guy
kuklaora
Ленивый программист
ivaliy(хотя ему сейчас, видимо, не до того...)
Бороздин Андрей

P.S. Да, совсем забыл SVN с Тартилой. Без них работа станет. Но свободные номера в списке уже закончились...

четверг, февраля 21, 2008

Agile и Offshore development.

Нашел в MSDN статью Андрея Филева (Andrew Filev) Успешное внедрение гибких методик разработки в оффшорной разработке программного обеспечения.
Честно говоря не ожидал прочитать что либо подобное в MSDN. Статья больше об offshore, чем об agile. Особо рекомендую прочитать тем, кто продолжает считать офшорные разработки чем-то вроде работы второго сорта.

Подборка материалов по WCF

понедельник, февраля 18, 2008

Результаты опроса "Что важнее для успеха в разработке ПО"

Опрос закончился. Приняло участие 88 человек. Итак в чем же, по мнению сообщества, роются секреты успешной разработки софта?
65 (73%) человек отметили хорошую постановку задачи.
59 (67%) человек выделили важность хороших программистов
42 (47%) человека (менее половины) верят в важность хорошего менеджмента
39 (44%) человек отмечают архитектуру
34 (38%) человек считают важными тесты
10 ((11%) человек отметили важность методологии.

В результате важность перечисленных аспектов распределилась следующим образом:

Согласно общественному мнению секрет успеха прост. Надо взять хороших программистов, толково объяснить им поставленную задачу и половина успеха уже у вас в кармане. Для полной уверенности в том, что все пойдет как надо, можно поставить на проект хорошего менеджера. Если не забыть про архитектуру и тесты, то успех будет полным. А методология, это штука из разряда nice to have, главное чтоб работать не мешала :)

Что я хочу сказать от себя. Меня определенно радует сфокусированность подавляющего большинства (73%) на требованиях. Ну а мои личные предпочтения распределились следующим образом:
1. Хороший менеджер, и менеджмент в целом. Мне, как человеку техническому, потребовалось определенное время (годы) для того, чтобы осознать, техническое совершенство продукта несмотря не на что играет в достижении успеха важную но все же вторичную роль. Проект - это в первую очередь управление, без него даже самый совершенный код останется бесполезными килобайтами на жестком диске.
2. Хорошая постановка требований. Требования - это наше все. Нельзя создать хороший софт не зная точно, что он должен делать.
3. Хорошая архитектура. Технический аспект важен. но всего лишь на третьем месте.
4. Хорошие программисты. Программисты нужны :) Причем нужен хотя бы один, способный обеспечить выполнение пункта 3. Не более того. Есть очень малое число проектов. для которых действительно нужны выдающиеся программисты.
5. Хорошее тестирование. Без тестирования невозможно выпустить хороший продукт. Это как воздух, без воздуха нельзя жить, но никто не говорит о роли воздуха в достижении счастья.
6. Хорошая методология очень важна. Но методология определяется менеджементом (извините за некрасивое слово). Методология - это стиль управления. Не столь важно какой будет стиль, главное чтобы управление было эффективным.

P.S. Диаграма построена при помощи Google Chart API

воскресенье, февраля 17, 2008

Простой дизайн

Размышления о том, в чем заключается роль опыта в проектировании, в чем опасность готовых решений или каркасов.

Недавно у меня завязалась дискуссия с одним коллегой на форуме RSDN. Обсуждался вопрос о способе расчета массы объекта, состоящего из множества составных частей (которые тоже состоят из частей). Я предложил использовать простейший вариант реализации, основанный на наследовании. Коллега предложил более сложный вариант с использованием интерфейса и выделенного класса (я специально не упоминаю детали, чтобы избежать обсуждения этого вопроса здесь). Дискуссия разгорелась довольно жаркая. Суть ее свелась к спору о том, что лучше: простое решение, учитывающее только текущие требования, либо более сложное, которое учитывает возможные дополнительные требования, которые могут возникнуть при дальнейшем развитии системы. Причем, как оказалось, корень противоречия лежит в самом подходе к проектированию системы.

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

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

Один из коллег высказал такую мысль:

«Это, в общем, вопрос компромисса:
Слишком частные решения как правило ограничивают масштабируемость приложения и увеличивают затраты на переработку. В том числе переработку архитектуры.
Слишком общие решения могут безосновательно увеличить стоимость разработки и снизить производительность.
Так что тут больше вопрос интуиции.
Начинающие разработчики, как правило, делают первую ошибку, разработчики среднего уровня — вторую»

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

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

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

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

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

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

Очень сложно получить хороший дизайн сразу и окончательно, хотя бы потому, что это всегда результат компромисса. Еще сложнее получить хороший дизайн, когда помимо реально существующих требований мы закладываем в него возможности «на будущее». Наоборот, выделив главное, отбросив несущественное, у нас появляется гораздо больше шансов создать предельно простой дизайн, который в тоже время наилучшим образом удовлетворяет самым важным требованиям. Наиболее ярко этот подход проявился в методологии XP, в знаменитом принципе YAGNI (You Aren't Gonna Need It) – «тебе это не пригодится».

Оппоненты данного подхода обычно говорят: «зачем я буду несколько раз переделывать свою систему, когда я сразу могу внести в нее все необходимые свойства, благо есть архитектурные паттерны, framework-и, software factory и т.д.». Ответ прост. Проектирование процесс «грязный» (подверженный ошибкам) и итеративный. Создать «сразу» окончательный дизайн невозможно. Поэтому наиболее выигрышной стратегией будет не «предвосхищение требований», а «ожидание изменений».

Совершенно показателен в этом плане пример использования готовых библиотек и «фабрик ПО». Несколько лет назад Microsoft начал публиковать так называемые Application Blocks, исходные коды библиотек для решения типовых задач, возникающих при построении приложений: конфигурирования, логирования, кэширования, бизнес логики и т.д. Это были действительно интересные библиотеки, которые обобщали наиболее передовой опыт. Затем все эти блоки были сведены в Enterprise Library. Это уже был своего рода каркас для построения распределенных корпоративных приложений. Сейчас на основе Enterprise Library созданы Software factory – библиотеки дополнены шаблонами и мастерами design time для Visual Studio. Само название «Фабрика ПО» подразумевает, что она позволяет максимально упростить и ускорить создание приложений, предоставляя каркас содержащий «все необходимое». На практике получается не все так гладко. Разработка идет очень быстро и хорошо, до тех пор, пока не возникает задача, на которую не были рассчитаны базовые библиотеки. Тут приходится вносить изменения в эти библиотеки, а поскольку они рассчитаны на максимально широкий класс задач, то они имеют достаточно сложный и нетривиальный дизайн, и вносить изменения в них весьма не просто. Это повторяется из проекта в проект – резкий старт, огромная экономия времени на рутинных аспектах и затем такой же резкий стопор в разработке, погружение в детали библиотек, переделки, а зачастую дублирование для реализации недостающих функций. В результате проект занимает примерно столько же времени, как и при разработке с нуля. А дизайн системы представляет собой огромный блестящий каркас, заполненный функционалом едва ли на десятую часть, окруженный достаточно неприглядными подпорками.

Альтернатива этому – итеративное проектирование с поддержанием максимально простого дизайна каждой части системы на низком уровне, и структурной целостности на более высоком уровне. Неизбежные изменения гораздо проще вносить, когда дизайн прост, чем когда он сложен. К тому же в этом случае ваша система никогда не будет обременена тоннами неиспользуемого или бесполезного кода. Я скажу более, оптимальная стратегия проектирования для систем с длительным жизненным циклом - вносить изменения в систему как можно позже, когда их необходимость становится совсем уж очевидной. Так вы не только уменьшите количество изменений, но и улучшите их «качество».

А как же framework-и и фабрики ПО? Это замечательные вещи, но использование их в проекте, особенно впервые, это значительный риск. И в тоже время, если вы уже использовали тот или иной каркас, вы зачастую можете обнаружить, что именно для вашего конкретного случая этот каркас, как говорится, именно то, что доктор прописал. Вот в чем роль опыта :) И в тоже время каркасы, это просто кладезь best practice архитектурных решений и поэтому они достойны всяческого внимания и изучения.