Руководство по стилю программирования и конструированию по
 Скачать 7.6 Mb.
|
|
ГЛАВА 28 Управление конструированием 665 ковые корпоративные кампусы, органичные организационные структуры, комфор- табельные офисы и прочие удобства, чтобы компенсировать интенсивную, а по- рой и скучную интеллектуальность самой работы. Наиболее успешные компании сочетают элементы высоких технологий и бережного отношения к людям (Naisbitt, 1982). В этом разделе программисты рассматриваются как нечто большее, чем орга- ническое отражение их силиконовых alter ego. Как программисты проводят свое время? Программисты большую часть рабочего времени программируют, но, кроме того, они тратят его на заседания, обучение, чтение почты и просто размышления. Исследование, проведенное в 1964 году в Bell Laboratories, показало, что програм- мисты тратят время так (табл. 28-3): Table 28-3. Одно из представлений того, как программисты тратят свое время Почта Техни- Обслужива- Исход- и др. ческие ющие Тестиро- Деятель- ный Деловые Личные Засе- доку- руко- процедуры, вание ность Код вопросы дела дания Обучение менты водства Разное программИтого Говорят 4% 17% 7% 3% 1% 32% или слушают Говорят 1% 1% с менед- жером Говорят по 2% 1% 3% телефону Читают 14% 2% 2% 18% Пишут 13% 1% 14% Отсутст- 4% 1% 4% 6% 15% вуют Гуляют 2% 2% 1% 1% 6% Разное 2% 3% 3% 1% 1% 1% 11% Итого 35% 29% 13% 7% 6% 5% 2% 2% 1% 100% Источник: «Research Studies of Programmers and Programming» (Bairdain, 1964, приведе- но в Boehm, 1981). Эти данные основаны на изучении времяпрепровождения 70 программистов. Данные старые, и пропорции времени, которое тратится на различные виды де- ятельности, у разных программистов будут иными. И все же результаты наводят на размышления. Около 30% времени тратится на нетехнические виды деятель- ности: прогулки, личные вопросы и т. д. Программисты в этом исследовании тра- тят 6% времени на прогулки — это примерно 2,5 часа в неделю и 125 часов в год. Это может показаться несущественным, пока вы не поймете, что программисты каждый год тратят на прогулки столько же времени, сколько на обучение, втрое больше, чем на чтение технической документации, и в шесть раз больше, чем ний этого показателя за прошедшие годы. 666 ЧАСТЬ VI Системные вопросы Различия в производительности и качестве Способности и прилагаемые усилия у разных программистов очень раз- ные, как, впрочем, и в других сферах человеческой деятельности. Иссле- дования показали, что в различных профессиях (писательство, футбол, изобретательство, полицейская работа и пилотирование самолетов) первые 20% людей производят примерно 50% результатов (Augustine, 1979). Выводы этого ис- следования базируются на анализе данных производительности, таких как заби- тые голы, патенты, решенные задачи и т. д. Так как некоторые люди вообще не вносят никакого вклада и они не учитывались в исследовании (защитники, не забивающие голы, изобретатели, не имеющие собственных патентов, детективы, не раскрывавшие преступлений, и т. д.), то данные, возможно, преуменьшают фак- тическую разницу в производительности. Конкретно в программировании многие исследования показывают разницу на порядки в качестве написанных программ, их размерах и в производительности программистов. Индивидуальные различия Первоначальное исследование, показавшее огромные различия в произ- водительности отдельных программистов, было проведено в конце 1960-х Секменом, Эриксоном и Грантом (Sackman, Erikson, Grant, 1968). Они изучали профессиональных программистов с примерно 7-летним стажем и вы- яснили, что соотношение первоначального времени кодирования между лучшим и худшим программистами — примерно 20:1, соотношение времени отладки — более, чем 25:1, соотношение размера программы — 5:1, а соотношение скорос- ти выполнения — 10:1.Они не нашли взаимосвязи между опытом программиста и качеством кода или производительностью. Хотя такие определенные значения соотношений, как 25:1, не имеют особого смысла, более общие утверждения, скажем: «Программисты раз- личаются между собой на порядки,» — достаточно содержательны и под- тверждаются другими исследованиями профессиональных программистов (Curtis, 1981; Mills, 1983; DeMarco and Lister, 1985; Curtis et al., 1986; Card, 1987; Boehm and Papaccio, 1988; Valett and McGarry, 1989; Boehm et al., 2000). Командные различия Команды программистов также показывают заметные различия в качестве ПО и производительности. Хорошие программисты стремятся к объединению, так же как и плохие программисты. Это наблюдение подтверждается исследованием 166 профессиональных программистов из 18 организаций (Demarco and Lister, 1999). В одном исследовании семи идентичных проектов потраченные усилия различались в 3,4 раза, а размеры программ — в 3 раза (Boehm, Gray and Seewaldt, 1984). Несмотря на такую разницу в производительности, про- граммистов в этом исследовании нельзя отнести к разным группам. Все они были профессионалами с несколькими годами стажа, окончившими учебные заведения по специальности, связанной с вычислительной техникой. Можно предположить, что исследование менее гомогенной группы показало бы еще большие различия. ГЛАВА 28 Управление конструированием 667 Более раннее исследование программистских команд показывало соотношение 5:1 в размерах программ и 2,6:1 во времени, необходимом команде для заверше- ния одного и того же проекта (Weinberg and Schulman, 1974). После обработки данных, полученных более чем за 20 лет, для разработки оценочной модели Cocomo II, Барри Бом и другие исследователи при- шли к выводу, что разработка программы с участием первых 15% про- граммистов, отсортированных по способностям, обычно требует примерно в 3,5 раз больше человеко-месяцев, чем разработка программы с участием 90% програм- мистов (Boehm et al., 2000). Бом и другие исследователи выяснили, что 80% рабо- ты выполняют 20% сотрудников (Boehm, 1987b). Выводы, с точки зрения найма персонала, очевидны. Если вам приходится пла- тить больше, чтобы заполучить программиста из первых 10%, а не программиста из последних 10%, не упускайте этот шанс. Вы получите мгновенное вознаграж- дение в качестве и производительности нанятого вами программиста, а кроме того, вы получите остаточный эффект в качестве и производительности остальных программистов, которых ваша организация может нанять, так как хорошие про- граммисты стремятся к объединению. Вопросы религии Менеджеры программных проектов не всегда осознают, что некоторые аспекты программирования сродни религиозным вопросам. Если вы менеджер и пытаетесь требовать исполнения определенных правил программирования, вы рискуете вы- звать гнев ваших подопечных. Вот список таких «религиозных» вопросов: 쐽 язык программирования; 쐽 стиль отступов; 쐽 размещение скобок; 쐽 выбор среды разработки (IDE); 쐽 стиль комментариев; 쐽 компромиссы между эффективностью и читабельностью; 쐽 выбор методологии — например, между методом Scrum, экстремальным про- граммированием или эволюционной разработкой; 쐽 программные утилиты; 쐽 соглашения по именованию; 쐽 применение goto; 쐽 использование глобальных переменных; 쐽 измерения, особенно меры производительности, например, количество строк кода в день. Общий знаменатель у всех этих вопросов в том, что позиция программиста по каждому из них отражает его личный стиль. Если вы считаете, что должны контро- лировать программиста в каких-то из этих «религиозных» сфер, учтите следующее. Вы вторгаетесь в область, требующую деликатного обращения Разуз- найте мнения программистов по поводу каждого эмоционального вопроса, прежде чем окунуться в него с головой. 668 ЧАСТЬ VI Системные вопросы Из уважения к теме используйте термины «предложения» и «советы» Из- бегайте установки жестких «правил» и «стандартов». Старайтесь обходить спорные вопросы, предпочитая давать явные по- ручения В выборе стиля отступов или размещения скобок поможет такая хит- рость; потребуйте прогнать код через средства создания «красивой» печати, прежде чем объявлять его законченным. Пусть форматирование выполняется специаль- ными средствами. Чтобы решить вопрос со стилем комментариев, требуйте, что- бы весь код рецензировался и неочевидный код исправлялся до тех пор, пока не станет ясным. Предложите программистам выработать собственные стандарты Как я уже говорил, детали конкретного стандарта зачастую менее важны, чем факт са- мого существования стандарта. Не устанавливайте стандарты вашим программис- там, но настаивайте на том, чтобы они стандартизовали области, важные для вас. Какие из «религиозных» тем настолько важны, чтобы из-за них ввязываться в спор? Подчинение в небольших вопросах стиля в любой области, возможно, не прине- сет особой выгоды по сравнению с ухудшением моральной атмосферы в коман- де. Если вы встречаете беспорядочное использование операторов goto или гло- бальных переменных, нечитаемый стиль или другие признаки, влияющие на проект в целом, то для улучшения качества кода будьте готовы мириться с некоторыми разногласиями. Если ваши программисты добросовестны, это редко становится проблемой. Самые большие сражения обычно разворачиваются вокруг стилисти- ческих нюансов кодирования, и вы можете стоять в стороне от этого без всяких потерь для проекта. Физическая среда Проведите эксперимент: поезжайте за город, найдите ферму, отыщите фермера и спросите его, во что ему обошлось оборудование. Фермер посмотрит в амбар и увидит несколько тракторов, фургонов, зерновой комбайн, молотилку, и скажет, что сумма превышает $100 000 на работника. После этого найдите в городе фирму, занимающуюся разработкой ПО, отыщите менеджера и спросите его, каковы его затраты на оборудование. Менеджер загля- нет в офис, увидит стол, стул, несколько книг и компьютер и скажет, что они не превышают $25 000 на каждого работника. Физическая среда сильно влияет на производительность. Демарко и Листер (DeMarco and Lister) опросили 166 программистов из 35 организаций о качестве их физи- ческого окружения. Большинство работников оценило свои рабочие места как не- приемлемые. После проведения соревнования по программированию оказалось, что программисты, результаты которых попадают в первые 25%, имеют более про- сторные, тихие и уединенные кабинеты, а также реже отвлекаются на других людей и телефонные звонки. Вот сводка различий в офисном пространстве между луч- шими и худшими программистами: ГЛАВА 28 Управление конструированием 669 Фактор среды Первые 25% Последние 25% Офисная площадь 9 м 2 5 м 2 Достаточно тихое рабочее место 57% «да» 29% «да» Достаточно уединенное место 62% «да» 19% «да» Возможность выключить телефон 52% «да» 10% «да» Возможность переадресовать звонки 76% «да» 19% «да» Частые ненужные прерывания 38% «да» 76% «да» Рабочее место, позволяющее 57% «да» 29% «да» программистам чувствовать себя оцененным по достоинству Источник: «Peopleware» (DeMarco and Lister, 1999). Эти данные показывают сильную корреляцию между производительно- стью и качеством рабочего места. Программисты из первых 25% были в 2,6 раза производительнее, чем программисты из последних 25%. Де- марко и Листер подумали, что более квалифицированным программистам могли быть предоставлены лучшие условия в качестве поощрения, но дальнейшая про- верка показала, что это не так. Программисты из одной организации имели сходные удобства независимо от разницы в их производительности. Большие организации, нацеленные на разработку ПО, подтверждают эти данные. Xerox, TRW, IBM и Bell Labs отмечают, что они получили значительный прирост в производительности, увеличив инвестиции с $10 000 до $30 000 на одного сотруд- ника. Возросшая производительность неоднократно компенсировала эти затра- ты (Boehm, 1987a). По собственным оценкам рост производительности в таких «производительных офисах» составил от 39 до 47% (Boehm et al., 1984). Подводя итоги, можно сказать, что если ваше рабочее место попадает в худшие 25%, вы можете увеличить свою производительность примерно на 100%, улучшив его до соответствия первым 25%. Если у вашего рабочего места средние показа- тели, вы все еще можете получить 40%-е увеличение производительности, улуч- шив его качество до первых 25%. Дополнительные ресурсы, посвященные программистам как человеческим существам Weinberg, Gerald M. The Psychology of Computer Programming, 2d ed. New York, NY: Van Nostrand Reinhold, 1998. Это пер- вая книга, которая явно определяет программистов как лю- дей, и в ней лучше всего рассматривается программирование как человеческая деятельность. Она наполнена проницательными замечаниями о человеческой природе программистов и ее последствиях. DeMarco, Tom and Timothy Lister. Peopleware: Productive Projects and Teams, 2d ed. New York, NY: Dorset House, 1999. Как сказано в названии, эта книга также рассмат- ривает человеческий фактор в программировании. Она содержит множество анек- дотов о менеджерах, офисном окружении, найме и развитии нужных людей, уве- личении команд и любви к своей работе. Авторы переусердствовали с анекдота- ми для поддержки некоторых необычных точек зрения, и их логика порой не- http://cc2e.com/2806 670 ЧАСТЬ VI Системные вопросы убедительна, но важен душевный настрой книги, ставящий людей на первое мес- то, и авторам, несомненно, удалось донести свою мысль. McCue, Gerald M. «IBM’s Santa Teresa Laboratory — Architectural Design for Program Development», IBM Systems Journal 17, no. 1 (1978): 4–25. Маккью рассказывает о том, как в IBM со- здавали офисный комплекс в Санта Тереза. IBM изучила нужды программистов и разработала здания с учетом их пожеланий. Программисты принимали участие в проекте на всем его протяжении. Результат: в ежегодных опросах мнений комп- лекс в Санта Тереза оценивается в компании как лучший. McConnell, Steve. Professional Software Development. Boston, MA: Addison-Wesley, 2004. В главе 7 «Orphans Preferred» подводятся итоги демографических исследований в среде программистов, включая типы личностей, образование и перспективы работы. Carnegie, Dale. How to Win Friends and Influence People, Revised Edition. New York, NY: Pocket Books, 1981. Написав заголовок для первого издания этой книги в 1936 году, Дейл Карнеги не мог подозревать, какой скрытый смысл он приобретет се- годня. Он звучит так, как будто книга взята с полки самого Макиавелли. Однако дух книги диаметрально противоположен манипуляциям в стиле Макиавелли, и один из ключевых моментов говорит о важности развития неподдельного инте- реса к другим людям. Карнеги глубоко проникает в ежедневные взаимоотноше- ния и объясняет, как работать с другими людьми с помощью лучшего их понима- ния. Книга полна запоминающихся историй, иногда по две-три на страницу. Лю- бой, кто работает с людьми, должен когда-нибудь прочесть ее, а тот, кто управля- ет людьми, должен прочесть ее немедленно. 28.6. Управление менеджером В области разработки ПО часто встречаются как нетехнические менеджеры, так и такие, кто имеет технический опыт, но отстал от жизни лет на 10. Технически компетентные, технически современные менеджеры редки. Если вы работаете с таким, делайте все, чтобы сохранить свою работу. Это необычайное везение. Если ваш менеджер более типичен, вы сталкиваетесь с не- завидной задачей управления собственным менеджером. «Управление менеджером» означает, что вам нужно объяс- нить менеджеру, что надо делать, а не наоборот. Фокус в том, что это надо сделать так, чтобы он продолжал считать, что это он вами управляет. Вот несколько подходов к работе с вашим менеджером: 쐽 посейте идеи того, что вы хотите сделать, а затем дождитесь, пока вашего ме- неджера посетит мысль, что вам нужно делать именно то, что вы хотите; 쐽 просвещайте вашего менеджера, как делать правильно; это непрерывная рабо- та, потому что менеджеров часто повышают, переводят или увольняют; 쐽 сосредоточьтесь на интересах менеджера, делая то, что он или она действи- тельно от вас хочет, и не отвлекайте его внимание несущественными деталя- ми реализации (думайте об этом, как об «инкапсуляции» вашей работы); http://cc2e.com/2820 В иерархии каждый работник стремится подняться до своего уровня некомпетенции. Принцип Питера (The Peter Principle) ГЛАВА 28 Управление конструированием 671 쐽 откажитесь делать то, что говорит ваш менеджер, настаивайте на выполнении работы правильным образом; 쐽 найдите другую работу. Наилучшим долгосрочным решением будет попытка просветить вашего менеджера. Это не всегда легкая задача, но одним из способов подготовиться к ней будет чтение книги Дейла Карнеги «How to Win Friends and Influence People». Дополнительные ресурсы по управлению конструированием Следующие книги освещают общие вопросы управления программными проектами. Gilb, Tom. Principles of Software Engineering Management. Wokin- gham, England: Addison-Wesley, 1988. Гилб прокладывает собственный курс на про- тяжении 30 лет, и большую часть времени он обгоняет остальных независимо от того, отдают ли они себе в этом отчет. Эта книга — хороший тому пример. Она была одной из первых работ, в которых обсуждались эволюционные методики раз- работки, управление рисками и применение формальных проверок. Гилб хоро- шо осведомлен о наиболее передовых подходах; действительно, эта книга, опуб- ликованная более 15 лет назад, содержит большинство хороших методик, кото- рые преподносятся в настоящее время в качестве быстрой (agile) разработки. Гилб исключительно практичен, и его книга до сих пор является одной из лучших в сфере управления ПО. McConnell, Steve. Rapid Development. Redmond, WA: Microsoft Press, 1996. Эта книга охватывает вопросы руководства и управления проектами, на выполнение кото- рых остро не хватает времени, что, по моему опыту, относится к большинству про- ектов. Brooks, Frederick P., Jr. The Mythical Man-Month: Essays on Software Engineering, Anniver- sary Edition (2d ed). Reading, MA: Addison-Wesley, 1995. Эта книга — смесь метафор и фольклора, связанного с управлением программными проектами. Она увлека- тельна и может пролить свет на содержимое ваших собственных проектов. В ее основе лежит рассказ о трудностях, с которыми сталкивался Брукс при разработ- ке операционной системы OS/360, что позволяет мне сделать несколько замеча- ний. Она полна советов наподобие «Мы сделали так, и это не сработало» и «Нам следовало сделать вот так, потому что тогда бы это работало». Наблюдения Брук- са по поводу неудачных методик хорошо обоснованы, но его заявления, что дру- гие технологии были бы удачны, слишком гипотетичны. Читайте эту книгу кри- тически, чтобы отделять наблюдения от умозаключений. Это предупреждение не умаляет значимости книги. Ее до сих пор чаще других цитируют в компьютер- ной литературе, и, хотя впервые она была опубликована в 1975 году, до сих пор кажется актуальной. Ее сложно читать без того, чтобы не восклицать «Точно!» каждые пару страниц. Соответствующие стандарты IEEE Std 1058-1998, Standard for Software Project Management Plans. IEEE Std 12207-1997, Information Technology — Software Life Cycle Processes. http://cc2e.com/2813 |