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

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

В базе данных есть ряд таблиц соответствия, которые вы можете заполнить так, как сочтете нужным. На то, чтобы сделать еще несколько таблиц, мне элементарно не хватило времени – в частности, я не добрался до таблицы проектов, которую можно было бы соединить с таблицей заданий. Это решение, надо сказать, упростило процесс генерации отчетов средствами программы Crystal Reports, а потому имейте в виду: любое изменение скажется на шаблоне отчетов. Если хотите, можете изменить мой код – мне, конечно, будет интересно увидеть результат. Возникнут вопросы – пишите на адрес [email protected]. Постараюсь на все отвечать.

А теперь – несколько слов о дополнительных экранах программы, которые способны оказать существенную помощь в деле организации личных информационных потоков. На рис. А.1 изображено родительское окно.

Экран Today, показанный на рис. 4.3 в главе 4, несомненно, важен для систематизации административных функций, однако им одним программа не исчерпывается. Согласно моей теории планирования руководящей деятельности, любое задание нужно рассматривать в трех основных измерениях: Project (Проект), Source (Источник) и Assigned (Назначенные задания). Представление Project (рис. А.2) помогает отслеживать ход выполнения всех заданий в рамках проекта. Представление Assigned (рис. А.З) демонстрирует распределение заданий между сотрудниками. Наконец, представление Source (рис. А.4) напоминает о том, кто (например, какой процесс или комитет) требует результата от вас. Все это дочерние окна интерфейса MDI с изменяемым размером, поэтому открывайте их столько, сколько хотите.

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

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

Я предпочитаю выделять отдельный элемент Source для отслеживания тех заданий, которые передо мной ставит моя многоуважаемая руководительница. Забыть предписание начальницы – это же так глупо (не говоря уже о том, что этот опрометчивый поступок ставит под угрозу карьерные перспективы)!

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

Ну и все на этом. Хотите узнать больше – поройтесь в исходном тексте. Забавляйтесь с живностью, но не обижайте ее!

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

Имея перед глазами исходный код, вам будет легче читать это приложение. Как я уже говорил в приложении А, скачать код можно с сайта http://www.piter.com.

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

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

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

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

• Внутри объектов соблюдается строгая связность. Объект – это несколько больше, чем просто группа процедур; он должен выполнять конкретную функцию. Как известно, сердце не дышит, а легкие не качают кровь.

• Взаимозависимость между объектами по возможности минимизируется. В большинстве случаев (в отсутствие существенных доводов в его пользу) взаимозависимость не приводит ни к чему хорошему – она лишь усложняет сопровождение. На последующую изоляцию взаимозависимых объектов затрачиваются серьезные финансовые и временные ресурсы.

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