Книги
чёрным по белому
Главное меню
Главная О нас Добавить материал Поиск по сайту Карта книг Карта сайта
Книги
Археология Архитектура Бизнес Биология Ветеринария Военная промышленность География Геология Гороскоп Дизайн Журналы Инженерия Информационные ресурсы Искусство История Компьютерная литература Криптология Кулинария Культура Лингвистика Математика Медицина Менеджмент Металлургия Минералогия Музыка Научная литература Нумизматика Образование Охота Педагогика Политика Промышленные производства Психология Путеводители Религия Рыбалка Садоводство Саморазвитие Семиотика Социология Спорт Столярное дело Строительство Техника Туризм Фантастика Физика Футурология Химия Художественная литература Экология Экономика Электроника Энергетика Этика Юриспруденция
Новые книги
Цуканов Б.И. "Время в психике человека" (Медицина)

Суворов С. "Танк Т-64. Первенец танков 2-го поколения " (Военная промышленность)

Нестеров В.А. "Основы проэктирования ракет класса воздух- воздух и авиационных катапульных установок для них" (Военная промышленность)

Фогль Б. "101 вопрос, который задала бы ваша кошка своему ветеринару если бы умела говорить" (Ветеринария)

Яблоков Н.П. "Криминалистика" (Юриспруденция)
Реклама

Совершенный код. Мастер-класс - Макконнелл С.

Макконнелл С. Совершенный код. Мастер-класс — М.: Русская редакция, 2005. — 896 c.
ISBN: 5-469-00822-3
Скачать (прямая ссылка): soversheniykodmasterklass2005.djvu
Предыдущая << 1 .. 306 307 308 309 310 311 < 312 > 313 314 315 316 317 318 .. 426 >> Следующая

предназначенный для использования другими людьми, а не самим
разработчиком. Программный продукт используется в средах,
отличающихся о той, в которой этот продукт был создан.
Он тщательно протестирован перед сдачей в эксплуатацию,
задокументирован, и другие люди могут осуществлять его
сопровождение. Разработка программного продукта стоит примерно
втрое дороже разработки программы.
Другой уровень сложности требуется и для разработки пакета
программ, работающих вместе. Такой пакет называется
программной "системой". Разработать систему гораздо сложнее,
чем простую программу из-за сложности разработки интерфейсов
между отдельными частями и необходимости интеграции этих
частей. В целом система также примерно втрое дороже, чем
простая программа.
Создание "системного продукта" предполагает наведение
глянца, прису- щего продукту, и наличие нескольких частей
системы. Системный продукт примерно в девять раз дороже
простой программы (Brooks, 1995, Shull et al, 2002).
Неучитываемые различия в сложности и глянце между программами,
продуктами, системами и системными продуктами и являются
частой причиной ошибок в оценках. Программисты, использующие
свой опыт в написании программ для составления плана создания
программного продукта, могут ошибиться в меньшую сторону
примерно в 10 раз. Рассматривая следующий пример, обратитесь к
графику на рис. 27-3. Если вы воспользуетесь своим опытом в
написании 2К строк
642 ЧАСТЬ VI Системные вопросы
кода, чтобы оценить, сколько времени займет разработка
программы длиной в 2К строк, ваши расчеты будут учитывать
только 65% времени, необходимого для выполнения всех операций
по созданию программы. Написание 2К строк кода не занимает
столько же времени, сколько создание целой программы,
состоящей из 2К строк. Если вы не учитываете время,
затрачиваемое не на конструирование, разработка займет на 50%
больше времени, чем вы рассчитывали.
При увеличении проекта конструирование требует все меньшей
доли общих затрат. Если вы основываете свои расчеты только на
опыте конструирования, оценочная ошибка растет. Если вы
использовали свой опыт написания 2К строк для оценки времени,
необходимого для разработки программы длиной 32К, ваша оценка
будет включать только 50% от необходимого времени; весь
процесс разработки может занять на 100% больше времени, чем вы
предполагали.
Ошибку в оценке можно полностью приписать вашему непониманию
влияния размера на разработку больших программ. Кроме того,
если вы не учли дополнительных усилий по наведению лоска, в
отличие от простой программы оценочная ошибка может легко
увеличиться в три или более раз.
Методология и размер
Методология используется в проектах любых размеров. В
маленьких проектах методология скорее случайна и инстинктивна
- в больших она скрупулезна и тщательно спланирована.
Порой методология бывает столь неопределенной, что
программисты даже не подозревают, что ее используют. Некоторые
программисты доказывают, что методология лишена гибкости,
поэтому они не будут ее использовать. Хотя они могут не
использовать методологию сознательно, любой подход к
программированию состоит из методологии независимо от простоты
этого подхода. Обычный утренний подъем и поездка на работу
являются рудиментарной методологией, хотя и не слишком
вдохновляющей. Программисты, отказывающиеся использовать
методологию, на самом деле просто не используют ее явно - куда
от нее денешься!
Формальный подход не всегда доставляет удовольствие, а если он
применяется неправильно, накладные расходы могут поглотить
получаемые от него преимущества. Однако возрастающая сложность
больших проектов требует более осознанного отношения к
методологии. Строить небоскреб и собачью будку нужно по-
разному. То же относится и к программным проектам разных
размеров. В больших проектах случайный выбор методологии не
соответствует задаче. Успешные проектировщики выбирают
стратегии для больших проектов осознанно.
В светском обществе чем формальней событие, тем более
неудобную одежду нужно надевать (высокие каблуки, галстуки и
т. д.). В разработке ПО чем формальней проект, тем больше
бумажных документов необходимо создать, чтобы убедиться, что
вы выполнили ваше домашнее задание. Кей- перс Джонс указывает,
что в проекте длиной в 1000 строк примерно 7% затрат
приходится на бумажную работу, тогда как в проекте в 100 000
строк затраты на бумажную работу увеличиваются в среднем до
26% (Jones, 1998).
Эта работа проводится не из чистой любви к писанине. Она
является прямым результатом интересного феномена: чем больше
человек вам приходится координировать, тем больше требуется
документов (рис. 27-1).
ГЛАВА 27 Как размер программы влияет на конструирование
643
Вы не создаете эти документы ради самого факта их
существования. Смысл написания плана управления конфигурацией,
например, не в том, чтобы потренировать пальцы рук, но в том,
чтобы заставить вас тщательно продумать управление кон-
Предыдущая << 1 .. 306 307 308 309 310 311 < 312 > 313 314 315 316 317 318 .. 426 >> Следующая