Мир меняется... и синтаксис вместе с ним.

Для новостей есть специальные сайты, но я никак не мог пройти мимо одной статьи. Нынче модно подогревать интерес к новым продуктам через блоги тремя битами выцеженной информации. Вот и Ходжес (а теперь получается и я) разродился заметкой про Тибурон, в которой подтвердились слухи о том, что компилятор наконец-то будет понимать конструкцию Exit(Result). Попытки реализовать это дело были и раньше в некоторых экспериментальных расширениях. Но проникновение в толстую кишку больного с помощью автогена не каждому по душе, поэтому такие расширения имели больше академический интерес. Теперь же это случится официально. Но интересно не это, а комментарии к посту, в которых, помимо глупых «Спасибо дорогому товарищу Сталину!», посыпались как из рога изобилия жалобы, слезы и стенания на конструкции, уже набившие оскомину нашему брату - программеру. Дайте нам мультикаст эвенты, уберите лишний Try и т.д. Пожаловались, так сказать, излили душу =) Эх, был бы результат... В общем, почитайте, прикольно =)

Красавец код

На днях был у коллег в гостях. Они купили стороннюю компоненту за 59 долларов для своего софта. Это ужос! Кашамр! Нет, всё работает, как надо, но код оформлен пренебрежительно плохо, с использованием самобытного урюпинского стиля форматирования. Выставлять такую «красоту» на всеобщее обозрение, а тем более продавать это за деньги … Нет слов, одни буквы.

Итак, для тех, кто ещё не знаком с правилами оформления public кода для Delphi, может прочесть эту статью. Кому некогда – просто скачайте Delfor или тулзу от протестантов на худой конец. И перед тем, как выдать код на свет божий, пропустите его через эти декастомизаторы, чтобы избавить от персонального или корпоративного «дизайна». Планета будет вам благодарна.

PS. Почему бы не встроить стандартный форматтер в среду? И что у нас есть из интегрированного? GExperts вроде не умеют форматировать, в MMX форматирование вызывает только смех, Lextutio я снес после очередного закидона...

Звездная команда (Часть 8). Хороший тон использования представлений на примере небольшой команды.

Теперь давайте на примере рассмотрим реализацию небольшого проекта на Starteam.

Перечислим основные постулаты, которых будем придерживаться при развертывании проекта:
1) Главное представление используется для реализации основной линии проекта;
2) Проект конфигурируется таким образом, чтобы предписать создание запросов на изменение, задач, обсуждений, или требований для каждого "модуля". Понятие "Модуль" определено свободно.
3) Для стандартных билдов используются метки представления (View labels) и, возможно, содействующие состояния (promotion states).

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



Когда необходима модификация ("mod"), разработчик отмечает (check-out) требуемые файлы в основном представлении, блокируя те, которые планирует изменить. После создания локальных изменений рабочего файла, включая и создание любых новых файлов, разработчик выполняет испытания модуля, чтобы быть уверенным, что файлы могут быть использованы другими разработчиками. Когда тестирование закончено, разработчик загружает(Check- in) новые и измененные файлы в БД.
Автоматизированный сценарий (не изображен на рисунке) выполняется периодически и создает новую метку представления. Выгрузка (Check-out) файлов из БД делается по этой метке, чтобы откомпилировать и собрать проект и запустить наборы тестовых программ.
Когда в основном потоке разработки приходит время выпуска приложения, от определенной метки представления (например, "Билд 5.3.142 Кандидат релиз") или от содействующего состояния создается branch-all представление. Такое представление используется как представление для поддержки этого релиза, так как единственные изменения, осуществляемые в этом представлении будут патчами для исправления ошибок. Развитие же системы продолжается в основном представлении.
Если изменение, сделанное для представления поддержки считают актуальным для других выпусков, то оно также объединяется с основным представлением (не изображено на рисунке). Сравнение/объединение представлений для этого обычно не требуется. Вместо этого, объединяются конеретные файлы, так как основное представление продолжает развиваться, в то время как представление поддержки остается относительно постоянным для определенного релиза. Этот процесс повторяется для каждого мажорного релиза. В результате для каждого релиза создается свое представление для поддержки.

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

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

PS. Возможно, я буду периодически публиковать посты на животрепещущие темы. Вот, например, про мёрдж(merge) народ интересуется. Вроде бы простая вещь, а ставит в тупик. Наверное, это какой-то психологический блок?

Звездная команда (Часть 7). Как следует и как не следует работать с представлениями.

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

Итак, основные пожелания по использованию представлений:

1) Трактуйте представления как потоки для реализации определенного этапа жизненного цикла приложения. Элементы представления могут сильно изменяться или не изменяться вообще в зависимости от назначения этого представления.

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

3) Используйте branch-all представления. Это Ваша основная рабочая лошадка. Используйте ссылочные представления для read-only задач, таких как, например, сценарии компиляции и компоновки.

4) Метки представления и содействующие состояния удобны и эффективны. С помощью метки представления вы можете быстро отметить все элементы в представлении, выполнить загрузку отмеченных файлов из БД и корректировать ревизию индивидуальных файлов. Содействующие состояния позволяют вам определять логические состояния жизненного цикла программы, такие как тестовые версии, релиз кандидаты и т.д. На основе метки представления или содействующих состояний также могут быть созданы новые представления.

5) Не используйте глубоко вложенных представлений. Представления необходимы в основном как непосредственные дочерние записи основного представления. Иногда необходимы представления третьего уровня (внуки). Если вы создаете представления глубже третьего уровня, вероятно, вы используете представления не эффективно.

6) Не используйте некоторые типы представлений. Не используйте non-derived представления, "плавающие" представления, или изменяемые ссылочные представления кроме как в случае крайней необходимости и только тогда, когда вы полностью понимаете поведение этих типов представления.

7) Не используйте слишком много представлений. Представления - это "тяжелые" объекты. Их создание из существующего представления может занимать значительное время. Они обычно добавляют тысячи новых дочерних элементов в БД. Нормально использовать до нескольких сотен представлений на одном сервере Starteam.

8) Представления не следует использовать как “личное рабочее пространство” для индивидуальных разработчиков.

(окончание следует)