Никто не выясняет прирост эффективности компьютерной отрасли
относительно общества в целом. Потому что если попробует
выяснить, то наверняка обнаружит, что она падает и может быть,
уже выражается отрицательным числом, поскольку области, в которых
эффективность положительна, перевешиваются областями, в которых
от компьютеров больше потерь, чем пользы.
Компьютерная отрасль берётся помогать всем организовываться,
хотя она не в состоянии организовать саму себя. Поэтому получает-
ся, что она по большей части поставляет в другие области деятель-
ности не свои средства поддержки организации, а свой абсурд.
Если использовать сложные программные средства, то к сложности
предметной области прибавляется сложность этих средств, а доверие
к ним тем меньше, чем они сложнее, потому что с ростом сложности
увеличивается число ошибок и в программных средствах, и в
использовании этих средств.
Увеличение сложности программного продукта должно допускаться
лишь тогда, когда оно даёт увеличение эффективности в широком
смысле, а не только облегчает всучивание этогопродукта покупате-
лям при том состоянии их мозгов, какое имеет место в настоящее
время после интенсивной многолетней обработки абсурдизирующей
рекламой.
В развитии технических средств существует как тенденция
усложнения, так и тенденция упрощения: отказа от излишних,
неуместно применяемых сложностей, замены сложного простым.
Новое buzz-word -- это новый товар, новая возможность заполучить
деньги клиента. Всякое новшество должно какие-то проблемы решать
и какие-то создавать: если не будет решения проблем, то трудно
убедить клиента, что продукт ему нужен; а если не будет создания
новых проблем, то не будет и возможности продать следующее
новшество.
Когда чешется затылок, можно просто почесать его. А можно
реализовать метод "почесать" объекта "правая рука", наследующего
объекту "рука", который, в свою очередь, наследует объекту
"конечность", наследующему объекту "часть тела". Простые вещи
можно делать и простым, и сложным образом, сложные -- только
сложным, иначе запутаешься.
Умение обходиться без сложностей не менее, а то и более
значимо, чем умение с ними работать.
* * *
Характер устанавливаемого технологического порядка должен
соответствовать характеру выполняемой работы, в противном случае
этот порядок будет выглядеть абсурдным, и его вряд ли станут
поддерживать в полной мере.
Компоненты экранного диалога:
1) простой ввод данных;
2) проверка допустимости типа вводимых данных;
3) проверка полноты вводимых данных;
4) выбор из списка или проверка наличия в списке;
5) проверка взаимного соответствия данных;
6) формирование новых данных на основе введенных и
предложение их для проверки и/или модифицирования;
7) экранное представление данных в основной форме (целостное
представление записей одной таблицы);
8) экранное представление данных в производной форме (частичное
представление записей одной таблицы, представление
взаимосвязаных записей нескольких таблиц);
Первые четыре позиции в этом списке могут обеспечиваться сред-
ствами СУБД, седьмая позиция -- посредством простой утилиты,
входящей в комплект средств СУБД.
Часть пользовательского диалога может быть обеспечена посред-
ством утилит СУБД.
Под все формируемые и используемые на предприятии данные можно
создать таблицы в базе данных (взаимосвязанные через внешние
ключи) и обеспечить к ним ЭЛЕМЕНТАРНЫЙ ДОСТУП в многопользова-
тельском режиме посредством утилит СУБД.
Можно создать коллекцию SELECT-ов для формирования на основе
этих данных любых отчётов, не требующих сложной предварительной
обработки данных и их сложной перекомпоновки.
Далее при этой базе данных можно создавать (в одном стиле и на
основе одной системы прототипов) множество любых приложений,
обеспечивающих более сложный ввод-вывод данных, а также обработку
данных, то есть формирование новых данных на основе имеющихся.
Можно создать ориентированную на малоподготовленного пользова-
теля настраиваемую программу для простой ручной работы с таблица-
ми базы данных: ввода, вывода, отбора по указанным признакам,
перекомпоновки экранного представления и пр. На основе этой
программы можно быстро создавать не очень сложные приложения,
которые в очень многих случаях будут достаточными.
Можно многое эффективно сделать даже просто на основе файловой
системы, то есть без использования СБД.
* * *
Опасности в процессе разработки программной системы:
1. Утрата стройности.
Невыполнение или неправильное выполнение системой некоторых
действий может быть следствием 1) неполноты архитектуры,
2) ошибок в архитектуре, 3) ошибок в реализации архитектуры.
Решать проблемы типов 1, 2 можно посредством переделки архи-
тектуры, проблемы типов 1, 2, 3 -- посредством локальных
изменений в устройстве системы. Такие локальные изменения
называются заплатами (patches). Когда заплат оказывается
слишком много, наступает утрата единообразия в устройстве
частей системы и понимать и корректировать работу системы
становится очень сложно.
2. Утрата единства стиля.
Одну и ту же архитектуру можно реализовывать очень по-раз-
ному -- как в отношении деталей алгоритма, так в отношении
оформления программного кода. Если разные части системы реали-
зуются разными людьми, не стремящимися к одинаковости решений,
эти части приобретают очень разный вид и знание устройства
одной из них уже не может значительно облегчить работу с
другой.
3, Утрата человеческого масштаба.
Даже при полном сохранении стройности системы и единства
стиля её частей сложность системы может оказаться такого
уровня, что для решения проблем в системе придётся удерживать
в голове одновременно такое количество фактов, которое
значительно превышает средний объём человеческого внимания и
кратковременной памяти, так что оперировать этими фактами
становится практически невозможно.
* * *
Программирование -- области деятельности, которая быстро обнов-
ляется, поэтому, чтобы удержаться в ней, программисту необходимо
регулярно наращивать свои знания, то есть уменьшать свои твор-
ческие возможности и нейтрализовывать свой профессиональный опыт.
В настоящее время широкий специалист -- тот, кто знает много
частностей из разных специальных областей и которого можно
переводить с одной "низовой" работы на другую. Между тем, нужны
широкие специалисты, которые умеют работать на уровне абстракций,
не порывая с реальностью. При нынешнем состоянии мозгов
"низовики" смотрят на редких доморощенных "стратегов" как на
философствующих бездельников, которые избегают настоящего дела,
чтобы скрыть свою некомпетентность, а "стратеги" на "низовиков"
-- как на профессионально изощрённых недоумков, которые блестяще
делают зачастую ненужную работу и создают проблемы друг другу и
следующим поколениям.
* * *
Неоправданное разнообразие сущностей (объектов, их атрибутов,
операций над ними) в компьютеризуемой области и их частое измене-
ние -- одна из причин сложности и низкого качества программного
обеспечения.
Компьютеры существенно облегчили операции с данными и докумен-
тами, но это привело не к повышению качества управления, а к то-
му, что люди воспользовались возможностью увеличить разнообразие
управляемых сущностей, так что качество управления осталось при-
близительно на докомпьютерном уровне, если и вовсе не понизилось.
Можно сказать, компьютеры провоцируют на усложнение компьютеризу-
емых областей деятельности, потому что издержки от усложнения не
отягощают ту или иную область, а переносятся в другую -- в
область компьютеризации, которая, в свою очередь, уже ставится
перед фактом усложнения, а кроме того, является модной, "прогрес-
сивной" и многообещающей, так что людям представляется, что эти
издержки будут иметь место только на первых порах или что они --
неизбежная плата за "прогресс", то есть, по сути, за то, чтобы
выглядеть передовыми в глазах всех.
Более сложное -- не обязательно лучшего качества. Мир вещей и
технологий усложняется зачастую неоправданно, без разумных осно-
ваний, не совершенствуясь относительно "первичных" показателей
его эффективности.
К примеру, банк организует принятие какого-то нового вида
вклада не потому, что старые виды вкладов страдают какими-то
недостатками, а потому что есть возможность привлечь клиентов
новизной, поскольку клиенты воспитаны на идеологии "прогресса",
то есть имеют подсознательную установку на то, что новое лучше
старого. Ещё одна причина появления нового вида вкладов -- то,
что отдел развития банковских услуг стремится себя проявить.
Между тем, новый вид вклада означает ряд изменений в документа-
ции, программном обеспечении и т. п., а также переучивание и
дополнительную работу сотрудников банка, которые будут этим видом
вклада заниматься. То есть, будут дополнительные затраты, которые
приведут в конечном счёте к тому, что проценты по вкладам и
зарплата банковских работников окажутся меньше, чем могли бы
быть. Вместо этого можно было бы законодательно ограничить разно-
образие видов вкладов и тем самым исключить конкурентную борьбу
банков в области демонстрации ненужных обновлений и перенаправить
усилия на уменьшение технологических издержек при оказании фикси-
рованных видов банковских услуг. Выгода от этого состояла бы ещё
и в том, что потенциальным клиентам банка не надо было бы затруд-
нять себя ознакомлением с новыми ненужными возможностями и тра-
тить время на сложный выбор между большим количеством вариантов.
* * *
Ещё одна причина низкого качества программного обеспечения --
прогресс в программировании: программисты не успевают вполне
освоить новые технологии разработки программ и вполне отладить
созданные с их помощью системы, как возникает необходимость осва-
ивать ещё более новые технологии и переделывать на их основе
системы, иначе эти программисты и их системы будут выглядеть
старомодными. Но даже если возникнет желание смириться со своей
старомодностью, из этого ничего не получится, потому что разра-
ботчики инструментальных средств перстанут их поддерживать, а
производители аппаратных платформ перестанут эти платформы по-
ставлять и ремонтировать. Замедлиться в своём "развитии" отдельно
от остальных невозможно: ты или бежишь в равном со всеми темпе,
или выпадаешь из толпы, из профессии, из бизнеса. Сбавить темп
этой всеобщей абсурдной гонки можно только реформированием ком-
пьютерной отрасли в целом, но она настолько мощная и соответст-
венно денежная, что сама способна "реформировать" любого, кто
будет мешать ей функционировать так, как она функционирует.
Чтобы заставить людей трезво взглянуь на ситуацию в целом, нужно
очень большое потрясение.
* * *
Если прототип для программной системы правильно выбран (или
специально создан), при её разработке искать решения тех или иных
технических задач почти не приходится: надо в основном размножать
те или иные отлаженные в прототипе решения. При возникновении
необходимости в новом техническом решении надо исследовать уже
отлаженный код системы на предмет наличия в нём готового решения,
которое можно заимствовать. При этом выгода получается не от
экономии сил, а от обеспечения единообразия кода. Если возникает
идея лучшего решения, чем то, которе уже реализовано в найденной
аналогичной ситуации, надо отказываться от неё либо добиваться,
чтобы это решение было применено в этой аналогичной ситуации --
вместо того решения, которое уже реализовано.
* * *
В бою лучший солдат -- не тот, кто храбрее других и метче дру-
гих стреляет, а тот, кто держит линию, прикрывает товарищей и
точно выполняет приказы. Аналогично в коллективной работе над
проектом лучший программист не тот, кто больше умеет и быстрее
других пришет код, а тот, кто соблюдает принятые на проекте пра-
вила, тесно взаимодействует с коллегами и точно следует установ-
кам руководителя проекта. От очень способных, но недисциплиниро-
ванных работников бывает больше вреда, чем пользы: они нарушают
правила ради каких-то локальных выгод и этим, возможно, ухудшают
качество системы в целом, а также создают конфликтные ситуации
внутри коллектива и в отношениях с заказчиком, чем затрудняют
работу над проектом. И их трудно переубждать.
В отношении нарушения правил наиболее опасны для проекта инди-
виды следующих типов: 1) молодые, да ранние; 2) страдающие кризи-
сом среднего возраста; 3) разболтанные. Первые характеризуются
избытком самоуверенности, не сдерживаемой опытом, и стремлением
поскорее проявить себя вопреки всему. Вторые побуждаются к отча-
яным поступкам хронической неудовлетворённостью своими жизненными
достижениями. Третьи вообще не имеют склонности к соблюдению
правил.
* * *
Названия компонентов системы должны в возможно большей степени
отражать назначение этих компонентов. Чем тщательнее это обеспе-
чивается, тем меньше потребность в различных справочных таблицах
и комментариях, требуемых для того, чтобы выяснять по названию
компонента его назначение, по назначению -- название.
Если в какой-то части системы принять некоторый порядок обозна-
чения некоторых компонентов, то во всех других частях системы
должен быть принят по возможности точно такой же порядок
обозначения тех же компонентов: это избавляет от необходимости
заниматься "переводом" с "языка" одной части системы на "язык"
другой части системы при переключении внимания от одной части к
другой.
* * *
Отладочная работа в процессе создания программной системы
должна иметь целью не столько устранение конкретных ошибок,
сколько внесение в архитектуру системы и в технологии её
разработки таких изменений, которые препятствуют появлению
ошибок и облегчают исправление тех ошибок, которые всё-таки
появляются. К примеру, если причиной ошибок является сходство
именований некоторых объектов, надо изменить эти именования.
...............................................................
...............................................................
Александр Бурьяк.