Развитие технологий программирования должно быть по преимущес-
тву делом тех специалистов, которые эти технологии используют
(не всех, конечно, а лишь тех, кто имеет к этому способности
и наклонность). Если же оно выделяется в качестве направления
работы особого подразделения предприятия, то есть становится
делом людей, непосредственно с проблемами технологий не сталки-
вающихся, а потому опирающихся в лучшем случае на воспоминания
из прошлых этапов своей трудовой деятельности, то начинаются
перекосы и излишества, из-за которых предлагаемые технологические
рекомендации и инструменты не вполне "ложатся" на реальные
потребности и возможности. Чтобы быть эффективным, подразделение
предприятия, отвечающее за развитие технологий программирования,
должно лишь стимулировать, координировать и методологически
поддерживать других -- тех, кто знает ноансы развиваемых
технологий по собственному опыту их использования.
На всяком крупном предприятии компьютерной отрасли есть подроб-
ные, очень правильные и гладко написанные документы по поводу
того, как надо разрабатывать программные продукты. Эти документы
выражают и практический опыт, и достижения теоретической мысли.
Они охватывают все аспекты работы и в совокупности вроде бы опре-
деляют механизм, который должен давать если не удивительные, то
хотя бы очень добротные рензультаты. Они хороши, местами блестя-
щи, только программисты почему-то не всегда им следуют. И тратят
огромные силы на возню с проблемами, которые они вследствие этого
создают друг другу и самим себе. И при этом каждый толковый
менеджер понимает, что если принуждать всех неукоснительно
придерживаться нормативных документов, то будет ещё хуже.
От нормативных документов почти всегда в той или иной степени
отступают. Возможные причины этого:
незнание нормативных документов;
лень;
недооценка важности следования нормативным документам;
дефицит времени;
неполное соответствие нормативных документов особенностям
конкретной работы;
чрезмерная сложность нормативных документов;
стремление использовать что-то более эффективное, чем то, что
предписано.
Отношение к нормативным документам бывает отрицательным отчасти
потому, что в них ради системности излагается много тривиального
и не выделено существенное и неочевидное.
Творческий процесс -- дело очень тонкое: решение некоторых про-
блем не даётся без просветления мысли, а просветление получается
нечасто, непредсказуемо и не надолго, так что если в те короткие
периоды, когда оно есть, тратить силы на выполнение формальных
действий, предписанных инструкциями, мало что остаётся на
творчество.
Основные причины того, что при выполнении работ по созданию и
сопровождению сложных программных систем имеют место отступления
от предписанных технологических правил, следующие:
1. Правила не всегда ясно сформулированы, понятны, обозримы.
2. Не все предписанные правила полезны. Бывают абсурдные правила
(зачастую это неуместно применяемые правила, которые когда-то
при некоторых условиях дали положительный эффект).
3. Соблюдение правил требует усилий и замедляет выполнение
некоторых компонентов работы.
4. Программные средства, используемые для обеспечения порядка,
сложны, интуитивно непонятны, неудобны.
5. Полезный эффект соблюдения правил не всегда очевиден: вредные
последствия нарушения правил зачастую сказываются не сразу, а
скрытно накапливаются или же проявляются лишь при некоторых,
не обязательно складывающихся обстоятельствах.
5. Зачастую есть надежда, что работа закончится раньше, чем на
ней начнут сказываться отсроченные вредные последствия нару-
шения правил.
Способы поддержания технологической дисциплины:
использование инструментальных средств, делающих невозможным
отступление от порядка или напоминающих о требуемых
действиях;
эпизодическое наказание нарушителей порядка (возможно,
символическое);
эпизодическое поощрение соблюдающих порядок (возможно,
символическое);
эпизодическое напоминание о составляющих порядка и о его
полезностях.
Как почти всякое усовершенствование, объектно-ориентированное
программирование не избавляет от сложностей, а переносит их в
другое место. Средствами ООП программы пишутся быстрее, но осво-
еное ООП требует больше времени. В разрабатываемой прикладной
системе многое оказывается уже написанным за прикладного програм-
миста разработчиком объектов, но ЧТО именно написано -- остаётся
в секрете.
Скрытый код -- это хорошо для продавца программного продукта,
но не для покупателя: покупателю лучше иметь полностью обозримые
исходные тексты программ, т. к. только в этом случае он имеет
возможность удостовериться, что в коде нет ничего лишнего, и
только в этом случае он при необходимости сможет обеспечить изме-
нение кода в любой его части, не прибегая к помощи первоначально-
го разработчика.
Программист, использующий покупные библиотеки, зависит от
поставщика библиотек. Если смена поставщика компилятора -- дело
трудное, то смена поставщика библиотек -- дело практически невоз-
можное. А чем больше зависимость от какого-либо субъекта, тем
больше расходы, риск, напряжение психики.
Если бы не "навороченные" пользовательские интерфейсы программ
для персональных компьютеров, объектно-ориентированное программи-
рование осталось бы маловостребованной остроумной концепцией,
представляющей в основном теоретический интерес.
Два программиста могут различаться производительностью в деся-
ток раз, из чего напрашивается идея оставлять в программировании
только тех, кто развивает высокую производительность. На самом
деле ситуация с производительностью в программировании очень
сложная, а идея отбора наиболее продуктивных -- малополезная.
Люди действительно различаются уровнем и характером умственных
способностей и качеством общей профессиональной подготовки, но на
различия в производительности при выполнении конкретной работы
влияет не столько это, сколько 1) знания, нужные для конкретной
работы, 2) свежий опыт выполнения конкретной работы, 3) соответ-
ствие психического склада личности особенностям конкретной рабо-
ты. Если приходится часто переключаться с одной работы на другую,
производительность будет низкая. Чем больше предметных областей,
в которых необходимо ориентироваться, тем хуже показатели ориен-
тирования в каждой из этих областей. Одному программисту везёт с
характером, последовательностью и длительностью выполняемых
заданий, поэтому он становится специалистом в некоторых вопросах,
другому везёт меньше, поэтому он становится только полуспециалис-
том, а то и хуже. Далее, всегда уместно предполагать, что
программист, работающий быстро, возможно, использует не лучшие
решения, необоснованно пренебрегает некоторыми обстоятельствами
или недостаточно отлаживает свой код. Кроме того, человек
творческого склада обычно плохо справляется с рутинной работой,
требующей внимания и памяти, а человек нетворческого -- с работой
творческой, требующей нестандартных подходов. Альтернатива отбору
лучших -- разработка эффективных технологий программирования,
технологий индивидуальной самоорганизации и обучение людей их
использованию.
Ошибки -- это в программировании неизбежная, нормальная, преду-
сматриваемая часть деятельности. Потери из-за них -- неизбежные,
нормальные, предусматриваемые. Время от времени любой программист
ошибается по-крупному, то есть причиняет заметный ущерб и рискует
испортить репутацию себе и своему коллективу. Чтобы репутация не
страдала, следует заранее готовить заказчика к адекватному вос-
приятию ошибок. Лучший способ -- выявлять его собственные ошибки
на этапе подготовки технического задания и демонстрировать своё
разумное отношение к ним.
Ошибки -- не только нормальная, но при некоторых условиях ещё и
желательная часть работы, потому что они позволяют человеку лучше
изучить предметную область, в которой он действует, используемые
там инструменты, а также самого себя в применении к этой предмет-
ной области и этим инструментам.
Инструментальная система, которая "всё делает за программиста",
представляет собой искусственный мирок, надстроенный над другим
искусственным мирком (к примеру, над языком программирования
типа C или Java), то есть является, так сказать, фикцией второго
порядка, в пределах которой уже ничего не надо знать о деталях
работы компьютерного "железа" как части реального мира.
Перешедший на использование такой системы программист...
меньше знает о том, как устроен создаваемый им продукт;
меньше задумывается об алгоритмах обработки данных в
компьютере;
больше зависит от поставщика инструментальной системы;
тратит время в основном на освоение системы, которая
потом "всё делает за него".
Повышать продуктивность и качество программирования можно
использованием шаблонов и прототипов, а также поддержанием
жёсткой технологической дисциплины, но такой подход требует от
программиста повышения культуры интеллектуальной работы, в том
числе работы коллективной. Использование же инструментальной
системы, которая "всё делает за программиста", перекладывает
организующий компонент деятельности на компьютер (точнее, на
разработчика инструментальной системы), чем приводит к ослаб-
лению соответствующих навыков у человека. Чем качественнее
инструментальная система, тем хуже подготовленным и менее ин-
теллектуально развитым может быть использующий её программист
и тем прочнее "империя" поставщика инструментальных средств.
Плохие программные системы создаются хорошими программистами:
плохим программистам создание систем не поручают, потому что
считают, что те не справятся, а хорошие программисты обычно мало
разбираются в устройстве систем, психологии пользователей, ком-
пьютеризуемой предметной области и управлении проектами. Поручить
хорошему программисту разработку системы -- приблизительно то же,
что поручить хорошему каменщику проектирование здания: он доволь-
но хорошо знает, где что должно быть и как это обычно бывает, но
он не в состоянии обеспечить некоторые важные детали, делающие
проект легко реализуемым, модифицируемым, удобным для пользовате-
ля, надёжным, хорошо вписывающимся в окружение и т. д. Программи-
рование, проектирование программных систем, управление программным
проектом -- это отдельные сложные специальности, близкие к
специальности прораммиста, но далеко не идентичные ей. Преуспеть
даже в одной из них -- сложно, а сразу в двух-трёх -- дело и
вовсе крайне затруднительное.
Система, сделанная особо хорошими программистами, обычно
устроена так: несколько блестящих технических решений на грани
гениальности и куча "заплат" поверх них, так что вполне разоб-
раться во всём этом может только другой особо хороший програм-
мист, да и то не сразу.
Программная система не сводится к совокупности хорошо написан-
ных и отлаженных программ. Программы должны соотноситься между
собой и взаимодействовать одна с другой таким образом, чтобы их
совокупная сложность не оказывалась суммой их частных сложностей
и сложности соединения их в целое и чтобы можно было легко выяв-
лять и устранять препятствия, мешающие работе системы.
Программную систему делает системой следующее:
единообразие именований;
единообразие алгоритмов;
единообразие оформления программного кода;
удобная подсистема трасировки;
удобная подсистема сообщений об ошибках.
Александр Бурьяк.
