О разработке ПО, отладке и Эйнштейне

Брайан Керниган (Brian Kernighan) когда-то выразил такую мысль:

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

Читая книгу Энди Ханта “Pragmatic Thinking and Learning” в одном из эпиграфов я встретил знаменитую цитату Эйнштейна:

Мы не можем решить проблему тем же способом мышления, посредством которого она появилась.

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

 

Оригинальная цитата Брайана Кернигана:

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

Оригинальная цитата Альберта Эйнштейна:

We can’t solve problem by using the same kind of thinking we used when we created them.

“Джоэл о программировании”. Часть 2.

Вторая порция цитат из замечательной книги Джоэла Спольски “Джоэл о программировании”.

Вы хватаете за рукав первого попавшегося вам в коридоре человека и требуете, чтобы он поработал с кодом, который вы только что написали. Проделайте это пять раз и вы найдете 95% всех проблем с юзабилити в своем коде
("Корридорное тестирование")
Глава 3. Проводится ли юзабилити-тестирование на случайных людях?

Продвижение хороших кодеров выдвижением их на другие должности, где требуется писать на человеческом языке, а не на С++, служит классической иллюстрацией принципа Питера: люди продвигаются по службе, пока не достигнут своего уровня некомпетентности.
Глава 7. Как принимать на работу менеджера программы?

Многие неопытные менеджеры полагают, что могут "стимулировать" более быструю работу своих программистов, если будут задавать для них трудные, "напряженные" (нереалистично быстрые) графики. Я думаю, что такого рода мотивация - глупость. Если я выбиваюсь из графика, я чувствую себя обреченным, подавленным и немотивированным. Если же я работаю с опережением графика, я чувствую себя бодрым и работоспособным. Психологические игры с графиком очень опасны.
Глава 9. Ни в коем случае не позволяйте программистам занижать оценку времени.

Если у вас есть кучка деревянных кубиков, которые не помещаются в коробку, есть два выхода: взять коробку побольше или убрать некоторые кубики. Если вы думали, что сможете сделать продукт через 6 месяцев, а по графику получается 12, вам придется либо отложить выпуск продукта, либо отказаться от каких-то функций. Сделать кубики меньше вы не можете, а если вы считаете, что можете, значит, вы лишаете себя полезной возможности реально смотреть в будущее и лжете себе о том, что вы там видите.
Глава 9. График похож на набор кубиков

Исправлять ошибки необходимо только тогда, когда сохранение ошибки обходится дороже, чем ее исправление
Глава 11. Тотальное уничтожение ошибок

Я заметил, что начиная с самой первой моей работы я как разработчик в среднем лишь два или три часа могу продуктивно писать код, и это меня изумляет. Когда я летом стажировался в Microsoft, то мой коллега-стажер рассказал мне, что фактически он ежедневно активно работал с 12 до 5. Пять часов, минус обед, и его бригада восхищалась им, потому что ему все удавалось сделать гораздо больше среднего. Я обнаружил, что со мной происходит то же самое. Я испытываю легкое чувство вины, замечая, как напряженно, по-видимому, работают все остальные, а у меня получается два или три часа настоящей работы в течение дня, и тем не менее я всегда был одним из самых результативных членов бригады. Видимо по этой причине "Peopleware" и экстремальное программирование настаивают на отмене сверхурочной работы и на строго 40-часовой рабочей неделе, будучи уверенными в том, что объем продукции команды от этого не уменьшится.
Глава 15. Огонь и движение

 

Все цитаты из книги Джоэла Спольски “Джоэл о программировании”:

Часть 1

Часть 2

Справочник бойца по проведению собеседования

Секреты айсберга

Часть 3

Отладка приложений для Microsoft .NET. Об ошибках и отладке

На этот раз речь пойдет о цитатах из книги Джона Роббинса “Отладка приложений для Microsoft .NET”. В целом, книга весьма не простая, помимо большого числа интересных тем, довольно часто встречаются и довольно “дремучие”. Подробное мнение об этой книге можно посмотреть на моем блоге или на rsdn.ru.

 

 

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

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

Пока я писал второе издание на солдат американского спецназа упала бомба, направленная на другую цель. Причиной была программная ошибка, возникшая при смене источника питания в системе наведения. За неделю до того, как я написал это введение к третьему изданию, корпорация Microsoft выпустила пакет исправлений для пакета исправлений, который ранее создал огромную уязвимость, связанную с переполнением буфера в Microsoft Internet Explorer 6.

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

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

Глава 1. Ошибки: откуда они берутся и как их устранять

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

Глава 1. Шаг 5. Думайте творчески

Помните, что отладчик – это всего лишь инструмент, как например, отвертка. Он делает только то, что вы приказываете ему делать. Настоящий отладчик находится у вас в голове.
Глава 1. Последний секрет процесса отладки

Программист-прагматик. Часть 5. Тестировние и отладка

Тестирование и отладка занимает в книге достойное место. Книга не заменит специализированную литературу по отладке, но все же будет полезна многим разработчикам.

 

Английское слово bug (ошибка) используется для описания "объекта, вызывающего ужас" уже начиная с XIV века. Контр-адмирал д-р Грэйс Хоппер (создатель языка COBOL) оказалась первой, кто наблюдала компьютерного «жучка», буквально – моли, попавшей в одно из электромеханических реле, из которых состояли первые вычислительные системы. Когда техника попросили объяснить, почему машина ведет себя не так, как надо, он сообщил, что в системе "завелся жучок", и в соответствии со своими должностными обязанностями приклеил его клейкой лентой вместе с крылышками и всем остальным в рабочий журнал.
Глава 3. Отладка

 

Очень простая, но весьма полезная методика поиска причины проблемы, состоит в том, чтобы разъяснить ее кому-либо. Ваш собеседник должен заглядывать через ваше плечо на экран монитора и время от времени утвердительно кивать головой (подобно резиновому утенку, ныряющему и выныривающему в ванне). Ему не нужно говорить ни слова; простое, последовательное объяснение того, что же должна делать ваша программа, часто приводит к тому, что проблема выпрыгивает из монитора и объявляет во всеуслышанье: "А вот и я!".*
Звучит просто, но разъясняя проблему вашему собеседнику, вы должны явно заявить о тех вещах, которые считаете само собой разумеющимися при просмотре текста вашей программы. Поскольку вам приходится озвучивать некоторые из этих положений, вы можете по-новому взглянуть на суть данной проблемы – неожиданно для самого себя.

* Почему "резиновый утенок"? Один из авторов книги, Дэйв Хант, учился в лондонском Империал колледже и много работал совместно с аспирантом, которого звали Грег Паг и которого Д. Хант считает одним из лучших известных ему разработчиков. На протяжении нескольких месяцев Грег носил при себе крохотного желтого резинового утенка, которого он ставил на край монитора во время работы. Прошло некоторое время, пока Дэйв не отважился спросить…

Примечание: один очень известный bug-slayer (речь идет о Джоне Роббинсе), считает, что лучшие отладчики – это кошки, а не утята… Но это уже, скорее, дело вкуса :-)
Глава 3. Рассказ о резиновом утенке

 

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

 

 

Если ваша программа обнаруживает, что произошло событие, которое считалось невозможным, программа теряет жизнеспособность. Начиная с этого момента, все действия, которые она совершает, попадают под подозрение, так что выполнение программы необходимо прервать как можно быстрее. В большинстве случаев мертвая программа приносит намного меньше вреда, чем испорченная.
Глава 4. Аварийное завершение не означает “отправить в корзину для мусора”

 

Предположим, Фреду дано задание написать программу. Фред составляет некую программу, пробует ее запустить, и она вроде бы работает. Фред пишет еще один фрагмент, пробует его запустить, и снова все работает. В такой обстановке проходит еще несколько недель, но внезапно программа прекращает работать, и, потратив несколько часов на устранение дефекта, Фред все еще не знает, в чем причина. Фред может потратить много времени, копаясь с этим фрагментом, без перспективы на восстановление работы программы. И что бы он ни делал, кажется, что программа никогда не будет работать правильно.
Фред не знает, почему программа сбоит, потому что не знает, почему она работала вначале. Она лишь казалась работающей в условиях ограниченного «тестирования», которое проводил Фред, но это было лишь стечением обстоятельств. Находясь в плену ложной уверенности, Фред впал в забытье. Большинству интеллектуалов знаком этот образ Фреда, но мы знаем его лучше. Мы ведь не полагаемся на стечение обстоятельств, не так ли?
Глава 6. Программирование в расчете на стечение обстоятельств

Тестируйте ваши программы, в противном случае это сделают ваши пользователи
Глава 6. Культура тестирования

 

Большинство разработчиков ненавидят тестирование. Они стремятся тестировать осторожно, подсознательно ощущая, в каком месте программа может сбоить, и избегая слабых мест.
Глава 8. Безжалостное тестирование

 

Несоответствие критериям удобства использования является дефектом такого же порядка, как деление на ноль.

Глава 8. Тестирование удобства использования

Если тестировщик обнаруживает дефект, это должно быть в первый и последний раз – обнаружение дефекта человеком. Автоматизированные тесты должны быть модифицированы для проверки наличия этого дефекта, начиная с момента его первоначального обнаружения, всякий раз, без каких-либо исключений, не обращая внимания на степень тривиальности, жалобы разработчика и его фразу "Этого больше не случится".
Глава 8. Кольцо сжимается

Все цитаты из книги Дейва Томаса и Энди Ханта “Программист-прагматик. Путь от подмастерья к мастеру”:

Часть 1. Философия программирования

Часть 2. Дублирование информации

Часть 3. Инструменты

Часть 4. Проектирование

Часть 5. Тестирование и отладка

Часть 6. Управление проектами