Программное обеспечение и его разработка

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

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

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

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

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

Важным фактором становится «рабочая гордость», так как теперь видны не только результаты работы программы, но и каждая команда программы. Многие программисты сообщают, что там, где раньше они позволяли себе проявлять беспечность и небрежность при программировании (хотя никто из них этого раньше не замечал), теперь изо всех сил стараются делать все наилучшим образом. Повышенная аккуратность в работе приводит к повышению качества программ.

Член группы программистов учится у других членов своей группы, изучая их работу; он перенимает методы программирования, возможности языка, тонкости прикладной тематики. Постепенно пробелов в знаниях не остается. Инспекция программ должна стать неотъемлемой частью каждого более или менее крупного программного проекта. Подобные обзоры надо проводить не только для уже написанных программ, их следует регулярно осуществлять на всех стадиях процесса разработки. (См. рис. 5.47.)

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

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

Рис. 5.47. Коллегиальные обзоры — сквозной контроль

Пример ошибки

Когда в 1965 г. приводнился корабль «Джемини V», мир затаил дыхание, ведь произошло это в 100 милях от заранее рассчитанной точки приводнения. Телевизионные комментаторы заставили весь мир поверить, что капсула может утонуть. К капсуле устремились авианосцы; через час после приводнения капсула была обнаружена вертолетами.

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

Спецификации для вычисления были правильные, однако программист решил пойти более короткой дорогой. Для вычислений следовало определить количество дней, часов, минут и секунд, прошедших со времени запуска, и, принимая Солнце в качестве неподвижного центра, рассчитать положение Земли в этой инерциальной системе. И все будет прекрасно. Программист выбрал более короткое решение и просто исключил из рассмотрения число дней полета (он разделил число часов на 24), «логично» рассудив, что по отношению к Солнцу Земля через каждые 24 ч оказывается в одинаковом положении. Это неправильно. Это было бы правильно, если Земля вращалась бы только вокруг собственной оси, а ведь она вращается и вокруг Солнца. Орбитальное движение вносит небольшие изменения в период возвращения Земли в ту же точку по отношению к Солнцу. Этот период не точно равен 24 ч. Этот «просчет» и привел к стомильной ошибке в определении места приземления.

Чья же это была ошибка? Конечно, программиста — он отклонился от проекта. Короткий путь оказался «заминированным». Но в самой программе ошибки не было; она была в формулировке решения. Сквозной контроль мог и, наверное, должен был привести к обнаружению ошибки. По крайней мере было бы обнаружено, что реализация не совсем точно следовала за проектом.

Тестирование и качество