Кодеры за работой. Размышления о ремесле программиста

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

Сейбел: Как насчет прочих инструментов?

Блох: С утилитами для программирования у меня не очень хорошо — а жаль. Инструменты сборки и системы управления версиями изменяются сильнее, чем хотелось бы, и мне трудно следить за ними. Поэтому, сталкиваясь с новой средой, я всегда пристаю к коллегам, более привычным к таким инструментам. Я вечно спрашиваю: «А как сегодня это делается?» Коллеги закатывают глаза и помогают мне, а я пользуюсь средой, пока она окончательно не откажет.

Гордиться тут нечем. Разработчики программ могут быть искусны в одном и малоискусны в другом. Кое-кто утверждает, что это не так, что разработчики взаимозаменяемы, что каждый может и должен уметь все. Но на практике это не так. И если заставлять каждого разработчика делать все, результат будет никудышным.

Я говорю прежде всего о тех, кто, по выражению Кевина Бурильона, «лишен гена эмпатии». Нельзя создавать хорошие API или языки, не представив себя в шкуре рядового программиста, который пользуется ими. Однако есть люди, создающие хорошие API и языки. И есть знатоки технической стороны проектирования языка, которые говорят: «Это сделает все несовместимым с LALR(l), надо сделать по-другому». Это крайне полезное знание. Но оно не заменяет гена эмпатии — такой знаток может создать кошмарный язык, не пригодный для использования.

Есть и другие — способные выжать из языка все, что возможно, ради большей эффективности. Надо найти им нужное применение — они будут счастливы и принесут пользу вашей компании. Вообще, необходимо знать сильные места ваших разработчиков и пользоваться этим. Это я так оправдываюсь за свое плохое знание инструментов. Слабое оправдание, понятно.

Сейбел: Поговорим об отладке. Можете ли вы назвать худшую ошибку из тех, что вам встречались?

Блох: Мне сразу приходит в голову один кошмарный и в то же время любопытный случай. Это было в начале 1990-х, я тогда работал в питт-сбургской компании Transarc. Мне пришлось заниматься реализацией транзакционной разделяемой памяти при очень плотном графике. Проектирование и реализацию я закончил в срок и даже успел написать несколько библиотечных компонентов. Но я нервничал из-за того, что произвел много нового кода в спешке.

Для тестирования кода я написал чудовищного «убийцу». Он запускал множество транзакций, каждая из которых содержала рекурсивно вложенные транзакции — вплоть до определенной глубины вложения. Каждая из вложенных транзакций могла блокировать и читать некоторые элементы разделяемого массива в восходящем порядке и что-то прибавлять к каждому из них, сохраняя инвариант, так что сумма всех элементов массива равнялась нулю. Каждая субтранзакция либо фиксировалась, либо прерывалась — соотношение случаев было 90:10, как-то так. Множество потоков запускали эти транзакции параллельно и воздействовали на массив в течение долгого времени. Поскольку я тестировал разделяемую память, то запускал несколько многопоточных «убийц», каждый в своем собственном процессе.

При разумном уровне многопоточности «убийца» работал вполне надежно. Но когда этот уровень повысился, я обнаружил, что иногда — именно иногда — «убийца» не проходил проверку внутренней целостности. Я не понимал, что делается, и, естественно, думал, что это моя ошибка — ведь я написал столько нового кода.

С неделю я потратил на модульные тесты для каждого компонента — все было в порядке. Потом я написал программу проверки целостности для каждой внутренней структуры данных и мог делать проверку после каждого изменения — пока не случалось, что элемент не проходил проверку. Наконец я уловил непрохождение проверки на низком уровне — такое было не каждый раз, но теперь я мог проанализировать происходящее. И пришел к неизбежному выводу: мои блокировки не работали. У меня были параллельные последовательности операций типа «прочесть-изменить-записать», так что две транзакции блокировали, читали и записывали одно и то же значение. И последняя запись затирала первую.