Лучшие примеры разработки ПО

Содержание

О редакторе
Об авторах
Кен Арнольд. Стиль есть содержание
Леон Бамбрик. Премия за самый дурацкий пользовательский интерфейс: поиск в Windows
Майкл Бин. Подводные камни внешнего подряда
Рори Блайс. Excel как база данных
Адам Босуорт. Доклад на ICSOC04
Дана Бойд. Аутизм в социальном программном обеспечении
Рэймонд Чен. Почему бы просто не заблокировать приложения, зависящие от недокументированных функций системы?
Кевин Ченг и Том Чи. Пинок для ламы
Кори Доктороу. Спасите канадский Интернет от WIPO
ea_spouse. EA: житейская история
Брюс Эккель. Сильная типизация против сильного тестирования
Пол Форд. Размышления о Processing
Пол Грэхем. Великие хакеры
Джон Грубер. Поле адреса как новая командная строка
Грегор Хопе. Почему в Starbucks не используют двухфазное закрепление
Рон Джеффрис. Страсть
Эрик Джонсон. C++ — забытый троянский конь
Эрик Липперт. Сколько работников Microsoft нужно для того, чтобы сменить лампочку?
Майкл “Рэндс” Лопп. Что делать? когда все плохо
Ларри Остерман. Правила разработки программного обеспечения от Ларри: не оценивайте труд тестеров по тестовым метрикам
Мэри Поппендик. Компенсация для групп
Рик Шаут. MAC WORD 6.0
Клей Ширки. Группа как собственный худший враг
Клей Ширки. Группа как пользователь: флейм и проектирование социального программного обеспечения
Эрик Синк. Заполнение промежутка, часть 1
Эрик Синк. Заполнение промежутка, часть 2
Эрик Синк. Опасности найма
Аарон Шварц. Вариации на тему PowerPoint
why the lucky stiff. Краткая экскурсия по языку Ruby
Алфавитный указатель

Лучшие примеры разработки ПО
Дж. Спольски

Эрик Липперт
Сколько работников Microsoft нужно для того, чтобы сменить лампочку?


Лично меня просто бесит, когда 16-летние гении от программирования начинают ныть о медленной работе и некомпетентности опытных программистов — в своих блогах они всегда такие храбрые и сильные, особенно когда в Интернете никто не знает о прыщах и скобках на зубах. Наверное, когда я увижу, что очередной вундеркинд на Slashdot жалуется на то, что Windows XP с ее миллионами строк программного кода “содержит больше багов1, чем озеро в Миннеаполисе летом”, и делает вид, что он (конечно, это всегда “он”) — так вот, он справился бы с этим лучше, меня стошнит.

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

Эрик Липперт был основным разработчиком сценарных технологий Microsoft, VBScript и JScript. Хотя после прочтения статьи начинает казаться, что Microsoft является бюрократической организацией (и в этом есть доля истины), бюрократизм возник не без причины. И такая же бюрократия потребуется лю­бому разработчику программ, которые должны идеально работать в руках пресловутого близорукого каталонца, не создавая дефектов в системе безопасности. Благодарю Эрика за его терпение и юмор, потому что я бы приговорил этих подростков с их “всего пятью строками кода!” к 30 годам каторжных работ по написанию трехмерного текстового редактора для близоруких каталонцев на Cobol. — Ред.


В те времена, когда я действительно регулярно занимался добавлением новых возможностей в VBScript, мне часто присылали сообщения с просьбами реализовать те или иные функции. Чаще всего запросы были “одноразовыми” — для функ­ций, решающих конкретную задачу. Скажем, “Мне нужно вызвать ChangeLightBulb­WindowHandleEx, но для этого нет специального элемента ActiveX, а напрямую вызывать­ функции Win32 API из сценариев нельзя; нельзя ли включить метод ChangeLightBulbWindowHandleEx в список встроенных функций VBScript? Ведь это всего пять строк кода!”

Я всегда отвечаю таким людям одно и то же: если это всего пять строк кода, напишите свой объект ActiveX. Потому что вы абсолютно правы, для включения этой возможности в библиотеку времени выполнения VBScript мне потребуется примерно пять минут. Но сколько работников Microsoft в действительности понадобится для того, чтобы сменить лампочку1? 1

Change a Lightbulb. — Примеч. перев.

- Один разработчик, чтобы за пять минут реализовать ChangeLight­BulbWindow­HandleEx.
- Один руководитель проекта (РП), чтобы написать спецификацию.
- Один специалист по локализации, чтобы просмотреть спецификацию на предмет потенциальных проблем с локализацией.
- предмет доступности для лиц с ограниченными возможностями и практической пригодности.
- По крайней мере один разработчик, один тестер и один РП, чтобы провести “мозговой штурм” для выявления потенциальных проблем безопасности.
- Один РП, чтобы включить модель безопасности в спецификацию.
- Один тестер, чтобы написать план тестирования.
- Один руководитель группы тестирования, чтобы обновить график тестирования.
- Один тестер, чтобы написать контрольные примеры и включить их в ночную автоматическую проверку.
- Три или четыре тестера, чтобы участвовать в выявлении ошибок именно для данного случая.
- Один технический автор, чтобы написать документацию.
- Один технический рецензент, чтобы проверить документацию.
- Один редактор, чтобы проверить документацию.
- Один руководитель отдела документации, чтобы интегрировать новую документацию в существующий текст, обновить содержание, алфавитные указатели и т. д.
- Двадцать пять переводчиков, чтобы перевести документацию и сообщения об ошибках на все языки, поддерживаемые Windows. Руководители пе­реводчиков живут в Ирландии (европейские языки) и Японии (азиат­ские языки); оба места существенно сдвинуты по времени относительно Редмонда1, поэтому общение с ними иногда создает непростые организационные проблемы.
- Группа старших руководителей, чтобы координировать работу всех этих людей, выписывать чеки и объяснить смысл дополнительных затрат вице-президенту.

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

Исходные пять минут программирования оборачиваются многими человеконеделями работы и огромными затратами — и только потому, что одному человеку лень за несколько минут склепать на VB6 элемент, выполняющий нужную задачу. Простите, но в коммерческом отношении это не имеет ни малейшего смысла. Мы в Microsoft очень, очень стараемся не выпускать полусырые программы. Довести программу до ума — что среди прочего означает, чтобы близорукий испанец, говорящий на каталонском, мог легко использовать любую функцию, не опасаясь создать дефект в системе безопасности — весьма недешево! Но мы должны довести ее до ума, потому что при поставке новой версии сценарного ядра сотни миллионов людей будут использовать этот код, а десятки миллионов будут для него программировать.

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

Перед вами книга Джоэла Спольски - ветерана индустрии программного обеспечения. Его электронный журнал "Joel on Software" http://www.joelonsoftware.com стал одним из самых популярных независимых веб-изданий среди программистов. Эта книга - не учебник, не документация, не набор методик и/или практик. Это классное чтиво для разработчика со стажем и мозгами. Это иллюстрации по поводу того, как можно вообще относиться к тому, что делаешь и что делается вокруг тебя. Это, в конце концов, набор сумасшедших идеек, которые могут примениться и в жизни.