Программист-прагматик. Путь от подмастерья к мастеру

СодержаниеГлава 7 Перед тем, как начать проект 40 Круги и стрелки Какова отдача от методов? → Часть 1

Глава 107

Часть 1

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

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

Составление спецификации – это большая ответственность.

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

Это является ошибкой по ряду причин. Во-первых, наивно полагать, что спецификация вообще способна зафиксировать каждую подробность некой системы или предъявляемых к ней требований. В узких предметных областях существуют формальные методы, с помощью которых можно описать систему, но для объяснения смысла обозначений конечным пользователям все равно требуется проектировщик – все еще имеет место человеческий фактор. И даже в отсутствии проблем, присущих этой версии, маловероятно, что средний пользователь точно знает, что ему нужно от этого проекта. Заказчики могут сказать, что осознают суть требований и подписаться под 200-страничным документом, составленным вами, но можете быть уверены – как только они увидят систему в работе, вы будете завалены просьбами о внесении изменений.

Во вторых, существует проблема выразительности самого языка. Все методики составления диаграмм и формальные методы все еще полагаются на выражение проводимых операций средствами естественных языков [42]. А естественный язык не приспособлен для этого. Посмотрите на формулировку любого контракта: юристам приходится коверкать язык самым неестественным способом, стараясь быть точными.

Проблемный вопрос для вас. Напишите короткую инструкцию по завязыванию бантиком шнурков на ботинках. Попробуйте!

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

Подсказка 57: Некоторые вещи лучше сделать, чем описывать

И наконец, существует "эффект смирительной рубашки" – конструкции, которая не оставляет кодировщику пространства для импровизации и отнимает усилия программирования любого рода. Кое-кто говорит, что хотел как лучше, но он неправ. Зачастую лишь на стадии написания текста некоторые варианты становятся очевидными. Во время написания программы вы можете подумать следующее: "Посмотрим вот сюда. Поскольку я написал эту подпрограмму именно таким образом, я смог добавить эту функциональную возможность практически без усилий". Или: "В спецификации говорится, что нужно сделать вот это, но я смог добиться практически того же результата, сделав по-другому, но затратил на это вдвое меньше времени". Ясно, что вы не обязаны вносить изменения, но у вас не было бы и намека на эту возможность, если бы ваши действия сдерживались конструкцией, изобилующей предписаниями.

Будучи прагматиком, вы должны стремиться рассматривать сбор требований, проектирование и реализацию как различные ипостаси одного процесса – поставки заказчику качественной системы. Не воспринимайте как изолированные друг от друга те среды, в которых происходит сбор требований, составление спецификаций и создание программ. Вместо этого постарайтесь принять «бесшовную» технологию: спецификация и реализация просто являются разными аспектами одного и того же процесса – попыткой зафиксировать и кодифицировать некое требование. Каждый из этих аспектов должен плавно переходить в другой без искусственных границ. Вы обнаружите, что в жизнеспособном процессе разработки поощряется обратная связь, идущая от реализации и тестирования к процессу составления спецификации.

Навигация

Закладки

Hosted by uCoz