Стандарты. Часть 1.

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

Столь же широкие цели преследует и отечественная Государственная стандартизация, законодательно устанавливая: «Стандартизация — деятельность, заключающаяся в нахождении решений для повторяющихся задач в сфере науки, техники и экономики, направленная на достижение оптимальной степени упорядочения в определенной области» (ГОСТ 1.0—85). Однако, поскольку возможности достижения этой цели ограничены, проявляется тенденция к подмене так понимаемой стандартизации стандартизацией в узком смысле — когда стандартизационная деятельность считается руководителями стандартизации достаточно успешной, если (и только если) она успешно завершается разработкой текста Государственного стандарта с максимально широкой областью распространения, его утверждением и введением в действие по установленным стандартным же процедурам. Надо разобраться, в какой момент, где и почему деятельность по стандартизации программного обеспечения (и прежде всего языков программирования), важность которой трудно переоценить, оказывается в лучшем случае бесполезной, а чтобы она не оборачивалась во вред, программистам приходится зачастую затрачивать больше усилий, чем на саму стандартизацию; почему она дает больший экономический эффект для лиц, участвовавших в разработке текста и введении стандарта, чем для отрасли программного обеспечения в целом.

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

Профессиональные программисты и сами стремятся к тому же, чего требует п. 1.3.1 ГОСТ 1.0—85, — к оптимальности уровней стандартизации и унификации, к прогрессивности требований, предъявляемых к продукции, к рациональности, совместимости и взаимозаменяемости, а также и к созданию методов и средств контроля качества продукции, отражающих высшие достижения отечественной и зарубежной науки, техники, технологии и передовой опыт. Но когда в практике стандартизации контроль стандартности в ПО понимается как синоним контроля качества, то это не укрепляет здания ПО. Неверно думать, что специалист по стандартизации, не будучи специалистом по программному обеспечению, может, сверяя текст стандарта с документацией, принимать решение о соответствии системы программирования стандарту и тем самым о качественности системы.