Совершенный код. Совершенный код. Мастер-класс. Стив Макконнелл. Руководство по стилю программирования и конструированию по
 Скачать 5.88 Mb.
|
|
ГЛАВА 32 Самодокументирующийся код 799 Управляющие структуры Комментируете ли вы каждый управляющий оператор? Комментируете ли вы концы длинных или сложных управляющих структур или упрощаете ли вы эти структуры по мере возможности, чтобы они не требовали комментариев? Методы Комментируете ли вы назначение каждого метода? Указываете ли вы в комментариях к методам в случае надобности другую информацию, такую как входные и выходные данные, предположения об интерфейсе, ограничения, исправленные ошибки, глобальные эффекты и источники алгоритмов? Файлы, классы и программы Включает ли программа краткий документ, подобный документу Книжной па- радигмы, предоставляющий общую информацию об организации программы? Описали ли вы назначение каждого файла? Указали ли вы в листинге фамилию и имя автора, адрес электронной поч- ты и номер телефона? Ключевые моменты Вопрос о том, стоит ли комментировать код, вполне обоснован. При плохом выполнении комментирование является пустой тратой времени и иногда при# чиняет вред. При грамотном применении комментирование полезно. Основная часть критически важной информации о программе должна содер# жаться в исходном коде. На протяжении жизни программы актуальности ис# ходного кода уделяется больше внимания, чем актуальности любого другого ресурса, поэтому важную информацию полезно интегрировать в код. Хороший код сам является самой лучшей документацией. Если код настолько плох, что требует объемных комментариев, попытайтесь сначала улучшить его. Комментарии должны сообщать о коде что#то такое, что он не может сооб# щить сам — на уровне резюме или уровне цели. Некоторые стили комментирования заставляют выполнять много нудной кан# целярской работы. Используйте стиль, который было бы легко поддерживать. 800 ЧАСТЬ VII Мастерство программирования Г Л А В А 3 3 Личность Содержание 33.1. Причем тут личность? 33.2. Интеллект и скромность 33.3. Любопытство 33.4. Профессиональная честность 33.5. Общение и сотрудничество 33.6. Творчество и дисциплина 33.7. Лень 33.8. Свойства, которые менее важны, чем кажется 33.9. Привычки Связаные темы Мастерство разработки ПО: глава 34 Сложность: разделы 5.2 и 19.6 С момента публикации в 1965 году знаменитой статьи Эдсгера Дейкстры «Prog# ramming Considered as a Human Activity» («Программирование как человеческая деятельность») личности программистов привлекают самое пристальное внимание ученых. Названия книг «Психология конструирования мостов» и «Эксперименталь# ные исследования поведения юристов» могли бы показаться абсурдными, однако работы «Психология программирования» («The Psychology of Computer Program# ming»), «Экспериментальные исследования поведения программистов» («Exploratory Experiments in Programmer Behavior») и т. п. уже стали классическими. В какой бы области ни работали инженеры, они должны знать возможности при# меняемых инструментов и материалов. Инженеры#электрики знают проводимость разных металлов и сотни способов использования вольтметра. Инженерам#про# ектировщикам строительных конструкций известны параметры прочности дерева, бетона и стали. http://cc2e.com/3313 ГЛАВА 33 Личность 801 Если вы разрабатываете ПО, вашим основным строительным материалом являет# ся интеллект, а главным инструментом — вы сами. Вместо того чтобы спроекти# ровать структуру до последних деталей и передать чертежи конструкторам, вы проектируете фрагмент ПО до последних деталей, и на этом работа над ним за# вершается. По сути все программирование состоит в создании воздушных замков — это умственная деятельность почти что в самом чистом виде. Соответственно, когда разработчики ПО изучают существенные свойства своих инструментов и материалов, они изучают людей: интеллект, характер и другие атрибуты, не столь осязаемые, как дерево, бетон и сталь. Если вам нужны конкретные советы, эта глава может показаться вам чересчур абстрактной, чтобы быть полезной. Поэтому прочтите следующий раздел и ре# шите, следует ли ее пропустить. 33.1. Причем тут характер? Крайняя замкнутость программирования придает свойствам личности програм# миста особую значимость. Вы сами знаете, как сложно поддерживать сосредото# ченность на протяжении восьми часов рабочего дня. Наверное, вы можете вспом# нить день или месяц, прошедший впустую из#за чрезмерной концентрации в пре# дыдущий день или месяц. Наверняка бывали дни, когда вы продуктивно работали с 8 часов утра до 2 ночи, после чего чувствовали, что пора отдохнуть. Но вы про# должали работать до 5 часов утра и тратили остальные дни недели на исправле# ние того, что написали ночью. Программирование плохо поддается контролю особенно потому, что никто на са# мом деле не знает, над чем вы работаете. У всех нас были проекты, при реализации которых мы проводили 80% времени над небольшим фрагментом, казавшимся интересным и тратили 20% времени на создание остальных 80% программы. Ваш работодатель не может заставить вас стать хорошим программистом, а зача# стую он даже не может оценить, насколько хороши вы как программист. Если вы хотите стать отличным программистом, вы отвечаете за это сами. Это зависит от вашего характера. Как только вы решили стать отличным программистом, перед вами от# крываются широкие перспективы. Исследования показывают, что лучшие программисты создают программы в 10 раз быстрее, чем их менее ква# лифицированные коллеги. Время, уходящее на отладку кода, а также объем и бы# стродействие итоговой программы, уровень ошибок и число обнаруженных оши# бок также различаются примерно в 10 раз (Sackman, Erikson, and Grant, 1968; Curtis, 1981; Mills, 1983; DeMarco and Lister, 1985; Curtis et al., 1986; Card, 1987; Valett and McGarry, 1989). Вы ничего не сделаете со своим интеллектом, но вы можете изменить свой харак# тер — именно от характера зависит, станете ли вы превосходным программистом. 802 ЧАСТЬ VII Мастерство программирования 33.2. Интеллект и скромность Интеллект не кажется чертой характера и на самом деле не является им. Высочайший уровень интеллекта — далеко не главное условие для человека, желающего стать хорошим программистом. Что? Для этого не нужно быть суперинтеллектуальным? Нет, не нужно. Никто не обладает достаточным для програм# мирования уровнем интеллекта. Чтобы полностью охватить и понять сразу все детали даже средней программы, чело# век должен был бы обладать почти неограниченными воз# можностями. Способ использования интеллекта важнее, чем его уровень. Как было сказано в главе 5, лекцию, посвященную получению премии Тьюринга в 1972 году, Эдсгер Дейкстра назвал «The Humble Programmer» («Скромный про# граммист»). Дейкстра заявил, что большинство аспектов программирования являет собой попытки компенсации строго ограниченных способностей разума. Самые лучшие программисты — те, кто понимают, насколько ограничены их возможно# сти. Они скромны. Худшие программисты отказываются признать, что их способ# ности не соответствуют задаче. Характер не позволяет им стать отличными про# граммистами. Чем усерднее вы работаете над компенсацией ограниченных воз# можностей своего разума, тем лучше будете программировать. Быстрота вашего развития напрямую зависит от вашей скромности. Многие методики эффективного программирования призваны снизить нагрузку на мозг. Вот несколько примеров. Цель «декомпозиции» системы — сделать систему проще для понимания (см. подраздел «Уровни проектирования» раздела 5.2). Обзоры, инспекции и тестирование представляют собой способы компенса# ции ожидаемых человеческих оплошностей. Эти методики обзоров возникли как часть «обезличенного программирования» (Weinberg, 1998). Если бы мы никогда не совершали ошибок, нам не нужно было бы выполнять обзоры сво# его кода. Однако наши интеллектуальные способности ограничены, поэтому мы дополняем их способностями других людей. Ограничение объема методов снижает нагрузку на ум. Написание программ в терминах проблемной области, а не низкоуровневых деталей реализации, преследует ту же цель. Использование всевозможных конвенций освобождает разум от забот о баналь# ных аспектах программирования, не приносящих особой пользы. Возможно, вы думаете, что было бы благороднее развить умственные способнос# ти и отказаться от этих костылей. Возможно, вам кажется, что программист, ис# пользующий умственные костыли, идет окольными путями. Однако эмпирически было показано, что скромные программисты, компенсирующие свои недостатки, пишут более понятный код, содержащий меньше ошибок. Настоящий окольный путь — это путь ошибок и сорванных планов. Чтобы стать экспертом в прак- тической или научной области, нужны огромный труд и долгое время. Если человек добросове- стно трудится каждый час ра- бочего дня, когда-нибудь он проснется одним из самых ком- петентных специалистов своего поколения. Уильям Джеймс (William James) ГЛАВА 33 Личность 803 33.3. Любопытство Как только вы признали, что ваши способности слишком малы для понимания большинства программ, и поняли, что эффективное программирование — это поиск способов компенсировать данный недостаток, вы начинаете этот поиск, продолжающийся вплоть до окончания карьеры. А поэтому важная черта харак# тера программиста — любопытство к техническим вопросам. Релевантная техни# ческая информация постоянно изменяется. Многим Web#программистам никог# да не приходилось программировать для Microsoft Windows, а многие разработ# чики программ для Windows никогда не имели дела с DOS, UNIX или перфокар# тами. Специфические особенности технической среды изменяются каждые 5—10 лет. Если вы недостаточно любопытны для того, чтобы не отставать от измене# ний, вы рискуете разделить участь динозавров. Программисты часто так заняты работой, что у них не остается времени на изуче# ние более эффективных способов работы. Если это относится и к вам, вы не оди# ноки. Ниже я расскажу, как развить любопытство и сделать обучение приоритетом. Изучите процесс разработки Чем больше вы узнаете о процессе разработки ПО из книг или на собственном опы# те, тем лучше будете понимать изменения и тем эффектив# нее вести свою группу в правильном направлении. Если ваша работа состоит исключительно из краткосрочных заданий, не способ# ствующих развитию навыков, подумайте, как исправить эту ситуацию. Если вы работаете на конкурентном рынке ПО, половина ваших знаний устареет за три года. Без обучения вы превратитесь в ископаемое. Не тратьте время, работая на компанию, не учитывающую ваших инте# ресов. Несмотря на экономические подъемы и спады и перемещение некоторых рабочих мест в другие регионы, ожидается, что среднее чис# ло рабочих мест, связанных с программированием, за период с 2002 до 2012 года в США значительно увеличится. Ожидается, что число должностей системных ана# литиков вырастет примерно на 60%, а разработчиков ПО — примерно на 50%. Что касается всех должностей, связанных с компьютерами, то в дополнение к 3 мил# лионам имеющихся рабочих мест за это время будет создано еще около 1 милли# она мест (Hecker, 2001; BLS, 2004). Если работа не способствует вашему развитию, найдите другую работу. Экспериментируйте Экспериментирование с процессами программирования и разработки — эффективный способ самообразования. Если вы не знаете, как работает какая#то возможность языка, напишите небольшую программу и узнайте. Создайте прототип. Изучите выполнение програм# мы в отладчике. Гораздо лучше написать короткую програм# му для проверки какой#то возможности, чем создать большую программу, реализовав в ней возможность, которую вы не совсем понимаете. А если короткая программа показывает, что какая#то функция работает не так, как вы хотите? Этого#то вам и нужно! Лучше обнаружить это в небольшой програм# ме, чем в большой. Быстро совершая ошибки и извлекая из них уроки, вы облег# Перекрестная ссылка О важно- сти процесса разработки ПО см. раздел 34.2. Перекрестная ссылка Идея эк- спериментирования лежит в основе нескольких ключевых аспектов программирования (см. подраздел «Эксперименти- рование» раздела 34.9). 804 ЧАСТЬ VII Мастерство программирования чите себе путь к эффективному программированию. Ошибка — не грех. Неспо# собность к обучению на основе ошибок — вот что такое грех. Читайте о решении проблем Решение проблем — глав# ный аспект создания ПО. Эксперименты показали, что люди не всегда находят эффективные стратегии решения проблем сами, хотя легко обучаются этим стратегиям (Simon, 1996). Так что, даже если вы хотите изобрести колесо, успех не га# рантирован — ваше колесо может оказаться квадратным. Анализируйте и планируйте, прежде чем действовать Анализ и действие несколько противоречат друг другу. В какой#то момент вы должны прекратить сбор данных и начать действовать. Однако проблемой большинства программистов является не избыточный анализ. Как правило, чаша действия значительно пере# вешивает чашу анализа, и проблема «аналитического паралича» крайне редко угрожает программистам. Изучайте успешные проекты Особенно хороший спо# соб самообразования — изучение опыта лучших програм# мистов. Джон Бентли (Jon Bentley) считает, что вы должны иметь возможность сесть в кресло со стаканом бренди и сигарой и читать про# грамму, как хороший рассказ. Это не так неестественно, как кажется. Большин# ству людей не хотелось бы тратить свободное время на анализ 500#страничного листинга, но многим вполне понравилось бы изучить высокоуровневый проект кода и погрузиться в некоторые тонкости. При разработке ПО крайне редко используются данные о прошлых успехах и неудачах. Если бы вас интересовала архитектура, вы изучили бы чертежи Луиса Салливана, Фрэнка Ллойда Райта и других известных архитекторов. Возможно, вы посетили бы спроектированные ими здания. Если бы вас интересовало проекти# рование строительных конструкций, вы изучили бы мосты Brooklyn Bridge, Tacoma Narrows Bridge и другие структуры из бетона, стали и дерева. Вы изучили бы при# меры успехов и неудач в своей отрасли. Томас Кун указывает на то, что частью любой зрелой науки является набор удач# ных решений проблем, которые можно использовать в качестве образцов при последующей работе (Kuhn, 1996). Разработка ПО только начинает приближать# ся к этому уровню зрелости. В 1990 году организация Computer Science and Tech# nology Board пришла к выводу, что задокументированных исследований успехов и неудач в отрасли разработки ПО мало (CSTB, 1990). В журнале «Communications of the ACM» приводятся доводы в пользу обучения на основе исследований конкретных проблем программирования (Linn and Clancy, 1992). Это кое о чем говорит. То, что один из самых популярных разделов в компь# ютерных журналах — «Programming Pearls» — был создан на основе исследований конкретных случаев проблем программирования, также наводит на мысли. А одна из самых популярных книг по разработке ПО — «Мифический человеко# месяц» — основана на исследовании управления проектом разработки IBM OS/360. Имеется ли у вас книга, включающая исследования конкретных проблем програм# мирования, или нет, ищите код, написанный лучшими программистами, и читай# те его. Постарайтесь изучить код программистов, которых вы уважаете. Взгляни# Дополнительные сведения От- личный учебник по решению проблем — книга Джеймса Адамса «Conceptual Blockbus- ting» (Adams, 2001). http://cc2e.com/3320 ГЛАВА 33 Личность 805 те на код программистов, которых вы не уважаете. Сравните их варианты кода между собой и со своим собственным. Каковы различия? Почему код различает# ся? Какой вариант лучше? Почему? Не ограничивайтесь чтением кода других программистов — старайтесь также узнать, что эксперты думают о вашем коде. Найдите высококлассных программи# стов, которые согласились бы покритиковать ваш код. Слушая критику, игнори# руйте аспекты, связанные с их субъективными взглядами, и сосредоточьтесь на важных моментах. После этого измените свой подход к программированию так, чтобы он стал еще лучше. Читайте! У многих программистов документация вызывает страх. Очень часто она плохо написана и организована, и все же преодоление «документофобии» мо# жет принести большую пользу. Документация — это ключ к замку ПО, и ее чтение никогда не бывает пустой тратой времени. Игнорирование имеющейся информа# ции стало настолько частым явлением, что привело к возникновению специально# го акронима «RTFM!», который расшифровывается как «Read the !#*%*@ Manual!» Почти все современные языки дополняются огромным объемом библиотечного кода. Время, потраченное на изучение документации к библиотекам, будет хорошей инвестицией. Скорее всего компания, разработавшая данную версию языка, уже создала массу нужных вам классов. Если это так, приложите все усилия, чтобы оз# накомиться с ними. Просматривайте документацию примерно каждые два месяца. Читайте другие книги и периодические издания Похвалите себя за чтение этой книги. За это время вы про# двинулись вперед гораздо дальше, чем большинство ваших коллег, потому что объем этой книги превышает годичный объем чтения большинства программистов (DeMarco and Lister, 1999). Неторопливое, но регулярное чтение — надежный путь к высоким профессиональным достижениям. Если, читая примерно по 35 страниц в неде# лю, вы будете прочитывать одну хорошую книгу по программированию каждые два месяца, скоро вы получите основательный багаж знаний и начнете выгодно отличаться почти от всех окружающих вас разработчиков. Общайтесь с единомышленниками Познакомьтесь с другими людьми, стре# мящимися улучшить навыки разработки ПО. Посещайте конференции, вступите в группу пользователей, общайтесь на Интернет#форумах. Постоянно стремитесь к профессиональному разви' тию Хорошие программисты всегда ищут возможности дальнейшего совершенствования. Обдумайте следующую лестницу профессионального развития, используемую в моей и нескольких других компаниях. Уровень 1: начало Новичок — это программист, спо# собный использовать базовые возможности одного языка. Такой человек мо# жет писать классы, методы, циклы и условные операторы, а также использо# вать многие средства, поддерживаемые языком. Перекрестная ссылка Книги, которые следовало бы прочи- тать любому программисту, ука- заны в разделе 35.4. Дополнительные сведения Об уровнях развития программис- та см. главу 16 книги «Profes- sional Software Development» (McConnell, 2004). 806 ЧАСТЬ VII Мастерство программирования Уровень 2: средний уровень Программист среднего уровня прошел началь# ный этап, может использовать базовые возможности нескольких языков и очень хорошо владеет по меньшей мере одним языком. Уровень 3: компетентность Компетентный программист обладает экспер# тными знаниями языка, среды или того и другого. Программист этого уровня может знать все тонкости J2EE или помнить все аннотированное справочное руководство по C++. Такие программисты очень ценны для работодателей, и многие из программистов никогда не поднимаются выше этого уровня. Уровень 4: лидерство Лидер имеет квалификацию программиста 3#го уровня и понимает, что программирование на 85% состоит из общения с людьми и лишь на 15% — из общения с компьютером. Средний программист только 30% времени работает в одиночку (McCue, 1978) и еще меньше времени тратит на взаимодействие с компьютером. Гуру программирования пишут код для людей, а не для машин. Истинные гуру пишут абсолютно ясный код, не забывая при этом комментировать его. Они не хотят тратить свои драгоценные умствен# ные ресурсы на восстановление логики какого#то фрагмента кода, если ее можно было бы легко понять, прочитав краткий комментарий. Прекрасный программист, не уделяющий должного внимания удобочитаемости кода, вероятно, сможет достичь лишь уровня 3, да и то в самом лучшем случае. Судя по моему опыту, главная причина нечитабельности кода в том, что код плох. Никто не говорит себе: «Мой код плох, поэтому я сделаю его непонятным». Про# граммисты просто не понимают свой код достаточно хорошо, чтобы сделать его удобочитаемым, и это запирает их на одном из более низких уровней. Самый худший код, который я когда#либо видел, написала женщина, никому не позволявшая изучать ее программы. В конце концов начальник пригрозил ей уволь# нением, если она не будет сотрудничать с коллегами. В ее коде полностью отсут# ствовали комментарии, но зато в избытке имелись глобальные переменные с именами вроде x, xx, xxx, xx1 и xx2. Начальник ее начальника считал ее отлич# ным программистом, потому что она быстро исправляла ошибки. Качество ее кода предоставило ей массу возможностей продемонстрировать свой талант исправ# ления ошибок на деле. Быть программистом начального или среднего уровня — не грех. Быть компетен# тным программистом, а не лидером, также не грех. Но если вы знаете, что нужно делать для собственного развития, и ничего не предпринимаете, иначе как гре# хом это назвать нельзя. 33.4. Профессиональная честность Становление высококвалифицированного программиста предполагает развитие обостренного чувства профессиональной честности, которая может проявляться в самых разных формах: отказ от притязаний на роль эксперта, если вы им не являетесь; охотное признание собственных ошибок; стремление разобраться в предупреждениях компилятора вместо их отключения; |