• Контекст и происхождение программного продукта
  • Правила игры
  • Следовал ли я стандартам?
  • Как насчет связности и взаимозависимости?
  • Другие достоинства и недостатки
  • Заключение
  • Приложение Б

    Как дать скотине в глаз – критический обзор кода электронного администратора

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

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

    Контекст и происхождение программного продукта

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

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

    Правила игры

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

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

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

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

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

    Следовал ли я стандартам?

    В основном я следовал стандартам – по крайней мере, мне так кажется. VB я пользуюсь, начиная с версии 1.0, и с годами отношения с кодом складывались у меня (наверное, так же как и у вас) по-разному – был и удачный, и провальный опыт. С моей точки зрения, следование стандартам VB выражается в попытках привести объектно-ориентированные понятия в соответствие с этим языком, который, по правде говоря, отнюдь не полностью поддерживает объектно-ориентированную парадигму.

    В главе 4 я изложил понятие задачи, или задания, – основного организующего принципа программного обеспечения. Просмотрев мой код, вы найдете в нем объект под именем clsTasks и вспомогательный объект clsTask. В этих двух модулях классов инкапсулированы пользовательское взаимодействие и все данные, обрабатываемые программой в связи с заданиями. Формы frmTask и frmTasks, ответственные за обработку заданий на стороне графического пользовательского интерфейса, являются дочерними объектами объекта clsTasks. Все прочие объекты, например clsToday, при обработке заданий обращаются к локальным экземплярам clsTasks. Эта схема довольно удачно, как мне кажется, иллюстрирует методику многократного использования объектов.

    Модульные объявления объекта clsTasks выглядят так:

    '-Закрытые объекты и события

    Private mo_DataService As clsDataService '–данные объекта

    Private mo_PickList As clsPickList '–список отбора для форм

    Private WithEvents mfjasks As frmTasks '–все задания, связанные с frmTasks

    Private WithEvents mfjask As frmTask '–отдельное задание, связанное с frmTask

    Private mo_DataGrid As DataGrid

    Private WithEvents mo_DataProvider As clsDataProvider '–основные данные

    Private ml_CurTaskID As Long '–выбранный идентификатор задания

    Private ms_Project As String '–применяется с frmProject

    Private mo_ProgConfig As clsProgConfig

    Private ms_TaskFilter As String

    Private mo_Task As clsTask

    Private mb_NeedRefresh As Boolean

    Private ms_Resource As String

    Private ms_Source As String '–открытые объекты и события

    Public Event TaskUpdatedO

    И что мы имеем? Много комментариев, среди которых нет ни одного, который описывал бы назначение центрального объекта. Плохой код и бездарный кот! И каким же образом человек со стороны сможет понять, зачем этот объект нужен, если нет никаких описаний?! Для этого придется основательно изучать код. Я-то его знаю вдоль и поперек, а вот свежий взгляд наткнется на труднопреодолимое препятствие.

    Будь вы менеджером, вы бы, конечно, настояли на введении заголовка модуля с указанием его автора и даты создания. Кроме того, вы, вероятно, потребовали бы от программиста составить обзор модуля, обозначив в нем имена открытых процедур и механизм «жизнеобеспечения» ими объекта.

    Нельзя, однако же, не признать некоторые достоинства вышеприведенного фрагмента кода. Обратите внимание на имена переменных – m в них идентифицирует область действия (модуль), а следующий символ обозначает тип переменной (Соответствует длинной переменной, s – строковой, b – логической, и т. д.).

    Теперь рассмотрим конкретную процедуру, инициирующую процесс отображения формы задания:

    Public Sub Show(Optional sResource As String ="")

    If (mf_Tasks Is Nothing) Then

    SetHourglass

    Set mf_Tasks = New frmTasks Load mfjasks

    Set mo_DataGrid = mf_Tasks .grdTasks

    '-load tasks

    LoadTaskGrid

    '-Load resource combo

    mo_PickList.LoadPickList mf_Tasks.cboResource. PIC_RESOURCE

    ' -configure task list

    ms_Resource = sResource

    mf_Tasks.Configure ms_Resource

    If sResource «» "" Then   ' -установка источника данных для отображения отдельного задания

    ms_TaskFilter = "Assigned =" & Chr$(39) & sResource & Chr$(39)

    mo_DataProvider.Filter ms_TaskFi1ter

    mo_DataProvider.Sort «Status»

    End If

    SetReady

    End If

    With mf_Tasks

    WindowState = 0

    Show

    ZOrder 0

    End With

    End Sub

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

    Как насчет связности и взаимозависимости?

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

    Программа управляется объектом clsApplication с глобальной областью действия. Из него создаются и управляются на высоком уровне все остальные объекты. К примеру, в процедуре с понятным именем cLsAppLication.StartApplication создана родительская форма MDI и ряд других вспомогательных объектов. С точки зрения процесса исполнения программы это сугубо положительный момент.

    Объявления модулей в clsApplication выглядят так:

    Private WithEvents mf_Parent As nidiManager

    Private WithEvents mo_Projects As clsProjects

    Private WithEvents mo_Tasks As clsTasks

    Private WithEvents mo_Today As clsToday

    Private WithEvents mo_Archive As clsArchive

    Private mo_Contacts As clsContacts

    Private mo_DataService As clsDataService

    Private mo_Reports As clsReports

    Private mo_ProgConfig As clsProgConfig

    Private mo_PickList As clsPickList

    Private mc_Tasks As New Collection '–коллекция объектов clsTasks

    Private mc_Projects As New Collection '–коллекция объектов clsProjects

    Private mc_Sources As New Collection '–коллекция объектов clsSource

    Private moJJser As clsUser

    Private mo_Source As clsSource

    Private ms_DSN As String 'применяется при подключении

    Здесь, если не считать нехватки комментариев уровня модуля, присутствуют все дочерние объекты clsApplication. Из этого фрагмента кода в принципе можно вывести всю объектную иерархию программы.

    Реализация в программе многочисленных событий заметно «стройнит» код форм. В большинстве случаев родителями форм выступают модули классов, причем имена форм явственно свидетельствуют об этих отношениях. К примеру, clsProjects запускает frmProjects; впоследствии, если в форме происходит какое-то событие, его аналог сразу запускается в родительском элементе управления. Таким образом, код по большей части локализуется, что, в свою очередь, способствует инкапсуляции.

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

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

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

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

    Как проводится подключение к базе данных?

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

    Какую роль в моей программе исполняют наборы записей?

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

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

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

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

    Есть ли в коде волшебные числа[141]?

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

    Заключение

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

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


    Примечания:



    1

    Мои шутки, по большей части размещаются в сносках, так что они не будут вас отрывать от основной мысли. Ну вот, например: что значит «обратная совместимость»? Это значит, что новая операционная система с тем же успехом, что и старая, может грохнуть все ваши программы.



    14

    Игра слов «шлюзовой уровень» – thunking layer, «уровень мышления» – thinking layer. Примеч. перев.



    141

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








    Главная | В избранное | Наш E-MAIL | Прислать материал | Нашёл ошибку | Наверх