Как пасти котов. Наставление для программистов, руководящих другими программистами - Дж.Ханк Рейнвотер

Все содержащиеся в программе основные объекты (clsTasks, clsProjects и clsToday) обращаются к локальной копии объекта-источника данных под именем clsData Provider. Это модуль класса VB, в котором поведение источника данных приравнено к значению vbDataSource. Объект clsDataProvider пользуется услугами посредника clsDataService, причем посреднические обязанности осуществляются через функцию под именем GetDataProviderRS, которая одним своим именем демонстрирует факт извлечения набора записей источника данных. Здесь же расположено большинство управляющих программой SQL-операторов. Наконец, приставка «Get» указывает на действие и в некоторой степени объясняет назначение процедуры. По-моему, я уже достаточно пожурил свою живность насчет нехватки комментариев, так что об этом недостатке я больше говорить не буду.

С точки зрения доступа к данным объект clsDataService является открытым интерфейсом логического звена данных. Объект clsDataProvider, описанный в предыдущем абзаце, обеспечивает взаимодействие между данными и уровнем графического пользовательского интерфейса. В составе clsDataService есть дочерний объект под именем clsDataAccess, который фактически осуществляет подключение к базе данных и исполняет передаваемые родительским объектом SQL-операторы. Подобного рода разделение обслуживания сводит взаимозависимость к минимуму и, по моему мнению, существенно облегчает сопровождение и модернизацию электронного администратора.

Другие достоинства и недостатки

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

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

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

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

Плохой код и безмозглый кот! И, опять же, пожертвовав здесь значительно более оптимальным решением, я предпочел завершить кодирование побыстрее. Впрочем, в защиту выбранного решения выступает и то обстоятельство, что процесс генерации отчетов с помощью программы Crystal Reports при передаче в файл-шаблон ненормализированного набора записей значительно упростился. Кроме того, так мне стало удобнее разрабатывать сам шаблон – ведь, работая в программе Crystal Designer, я просто открывал базу данных и копировал в шаблон ее поля.

Конечно, можно было бы подумать и над другими решениями, но то, на котором я остановился, по крайней мере, позволило оперативно генерировать для подведомственной мне группы еженедельные отчеты.

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

Заключение

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

Я вам советую иногда перечитывать главу 6 – так вы хотя бы не забудете основные принципы технического руководства. Написание этой главы, честно говоря, побудило меня сознаться в собственных неудачах в роли руководителя, и я в очередной раз осознал опасность неумения применять на практике полученные знания.

Библиография

Ресурсы для специалистов по выпасу котов

В библиографию я поместил все работы, упоминаемые в сносках, и ряд других трудов по теме книги – в основном те, которые недавно опубликованы.

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

Разработка программного обеспечения

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

Классические труды

• Brooks, Frederick P. The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition. New York: Addison-Wesley, 1995.

Основываясь на собственном опыте деятельности в качестве руководителя проекта IBM 360, Брукс излагает принципы разработки, казавшиеся в его время новаторскими и полностью доказавшие со временем свою состоятельность. Его хрестоматийный принцип – «стоит ввести в запаздывающий проект новых людей, как он начнет запаздывать еще больше» – подтвержден многократно. Обязательное чтение для всех руководителей. С точки зрения технологии данные Брукса устарели, но проведенный им анализ задач персонала для групп разработчиков полностью актуален.

Русский перевод книги доступен на http://lib.rus.ec/b/110948 (прим. сост. FB2)

• Weinberg, Gerald М. The Psychology of Computer Programming, Silver Anniversary Edition. New York: Dorset House Publishing, 1998.

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

Выдающиеся работы

• Beck, Kent. Extreme Programming Explained: Embrace Change. Reading, MA: Addison-Wesley, 2000.

Бек часто обращается к школе программной инженерии, но при этом предлагает новые методы и практические рекомендации для тех, кто окончательно погряз в процессе кодирования. С точки зрения руководителя его методология кажется несколько диковатой, однако нельзя не признать, что она способствует интеграции небольших групп разработчиков. Тем кто предпочитает писать код в одиночку, работа не понравится.

Русский перевод книги доступен на http://lib.rus.ec/b/101297 (прим. сост. FB2)

• Cockburn, Alistair. Agile Software Development. New York: Addison-Wesley, 2002.

Термин «гибкая разработка» появился не так уж давно, но описанные в этой замечательной работе методы в полной мере адаптированы к реальным повседневным попыткам перенести бизнес-требования на реализацию программных продуктов. Если в ходе разработки область действия разрастается (а разве бывает по-другому?), прочтите эту книгу – она научит адекватно реагировать на такого рода изменения.