потому что они нечитаемы . Обычно это правило навязывается руководителями, знающими ФОРТРАН, БЕЙСИК или какой-то другой язык, не поддерживающий указатели, ибо их не очень-то заставишь изучать Си. Вместо того, чтобы допустить, что их знания недостаточны, такие руководители будут лучше калечить своих программистов. Указатели отлично читаемы для программистов на Си.

И наоборот, я видел ситуации, где руководство требовало, чтобы программисты перешли с языка программирования типа КОБОЛ на Си, но не желало оплачивать переподготовку, необходимую для перехода. Или хуже, руководство платило за переподготовку, но не предоставляло времени, необходимого для действительного изучения материала. Переподготовка является занятием, требующим всего рабочего дня. Вы не можете одновременно выполнять полезную работу, а если попытаетесь, то ваши деньги будут выброшены на ветер. Так или иначе, после того, как руководители видят, что их работники не были превращены в гуру программирования на Си++ после 3-дневного краткого курса, они реагируют, накладывая ограничения на использование некоторых частей языка. Фактически говоря вы не можете использовать ту часть Си++, которая не похожа на язык, который мы использовали до перехода на Си++ . Естественно, что будет нельзя эксплуатировать ни одну из прогрессивных особенностей языка - которые прежде всего и являются главной причиной его использования - если вы ограничите себя простейшим подмножеством особенностей.

Глядя на эти ограничения, мне в первую очередь интересно знать, зачем было менять КОБОЛ на Си. Принуждение программистов на языке КОБОЛ использовать Си всегда поражало меня своей большой глупостью. КОБОЛ - великолепный язык для работы с базами данных. У него есть встроенные примитивы, упрощающие выполнение задач, которые довольно трудны для Си. Си, в конце концов, был разработан для создания операционных систем, а не систем управления базами данных. Довольно просто дополнить КОБОЛ, чтобы он поддерживал модный графический интерфейс пользователя, если это единственная причина перехода на Си.

10. Проблема должна быть хорошо продумана перед тем, как она сможет быть решена

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

правилами в этой книге.

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

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

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

11. Компьютерное программирование является индустрией обслуживания

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

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

Легко увидеть, как возникает эта печальная ситуация: программисты создают программы, которые никому не нужны. Исправить ее тоже легко, хотя это и сталкивается с неожиданными трудностями в некоторых условиях: спросите людей, что им нужно, и затем сделайте то, что они вам сказали.

К сожалению, многие программисты производят впечатление полагающих, что конечные пользователи не знают, чего хотят. Вздор! Почти всегда пользователи оказываются так запуганы сыплющим специальными терминами экспертом , что замолкают. Мне часто говорили: Я знаю, что мне нужно, но не могу это выразить . Лучший ответ на это: Отлично, скажите это на нормальном языке - я сделаю перевод на компьютерный .

12. Вовлекайте пользователей в процесс проектирования

13. Заказчик всегда прав

Ни одной программе не добиться успеха, если ее проектировщики не общаются непосредственно с ее конечными пользователями. Несмотря на это, часто ситуация больше напоминает игру ( испорченный телефон ), в которую многие из нас играли в детском саду и при которой 20 ребятишек садятся в кружок. Кто-нибудь шепчет фразу своему соседу (соседке), который передает ее своему, и так далее по кругу. Забава заключается в том, чтобы послушать, как сообщение звучит после того, как пройдет весь круг - обычно ничего похожего на исходную фразу. Тот же самый процесс часто встречается при разработке программ. Пользователь говорит с управляющим, докладывающим другому управляющему, который нанимает консультационную фирму. Президент консультационной фирмы разговаривает с руководителем разработчиков, который в свою очередь говорит со старшим группы, обращающимся, наконец, к программистам. Шансы на то, что даже простой документ с требованиями останется после этого процесса невредимым, равны нулю. Единственным решением этой проблемы является тесное вовлечение пользователей в процесс разработки, лучше всего путем включения, по крайней мере, одного конечного пользователя в команду разработчиков.

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