понедельник, 29 июня 2009 г.

Цитаты из книги Джона Роббинса "Отладка приложений для Microsoft .Net"

Уже достаточно давно чешутся руки выписывать интересные цитаты, которые встречаются в различных книгах. Это, весьма странное желание, обусловлено несколькими причинами. Во-первых, во многих хороших книгах интересных выражений наберется достаточное количество и появляется желание этими выражениями, так сказать, поделиться, во-вторых, если их не перенести на более надежный носитель информации, чем хранилище по-умолчанию, коим является наше серое вещество, то они слишком быстро забываются и потом становится довольно сложно их отыскать. Ну и в-третьих, ... хотя, ладно, получилось только во-первых и во-вторых, но думаю и так понятно, что польза от сего занятия в любом случае есть:) Итак, сегодня на повестке дня, Джон Роббинс и его интересные и, зачастую, веселые высказывания.
 

Об ошибках

Ошибки - это мрак. Точка. Ошибки - вот из-за чего вы вкалываете на безнадежными проектами с давно просроченными сроками сдачи, просиживаете у компьютера ночи на пролет и ссоритесь с вечно ворчащими коллегами. Ошибки действительно могут превратить вашу жизнь в кошмар, если достаточное их количество обнаружится в вашем программном обеспечении. Клиенты могут прекратить использовать ваш продукт, а вы можете потерять работу.
 
Ошибки - это серьезно! Очень часто люди, работающий в нашей индустрии, представляют себе ошибки просто как досадные мелочи. Сильнее заблуждаться невозможно. Любой разработчик расскажет вам о проектах с немыслимым количеством ошибок и даже о компаниях, загнувшихся оттого, что их продукт содержал столько ошибок, что был непригоден. Когда я писал первое издание этой книги, NASA потеряла космический зонд, направленный на Марс, из-за ошибок, допущенных на этапе формулировки требований и проектирования ПО.
 
Пока я писал второе издание на солдат американского спецназа упала бомба, направленная на другую цель. Причиной была программная ошибка, возникшая при смене источника питания в системе наведения. За неделю до того, как я написал это введение к третьему изданию, корпорация Microsoft выпустила пакет исправлений для пакета исправлений, который ранее создал огромную уязвимость, связанную с переполнением буфера в Microsoft Internet Explorer 6.
 
Хотя к программным ошибкам уже начинают относится с бОльшим уважением, нам еще очень далеко до появления культуры разработки, в которой к ошибкам будут относиться чрезвычайно серьезно, а не как к незначительным проблемам, иногда возникающим в процессе разработки. Ошибки – это круто! Они помогают залезть в самую глубину и понять, как работают вещи. Мы все попали в этот бизнес, потому что нам нравится учиться, выслеживание ошибок – неотъемлемая часть обучения… Ведь так здорово бывает найти и исправить ошибку! Конечно же, самые хорошие ошибки – это те, которые обнаруживаются до того, как заказчик увидит ваш продукт. Таким образом, вы должны успевать сделать свою работу и найти ошибки до того, как это сделают ваши заказчики. Видеть, как заказчики обнаруживают ошибки, - это совершенно не круто.
 

Об отладке

Отладка - это очень захватывающая тема, независимо от того, какой язык вы используете и на какой платформе работаете. Это единственный этап процесса разработки программного обеспечения, на котором инженеры пинают свои компьютеры, орут на них и даже разбивают их об стену. Для обычно сдержанной замкнутой группы такой накал эмоций представляет собой что-то невероятное. Также отладка является тем этапом процесса разработки ПО, который чаще всего в нашем сознании связывается с "ночными бдениями". Мне еще не встречался инженер, который бы позвонил домой, чтобы сказать: "Дорогая, я не могу прийти домой, потому что мы так веселимся, составляя UML-диаграммы, что хотим посвятить этому развлечению всю ночь!" Однако многие из знакомых инженеров имели опыт жалобных звонков домой в стиле: "Дорогая, я не могу прийти домой, потому что наткнулся на чудовищную ошибку в программе".
 

О сроках

Всем нам приходилось бывать участниками команд разработчиков, для которых «менеджмент» устанавливал сроки выполнения, определенные при помощи толкования карт Таро или, если это было слишком дорого, путем метания дротиков в календарь. Хотя нам хотелось бы верить, что менеджеры несут ответственность за большинство нереалистичных графиков работы, чаще всего это все же не их вина. Обычно основой графика работы становится оценка, даваемая инженерами, и иногда они недооценивают время, которое им может понадобиться для разработки надежного продукта. Инженеры – забавные люди. Они интроверты, но практически всегда большие оптимисты. Получая техническое задание, они до глубины костей верят, что могут с легкостью заставить компьютеры встать и танцевать. Если менеджер зайдет к ним и скажет, что в приложение необходимо добавить блок преобразования XML, средний инженер ответит: «Без проблем, босс! Дайте мне три дня». Конечно же этот инженер может даже не знать, как правильно пишется «XML», но он уверен, что за три дня справится с чем угодно.
 

Об анализе рисков

В первый раз, когда на встрече разработчиков я сказал: «Что, если Боб умрет до того, как мы закончим фазу формулировки требований?», все стали заметно нервничать, так что теперь я формулирую вопросы в менее патологической форме, например: «Что, если Боб выиграет в лотерею и оставит нас ради беззаботной жизни богатого человека до того, как мы закончим фазу формулировки требований?». Однако идея все та же. Найдите в своих планах все места, вызывающие смущение и сомнение, и разберитесь с ними.
 

О дальновидности руководителей

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

Кошки и отладка

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

Разное

Помните, что отладчик – это всего лишь инструмент, как например, отвертка. Он делает только то, что вы приказываете ему делать. Настоящий отладчик находится у вас в голове.
 
Было бы здорово, если бы за ошибки в коде можно было винить барабашек, но необходимо принять и смириться с фактом, что именно вы и ваши коллеги населяете код ошибками. (Если вы читаете эту книгу, то основная вина ложится, конечно же, на ваших коллег.)
 
«Если отладка – это процесс устранения ошибок, то программирование должно быть процессом их порождения»
Эдсгер Дейкстра
 
Кодируй так, как будто человек, поддерживающий твой код, - буйный психопат, знающий, где ты живешь.
 
Многие разработчики жалуются, что пользователи совершенно не хотят тратить время на то, чтобы хоть что-то узнать о компьютерах. Я всегда парирую: «Не могу поверить, как много разработчиков практически ничего не знают о своих средах разработки».

Книга “Framework Design Guidelines” 2nd edition by Krzysztof Cwalina and Brad Abrams

Одним из главных достоинств объектно-ориентированного программирования является возможность повторного использования кода. Выполняя один проект за другим, команда разработчиков накапливает опыт в предметной области и обрастает различными вспомогательными классами, облегчающими решения повседневных задач. И даже, когда код повторно используется всего в нескольких местах, разработчики понимают, что к такому коду предъявляются уже совсем другие требования. Если при разработке приложений основной акцент делается на простоту сопровождения внутренней реализации, то при разработке библиотек он смещается в сторону простоты и удобства использования, даже за счет пренебрежения некоторыми идеями объектно-ориентированного проектирования. Кроме этого, разработка библиотек требует от команды разработчиков совершенно другого подхода ко всему циклу разработки, начиная от анализа требований и составления функциональной спецификации, заканчивая комплексным тестированием. Книга содержит множество правил, рекомендации и предостережений, которые нужно учитывать при создании библиотек, а аннотации таких известных людей, как Джеффри Рихтер, Крис Селлз, Андерс Хейлсберг, Герб Саттер и других, придают некоторую живость обсуждению и помогают лучше понять то, или иное правило.

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

Chris Sells

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

"Издатели говорят, что количество проданных копий книги обратно пропорционально количеству формул в ней. Для разработчика библиотек версия этого закона следующая: количество пользователей, которые будут использовать вашу библиотеку обратно пропорционально количеству операторов new, необходимых в простых сценариях использования"

Krzysztof Cwalina

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

Оценка: Must Have.