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

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

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

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

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

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

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

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

Я вам советую иногда перечитывать главу 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.

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