Как пасти котов. Наставление для программистов, руководящих другими программистами
Шрифт:
А теперь – несколько слов о дополнительных экранах программы, которые способны оказать существенную помощь в деле организации личных информационных потоков. На рис. А.1 изображено родительское окно.
Экран Today, показанный на рис. 4.3 в главе 4, несомненно, важен для систематизации административных функций, однако им одним программа не исчерпывается. Согласно моей теории планирования руководящей деятельности, любое задание нужно рассматривать в трех основных измерениях: Project (Проект), Source (Источник) и Assigned (Назначенные задания). Представление Project (рис. А.2) помогает отслеживать ход выполнения всех заданий в рамках проекта. Представление Assigned (рис. А.З) демонстрирует распределение заданий между сотрудниками. Наконец,
По информации с каждого из этих экранов генерируются отчеты, которые можно отправить по почте сотрудникам, принести на собрание, предоставить начальнику, просмотреть на предмет согласования ваших планов с деятельностью других подразделений компании. До тех пор пока приложения для коллективной работы не достигнут определенного уровня зрелости, несогласованность в действиях между отделами при отслеживании разных типов заданий будет оставаться обычной практикой – при этом каждый из отделов будет навязывать собственный стиль руководства. Поэтому для управления списками заданий часто привлекается метод «вырезания и вставки», а управленческие реалии, которые больше напоминают страшный сон, некоторые именуют не иначе как «казнь через разрезание на тысячу кусочков».
Три окна со списками, расположенные по периметру родительского окна (см. рис. А.1), предназначены для быстрого доступа к трем основным представлениям. В этих окнах содержатся списки имен проектов, ресурсов, которыми можно назначить новые задания (в основном это имена людей), и источников заданий, над которыми вы работаете или которые отслеживаете. По двойному щелчку на любом пункте списка на экране появляется новое представление, в котором задания рассортированы в соответствии с назначением представления.
Я предпочитаю выделять отдельный элемент Source для отслеживания тех заданий, которые передо мной ставит моя многоуважаемая руководительница. Забыть предписание начальницы – это же так глупо (не говоря уже о том, что этот опрометчивый поступок ставит под угрозу карьерные перспективы)!
Выполнение функций, представленных в открываемых щелчком правой кнопкой мыши контекстных меню, обеспечивается несколькими объектами-контейнерами. Испробуйте их или хотя бы взгляните на соответствующий код обработки событий.
Ну и все на этом. Хотите узнать больше – поройтесь в исходном тексте. Забавляйтесь с живностью, но не обижайте ее!
Приложение Б
Как дать скотине в глаз – критический обзор кода электронного администратора
В главе 6, в разделе «Кодовая полиция», я объяснял, как стать кодовым полицейским. Сохранять объективность при чистке собственного кода очень сложно, но я постараюсь. Связав в названии этого приложения свой код со скотным двором, я надеялся подсказать вам, что я собираюсь делать. Все, что я хочу, – это чтобы
Имея перед глазами исходный код, вам будет легче читать это приложение. Как я уже говорил в приложении А, скачать код можно с сайта http://www.piter.com.
Контекст и происхождение программного продукта
Код электронного администратора я написал вскоре после прекращения работы над неким веб-проектом, призванным облегчить административную волокиту, сопровождающую любой процесс разработки программного обеспечения. Поскольку времени на написание кода, который мне позже предстояло самому же раскритиковать, категорически не хватало, для иллюстрации нескольких архитектурных принципов я привлек материалы упомянутого проекта. Эксперимент этот, принесший мне немало забавных впечатлений, кажется, удался.
Не скажу, что код, о котором идет речь, может по своему качеству соревноваться с коробочными продуктами, но, в общем, он не так уж плох и с моими административными функциями справляется успешно.
Правила игры
Анализировать код я намерен по методике, изложенной в главе 6. Итак, как я уже говорил, хороший код отличается следующими особенностями.
• Он пишется в соответствии со стандартами программирования, принятыми для конкретного языка. В таком случае применяемые разными программистами методики конструирования объектов, обусловленные архитектурой, не будут слишком разниться.
• Внутри объектов соблюдается строгая связность. Объект – это несколько больше, чем просто группа процедур; он должен выполнять конкретную функцию. Как известно, сердце не дышит, а легкие не качают кровь.
• Взаимозависимость между объектами по возможности минимизируется. В большинстве случаев (в отсутствие существенных доводов в его пользу) взаимозависимость не приводит ни к чему хорошему – она лишь усложняет сопровождение. На последующую изоляцию взаимозависимых объектов затрачиваются серьезные финансовые и временные ресурсы.
Я обращу ваше внимание на ряд слабых сторон кода. По большей части они обусловливаются сжатыми временными рамками и тем обстоятельством, что инструмент, к которому этот код относится, я проектировал исключительно под себя. Пока что я ни разу не утверждал, что безгрешен, поэтому мои самоистязания вряд ли кого-нибудь удивят.
Следовал ли я стандартам?
В основном я следовал стандартам – по крайней мере, мне так кажется. VB я пользуюсь, начиная с версии 1.0, и с годами отношения с кодом складывались у меня (наверное, так же как и у вас) по-разному – был и удачный, и провальный опыт. С моей точки зрения, следование стандартам VB выражается в попытках привести объектно-ориентированные понятия в соответствие с этим языком, который, по правде говоря, отнюдь не полностью поддерживает объектно-ориентированную парадигму.
В главе 4 я изложил понятие задачи, или задания, – основного организующего принципа программного обеспечения. Просмотрев мой код, вы найдете в нем объект под именем clsTasks и вспомогательный объект clsTask. В этих двух модулях классов инкапсулированы пользовательское взаимодействие и все данные, обрабатываемые программой в связи с заданиями. Формы frmTask и frmTasks, ответственные за обработку заданий на стороне графического пользовательского интерфейса, являются дочерними объектами объекта clsTasks. Все прочие объекты, например clsToday, при обработке заданий обращаются к локальным экземплярам clsTasks. Эта схема довольно удачно, как мне кажется, иллюстрирует методику многократного использования объектов.