Кент Бек - Экстремальное программирование
.pdf
Краткое содержание
О серии ХР |
|
|
|
12 |
Предисловие |
|
|
|
13 |
Введение |
|
|
|
15 |
Часть 1. Проблема |
|
|
||
Глава |
1. Риск: основная проблема |
24 |
||
Глава |
2. Эпизод из программистской практики |
28 |
||
Глава |
3. Экономика разработки программного обеспечения |
32 |
||
Глава |
4. |
Четыре переменные |
36 |
|
Глава |
5. Стоимость внесения изменений |
43 |
||
Глава |
6. Обучение управлению автомобилем |
49 |
||
Глава |
7. Четыре ценности |
5 |
||
Глава |
8. Базовые принципы |
60 |
||
Глава |
9. Обратно к истокам |
68 |
||
Часть 2. Решение |
|
|
|
|
Глава 10. Краткий обзор |
7 |
|||
Глава |
11. |
Как это работает? |
89 |
|
Глава 12. Стратегия менеджмента |
97 |
|||
Глава 13. Стратегия организации рабочего места |
104 |
|||
Глава 14. Разделение полномочий между технарями и бизнесменами |
109 |
|||
Глава |
15. Стратегия |
планирования |
114 |
|
Глава |
16. |
Стратегия |
разработки |
127 |
Глава 17. |
Стратегия проектирования |
134 |
||
Глава |
18. |
Стратегия |
тестирования |
147 |
Часть 3. Реализация ХР |
|
|
||
Глава |
19. Внедрение ХР |
154 |
||
Глава 20. Адаптация ХР для существующего проекта |
156 |
|||
Глава 21. Жизненный цикл идеального ХР-проекта |
162 |
|||
Глава 22. Роли для людей |
171 |
|||
Глава 23. Правило 20 на 80 |
182 |
|||
Глава 24. Что делает ХР сложной? |
184 |
|||
Глава 25. Когда не следует использовать ХР |
189 |
|||
Глава 26. ХР в работе |
19 |
|||
Глава 27. Заключение |
20 |
|||
Аннотированная |
библиография |
|
20 |
|
Словарь терминов |
|
|
|
|
Алфавитный указатель |
|
2 |
||
Содержание
О серии ХР Предисловие Введение
Данная книга |
|
16 |
|
Что такое ХР? |
". |
|
|
Достаточность |
|
19 |
|
План книги |
|
20 |
|
Благодарности |
|
|
|
От издательства |
|
|
|
Часть 1. Проблема |
|
|
|
Глава 1. |
Риск: основная проблема |
|
24 |
Наша цель |
|
27 |
|
Глава 2. Эпизод из программистской практики |
28 |
||
Глава 3. |
Экономика разработки программного обеспечения |
32 |
|
Варианты |
|
33 |
|
Пример |
|
3 |
|
Глава 4. |
Четыре переменные |
|
36 |
Взаимосвязь между переменными |
|
37 |
|
Фокус на объеме работ |
|
40 |
|
Глава 5. |
Стоимость внесения изменений |
|
43 |
Глава 6. |
Обучение управлению автомобилем |
49 |
|
Глава 7. |
Четыре ценности |
|
52 |
Коммуникация |
|
52 |
|
Простота |
|
53 |
|
|
|
Содержание 7 |
Обратная связь |
54 |
|
Храбрость |
56 |
|
Ценности на практике |
58 |
|
Глава 8. |
Базовые принципы |
60 |
Глава 9. |
Обратно к истокам |
68 |
Кодирование |
69 |
|
Тестирование |
70 |
|
Слушание |
73 |
|
Проектирование |
74 |
|
Заключение |
75 |
|
Часть 2. Решение |
|
|
Глава 10. |
Краткий обзор |
78 |
Игра в планирование |
80 |
|
Небольшие версии |
81 |
|
Метафора |
82 |
|
Простой дизайн |
82 |
|
Тестирование |
83 |
|
Переработка |
84 |
|
Программирование парами |
84 |
|
Коллективное владение |
85 |
|
Постоянно продолжающаяся интеграция |
86 |
|
40-часовая рабочая неделя |
86 |
|
Заказчик на месте разработки |
87 |
|
Стандарты кодирования |
88 |
|
Глава 11. |
Как это работает? |
89 |
Игра в планирование |
90 |
|
Небольшие версии |
90 |
|
Метафора |
91 |
|
Простой дизайн |
91 |
|
Тестирование |
92 |
|
Переработка кода |
92 |
|
Программирование в парах |
93 |
|
Коллективное владение |
94 |
|
Постоянно продолжающаяся интеграция |
94 |
|
40-часовая рабочая неделя |
95 |
|
Заказчик на месте разработки |
95 |
|
Стандарты кодирования |
96 |
|
Заключение |
96 |
|
Предисловие
Экстремальное программирование (eXtreme Programming, XP) определяет кодирование как ключевую и основополагающую деятельность при работе над программным проектом. Возможно, что это неправильно!
Думаю, что стоит вспомнить о моем собственном опыте разработки программного обеспечения. Я работаю в среде, где разрабатываемый продукт постоянно находится в работоспособном состоянии, и при этом в него постоянно вносятся изменения. Сроки выпуска очередной работоспособной версии чудовищно сжаты, и при этом над всем этим нависает огромный технический риск. В подобной среде способность поправить своего соратника — это искусство, без которого не выжить. Обмен информацией как внутри некоторой команды, так и между несколькими командами, которые часто разделены географически, выполняется при помощи кода. Мы читаем код для того, чтобы понять устройство новых или модифицированных программных интерфейсов системы. Жизненный цикл и поведение сложных объектов определяются с использованием тестовых случаев, то есть снова при помощи кода. Сообщения о возникающих проблемах сопровождаются тестовыми случаями, демонстрирующими проблему, для этого опять используется код. Наконец, мы постоянно заняты улучшением существующего кода, делая его более производительным, более гибким, более понятным. Очевидно, что в подобных условиях разработка программного продукта почти целиком основана на кодировании, однако при этом нам удается с успехом завершать проекты к сроку, таким образом, данный подход вполне жизнеспособен.
Не следует делать вывод, что все, что вам потребуется для успешной реализации программного проекта, — это безоглядное ожесточенное программирование. Разрабатывать программное обеспечение очень непросто, а разрабатывать качественное программное обеспечение и при этом завершать работу в срок — еще сложнее. Чтобы описанный мною подход сработал, необходимо последовательное применение важных дополнительных правил и методик. Именно с этого Кент Бек (Kent Beck) начинает свою побуждающую к размышлениям книгу об ХР.
Кент был среди тех руководителей компании Tektronix, которые осознали огромный потенциал, заложенный в методике программирования в связанных парах при разработке сложных инженерных приложений