Форма входа
0/0
Программист-прагматик. Путь от подмастерья к мастеру - Эндрю Хант
- Дата:19.06.2024
- Категория: Компьютеры и Интернет / Программирование
- Название: Программист-прагматик. Путь от подмастерья к мастеру
- Автор: Эндрю Хант
- Просмотров:3
- Комментариев:0
Уважаемые читатели!
Тут можно читать бесплатно Программист-прагматик. Путь от подмастерья к мастеру - Эндрю Хант. Жанр: Программирование. Так же Вы можете читать полную версию (весь текст) онлайн книги без регистрации и SMS на сайте Knigi-online.info (книги онлайн) или прочесть краткое содержание, описание, предисловие (аннотацию) от автора и ознакомиться с отзывами (комментариями) о произведении.
Описание онлайн-книги Программист-прагматик. Путь от подмастерья к мастеру - Эндрю Хант:
Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.
Читем онлайн Программист-прагматик. Путь от подмастерья к мастеру - Эндрю Хант
Шрифт:
-
+
Интервал:
-
+
Закладка:
Сделать
Мы не выступаем против функций-мастеров. Напротив, их созданию в книге посвящен целый раздел "Генераторы исходных текстов". Но если вы все же используете функцию-мастера и не понимаете всей создаваемой ею программы, то не сможете управлять вашим собственным приложением. Вы не сможете сопровождать его и будете затрачивать неимоверные усилия при отладке.
Подсказка 50: Не пользуйтесь программой функции-мастера, которую не понимаете
Некоторые полагают, что это совсем уж экстремистская позиция. Они говорят, что разработчики всегда основывают свою работу на предметах, которые до конца им непонятны, – на квантовой механике в интегральных схемах, схеме прерываний в процессоре, алгоритмах, используемых при диспетчеризации процессов, программах из имеющихся библиотек и т. д. Мы согласны. И мы придерживались бы того же мнения о функциях-мастерах, если бы они представляли собой просто набор библиотечных вызовов или стандартные службы операционной системы, на которые могли положиться разработчики. Но это не так. Функции-мастера генерируют программу, которая становится неотъемлемой частью приложения, написанного разработчиком Джо. Сгенерированная программа не выносится за скобки, прячась за опрятным интерфейсом, она переплетена, строчка за строчкой, с теми функциональными возможностями, которые созданы самим Джо [40]. В конечном итоге она перестает быть программой функции-мастера и становится программой самого Джо. Никто не должен генерировать программу, не понимая ее до конца.
Другие разделы, относящиеся к данной теме:• Ортогональность
• Генераторы исходных текстов
Вопросы для обсуждения• Если в вашем распоряжении имеется функция-мастер построения графического интерфейса, воспользуйтесь ей для генерирования «скелета» приложения. Внимательно изучите каждую строку сгенерированной программы. Всели в ней вам понятно? Могли бы написать ее сами? Лучше написать ее самому, или же она делает то, что вам не нужно?
Глава 7
Перед тем, как начать проект
У вас никогда не возникало ощущения, что ваш проект обречен еще до его начала? Иногда так и происходит, если вначале вы не установите некоторые основополагающие правила. В противном случае вы можете объявить проект закрытым и сэкономить спонсору некоторую сумму.
В самом начале проекта вам придется определить требования. Недостаточно лишь выслушать пользователей, необходимо прочесть раздел "Карьер для добычи требований".
Житейская мудрость и управление сдерживающими факторами являются основными темами раздела "Разгадка невероятных головоломок". Неважно, какую операцию вы осуществляете – анализ, составление текста программы или тестирование, проблемы возникают все равно. Чаще они не будут настолько сложными, какими показались вначале.
Даже когда вы подумаете, что решили все проблемы, то все равно будете чувствовать неудобства, начав работать над проектом. Является ли это простым промедлением или чем-то большим? В разделе "Пока вы не готовы" предлагается совет – в какой момент благоразумно прислушаться к предостережению внутреннего голоса.
Слишком раннее начало – это проблема, но слишком долгое ожидание еще хуже. В разделе "Западня со стороны требований" обсуждаются преимущества создания спецификаций по образцу.
В разделе "Круги и стрелки" рассматриваются некоторые ловушки, в которые можно попасть при использовании формальных процессов и методологий. Неважно, насколько хорошо он продуман, и какие "лучшие случаи из практики" в нем использованы, – никакой метод не заменит мышления.
Если вы устраните эти критические аспекты до того, как проект будет запущен, вы лучше справитесь с "аналитическим параличом" и начнете выполнять реальный успешный проект.
36
Карьер для добычи требований
Совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять.
Антуан де Сент-Экзюпери, Ветер, песок и звезды, 1939Многие книги и учебные пособия относят процедуру сбора исходных требований к начальной фазе проекта. Термин «сбор» напоминает о племени счастливых аналитиков, занимающихся собирательством камней-самородков мудрости, разбросанных по земле на фоне приглушенного звучания "Пасторальной симфонии". Этот термин напоминает о том, что все требования уже имеются в наличии, нужно лишь отыскать их, положить в корзину и весело шагать дальше.
Это не совсем так. Требования редко лежат на поверхности. Обычно они находятся глубоко под толщей предположений, неверных представлений и политики.
Подсказка 51: Не собирайте требования – выискивайте их
В поисках требований
Как распознать истинное требование, пробиваясь к нему сквозь толшу грязевых наносов? Ответ на этот вопрос и прост, и сложен одновременно.
Простой ответ состоит в том, что требование формулирует необходимость осуществления чего-либо. Грамотно составленное требование выглядит следующим образом:
• Доступ к личному делу сотрудника ограничен группой уполномоченных на то лиц.
• Температура головки блока цилиндров не должна превышать определенного критического значения, зависящего от марки двигателя.
• Редактор выделяет ключевые слова, выбор которых зависит от типа редактируемого файла.
Однако подобной четкостью могут похвастаться лишь немногие требования, что и делает их анализ весьма сложной задачей.
Первая формулировка в списке, приведенном выше, вероятно, была составлена пользователями следующим образом: "Доступ к личному делу сотрудника ограничен его руководителями и работниками отдела кадров". Является ли эта формулировка требованием? Возможно, что сегодня и является, но она воплощает бизнес-политику в абсолютной формулировке. Политика же регулярно меняется, поэтому, скорее всего, мы не захотим жестко встраивать ее в наши требования. Мы рекомендуем документировать положения политики отдельно от требований и связывать их посредством гиперссылки. Сделайте требование общей формулировкой и снабдите разработчиков информацией о политике в качестве примера того, что им придется поддерживать в реализации. В конечном счете политика конечна, как и метаданные в приложении.
Это весьма тонкое различие, но именно оно окажет серьезное воздействие на разработчиков. Если требование сформулировано как "Доступ к личному делу сотрудника ограничен персоналом фирмы", то разработчик может прекратить составление программы проверки на том месте, где приложение обращается к этим файлам. Однако если эта формулировка звучит как "Доступ к личному делу сотрудника ограничен уполномоченными на то пользователями", то разработчик, по всей вероятности, спроектирует и реализует нечто вроде системы управления доступом. При изменении политики (а оно обязательно произойдет) потребуется лишь обновление метаданных системы. На самом деле подобный метод сбора требований приведет к созданию системы, четко структурированной для поддержки метаданных.
Различия между требованиями, политикой и реализацией могут быть весьма размытыми, если речь идет о пользовательских интерфейсах. Слова "Система должна давать возможность выбора срока предоставления ссуды" представляют собой формулировку требования. Выражение "Для выбора срока предоставления ссуды необходимо окно списка" может являться формулировкой, а может таковой и не являться. Если пользователям позарез нужно окно списка, то в этом случае речь идет о требовании. Если же вместо этого они описывают свою способность выбирать, используя окно списка лишь в качестве примера, то здесь говорится не о требовании. Врезка ниже "Когда интерфейс становится системой" описывает проект, который пошел совсем не в ту сторону, поскольку потребности пользователей в интерфейсе были проигнорированы.
Важно обнаружить основополагающую причину того, почему пользователи поступают определенным образом, а не так, как они привыкли это делать. В конечном итоге разрабатываемой программе придется решать проблемы их бизнеса, а не просто отвечать их заявленным требованиям. Документируя причины, по которым были выдвинуты требования, команда разработчиков получит бесценную информацию, необходимую для принятия ежедневных решений, связанных с реализацией.
Существует простая методика: чтобы взглянуть изнутри на требования (которые часто являются весьма недостаточными) ваших пользователей, нужно самому стать пользователем. Пишете систему для службы поддержки? Посидите пару дней на телефоне вместе с опытным сотрудником этой службы. Занимаетесь автоматизацией ручной системы управления складскими запасами? Поработайте на складе с неделю [41]. Вы получите представление о реальном использовании системы и вдобавок будете просто поражены тем, насколько просьба "Можно я посижу рядом с вами недельку и посмотрю, как вы работаете?" способствует доверию и закладывает основы ваших взаимоотношений с пользователями. Но не путайтесь у них под ногами!
На этой странице вы можете бесплатно читать книгу Программист-прагматик. Путь от подмастерья к мастеру - Эндрю Хант бесплатно.
Похожие на Программист-прагматик. Путь от подмастерья к мастеру - Эндрю Хант книги
- Аквариум. (Новое издание, исправленное и переработанное) - Виктор Суворов (Резун) - Шпионский детектив
- Цифровой журнал «Компьютерра» № 184 - Коллектив Авторов - Прочая околокомпьтерная литература
- Искусство снайпера - Алексей Потапов - О войне
- Древний рим — история и повседневность - Георгий Кнабе - История
- Магазин волшебных украшений - Наталия Владимировна Полянская - Любовно-фантастические романы
