Совершенный код. Совершенный код. Мастер-класс. Стив Макконнелл. Руководство по стилю программирования и конструированию по
 Скачать 5.88 Mb.
|
|
ГЛАВА 33 Личность 807 желание ясно понять программу и отказ от компиляции кода с той лишь це# лью, чтобы узнать, работает ли он; предоставление реалистичных отчетов о статусе проекта; предоставление реалистичных оценок срока выполнения проекта и отстаива# ние своей позиции, даже если руководители просят адаптировать оценку. Два первых элемента этого списка — признание собственных недостатков и ошибок — можно считать отголосками интеллектуальной скромности, рассмотренной выше. Как вы узнаете что#то новое, если будете считать, что уже все знаете? Если на то пошло, гораздо лучше считать, что вы ничего не знаете. Прислушивайтесь к мнениям людей и учитесь у них, но старайтесь при этом понять, действительно ли они знают, что говорят. Оценивайте степень своей уверенности в тех или иных суждениях. Если вы обычно уверены в них на 100%, это предупреждающий знак. Отказ от признания ошибок — особенно вредная привычка. Если Салли отказывается признать ошибку, она, очевидно, считает, что сможет убедить в этом окружающих, но на са# мом деле имеет место обратное. Все будут знать, что ошиб# ку допустила Салли. Ошибки — естественный результат подъ# емов и спадов сложных интеллектуальных процессов, и если Салли не была небрежной, никто не будет ее ни в чем упрекать. Если она отказывается признать ошибку, она сможет одурачить только одного человека — себя. Что касается ее коллег, то они поймут, что они работают с над# менным и не совсем искренним программистом. Это уже не просто ошибка, а нечто худшее. Если вы совершили ошибку, признавайте это быстро и охотно. Еще один распространенный недостаток — убежденность в понимании сообще# ний компилятора. Если вы не понимаете предупреждение компилятора или ду# маете, что понимаете, но вам не хватает времени, чтобы проверить свое предпо# ложение, к чему это приведет? Вероятно, в итоге вам придется решать проблему с нуля, тогда как компилятор буквально размахивал готовым решением перед вашим носом. Если меня просят помочь отладить программу, я спрашиваю, компилиру# ется ли она без ошибок и предупреждений. Довольно часто программисты отве# чают «да» и начинают объяснять симптомы проблемы. Я отвечаю: «Хм… Похоже на неинициализированный указатель, но компилятор должен был предупредить вас об этом». В ответ на это они заявляют: «О да, он предупреждал об этом, но мы думали, что это означает что#то другое». Совершив ошибку, вы едва ли сможете убедить людей в том, что она не ваша. Обмануть компьютер еще сложнее, так что не тратьте попусту свое время. Похожий вид интеллектуальной небрежности имеет место тогда, когда вы не со# всем понимаете свою программу и «просто компилируете ее, чтобы увидеть, бу# дет ли она работать». Примером может служить запуск программы с целью опре# делить, какое условие следует использовать: < или <=. На самом деле работоспо# собность программы в этой ситуации не играет никакой роли, потому что вы понимаете ее недостаточно хорошо, чтобы сказать, почему она работает. Помните: тестирование может указать только на наличие, но не на отсутствие ошибок. Если вы не понимаете программу, вы не сможете тщательно ее протестировать. Ком# Любой дурак способен отстаивать свои ошибки — большинство ду- раков именно так и делают. Дейл Карнеги (Dale Carnegie) 808 ЧАСТЬ VII Мастерство программирования пиляция программы с целью «посмотреть, что будет» — предупреждающий знак. Это может означать, что вам нужно вернуться к проектированию или что вы при# ступили к кодированию, плохо понимая свои действия. Прежде чем компилиро# вать программу, убедитесь, что вы хорошо понимаете ее. Оценка статуса проекта — один из главных источников лжи в нашей работе. Программисты печально известны своими заявлениями, согласно которым на протяжении всей второй половины проекта программа неизменно «готова на 90%». Если вы плохо представляете ход работы над проектом, по# старайтесь лучше разобраться в методах работы. Но если вы не говорите правду, потому что хотите угодить своим ру# ководителям, это совсем другое дело. Как правило, руководители будут благодар# ны вам за объективные оценки статуса проекта, даже если эти оценки им не по# нравятся. Если ваши выводы обоснованы, высказывайте их лично и без всяких прикрас. Для координации процессов разработки руководителям нужна точная информация, и искреннее сотрудничество играет при этом очень важную роль. С сообщением неверного статуса проекта связана неверная оценка сроков выполнения проекта. Типичный сценарий таков: руководитель спрашивает у Берта, сколько времени потребуется на разработку новой БД. Берт беседует с программистами, подсчи# тывает некоторые показатели, возвращается и говорит, что над проектом долж# ны будут работать восемь программистов в течение шести месяцев. Руководитель говорит: «Нас это не устраивает. Можно ли выполнить проект быстрее и с мень# шим числом программистов?» Берт уходит, думает и решает, что он мог бы со# кратить время обучения и отпуска и попросить каждого из программистов пора# ботать сверхурочно. Он возвращается и говорит, что проект будет реализован шестью программистами за четыре месяца. Руководитель заявляет: «Отлично. Это довольно низкоприоритетный проект, поэтому постарайтесь выполнить его точ# но вовремя: мы не справимся с дополнительными расходами». К сожалению, Берт не учел, что оценка не может являться предметом перегово# ров. Он может пересмотреть оценку и сделать ее более точной, но переговоры с руководителем не повлияют на время, необходимое для реализации проекта. Билл Ваймер из IBM однажды заявил: «Мы обнаружили, что технические специалисты в целом очень точно оценивали требования, предъявляемые к проектам, и сроки их реализации. Но они не могли защитить свои решения — им нужно научиться отстаивать свое мнение» (Weimer в Metzger and Boddie, 1996). Пообещав выпол# нить проект за четыре месяца и выполнив за шесть, Берт едва ли обрадует своего руководителя сильнее, чем пообещав выполнить проект за шесть месяцев и сдер# жав свое слово. Не сдержав обещания, Берт потеряет доверие, а отстаивая свою позицию, лишь заслужит уважение. Если руководство давит на вас, желая услышать более приемлемую оценку, дайте понять, что окончательное решение о том, следует ли браться за проект, остается за ними: «Смотрите: вот сколько это будет стоить. Я не знаю, приемлема ли такая цена для компании, — это ваша работа. Но я могу сказать, сколько времени по# требуется для разработки ПО, — это моя работа. Обсуждать сроки в данном слу# На первые 90% кода приходят- ся первые 90% времени разра- ботки. На оставшиеся 10% кода приходятся другие 90% време- ни разработки. Том Каргилл (Tom Cargill) http://cc2e.com/3341 ГЛАВА 33 Личность 809 чае неуместно: это все равно что обсуждать, сколько футов в миле. Мы не можем пересмотреть законы природы. Однако мы можем пересмотреть другие аспекты проекта, влияющие на срок его выполнения, и переоценить его. Мы можем отка# заться от некоторых возможностей, снизить производительность, выполнить про# ект инкрементно, а также привлечь к работе меньшее число людей и установить более длительный срок выполнения проекта или наоборот: привлечь больше раз# работчиков и реализовать проект быстрее». Один из самых ужасных советов я получил на лекции об управлении проектами разработки ПО. Лектором был автор бестселлера по управлению проектами. Один из присутствующих спросил: «Что вы делаете, если руководители просят оценить срок выполнения проекта, но вы знаете, что если вы сообщите верную оценку, они откажутся от проекта?» Лектор ответил, что в такой щекотливой ситуации следу# ет склонить руководителей к реализации проекта, недооценив его. Он сказал, что, как только руководители инвестируют средства в первую часть проекта, им при# дется довести его до конца. Абсолютное заблуждение! Начальство отвечает за управление компанией в целом. Если какая#то функция программы обойдется компании в 250 000 долларов, а вы оцените ее в 750 000, разрабатывать программу не следует. Принимать такие ре# шения должны руководители. Когда лектор отстаивал недооценку проекта, он от# стаивал скрытое воровство власти у руководителей. Если вы считаете, что проект интересен, открывает перед компанией новые возможности или позволяет мно# гому научиться, так и скажите. Руководители тоже способны взвесить эти факто# ры. Но подталкивание их к неверным решениям может стоить компании сотен тысяч долларов. Если из#за этого вы лишитесь работы, пеняйте на себя. 33.5. Общение и сотрудничество По#настоящему отличные программисты учатся эффективно сотрудничать, что всегда подразумевает написание удобочитаемого кода. Вероятно, компьютер чи# тает вашу программу так же часто, как другие люди, но он читает плохой код го# раздо лучше, чем люди. Работая над кодом, не забывайте про людей, которым придется изменять его в будущем. Программирование — это в первую очередь общение с другим программистом и только во вторую — с компьютером. 33.6. Творчество и дисциплина Закончив институт, я считал себя лучшим программистом в мире. Я мог раз% работать непобедимый алгоритм игры в крестики%нолики, владел пятью раз% ными языками и мог писать программы из 1000 строк, которые РАБОТАЛИ (в самом деле!). Затем я очутился в Реальном Мире. Первая моя задача в Реальном Мире требовала, чтобы я разобрался в программе из 200 000 строк, написан% ной на Фортране, и ускорил ее в два раза. Любой Реальный Программист ска% жет вам, что никакие методики Структурного Кодирования никогда не помогут решить подобную проблему — для этого требуется настоящий талант. Эд Пост (Ed Post) 810 ЧАСТЬ VII Мастерство программирования Выпускнику института трудно объяснить важность конвенций и дисциплины. Самая крупная программа, написанная мной в институте, состояла примерно из 500 строк исполняемого кода. За свою профессиональную карьеру я написал десятки ути# лит, включающих менее 500 строк, однако в среднем мои проекты содержали от 5000 до 25 000 строк, а объем некоторых проектов, в которых я принимал учас# тие, достигал полумиллиона строк. Подобные проекты требуют не тех же навы# ков в более крупном масштабе, а совершенно иных навыков. Некоторые программисты считают, что стандарты и конвенции подавляют сво# боду творчества, но с этим трудно согласиться. Можете ли вы представить Web# сайт, на каждой странице которого использовались бы разные шрифты, цвета, способы выравнивания текста, графические стили и способы навигации? Какое уж тут творчество — это хаос. Если стандарты и конвенции не используются в крупном проекте, завершить его становится невозможно. Не тратьте свою твор# ческую энергию на то, что не играет никакой роли. Установите конвенции для второстепенных областей и сосредоточьтесь на действительно важных аспектах. Анализируя 15#летний опыт работы в Лаборатории проектирования ПО NASA, Макгарри и Паджерски пришли к выводу, что особенно эффективными были ме# тодики и инструменты, акцентированные на дисциплине (McGarry and Pajerski, 1990). Многие в высшей степени творческие люди отличаются крайней дисцип# линированностью. «Форма освобождает», — гласит пословица. Прекрасные архи# текторы и художники работают в условиях ограниченности физических матери# алов, времени и расходов. Любой, кто изучал произведения Леонардо да Винчи, не может не восхищаться его дисциплинированным вниманием к подробностям. Перед росписью свода Сикстинской капеллы Микеланджело разделил его на сим# метричные наборы геометрических фигур, таких как треугольники, окружности и прямоугольники. Он разделил свод на три зоны в соответствии с тремя этапа# ми Платона. Без этой структуры и дисциплины 300 человеческих фигур были бы просто хаотично разбросанными фрагментами, а не согласованными элемента# ми художественного шедевра. Создание шедевра программирования требует не меньшей дисциплины. Если вы не проанализируете требования и проект до начала кодирования, многие знания вам придется приобретать во время кодирования, и результат вашей работы будет больше напоминать мазню трехлетнего ребенка, а не произведение искусства. 33.7. Лень Лень может проявляться несколькими способами: отсрочка выполнения неприятной задачи; немедленное выполнение неприятной задачи с целью как можно более быстрого избавления от нее; написание инструмента для выполнения неприятной за# дачи, чтобы ее никогда не пришлось выполнять снова. Одни проявления лени лучше, другие — хуже. Первое едва ли когда#нибудь бывает выгодным. Наверное, и вы когда#то тратили несколько часов на выполнение необязательных Лень: качество, которое застав- ляет прилагать больше усилий для снижения общих затрат энергии. Она заставляет писать программы, облегчающие труд, и документировать написанное, чтобы вам не пришлось отве- чать на лишние вопросы. Ларри Уолл (Larry Wall) ГЛАВА 33 Личность 811 задач, желая отсрочить решение относительно неважной задачи, избежать кото# рой тем не менее вы не могли. Я ненавижу ввод данных, и многие программы требуют ввода небольшого объема данных. Я иногда откладываю работу над про# граммой на несколько дней только затем, чтобы отсрочить неизбежный ввод не# скольких страниц чисел вручную. Это «истинная лень». Она проявляется и в ком# пиляции класса с целью проверки его работоспособности и избавления от про# верки класса в уме. Небольшие задачи никогда не бывают такими плохими, какими кажутся. Вы смо# жете избавиться от первого типа лени, если выработаете привычку выполнять эти задачи сразу. Эта привычка соответствует второму типу лени — «просвещенному». Вы все так же ленитесь, но решаете неприятные проблемы, тратя на них как можно меньше времени. Третий вариант лени предполагает написание инструмента для выполнения не# приятной задачи. Это «долговременная лень». Несомненно, это самый продуктив# ный вид лени (если, конечно, инструмент позволяет в итоге сэкономить время). В этом контексте определенная лень даже выгодна. Однако лень имеет и обратную сторону. «Спешка» и «усилия» ценятся в програм# мировании совсем не так высоко, как на уроках физкультуры. Спешка — это до# полнительные, ненужные усилия. Она указывает на активность, но не на выпол# нение работы. Движение нетрудно спутать с прогрессом, а занятость с продуктив# ностью. Главную роль в эффективном программировании играет мышление, а размышляющие люди обычно не кажутся занятыми. Если бы я видел, что какой# то программист постоянно занят, я подумал бы, что он — неважный программист, потому что он не использует свой наиболее ценный инструмент, которым, как известно, является голова. 33.8. Свойства, которые менее важны, чем кажется Помимо спешки есть и другие свойства, уместные в других областях жизни, но не особо эффективные при разработке ПО. Настойчивость Как и большинство подобных субъективных понятий, настойчивость в зависимости от обстоятельств может быть и достоинством, и недостатком и обозначается раз# ными словами. Если вы хотите считаете ее плохим качеством, вы называете ее «упрямством», а то и «ослиным упрямством». Если вы желаете придать ей хоро# ший оттенок, можете назвать ее «упорством». Как правило, при разработке ПО настойчивость принимает форму ослиного уп# рямства, т. е. пользы не приносит. Настойчивое стремление довести код до ума с использованием одного подхода трудно признать достоинством. Попробуйте перепроектировать класс, перепишите код или вернитесь к проблеме позже. Если один подход не работает, самое время испытать другой (Pirsig, 1974). 812 ЧАСТЬ VII Мастерство программирования Во время отладки иногда очень увлекательно отслеживать надоедливую ошибку четыре часа, но, если в течение како# го#то времени (скажем, 15 минут) вы не добиваетесь про# гресса, обычно лучше отложить поиск ошибки. Позвольте своему подсознанию немного поработать над проблемой. Попробуйте подумать об альтернативном подходе, который вообще устранил бы проблему. Перепишите проблемный фрагмент кода с нуля. Вернитесь к нему со свежей головой. В борьбе с компьютерными проблемами нет ничего благород# ного. Лучше их избегать. Трудно сказать, когда отложить работу, но очень важно, чтобы вы спрашивали себя об этом. Если вы чувствуете замешательство, задайте себе этот вопрос. Это не всегда означает, что пришло время сдаться, однако скорее всего это значит, что пора установить некоторые временные параметры: «Если я не решу эту проблему с использованием этого подхода в следующие полчаса, я проведу 10#минутный „мозговой штурм“ в поиске других подходов и попробую в течение следующего часа самый лучший из них». Опыт По ряду причин важность практического опыта в сравнении с книжным образо# ванием в области разработки ПО не столь велика, как во многих других областях. В других областях базовые положения изменяются довольно медленно, вследствие чего люди, закончившие вуз с интервалом в 10 лет, обладают по сути одинаковы# ми знаниями. В отрасли разработки ПО даже основы претерпевают быстрые из# менения. Человек, закончивший вуз через 10 лет после вас, вероятно, будет знать вдвое больше об эффективных методиках программирования. К программистам старшего возраста относятся с подозрением не только потому, что они якобы не имеют представления об отдельных технологиях, а потому, что они, возможно, никогда и не сталкивались с базовыми концепциями программирования, распро# странившимися после того, как они закончили вуз. В других областях текущие знания человека о работе будут служить ему и завтра. Что до разработки ПО, то, если программист неспособен пересматривать привыч# ные способы мышления, приобретенные им при использовании предыдущего языка программирования, или методики оптимизации кода, работавшие на старом ком# пьютере, наличие опыта окажется худшим вариантом, чем его полное отсутствие. Многие программисты тратят время на подготовку к завершившейся битве, а не предстоящей. Если вы не изменяетесь вместе со временем, опыт скорее вредит, чем помогает. Кроме того, опираясь на собственный опыт, люди часто делают неверные выво# ды. Трудно объективно оценить свою жизнь. Вы можете упустить из виду ключе# вые элементы своего опыта, которые подтолкнули бы вас к другим выводам, если бы вы их учли. В этом смысле могут помочь книги о работе других программис# тов, потому что так вы узнаете опыт других людей, достаточно очищенный, что# бы его можно было изучить объективно. Стоит упомянуть также абсурдное внимание к объему опыта программистов. «Нам нужен программист, обладающий 5#летним опытом программирования на C» — Перекрестная ссылка О настой- чивости при отладке см. подраз- дел «Советы по поиску причин дефектов» раздела 23.2. |