• известного российского системного программиста,
• зав. лабораторией Института системного анализа РАН,
• члена Российской академии интернета,
• автора шахматной программы «КАИССА» (первого чемпиона мира среди шахматных программ),
• президента компьютерной фирмы ДИСКо,
• лауреата всех профессиональных опросов «Top-100 Российского компьютерного бизнеса».

У каждой профессии есть свой романтический период и есть период, когда она превращается в рутинную. Быть шофером в начале прошлого века было трудно и почетно. Сегодня автомобиль может водить любой желающий, а в большинстве районов США жизнь без автомобиля практически невозможна. Так профессия шофера прошла полный цикл от интеллектуальной и романтической до бытовой и повседневной за какие-то 60 лет.

Цикл профессии авиапилота тоже близится к окончанию и займет те же 60 лет.

Но время ускоряется, и новые профессии имеют гораздо более короткий цикл. Особенно это верно по отношению к профессиям, связанным с информационными технологиями.

Так получилось, что время моей жизни практически совпало с жизненным циклом моей профессии. Я – программист. Сами компьютеры появились в 40-х годах (и не надо здесь вспоминать ерунду про дочку Байрона), то есть в то же десятилетие, когда я родился.

В этой статье я хочу, вспоминая свою профессиональную жизнь, напомнить, как менялась профессия программиста.

Когда я школьником учился программировать на М-20, в СССР программистами были известные математики, на ходу выдумывавшие то, чему сейчас учат в школе.

В группе программистов Института Теоретической и Экспериментальной Физики, где для вычислительных работ ядерной физики стояла эта самая М-20, придумали массивы, списки, необходимость использования подпрограмм и многое другое. Один из моих учителей, Г.М. Адельсон-Вельский придумал хэш память. Подробности можно найти в книге другого моего учителя – А.С. Кронрода «Беседы о программировании». Еще до Дийкстры основные принципы структурного программирования были изложены А.Л. Брудно в книге «Программирование в содержательных обозначениях». Там же была создана первая шахматная программа.

А ведь в то время программировали в кодах, память под программы и переменные распределяли своими руками, и известны случаи, когда на одно и то же место грузились разные подпрограммы, и всегда работала только последняя. Всерьез была распространена так называемая «польская игра», когда надо было уложить заданный алгоритм в минимальное число ячеек памяти.

В итоге тогда шахматная программа ИТЭФ, предшественница «Каиссы», умещалась в памяти М-20, а именно в 4096 ячейках, каждая из которых имела 48 разрядов (теперь это называют битами). Где-то рядом уже существовал Алгол-60, но им «настоящие» программисты не пользовались, поскольку техники отладки практически не было. Чуть позже большую популярность получила статья «Почему настоящие программисты не пишут на Фортране».

Мои студенческие годы пришлись на целый ряд советских машин – Раздан-3 , Минск 1, 2, 22, 32, Урал-14, все из которых имели пульт, за которым сидели программисты, а программы и данные вводились с перфокарт или с перфолент. АЦПУ — устройство «широкой» печати — появилось только в конце 1960-х.

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

Рассказывают, что в операционной системе «Пульт», написанной в Вычислительном Центре АН СССР для БЭСМ-6, был счетчик ошибок оператора, и при достижении некоторого порога система выдавал «вежливое» сообщение «А если ты – дурак, то не садись за “Пульт”». Когда директор ВЦ академик А. Дородницын инспектировал систему, он понажимал несколько раз случайные кнопки и был крайне огорчен полученным результатом.

О серьезности задач, которые тогда приходилось решать на тогдашних компьютерах, говорит то, что одним из моих проектов в студенческое время была система инверсного поиска патентов для экспертов. Кстати, ВМК еще не было, было отделение вычислительной математики на мех-мате, но я учился на отделении математики. Сдавая зачет по программированию, я должен был аппелировать к своему профессору М.Р. Шуре-Буре, поскольку его аспиранты, принимавшие зачет, программировать почему-то не умели. И вообще на мех-мате программирование считалось чем-то вроде предательства чистой математики, и всерьез на моем курсе им занималось не больше десятка человек. Была даже частушка: «Меня милый не целует, не садится близко, говорит “я – математик, а ты – программистка”». А потом 90 процентов выпускников с моего курса пошло-таки работать программистами.

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

Конец моих студенческих времен совпал с революцией в компьютерах. Появились компьютеры «общего пользования с системами разделения времени. Это IBM 360, ICL 4-70, ЕС ЭВМ. Писать в кодах для таких машин стало принципиально невозможно, и на передний план вышел (как наименьшее зло) язык ассемблера. Были и другие языки программирования (Фортран, Кобол, Алгол, PL-1), но они не позволяли эффективно контролировать оттранслированный код. Мой сосед по кабинету в ИПУ М. Фурман, на мой изумленный вопрос, как ему удается программировать на PL-1, просто заметил, что он в уме транслирует все операторы, прежде чем написать их.

За 15 лет работы с ассемблером мы общими усилиями овладели этим языком так, что он стал языком более высокого уровня, чем все выше перечисленные. Под термином «овладеть языком» я имею в виду не то, что мы досконально знали его синтаксис и семантику, а то, что были наработаны библиотеки подпрограмм, приемы программирования, идиомы и многие специфические приемы, так что программы писались легко и свободно. И, главное, еще легче отлаживались и адаптировались. Те, кто писал на Фортране, оценят последние свойства.

Именно за эти годы мною и моими товарищами по работе под руководством В. Арлазарова были написаны «Каисса», «ИНЕС», АСУ МНТС (Международного научно-технического сотрудничества для ГКНТ СССР) и много конкретных прикладных систем. Где-то в это время нам пришлось расстаться с привычными перфокартами и пересесть за дисплеи, между прочим, – алфавитно-цифровые.

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

Среди них были знаменитые в мире информационных технологий люди – К. Шеннон (автор теории информации), К. Томпсон (автор операционной системы Юникс), Д.Леви, М. Ньюборн, А. Марсланд, Б. Миттман, Ф. Фридель (автор ChessBase) и многие другие.

СУБД «ИНЕС», в которой я занимался системными вопросами – генерацией и дистрибуцией системы, системой поддержки версий, для чего была написана Архивная Система — и АСУ МНТС, устанавливать которую мне пришлось по всем министерствам и республикам СССР, принесли мне много хороших знакомых по всей стране. В любой город СССР можно было поехать, и везде встречали очень тепло, даже когда устанавливаемые мною системы были принимающим, мягко говоря, не слишком нужны (как сейчас сказали бы, АСУ МНТС снижало коррупционную емкость планирования научных командировок за границу).

И мое тогдашнее хобби – спортивный бридж – тоже было источником многих дружб и знакомств. Не случайно, когда мои американские друзья приезжали в СССР, они, после очередной случайной встречи с кем-нибудь на улице, спрашивали меня «Тебя все здесь знают?».

С К. Шенноном связана одна из самых удивительных историй в моей жизни. Меня с ним познакомили в 1980 году на чемпионате мира среди шахматных программ в Линце. Каждый чемпионат имеет своего почетного гостя, и в том году им был Клод. Услышав его имя, я подумал «Как! Он еще жив?». Ведь работы Шеннона по шахматному программированию относились к году моего рождения, то есть для меня он существовал в очень давней перспективе. Оказалось, что ему в год моего рождения было меньше тридцати, и в 1980м он был еще очень не старым человеком. Когда же пришла моя очередь быть почетным гостем чемпионата мира 1999 года в Падерборне, я прочел в глазах молодых шахматных программистов все тот же немой вопрос «Как! Он еще жив?». И, поняв, что с момента моих публикаций уже прошло больше двадцати лет, я вспомнил Шеннона и успокоился.

В начале 1970-х появились машины серии «Ряд». Так получилось, что во время моего распределения после МГУ мне пришлось быть свидетелем, как А.С. Кронрод боролся за продолжение проектирования и производства оригинальных советских машин (он даже предлагал назвать серию «АС» — автоматическая советская — по своим инициалам) против В.М. Глушкова и Л.Т. Кузина, которые ратовали за копирование IBM. Одним из аргументов у последних было то, что можно будет воспользоваться всем математическим обеспечением, созданным для IBM и ликвидировать то небольшое отставание в вычислительной технике, которое имелось в конце 1960-х.

Глушков и Кузин победили (а судьей был председатель ГКНТ Кириллин), но все оказалось не так-то просто. Первый компьютер серии с трудом (титаническим трудом инженеров-электронщиков, запустивших его в жаркое лето 1972 года на ВДНХ, после чего они искупались в фонтане Дружбы Народов) был запущен в 1972 году, а массовая работа на нем – только в 1979 году. Все это время я неплохо зарабатывал лекциями по ОС ЕС ЭВМ. Документация по системе переводилась моими однокурсницами и другими людьми, не представлявшими себе, что такое компьютер вообще и операционная система в частности, и разобраться по такой документации было невозможно.

Таким образом, Глушков и Кузин просчитались именно в этой компоненте – культуре пользования. Теперь я понимаю, что неправ был и Кронрод, за которого я «болел», потому что надо было и копировать IBM и делать свои машины именно для сохранения культуры. А в итоге к 80-м мы потеряли культуру проектирования элементов, потом и культуру проектирования устройств, а сейчас от нас уходит (вместе с носителями – людьми, которые умеют это делать) культура создания операционных систем.

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

А в 80-х началась эра языка Си на машинах, скопированных с PDP и IBM PC. Мы потеряли весь свой ассемблерный «языковый запас» и так и не достигли аналогичного уровня инструментария на Си. Это была своего рода эмиграция. Привыкнув к детальному пониманию, как происходят реальные вычисления в памяти, пришлось отвыкать и работать в гораздо более абстрактных сущностях.

Зато остался интерес к базовым понятиям программирования, выходящим за пределы конкретных языков, операционных систем и устройств. Как любят говорить мои сотрудники «В конце концов, в компьютере биты бегают».

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

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

Создание собственного «языка программирования» и отладочных средств для конкретного проекта оказало решающее влияние в победе «Каиссы» на первом чемпионате мира среди шахматных программ. Большая часть программы была написана в терминах операций над «досками» — 64 битными объектами, которые задавали булево значение одновременно для всех полей доски. Эффективная реализация таких операций и их использование в алгоритмах позволили реализовывать сложные решающие правила за приемлемое время.

«Система наблюдения» «Каиссы» состояла в возможности вывода на печать хода перебора в любом разрезе, начиная с любой точки, как в партии, так и в переборе. Что важно, сама форма выдачи была «человеческой», то есть в шахматных терминах, а не в терминах программы. Во время матча «Каиссы» с читателями «Комсомольской Правды» в 1972 году результатом каждого хода была распечатка толщиной 2-3 сантиметра. И мы ее всю внимательно прочитывали. Поэтому к чемпионату мира мы знали о глубинах перебора гораздо больше, чем все остальные. В этих условиях было трудно не придумать эффективные методы сокращения перебора, которые и принесли «Каиссе» победу. Кстати, в научных кругах, матч 1972 года ценится гораздо выше, чем победа в чемпионате мира.

С течением времени программирование из тонкого ремесла, иногда восходящего к искусству, становилось ремеслом все более и более рутинным.

Если до середины 80-х еще реальны были программы, созданные если не одним человеком, то хотя бы в рамках одного коллектива, то в дальнейшем в производство шли программы, построенные по принципу «Лего», а именно, собранные из различных полуфабрикатов (библиотек и компонент), разработанных в разных уголках мира.

Как ни странно, это сделало ценность программистов с хорошим математическим (не скажу образованием, а подходом) гораздо выше. Их стали называть по-разному – системными аналитиками, руководителями проектов, системными архитекторами. И наряду с программистами, умевшими «выполнить проект» — реализовать конкретное техническое задание, — потребовались именно такие «абстрактные» специалисты, умевшие совсем другое. А именно, разбить процесс создания большой системы на проекты, выбрать для них инструментарий, подобрать исполнителей, суметь их проконтролировать и, в конечном счете, обеспечить работоспособность созданной системы. И сегодня таких специалистов приблизительно столько же, сколько было программистов в начале моего трудового пути.

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

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

Однако инструментарий инструментарием, но приходится выбирать алгоритмы обработки информации, и иногда ограничения на их трудоемкость влияют на размер решаемых задач, а, значит, и подходов. Здесь мой опыт семинара по эффективным алгоритмам и, особенно, опыт работы над шахматной программой, сыграл существенную роль. Как говорил мой соратник А. Усков «после шахматной программы все задачи кажутся простыми».

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

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

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

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

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

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

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

Как известно, персональные компьютеры победили Советский Союз (не только вышеописанным способом, а главным образом отменой монополии на информацию и разрушением барьера между безналичными и наличными деньгами).

В начале российской эпохи персональных компьютеров, случайно или не случайно совпавшей с кооперативным движением, ко мне обратился прекрасный менеджер Е. Соколинский, возглавлявший кооператив «Перспектива» с предложением реанимировать «Каиссу» для ПК. Для этого мне нужно было из работавшего в свое удовольствие ученого стать начальником группы программистов, да еще и создать эту группу с нуля. Уговорив меня, Соколинский нашел изумительный способ формирования группы. Мы дали объявление в газеты о платных курсах шахматного программирования. Стоимость месячного обучения для наших слушателей составляла 200 рублей, что по тем временам была существенная сумма. Занятия шли шесть дней в неделю и кооператив доплачивал за аренду аудиторий и компьютеров немалую сумму.

Из десяти слушателей, которых мы тщательно отобрали, только один человек пропустил одно занятие потому, что у него в этот день был выпускной из Физ-теха. Потом мы всей группой перешли в СП «Параграф».

В конце 1980-х, когда я оказался в СП «Параграф», он представлял собой своеобразную сборную лучших московских программистов. В «Параграфе» того времени работали Е.Веселов (автор «Мастера» и «Лексикона»), А. Чижов (автор многих русификаторов, в частности, знаменитой «Беты», он же автор альтернативной таблицы кодировки кириллицы) и другие. В качестве помощницы у Веселова в «Параграфе» работала О. Дергунова, получившая известность уже в Майкрософте. Игры продавал В. Савюк, потом раскрутивший марку «Денди». В общем, компания подобралась неплохая.

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

У меня в «Параграфе» был отдел шахматного программирования, в котором «Каисса» получила вторую жизнь в качестве программы для IBM PC. Хотя мы и сделали в отделе шахматную программу – реинкарнацию «Каиссы» для IBM PC, которая достойно сыграла на компьютерной олимпиаде 1990 года, заняв третье место, интерес быстро сдвинулся в сторону пользовательского интерфейса, поскольку графические оболочки Мака и Windows очень манили в эту сторону.

Наш отдел, в котором работали А. Дубец, М. Караев, В.Кокин, И. Шабалин и другие, открыл целое направление графических редакторов. Мы сделали редактор формул, а, уже уйдя из Параграфа, и редактор факсов, а потом и новую версию Лексикона.

Оказалось, что общее всех этих редакторов – разбиение на три составляющих: данные, их отображение и собственно редактор, преобразующий данные согласно действиям пользователя, -является фундаментальным для систем пользовательского интерфейса. Недаром операционная система Symbian базируется на таком разбиении.

В это же время пришлось осваивать C++. Мое знакомство с этим языком началось с экскурсии в офис Bell Laboratories в Murray Hill, которую мне устроил в 1989 году автор Юникс Кен Томпсон. Мы с сыном жили у Кена в гостях, и в воскресный вечер он предложил прокатиться в офис. Офис был безлюден, и я с интересом смотрел на технические чудеса, которых там хватало. В какой-то момент Кен показал на дверь кабинета со словами «А здесь сидит чудак, который думает, что на его языке будет программировать весь мир». Табличка на кабинете гласила, естественно, «Б. Страутсруп».

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

Зато C++ позволил вернуться к эффективному созданию инструментальных средств. Наборы идиом, библиотечных классов, правила пользования, все это стало багажом наших программистов, сделав их работу более легкой и приятной.

После ухода из «Параграфа», я не смог найти другую работу, в основном по принципу «двух медведей в одной берлоге», когда начальник не хотел иметь в команде еще одного лидера. Поэтому в 1994 году мне пришлось заняться бизнесом, организовав свою фирму «ДИСКо» (Donskoy Interactive Software Company), существующую по сей день. Фирма занимается разработкой программ на заказ. Основными клиентами являются крупные фирмы, работающие в области информационных технологий. Связано это, в первую очередь с тем, что доказывать разумность нашей ценовой политики клиентам из других отраслей крайне сложно. Они искренне полагают, что любую программную систему можно сделать одному человеку за месяц. Ситуация усугубляется тем, что рынок полон дешевых предложений, связанных либо с самонадеянностью вчерашних студентов, либо, что еще хуже, с сознательным затягиванием клиента с целью дальнейшей раскрутки его уж на совсем большие деньги. Это напоминает «бесплатные» лекции по народной медицине, где вход формально свободен, а выход фактически с пустым кошельком.

Фирмы в отрасли информационных технологий гораздо более адекватно оценивают и стоимость работ и их исполнителей. Рынок наш небольшой, все фирмы на виду, репутации известны. Известны, к сожалению, только внутри отрасли. Тем не менее, заказов хватает.

До кризиса доткомов «ДИСКо» работало в основном на рынке США, но после него пришлось переориентироваться на российский рынок. Одну вещь после этого перехода пришлось прочувствовать сразу. В Америке ни один менеджер не ведет переговоры вне рамок своей компетенции и, особенно, вне рамок своего бюджета. В России, особенно на первых порах, много раз приходилось, уже придя к соглашению по всем параметрам проекта – техническим требованиям, цене, срокам, — слышать замечательную фразу «А теперь я пойду согласовывать это с начальством». Эффективность переговоров с такого рода менеджерами, мягко говоря, невелика. Отсюда – нацеленность «ДИСКо» работать с крупными кампаниями, про которые ясно, кто есть кто.

В начале этого тысячелетия пришлось сделать еще один крутой поворот. На этот раз — в сторону мобильных устройств и всего, что с ними связано, в первую очередь, беспроводными технологиями связи. Поскольку первые заказы были американскими, приходилось убеждать авторов технологий в их «незрелости» для практического использования. Слышать это от маленькой российской фирмы им было странно. К счастью, это потом подтверждалось и другими, более авторитетными источниками. Так было, например, с технологией BlueTooth, про которую было много критики на CeBit-2002. Мы сделали пилотный проект для разных средств связи по заказу 3COM, и, если инфракрасная связь и WiFi работали прекрасно, то с BlueTooth были серьезные проблемы.

Однако с 2004 г. с BlueTooth стало все в порядке, а мобильные устройства становятся все популярнее и популярнее. Хотя карманные компьютеры и сходят на нет, их с успехом заменяют (а может, и вытесняют) смартфоны, имеющие все прелести и карманных компьютеров и мобильных телефонов. Для лэптопов и ноутбуков сейчас тоже очень хороший сезон. А впереди маячат планшетные компьютеры и сетевые и многое другое.

Весь этот зоопарк мобильных устройств объединяет одно существенное свойство – умение работать вдали от офиса. И тут интересно заметить, как многолетнее желание иметь компьютер всегда на связи с Интернет входит в противоречие со способом пользования мобильным компьютером. И дело не только в том, что пройдет еще существенное время, когда Интернет будет доступен отовсюду – из самолета, из далеких стран и много еще откуда, где он сейчас не доступен, — но и в том, что инструментальные средства Интернета (браузеры и встроенные в них объекты) не слишком пригодны для многих практических нужд. Например, заполнение в Интернете формы из нескольких страниц, особенно, если последующие страницы зависят от полей предыдущих, хотя и возможно, но слишком часто приводит к неудачам, как вследствие ошибок заполнения, так и вследствие обрывов связи.

Мы прочно стоим на идеологии сеансовой связи. Она состоит в том, что клиент (мобильный компьютер) связывается с сервером только время от времени, синхронизуя данные в обе стороны, то есть, передавая данные, измененные на клиенте на сервер, в ответ получая данные, измененные на сервере. Изысканные схемы обмена могут строиться так, что на клиент передаются только те данные, которые нужны на ближайшее время. Примером может служить сеанс связи руководителя предприятия перед поездкой к партнеру. Во время этого сеанса можно загрузить на мобильный компьютер всю информацию о взаимоотношениях с этим конкретным партнером – договора, сделки, расчеты – и иметь ее под рукой во время переговоров.

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

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

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

Похожая история должна произойти с Symbian, операционной системой, установленной на телефонах Nokia и Sony Eriicsson. Подход ее авторов тоже был минималистским. Она, конечно, лучше, чем Палм, но все равно, крайне трудна для программистов. А именно программисты решают все. Самой лучшей операционной системой последние 30 лет является Юникс, но плохой пользовательский интерфейс привел к тому, что более популярно изделие Майкрософта.

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

Сила Майкрософта не только в больших деньгах, вкладываемых в раскрутку продуктов, иногда не совсем работающих, а и в армии программистов, умеющих работать в этой системе, и в куче полуфабрикатов, которыми могут пользоваться эти программисты. Для меня, например, разработка программы для Windows по себестоимости вдвое дешевле, чем разработка аналогичной программы для Symbian. Нетрудно догадаться, какую систему я рекомендую своим заказчикам.

Пока последний поворот в моей программистской биографии – видео в Интернет. Интернет, точнее, мировая паутина – это особая тема для разговора. Она обладает врожденным пороком. Это — система, придуманная для обмена гипертекстовой информацией в распределенных сетях. Однако за свои 13 лет, начиная с появления «Мозаики», паутина эволюционировал в сторону системы доступа к гигантскому хранилищу информации.

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

В итоге получился суп из топора. Сегодня принятый как стандарт формат представления информации в Интернет (HTML) является сдерживающим фактором для построения интерактивного контента. Но, как и в случае с левосторонним автомобильным движением, сменить его крайне трудно. Ведь можно потерять накопленную за десятилетие информацию, да и пользователей так быстро на новые браузеры не переведешь.

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

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

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

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

Приходящая же в профессию молодежь, не имеет такого запаса. И не столько потому, что глупее, а потому, что их не так учат. В моей молодости обучение программированию в институтах было вообще смешным – изучались только синтаксисы разных языков на простейших программах. Сейчас дело обстоит чуть получше, но я не слышал, чтобы во время сдачи курсовой или дипломной работы студенту на ходу меняли техническое задание. А мне в жизни приходилось, сдавая большую систему с удивлением узнавать об изменении формата входных данных. Я считаю такую ситуацию нормальной, а молодые программисты – издевательством. Почти все учащиеся ВУЗов решают сделать дипломную работу на заказ из-за того, что такая работа требует много времени для ее подготовки. Размер дипломного изыскания может быть или от 50 до 70, или около 80-100 страничек. Могут быть и другие требования, которые зависят от конкретного учебного заведения.

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

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

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

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

В итоге профессия программиста меняет свой характер. Если раньше программисты знали свою программу досконально, то теперь в лучшем случае они умеют эффективно использовать то или иное инструментальное средство. Появились вообще странные на мой вкус термины как «программисты на PHP и HTML».

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

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

Просто, в Москве я жестоко не высыпался. Надо было поговорить, почитать, подумать, посетить, встретиться с кем-то еще. В какой-то момент начал действительно бегать по улицам и метро, как это представляют себе все живущие за МКАД. Там, если не бегать, действительно никуда особо не успеешь.

План подготовки к конференции был по-наполеоновски прост: собран список людей, с которыми очень хочется поговорить, надо только посетить их доклады, выявить в толпе, и пообщаться.

В действительности, как всегда…

Однако я очень постарался, и в следующие недели у меня запланированы сплошные пересказы звуков интервью во внятные тексты интервью. Ради этого я слегка придушил все текущие проекты, над которыми традиционно работаю по вечерам. Отложен даже проект «Выспаться».

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

Вообще, дилемма «или слушать доклады, или искать общения» передо мной не вставала. Она лежала, придавленная аргументом «разговаривать интереснее», поэтому «краткий отчет о прослушанных докладах» здесь неуместен. Не пересказывать мне краткое содержание или ощущение от докладов, на которые уже не сходить… Зато я смог узнать не только то, что входило в некоторые доклады, но и причины их появления, тот background, который почти всегда скрыт и не очевиден, и наиболее интересен.

Попадайте под наш маховик!

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

Для московских студентов ситуация сложилась благоприятнее, нежели для молдавских — большие компании стараются обучить юных работников «своим» технологиям, а после окончания учебы — «забрать» юную душу к себе в разработку. Пусть и ненадолго. Благодаря засилью уже установленных процессов в крупных компаниях и обучающих программ, все это возможно. Маховик запущен и требует рабочей силы, поэтому неудивительно. Даже если позже повзрослевшие студенты разбегутся… А может быть, и не разбегутся, мало ли.

А вот в Кишиневе, и всех его клонах на территории СНГ, компании любого калибра, в первую очередь, вынуждены искать тех, кто уже УМЕЕТ работать.

Идея «а вот когда я наконец-то уеду в Канаду (Россию, Румынию, Кипр, Албанию)…» у нас всё ещё бытует на очень подспудном уровне, и бытовое окружение эту идею только подпитывает. Работать с настолько идейной молодежью сложно. Вон, французы из Pentalog даже проводили общественные слушания на тему «Да сделайте же вы что-нибудь, чтобы ваша молодежь не разбегалась, а то мы не знаем, как пережить сложности с наймом нужного количества людей под наши проекты…»

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

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

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

Вы на каком языке говорите?

SECR 2009 представлялся как место встречи разработчиков и тестировщиков. Наверное, следовало каждому представителю определенной гильдии носить какие-нибудь знаки различия, например, бумажные колпаки разных цветов — все равно ведь кучковались среди «своих».

Кто может поддержать беседу о методах автоматической выборки юнит-тестов, которые следует прогонять после внесения изменений только в определенные места в коде? Я?! Не…

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

Но поддержать мысль и развить…

Сергей Архипенков (справа) рассуждает «за тестировщиков»

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

«Дедушка русского тестирования», Александр Александров, восхитил неубиваемой способностью отвечать на все мои вопросы. Ответов в нем хранится больше, чем можно предположить.

С Ларсом Баком, разработчиком браузера Chrome, контакт наладился очень быстро — я спросил его только об аспектах тестирования в его работе. Кажется, он понял мой английский. Во-всяком случае, я понял ЕГО английский.

Стас Калканов оказался именно таким, каким он кажется по его ЖЖ. Знаток и поклонник системности во всем. В системах всему есть свое место. Аудит процессов, которым он занимается, является для него органичной, логичной, наиболее подходящей профессией.

Асхат Уразбаев оказался почти высоким. Ну, почти как я. Но оба мы не так крупны и основательны и в поведении, и в речах, как Владислав Орликов.

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

Юля Нечаева как-то незаметно, но эчень элегантно заполняет вокруг себя любое пространство. Сколько ей выдели, столько там ее и будет — два метра в толпе, комнату, зал, и, наверное, целую Красную площадь. Редкое позитивное качество. Обычно пространство невыносимо заполняют нахальные нахалы — это не тот случай.

Александр Орлов, таки да, действительно «лысый». И хотя пребывал он в очень усталом виде (увлекается многочасовыми перелетами и переездами из Лондонов по Финляндиям, Питерам и Москвам), все равно было заметна натура цельная и планомерная.

Полагаю, что есть какое-то явное благо в том, что следующая конференция «SQA Days» (май, 2010, Харьков) будет заселена только тестировщиками. Адекватность твоих собеседников определяется, в первую очередь, твоей личной адекватностью и способностью рассуждать на предложенные темы.

Хочется верить, что в докладах SQA Days 2010 все известные темы уже будут рассматриваться на уровне «максимум практичности и минимум толковательных теорий из разряда «как надо поставить процесс». Как надо — каждый знает. У нас с воплощением постоянные сложности.

У программистов постоянно есть о чем поговорить в очень утилитарном плане именно потому, что общие темы у них уже давно устаканены. На том же Хабре в епархии программистов постоянно появляются новые материалы из разряда «How To» применительно к определенным инструментам и сервисам.

А в полушарии тестировщиков — все больше анонсы тренингов да поздравления с очередным ежегодным «днем первого бага, который залетел в компьютер»…

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

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

По верхам

Еда — приличная. Не съезд дегустаторов имени Эскоффье.

Организация — знаю, из каких мелочей складываются подобные мероприятия, и понимаю, что иногда в погоне за чем-то важным некоторые мелочи остаются неохваченными. Но, все-таки, очень был удивлен, когда открыл диск с надписью «Разработка ПО 2009». Ожидал найти там все презентации конференции, а нашел только два крупных pdf-файла с перечнем докладов и их краткими анонсами — те же материалы, что и на сайте конференции, на русском и на английском языках. Свободного места на диске осталось очень много.

Координация мероприятия ничуть не напрягала, все происходило вовремя и при наступлении необходимости. Это очень существенный плюс.

Качество помещений тоже отмечабельно. Был большой зал, в стиле «концертный», был малый зал, в стиле «камерно-концертный», был холл, переделанный в зал, и был большой коридор между всеми этим помещениями — всё очень хиппово и уместно.

Организаторы!

Большое спасибо!!!

Послевкусие от участия

Чем-то конференции подобного рода сравнимы с Олимпиадами.

Вранье, что в Олимпиаде главное — участие. В спорте вообще не бывает второго и третьего почетного еста, есть только первое. Или ты на коне, или иди домой пешком.

Но участие в Олимпиаде действительно ценный опыт для любого портсмена. Можно быть чемпионом двора… но надо сравнивать себя с другими чемпионами. Поставить рекорд дома — это круто. Поставить рекорд на Олимпиаде — круто вдвойне.

Ценность Олимпиады в том, что все ее участники находятся в одинаковых условиях — одно поле, один ветер, один судья.

Вот для того, чтобы было понятно, куда, как и зачем двигаться дальше, надо ходить на Олимпиады.

То есть, да, конференция в чем-то — соревнование.

PS Москва спроектирована таким образом, что каждое здание, которое следует легко находить, очень хорошо и непонятно где спрятано. Например, вздерзнулось мне отлучиться от места проведения конференции всего на полчаса, и на обратном Столица силком завернула меня в какой-то Лялин переулок, и, напугав созвездием проулков и странной вывеской «Булошная», долго не выпускала на истинный путь.

habrahabr → Тестирование → Тестирование ПО: как объяснить руководителю, что 2 х 2=4?

Простой, но внезапный вопрос чуть не поставил в тупик: «Почему тестировать должны тестировщики, а не аналитики, разработчики или пользователи?»

К записи 55 комментариев, и ни одного внятного ответа.

Далее следует мой любительский и очень краткий, буквально тезисный перевод свежей заметки «Top 10 reasons why there are Bugs/Defects in Software!» от 15 дек 2008.

Наверное, это ответ на процитированный вопрос хабрахабравчанина.

Почему в программном обеспечении бывают ошибки?

1. Человеческий фактор

   Софт делают люди. А люди не совершенны.

   Собственно, на этом пункте можно и остановиться, настолько он всеобъемлющ и великолепен…

2. Проблемы в общении

   Расхождение между ожидаемым и фактическим, когда «Мы же думали, что вы имеете ввиду…» и «Имеем мы ввиду то, что вы там думали…»

3. Нереальные сроки разработки

   Недостаток временных ресурсов так же критичен, как и недостаток финансирования.

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

4. Плохой дизайн софта

   В эпоху комплексного программного обеспечения для поиска наилучшего решения постоянно приходится балансировать на гранях предположений, догадок и понимания о том, что, собственно, кодим…

5. Кривые руки кодеров

   Иногда ошибки возникают как следствие плохого кодинга…

6. Плохой контроль версий

   Недостаточный или же поверхностный контроль версий кода — логово багов, которые «вылезают» при регрешне.

   Да, это страшно!

7. Дефекты во внешних приложениях

   Иногда проблема может быть не только в том, что делаем, но и в том, посредством чего делаем.

   Плохому танцору вечно что-то мешает…

8. Низкие навыки тестирования

   Тестировщики в этом не признаются, но будем честны: это бывает.

   Самое время для того, чтобы сказать «Вооот! Нет тестировщиков на проекте, ну и воооот вам…»

9. Изменения «в последнюю минуту»

   Изменения могут быть внесены в последнюю минуту и в требованиях, и в инфраструктуре, и в инструментах девелоперов, и в платформе…

Эй, пацаны, а вы заметили, что я обещал десять пунктов, а написал только девять? Аааа, это же страшный баг! Почему бы вам самим не приписать тут десятый (11-тый, 12-тый…) пункт?

Один из комментариев к переводимому тексту принадлежит сэру Кему Канеру. Суть:

Development groups rely on test groups the way that countries rely on regulators. We trust them to do their work well and we do other things ourselves instead of redoing the work that we know will be done by the testers (regulators). If the testers do their work poorly, problems stay in the product — partially because the testers don’t find them and partially because the testers don’t alert management to more general trends of weakness that cause corrective action in design and programming.

So, I agree, in some contexts, bad testing can certainly lead to lower quality.

Автор блога немедленно распоясался 🙂

@ Dr. Cem Kaner,

You have made me the Happiest tester today by leaving behind your comment on my blog.

It is a privilege and honor to have comment of a testing guru like you on my post, who also happens to be one of the pioneers of Context Driven Community.

It is simply brilliant how you correlated regulators (Security and Exchange Commission) with testers.

Оно и понятно…

Тщетно пытается программист уточнить, какая именно труба должна получиться в итоге — иногда клиент этого не знает.

Пытается программист уточнить, зачем эта труба клиенту нужна. Умудренный знает, что клиенту этой информацией делиться нафиг не нужно. Что ему труба нужна. Или пирожок 🙂 Но пытается.

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

«How to test software with dynamic requirements?» — достаточно вменяемая статья на тему нестандартных труб, исходя из всей доступной «широты» этого вопроса.

Решение в этому случае достаточно взвешенное, хотя и местами рисковое — чек-лист.

Кто незамутненно уверен в том, что чек-лист — стопроцентная панацея в работе тестировщика, тот дурак. Зависит от проекта и уровня образования тестировщика. Например, без понимания софта тестировать в таком режиме почти невозможно. А вот по тест-кейсам может тестировать любой товарищ, даже не понимающий, что именно оне изволят-с тестировать и зачем. Доказательство.

Или MindMap.

Вот пример карты в MindMap (required Flash). В примере я показал часть того, что должно было быть сделано программистом в отношении гипотетической задачи «ER-678».

Это все было расписано не в требованиях, а размазано в комментариях к задаче. Занести все это в MindMap и как следует раскидать по логикам вещей — 7 минут. Проще, чем просить письмо с однозначными требованиями и громко предпочитать работать в гетеросексуальном коллективе.

Сколько времени занимает само тестирование — уже не так важно, it’s depends… Важно то, что если какое-то требование будет изменено через час, его изменение займет в этой карте минимальное время, и все равно будет понятно, что и как надо делать. А если будет добавлено что-то новое, то и в карту его добавить несложно.

Интереснее всего то, что будет видно потом. Видно, что в пункте «all the other checkboxes should be unchecked and greyed out» возникли какие-то проблемы… И в комментарии указано, что по этому поводу открыт новый баг в баг-трекере.

MindMap позволяет очень и очень грамотно и гибко сортировать топики по разным признакам — пользуемся Queries.

Запись по всяким соображениям удобностей доступна на

http://testitquickly.com/2009/01/16/excel-calc-drop-down-list/

Текст чуток уточнен и улучшен.