БЕСЕДЫ О ПРОГРАММИРОВАНИИ
В прошлом номере я цитировал Брэда Кокса, инициатора разработки языка Objective-C и соучредителя корпорации Stepstone: "Разве что-нибудь делается в области разработки методов для постановки задач?" Вопрос заслуживает более пристального внимания, так как самый дорогостоящий недостаток нашей промышленности - это склонность к задержке решений малопонятных задач, когда сразу неясно, "правильное" решение или нет.
Ввязаться в спор по поводу языков программирования очень легко, но "правильный" язык просто облегчит вам создание программы, которую вы хотите написать. Я так и не дождался дискуссий на тему, как правильно определить цели разработки, которая должна логически предшествовать спорам о выборе инструментов.
С сожалением должен сказать, что последние модные течения в области разработки приложений не позволяют преодолеть разрыв между истинными требованиями пользователей и последствиями от их неправильного понимания. Разумеется, если неверно используются ценные идеи типа объектно-ориентированного подхода, то на разработку просто уходит больше ресурсов без какой-либо компенсации.
"При истинно объектно-ориентированном подходе может потребоваться буквально несколько минут, чтобы расширить какие-то свойства или добавить новые", - замечает Брюс Вебстер из Pages Software в своей новой книге "Проблемы объектно-ориентированного программирования", вышедшей в издательстве М&Т. "Подобная расторопность очень нравится начальству, - продолжает Вебстер, - поэтому инженеры предпочитают добавлять новые возможности, а не обеспечивать надежность и эффективность работы уже имеющихся".
Одна из ловушек, согласно Вебстеру, состоит в том, что "допускается изменение и замена спецификаций без согласования". Он предлагает четырехступенчатый план, который позволит определить, влияют ли подобные изменения на ваш проект.
Для начала просто посмотрите на формальный список свойств. Если такового не существует, у вас уже есть проблема. Фирма Бебстера однажды решила этот вопрос следующим способом: разослала всем, вплоть до инженеров, руководство пользователя за девять месяцев до выпуска продукта.
Если список свойств существует, в нем может быть неточно описано, что делает каждая из функций и, что более важно, чего она не должна делать. Инженеры в других областях задают ограничения на конструкцию: предельную прочность стержня, например, или предельное значение напряжения в цепи и т. п. Так и требования к программному продукту должны содержать ограничения на свойства, которые могут меняться.
Допустим, существует список свойств. Допустим, он содержит достаточно подробный перечень требований и ограничений свойств. Но очень может быть, что люди, пишущие код, реализуют не то, что требует от них спецификация.
Такая ситуация может возникнуть из-за "дрейфа свойств", когда по тем или иным причинам свойства добавляются по мере продвижения проекта. Это может войти в привычку - добавлять при каждом удобном случае все, что кажется полезным. Но, если вы не будете жестко придерживаться спецификации, график выполнения будет сорван и вы перерасходуете ресурсы.
Заключительный шаг, предложенный Вебстером, такой: предположите изменение спецификации и посмотрите, к чему это приведет. "Чем менее формален и документирован процесс, тем больше опасность", - предупреждает он.
Существуют попытки представить спецификации и календарные планы как наваждение со стороны тех, кто от них страдает, так как не способны контролировать работу самостоятельно. Но в конце концов результат работы, не имеющий отношения к делу, - это не продукт, это просто что-то вроде последствий стихийного бедствия.
К Питеру Кофи можно обратиться через MCI Mail по номеру: 357-1756 или через CompuServe по номеру: 72631,113.
Питер Кофи
