В этом разделе собраны мои статьи, а также есть ссылки на чужое творчество. Статьи не отсортированы по темам, это просто моя записная книжка. Если найдёте в них для себя что-то полезное - буду только рад.

Использование препроцессора С при проектировании.

Про CUI и терминальные системы.

Статьи других авторов.

Использование препроцессора С при проектировании.

Нередко прикладная задача плохо формализуется. Как правило, это происходит тогда, когда изначально в проект не была заложена определённая идеология и его развитие "исторически" протекало спонтанно и бессистемно. Появилось требование заказчика - добавили новый тип данных. Для конкретных целей для реализации этого обычно появляются тучные стада операторов if или switch. В каждом отдельном случае это не тяжело и не страшно, но со временем код становится совершенно нечитаемым.

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

• Я разработал концепцию, по которой сначала в программе создавались массивы описателей, представляющие собой структуры со всей необходимой информацией (размер в битах, смещение от начала, тип данных, есть знак или нет, границы, название, единица измерения и т.п.). Эти структуры нужно было как-то создавать, а т.к. для описания каждой поддерживаемой категории таких записей нужно было создать штук 300-400б то метод их создания должен был быть ещё и удобным для дальнейшего использования.
• Были разработаны стандартные наименования для функций, переменных и членов классов, используемых в программе. Для этого была придумана система суффиксов и префиксов для каждой категории. Например ток по каналу "А" ранее встречался как Ia, I1 или I_ch_A. Переименование заняло много времени, но оно того стоило, теперь ток по каналу "А" стал всегда именоваться как Ia. Аналогичным образом поступил и функциями получения значений - различные Tok1() и ChanIa() стали всегда GetDbl_Ia().
• Для наполнения массивов описателей были разработаны специальные макросы на основе тех соглашений (суффиксов и префиксов), которые описаны выше. Макросы получились следующего вида:

  #undef ADDUS_PM
  #define ADDUS_PM(c1k,typ,name,dim,dec,min,max,sign) \
      case c1k: \
      { \
          CUSet uSet(iOffset+offsetof(GS_USETITEM,wValue), \
                  c1k,typ,name,dim,dec,min,max,sign); \
          uSet.AddDesc(0,_T("ОТКЛ")); \
          uSet.AddDesc(1,_T("БЛОК")); \
          uSet.AddDesc(2,_T("АПВ")); \
          m_arrUSet.Add(uSet); \
      } \
      break;
              

  Это позволило сделать вполне читаемыми блоки добавления и последующего анализа большого количества параметров, примерно такого вида:

  ADDUS(wUv388,388,CUSet::E_NUM,_T("Время срабатывания РЛ1"),_T("с"),0,0,600,FALSE);	
  ADDUS_PM(wUv514,514,CUSet::E_NUM,_T("Режим защиты Rиз"),_T(""),0,0,0xffff,FALSE);	
  ADDUS(wUv390,390,CUSet::E_NUM,_T("Время срабатывания обрыв фаз"),_T("с"),0,0,9999,FALSE);	
              

• Для получения битовых полей информационных записей журнала макросы были несколько более интересными т.к. в них генерировались имена функций с префиксами:

  #define ADDDN(txtDesc,txtShot,txtDim,eGR,fmin,fmax,nam,clrRgb) \
      m_arrColumnFN.Add(CRLogFN(txtDesc,txtShot,txtDim,eGR,fmin,fmax, \
      UPI_STR_JEVENT_9::GetDbl_##nam##,UPI_STR_JEVENT_9::GetStr_##nam##, \
      clrRgb));
              

  В результате описания информационных полей стали занимать одну строчку и могли уже не вызывали приступов головной боли и ночных кошмаров:

  ADDDN(_T("Полная мощность"),_T("Pполн"),_T("кВт"),CG_POW,0.,1638.3,PowFull,RGB(140,70,210));
  ADDDN(_T("Сигнал аналогового входа №1"),_T("Ан1"),_T(""),CG_AN,0.,1638.3,AnalogInp1,RGB(0,70,70));
  ADDDN(_T("Сигнал аналогового входа №2"),_T("Ан2"),_T(""),CG_AN,0.,1638.3,AnalogInp2,RGB(70,0,70));
              

• В программе эти писатели могут встречаться несколько раз: первый раз при добавлении в список, потом при разборе полученного журнала. Для того, чтобы список остался в единственном месте (чтобы не корректировать несколько раз одно и то же) я вынес все описания в отдельные включаемые файлы. А всякий раз, когда мне нужно было сделать с этими описания, я делал примерно так:

      switch (refUsi.wCode1024)
      {
          #include "RLogFile09.inc"
      }
              

  При этом совсем макросы в любой момент можно отменить директивой #undef и определить другие, которые нужны в данный момент.
Такой способ сокращения исходного кода порой может дать сокращение времени разработки в разы и я его Вам рекомендую обязательно попробовать. В чужом проекте, конечно, это сделать тяжелее, но в своём собственном его можно предусмотреть с самого начала. Как можно видеть из данного примера, несмотря на господство C++ и модные течения (вроде Java и C#), старый добрый C-шный препроцессор ещё очень даже эффективен.

---

Про CUI и терминальные системы.

Некоторые склонны считать, что терминальные системы устарели много лет назад и что пользовательский интерфейс "зелёными буквами по чёрному фону" уже не способен удовлетворить никаких потребностей. Тех, кто так думает могу сразу огорчить - это заблуждение. Текстовый монохромный интерфейс является действительно самым старым, но задачи, для решения которых он возник, за 30-40 лет изменились ещё меньше. Перечислю некоторые из систем, действующих и сегодня:

• Система резервирования железнодорожных билетов "Экспресс-2";
• Система резервирования авиабилетов "Сирена";
• Различные учётно-финансовые системы на основе SAP R3."
Терминальные системы с текстовым интерфейсом на два порядка менее ресурсоёмки, чем их GUI-аналоги. Например, комплекс ТехПД, в разработке которого много лет назад принимал участие, великолепно обслуживал до 32-х терминальных пользователей, работающих одновременно. Приемлемая скорость обеспечивалась даже при работе пользователей по модему на скорости 9600! А сервером в то время был (не поверите!) Pentium-60 с 16 Мб оперативной памяти и жёстким диском размером 1 Gb. В 2002 году его заменили на АСУЛР (АСУ Линейных районов), которая теперь вместе с Oraclе требует для своей работы многопроцессорный кластерный сервер, дисковый массив и высокоскоростные каналы связи. Но делает то он во многом всё то же самое, задача управления грузовыми перевозками с тех пор изменилась мало.
Если раньше для работы с "ТехПД" было достаточно "зелёного терминала", то для работы с АСУЛР требуется клиентская часть, устанавливающаяся на ПК. А где ПК, там нужен администратор. А где его найти на узловой станции где-нибудь в Калмыцких степях? А ещё, где есть ПК, там есть "нецелевое использование", вроде установленных "левых" программ, со всеми вытекающими проблемами: контроль лицензионной чистоты и борьба с вирусами.

На терминальных системах таких проблем нет - туда не поставить ворованный PhotoShop, не установить "Тетрис", нет опасности подцепить какую-нибудь заразу. Как правило, в них сразу после логина и пароля выходит рабочая программа и выход из неё означает закрытие сессии. Так "с какого перепуга" компании 1С, к примеру, понадобилось создавать свою "1С:Бухгалтерию" с графическим интерфейсом?! Там что, графика нужна? Это же не САПР, деньги цифрами всегда показывают.

Зачастую многие технологии являются сегодня забытыми совершенно незаслуженно. Текстовые терминальные системы имеют право на существование гораздо чаще, чем это происходит сейчас. Их проще разрабатывать и сопровождать, это безопаснее и это, наконец, дешевле. Причём, это совершенно не означает, что нужно обязательно строить их на базе одной из ветвей UNIX - необходимые средства есть под любой серьёзной ОС, даже win32.

---

Статьи других авторов.

http://www.joelonsoftware.com	Джоель Спольски (Joel Spolsky). Сборник великолепных статей о культуре программирования и о многом другом. Очень рекомендую прочитать.
http://www.cfin.ru/	Константин Берлинский. Как добиться успеха в безнадежных проектах. Хороший анализ и готовые советы для планирования, снабжённые фактическими данными и замерами времени. Особенно наглядны потери времени при неверной организации коммуникаций.
http://itblogs.ru/blogs/itlife/	Блог опытного программиста. Масса полезного опыта, который вдобавок просто интересно читать.
http://proklondike.com/	Статья о повадках и особенностях заказчиков. Очень хорошо описаны основные проблемы взаимодействия, остальные материалы сайта тоже очень даже интересные.
http://www.proces.biz/Reingeneering/	Хороший ресурс о реинжиниринге бизнес-процессов. Предназначено для руководителей предприятий. Остальным может быть полезно для подготовке к беседе с руководителем.
http://forum.insidepro.com/	С-шные трюки от "мыщъх'а". На первый взгляд, это не совсем имеет отношение к теме, но здесь приводятся очень интересные приёмы, некоторые из которых применять совсем не нужно! Эти приёмы часто способны сделать Ваш код менее читаемым и всё это со временем приведёт к... необходимости досрочно провести реинжиниринг.
http://www.rsdn.ru/article/baseserv/apicallsintercepting.xml	Методы перехвата API-вызовов в Win32. Это должен знать каждый!
http://www.edgeofnowhere.cc/viewtopic.php?p=2483118	Ещё одна прекрасная статья по внедрению своего кода в чужой :-)
http://www.codejock.com/support/articles/mfc/general/g_7.asp	Использование полноцветных (24 бита) икон в toolbar-ах при написании программ на MFC. Небольшая, но очень полезная статья, особенно для тех, кто продолжает использовать старые версии Visual C++.

 



© Пчелинцев А.В. 2009-2011. Использование материалов допускается только с разрешения автора.

Используются технологии uCoz