Дж.Ханк Рейнвотер - Как пасти котов. Наставление для программистов, руководящих другими программистами

Перевод на русский язык: http://www.ozon.ru/context/detail/id/2446031/ (прим. сост. FB2)

Ряд предложений касательно программных продуктов, помогающих составлять для программистов перечни задач, содержится в главе 4. Но не торопитесь переходить к этому материалу – иначе пропустите все мои подготовительные пассажи о том, в какую путаницу вы рискуете попасть, если не призовете на помощь инструменты электронной организации рабочего процесса.

DeMarco and Lister, op. cit., p. 56.

Watts S. Humphrey, Managing the Software Process (New York: Addison-Wesley, 1989), p. 93.

Вспомните, что говорил Йода: «Сила Джедая есть результат его собственных усилий». У нас то же самое.

Robert L. Glass, Software Runaways (Upper Saddle River, NJ: Prentice Hall, 1998), p. 20.

См. также Robert L. Glass, ComputingFailure.com (Upper Saddle River, NJ: Prentice Hall, 2001).

Это лишь немногие грехи. Существует множество альтернативных перечней. Добротный пример см. в издании William Н. Brown ctal, AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (New York: John Wiley & Sons, 1998).

Gerald М. Weinberg, The Psychology of Computer Programming: Silver Anniversary Edition (New York: Dorset House Publishing, 1998), p. 5.

Достойные тесты оценки личности есть на сайте http://www.advisortcam.com.

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

Pete McBreen, Software Craftsmanship (New York: Addison-Wesley, 2001), p. 61.

Я просмотрел несколько изданий по бизнесу и кое-какие из них мне понравились. В частности, возьмите на заметку издание Ronni Eiscnberg. Organize Your Office (Hyperion, 1998).

Имеются в виду не логические, а физические звенья.

Я пробовал структурировать электронного администратора в качестве веб-приложения, но такая схема не подходит моим программистам. Я их не виню; в конце концов, я должен давать задания, а они – выполнять их. Кроме того, мне не нравится ограниченность веб-интерфейса.

Присутствие этой записи подразумевает наличие документации относительно области действия, в которой характеристики конструируемого продукта представлены в виде нумерованного списка.

Richard Carlson, Don't Sweat the Small Stuff at Work (New York: Hyperion, 1998), p. 74.

Larry L. Constantino, Beyond Chaos: The Expert Edge in Managing Software Development (New York: Addison-Wesley, 2001), p. 4.

William Н. Brown et al, AntiPatterns in Project Management (New York: John Wiley & Sons, 2000), p. xxi.

Thomas Merton, No Man Is an Island (New York: Harcourt Brace Jovanovich, 1955), p. 117.

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

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

Я отнюдь не утверждаю, что все программисты социально пассивны, – мы просто, скажем так, особенные, и именно в этом кроется наша индивидуальность и благодаря этому мы способны проводить долгие часы в умственном напряжении, размышляя о том, как решить поставленные программные задачи.

Мне очень понравилась фраза, которую в фильме «Crimson Tide» Джин Хэкман сказал Дэнзелу Вашингтону: «Мы должны не заниматься демократией, а оберегать ее». Аналогичным образом, проводя проектное совещание, лучше воздерживаться от реверансов в пользу той или иной обсуждаемой идеи – как бы красноречиво ее ни защищали приверженцы. Ваша цель заключается в том, чтобы поощрять активный и плодотворный мыслительный процесс.

Larry L. Constantine, The Pcoplewarc Papers (Upper Saddle River, NJ: Yourdon Press, 2001), p. 10.

Norman L. Kerth, Project Retrospectives (New York: Dorset House Publishing, 2001), p. 7.

И строительство, и конструирование выражаются в английском языке одним словом – construction. Поэтому нам при переводе пришлось в меру сил лавировать между этими двумя значениями. Таким вот печальным образом гипертрофированная метафоричность автора разбивается об языковой барьер. – Примеч. перев.

Andrew Hunt and David Thomas, The Pragmatic Programmer (New York: Addison-Wesley, 2000), p. 184.

Перевод на русский язык: http://www.ozon.ru/context/detail/id/1657382/ (прим. сост. FB2)

Рекомендую в этом контексте ознакомиться с работами апологетов позитивных и негативных эталонов, например с трудами Брауна (Вroun) и других исследователей, чьи публикации перечислены в библиографии.

Marc Т. Sewell and Laura М. Sewell, The Software Architect's Profession (Upper Saddle River, NJ: Prentice Hall, 2002), p. 68.

Raphael С. Malvcau and Thomas Mowbray, Software Architect Bootcamp (Upper Saddle River, NJ: Prentice Hall, 2001).

Как просто, оказывается, вернуться к привычной терминологии! Если бы я сказал «…в выращивании применяются старые технологии…», смогли бы вы понять, о чем я говорю?

Ах, какой я молодец, что подобрал анатомическую метафору!

Лично я пользуюсь VB, начиная с версии 1.0, поэтому никаких предрассудков против этого языка не питаю. Всем интересующимся проблемами создания архитектуры и проектирования средствами VB рекомендую ознакомиться с работой Billy S. Hollis, Visual Basic 6 Design, Specification and Objects (Upper Saddle River, NJ: Prentice Hall, 1999).

Stuart Kauffman, At Home in the Universe (New York: Oxford University Press, 1995), p. 179.

James A. Highsmith III, Adaptive Software Development (New York: Dorset House Publishing, 2000), p. 40.

«Стандарты программирования» – выражение многозначное. Диапазон его значений простирается от инструкции по написанию качественной процедуры до утверждения единственной точки выхода из подпрограммы. Список этот можно продолжать бесконечно. Объединяющий принцип прост – заведите стандарт и придерживайтесь его.

Что такое кошмар для программиста? Это когда он вынужден не спать всю ночь, исправляя код, в котором, внеся одно исправление в одном объекте, получает изменение в трех местах другого объекта.

T.S. Elliot, Collected Poems 1909–1962 (New York: Harcourt Brace Jovanovich, 1971), p. 82.

См. Humphrey, op. cit., p. 5.

Capers Jones, Applied Software Measurement (New York: McGraw-Hill, 1991), p. 1.

Специалистам по VB я рекомендую труд James D. Foxall, Practical Standards for Microsoft Visual Basic (Redmond, WA: Microsoft Press, 2000). Что касается других языков, выбор литературы обширен; взять хотя бы классическое издание по С – Steve Maguire, Writing Solid Code (Redmond, WA: Microsoft Press, 1993). Дополнительную литературу см. в библиографии.