Во что обходятся провалы?

Часть перфекционистов в индустрии разработки ПО чрезмерно озабочена провалами, а большинство других не подвергают вдумчивому анализу ценность бесперебойной деятельности. Тем не менее, обычно при тщательной оценке стоимости провала мы видим, что повышение надежности программного обеспечения может принести огромную пользу. В книге “Responding to Significant Software Events” я представляю пять примеров, которые вас убедят.

Национальный банк государства X выдал займы всем банкам страны. Крошечная ошибка в вычислении процентной ставки стоила более миллиарда долларов, которые национальный банк так и не смог восполнить.

Коммунальное предприятие изменяло алгоритм выставления счетов в соответствии с изменением ставки оплаты труда (эфвемизм коммунальщиков для “повышения тарифов”). Процедура сводилась к корректировке нескольких численных констант в существующей программе биллинга. Незначительная ошибка в одной константе приумножилась миллионами потребителей и вылилась в X долларов, безвозвратно потерянных предприятием. Я говорю “X долларов”, поскольку слышал эту историю от четырех разных клиентов с различными значениями X. Оценка потерь варьировалась от 42 миллионов до 1,1 миллиарда долларов. Учитывая, что такая история произошла с четырьмя моими клиентами, и лишь малая часть коммунальных компаний пользуется моими услугами, я уверен, что на самом деле такие случаи бывали намного чаще.

О следующем случае я узнал из общедоступной прессы, поэтому могу сказать, что речь идет о New York State Lottery. Законодательный орган штата Нью-Йорк разрешил проведение особой лотерии в целях сбора дополнительных средств на одно достойное дело. Поскольку эта лотерея отличалась от обычной лотереи, в программу для печати лотерейных билетов нужно было внести изменения. К счастью, модификация заключалась в изменении одной цифры в существующей программе. Крошечная ошибка привела к печати билетов-дубликатов, а общественное доверие к лотерее было подорвано и сопровождалось убытками, оцениваемыми в пределах между 44 и 55 миллионами долларов.

Другую историю я знаю со стороны, как клиент одной большой брокерской фирмы. Однажды фиктивная строка с 100.000$ была напечатана в сводках 1500000 аккаунтов, и никто не знал причин ее появления. Суммарная стоимость этого провала составила по меньшей мере 2000000 долларов, а причина заключалась в простейших ошибках при программировании на языке COBOL: не очищалась строка в зоне печати.

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

Сценарий Больших Провалов

В каждом из исследованных случаев события развивались согласно универсальному сценарию:

1.   Есть работающая система, которая считается надежной и архиважной

2.   Запрос на быстрое изменение в системе обычно исходит от высокопоставленного лица в организации.

3.   Изменение признается “тривиальным”.

4.   Никто не замечает, что пункт 3 говорит о сложности выполнения изменений, а не о последствиях их выполнения или последствиях допущенных при этом ошибок.

5.   Изменение проводится без каких-либо мер предосторожности, типичных для разработки ПО и внедренных в организации (пусть в минимальном объеме).

6.   Изменение проводится непосредственно в системе, выполняющей повседневные операции.

7.   Точечный эффект от изменения невелик, поэтому никто не замечает его сразу.

8.   Этот скромный эффект приумножается многократными операциями и приводит к большим последствиям.

Всякий раз когда мне удавалось отследить действия руководства, предпринимаемые вслед за убытками, я обнаруживал продолжение универсального сценария. После выявления провала:

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

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

11.   Руководитель группы понижается в должности до программиста – наверное, вследствие продемонстрированного (не)понимания технических аспектов работы.

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

13.   Вышестоящие менеджеры остаются нетронутыми. В конце концов, что они могли сделать?

Первое Правило Предотвращения Провала

Осознав Универсальный Сценарий Гигантских Потерь, вы знаете как поступать в ответ на высказывания такого рода:

Когда вы слышите, как кто-нибудь считает нечто слишком маленьким и недостойным внимания, будьте начеку. Вот Первое Правило Предотвращения Провала:

Нет ничего слишком маленького, чтобы оно было недостойно внимания.

Все может быть иначе

Истории катастроф всегда служат хорошим предметом новостей, но наблюдение за ними может исказить реальность. Если мы рассматриваем только катастрофы в разработке ПО, мы упускаем все организации с эффективным управлением. Но хорошее управление так скучно! Не происходит ничего достойного публикации в прессе. Или почти ничего. К счастью, мы изредка встречаем согревающие душу истории, как, например, публикация в Financial World, рассказывающая о Чарлзе T. Фишере III из NBD Corporation, одном из титулованных CEO восьмидесятых:

“Когда компьютеры Comerica начали извергать ошибочные отчеты своим клиентам, Фишер ввел Контроль Гарантированной Производительности, обещая 10$ за каждую ошибку в месячном отчете клиента NBD. В течение двух месяцев корпорация NBD заявила о 15000 новых клиентов и более чем 32 миллионах долларов в новых аккаунтах.”

История умалчивает о том, что происходило в недрах департамента Информационных Систем, когда его сотрудники осознали, что их CEO Чарлз Т. Фишер III установил стоимость их работы. Я не присутствовал при этом, но могу предположить эффект от осознания того, что каждая непредотвращенная ошибка стоила бы 10$ наличными.

Второе Правило Предотвращения Провала

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

Потеря X долларов всегда является ответственностью управленца, чья финансовая ответственность превышает X долларов.

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

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

Учиться у других

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

Вот вопрос на проверку ваших познаний в разработке ПО:

Каков самый ранний, дешевый, легкий и наиболее практичный способ обнаружить провалы?

И вот ответ, который вы, возможно, не ожидали:

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

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

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

(По материалам книги Responding to Significant Software Events)
Оригинальная публикация: http://secretsofconsulting.blogspot.com/2011/01/universal-pattern-of-huge-software.html

Ранее мы выделили 32 прощальных послания (post-mortem), в которых предприниматели анализировали причины провала созданных ими стартапов и были столь любезны поделиться уроками, извлеченными из неудач. Многие читатели заинтересовались наиболее типичными причинами краха, которые можно выделить из представленных публикаций.

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

20. Организация компании в неподходящее время

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

Наш анализ поддерживался статьями в Wall Street Journal и NYT, а также индексом предметов искусства Mei Moses , согласно которому рынок был антициклическим и имел слабую корреляцию с S&P. Но мы не учли величину текущих колебаний и их влияние на дискретный уровень затрат на предметы роскоши в кругу клиентов, которым наш продукт по-прежнему был по карману. Очевидно, мы ошиблись в своей возможности расти на фоне грядущего экономического спада.

19. Неполный рабочий день

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

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

18. Дислокация, дислокация, дислокация

Дислокация оказалась важной в двух аспектах. Во-первых, должна быть согласованность между концепцией вашего стартапа и местоположением. Грубый пример: если вы создаете инновационное программное обеспечение для торговли на Wall Street, находитесь рядом со своими клиентами для наилучшего взаимодействия с ними. Местоположение также сыграло свою роль в неудачах распределенных команд. Ключевой момент для распределенной команды: найдите эффективные методы коммуникации, иначе отсутствие командной работы и планирования может привести к провалу. Нюансы местоположения назывались в качестве причины неудач в 6% случаев. В своем прощальном письме создатель сервиса микроблоггинга Nouncer рассматривает решение разместиться в Нью-Йорке как фактор, повредивший его компании:

В моем случае в Нью-Йорке не ощущалось нехватки денег, сообщества, достойных сотрудников и умных людей, способных дать хороший совет. Для успеха моего продукта не хватало целевой аудитории – ранних последователей, веб-хакеров, ищущих новую клевую игрушку. Я мог рассчитывать лишь на малое количество людей, встреченных на редких нью-йоркских тусовках, которые подходили под это описание. В Сан-Франциско такие конференции можно было найти каждый день, не говоря уже о неформальных сборищах, где люди “пачкали руки”, играя с программным кодом. Это очень специфичная аудитория, выбор которой был обусловлен моим решением не создавать продукт для широкого круга клиентов.

17. Неспособность привлечь инвесторов

Эту причину можно было счесть родственницей причины №20 (организация компании в неподходящее время), если бы не группа основателей стартапов, откровенно заявивших о неспособности привлечь инвесторов как причине заката своей деятельности. Если у вас нет денег для реализации идеи, пересмотрите состояние рынка и свои подходы.

16. Вытеснение на второй план

Вопреки банальным утверждениям, согласно которым стартапам не следует уделять внимание конкуренции, в реальности происходит так: как только свежая идея получает одобрение рынка, на сцене появляется много соперников. И хотя навязчивые мысли о конкуренции не прибавляют здоровья, ее игнорирование привело к неудаче 10% стартапов. Marc Hedlund, руководитель Wesabe (сервис для управления персональными финансами) рассказал об этом в своих прощальных заметках:

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

15. Выгорание

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

14. Потеря фокуса: распыление

Отвлечение на “а что если” было множество раз названо в качестве фактора, способствовавшего провалу. Важно запустить на рынок одну вещь и сфокусироваться на одном продукте, иначе вы рискуете остаться с большим количеством почти готовых продуктов, которые не представляют ценности для вас или ваших клиентов. В последней заметке о проекте Kiko его основатель Mahesh Piddshetti пишет:

У большинства предпринимателей есть куча идей. Зачастую многие из них действительно хороши. Я не знаю, как у вас, но мое излюбленное занятие, связанное со стартапами – разговор о новых продуктах и бизнес-идеях. Творческой личности легко отвлечься на побочные идеи в то время когда вам реально нужно работать над основной задумкой. Это плохо. Плохо, плохо, плохо. В Kiko такое случалось с нами много раз, и это привело к большим задержкам с выходом продукта.

13. Разногласия с инвесторами/cooснователями

Разлад с сооснователем стал одним из наиболее фатальных факторов для компаний. Сооснователь Bricabox рекомендует: “Когда сооснователь покидает компанию (как в случае со мной), вам уже нанесен сокрушительный удар. Не усугубляйте ситуацию бременем заботы о капитале компании, оставшейся на ваших руках (инвесторам не понравится, что второй акционер отсутствует – даже если он уже не имеет никакого отношения к компании). Поэтому наилучший вариант в такой ситуации – длинный-длинный срок ограничения на обращение акций для всех ключевых сооснователей.”

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

12. Недооценка круга общения

Мы часто слышим, как организаторы стартапов сокрушаются о нехватке деловых контактов. Нас удивило, что в качестве одной из основных причин неудачи предприниматели называют неэффективное использование собственной сети общения. Об этом говорится в 16% прощальных заметок. Чему учит нас этот факт? Если у вас есть сеть общения (она есть у каждого), будьте осмотрительны с этим ресурсом, но ни в коем случае не забывайте о нем.

11. Вопросы ценообразования

В ценообразовании одна часть наука и десять частей искусство. И это темное искусство, судя по большому количеству стартапов, которые потерпели неудачу и выставляли слишком большую или слишком маленькую цену за продукт. К примеру, один предприниматель сказал: “Потребовалось немало ключевых цепочек с покупкой за 50 центов и продажей за 1,25$, чтобы оплатить телефонные счета”. Основатель EventVue заметил, что их смертельной стратегической ошибкой было “следование модели продаж в корпоративном секторе с каждый раз новой маленькой ценой”.

10. Продукт, недружественный пользователю

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

9. Запоздалый отказ от убыточного пути

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

8. Нехватка страсти и специфических знаний

В мире рождается много хороших идей, но создатели угасших стартапов считают остутствие интереса к выбранной области и нехватку специфических знаний ключевыми причинами провала вне зависимости от того, насколько идея хороша. Сооснователь Untitled Partners заявил: “Я недооценил важность взаимосвязи между нашими корпоративными и личными интересами”. Нехватка страсти как причина краха фигурирует в 18,8% случаев. В своем последнем обращении основатели NewsTilt откровенно говорили об отсутствии интереса к выбранной отрасли:

7. Выпуск продукта в неподходящее время

Если вы выпускаете продукт слишком рано, пользователи могут сбросить его со счетов как недостаточно хороший. Если первое впечатление пользователей было отрицательным, вернуть их назад будет трудно. Если вы выпускаете продукт слишком поздно, вы можете упустить благоприятное стечение обстоятельств. “Здесь требуется баланс. Если речь идет о мегапопулярном веб-сайте, от которого зависят пользователи, скажем, Ebay или Mint.com, то его недоступность может обернуться катастрофой. Но если речь идет о сайте, подобном Twitter, то простой могут счесть шуткой. Знайте свой сайт, не затягивайте до бесконечности его выход на рынок. Но если он критически важен для пользователей, обеспечьте надежность его работы». Как сказал Reid Hoffman, “Если вы не испытываете определенных трудностей при запуске версии 1.0 своего продукта, вы выпустили его слишком поздно”. Неподходящее время выхода продукта было названо причиной краха в более чем 20% случаев.

6. У меня есть продукт, теперь мне нужна бизнес-модель

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

5. Деньги кончились

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

Единственная важная причина, по которой мы закрываем проект – у нас кончились деньги. Несмотря на ЧРЕЗВЫЧАЙНО бережливое управление компанией, наличие выручки и готовность держаться до конца, у нас не было денег для продолжения работы. Следующие несколько причин могут пролить больше света на наше решение закрыться вместо того чтобы найти другой источник денежных средств.

4. Слабый маркетинг

Понимание целевой аудитории, знание способов заполучить внимание пользователей и умение в конце концов превратить их в клиентов – одни из наиболее важных навыков в успешном бизнесе. Тем не менее, в 30% провалов неэффективный маркетинг стал главной причиной неудачи. Зачастую неспособность заниматься маркетингом была отличительной чертой основателей. Им нравилось писать код и строить продукт, но у них отсутствовала тяга к продвижению продукта. Ребята в проекте Devver подчеркнули крайнюю важность заполучить кого-нибудь, кто любит создавать и находить каналы дистрибуции, развивать деловые связи.

3. Неподходящая команда

Наличие разноплановой команды с взаимодополняющими навыками часто выдвигалось в качестве критически важной составляющей успеха стартапа. В прощальных записках зачастую слышались стенания вида “вот если бы у нас был CTO с самого начала” или “основатель, которому бы нравилось заниматься деловыми вопросами”. В некоторых случаях команда основателей желала более глубокого контроля действий друг друга и достижения баланса. Как заметил основатель Nouncers, “Теперь мне ясно, что базовой проблемой было отсутствие партнера, который мог меня сбалансировать, а также тщательно анализировать принимаемые деловые и технические решения”. Основатель Wesabe также отмечает, что решения, касаемые деятельности предприятия, он упорно принимал в одиночку и потому в неудаче Wesabe не может обвинить никого кроме себя. Нехватка умений в команде называлась в качестве причины провала почти в каждом третьем случае.

2. Решение интересной задачи вместо нацеливания на потребности рынка

Выбор интересной задачи вместо решения задачи, соответствующей требованиям рынка, часто назывался в качестве причины неудачи. Конечно, вы можете создать приложение и посмотреть, что с ним будет, но лучше заранее знать потребности рынка. “Компании должны браться за проблемы рынка, а не за технические задачи”, утверждает основатель BricaBox. Одной из основных причин провала BricaBox было стремление решить техническую задачу: “Здорово уступать своим желаниям, но лучше всего если ваши желания находят отклик на широком рынке. Если вы хотите решить техническую проблему, соберите группу и создайте проект с открытым кодом”.

1. Негибкость и отсутствие активного внимания к отзывам клиентов

Игнорирование своих пользователей – проверенный способ прийти к неудаче. Несмотря на очевидность этого постулата, отказ от него назывался первейшей причиной краха. Узость взглядов и пренебрежение отзывами пользователей – это фатальные упущения для большинства стартапов. Например, основатель компании eCrowds, создавшей систему управления веб-контентом, отметил: “Мы потратили слишком много времени, создавая систему для себя и не получая обратной связи от потенциальных клиентов. Легко оказаться в ситуации с ограниченным полем зрения. Я рекомендую не затягивать больше чем на два-три месяца получение объективного мнения потенциальных клиентов”.

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

Оригинальная публикация: http://www.chubbybrain.com/blog/top-reasons-startups-fail-analyzing-startup-failure-post-mortem/

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

DTrace была разработана в компании Sun Microsystems, и открытый код всех ее компонентов был опубликован в том же 2005 году. С тех пор DTrace была перенесена в Mac OS X, QNX и FreeBSD, и появилась также во всех дистрибутивах, унаследовавших код ядра Solaris: Belenix, Korona, Nexenta, OpenIndiana и Milax. Разумеется, в Solaris технология DTrace тоже осталась и даже развилась – датчиков стало больше. В настоящее время DTrace доступна в самой свежей версии Solaris 11 Express, равно как и в Solaris 10.

По сравнению с другими средствами сбора информации о системе и отладки приложений, DTrace обладает рядом уникальных свойств:

Основным компонентом DTrace является модуль ядра, обеспечивающий функционирование подсистемы DTrace, а основным инструментом – приложение dtrace, которое воспринимает скрипты, написанные на языке D, созданном специально для работы с DTrace. В этой заметке мы не будем вдаваться в детали реализации DTrace; тем, кто в них заинтересован, я могу посоветовать найти их описание в Google, а также в главах 27 и 28 второго издания книги «Операционная система Solaris», написанной мной в соавторстве с Евгением Ильиным в 2009 году. Кроме того, наблюдение, профилирование и трассировка работы приложений с помощью DTrace подробно рассмотрены в одной из лекций по курсу «Системное администрирование ОС Solaris 10».

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

Однажды на конференции OSDevCon в Дрездене Чад Минхир (Chad Mynhier) вел мастер-класс по DTrace. Интерес к нему был огромный, и вот почему. Чад работает в компании Forsythe, зарабатывающей миллионы долларов в месяц на оптимизации банковских приложений. Как-то раз у одного из заказчиков он триумфально ускорил работу приложения в тысячу раз, заодно побив рекорд скорости зарабатывания гонорара.

Дело в том, что одно из основных банковских приложений, функциональность которого вполне удовлетворяла всех раньше, стало работать значительно медленнее с ростом нагрузки. Так как банк планировал еще больший рост нагрузки, опасное замедление становилось неприемлемым. Анализ приложения с помощью DTrace вначале не выявил ничего особенного, однако распределение функций по частоте вызовов показалось Чаду настораживающим: чаще всех вызывалась функция gettimeofday(), возвращающая текущее системное время. При работе с базами данных в вызове этой функции нет ничего подозрительного, так как в БД часто записывается время, в которое произошла транзакция, но эта функция отчего-то доминировала в вызовах… С помощью DTrace было локализовано место в приложении, где эта функция вызывалась чаще всего. Оказалось, что по недосмотру разработчика она вызывалась в цикле, который, как назло, тоже был задействован почти в каждой операции приложения.

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

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

pfexec dtrace -n 'pid$target:::entry {@funсtions[probefunc]=count();}' -c ls

А вот таким скриптом можно посчитать количество функций, вызванных конкретным процессом с PID=2355; для получения результата надо прервать выполнение скрипта с помощью Ctrl-C:

pfexec dtrace -n 'pid2355:::entry {@funсtions[probefunc]=count();}'

А вот так можно посчитать количество системных вызовов в том же процессе:

pfexec dtrace -n 'syscall:::entry /pid==2355/ {@funсtions[probefunc]=count();}'

Итак, в скриптах на языке D всегда используется следующий синтаксис:

провайдер:модуль:функция:датчик
/условие/
{
действия
}

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

Модуль – это название модуля или библиотеки, например, libc.

Функция – имя функции, датчик в которой нам интересен, например, fopen.

Датчик – название датчика (во многих случаях датчик называется entry или return).

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

 /execname == top/

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

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

Простой пример того, как я использую DTrace в повседневной жизни: после переноса пользовательских настроек с одного компьютера на другой система на не захотела работать с принтером, как раньше. Было ясно, что какой-то из файлов настроек отчего-то не скопирован. Но какой именно? Их же сотни… Банальные /etc/printers и /etc/lp/* были проверены и разгадки не дали. Тогда пришлось задействовать DTrace. Простой скрипт дает возможность заглянуть в недра программы lpstat (наиболее безвредная программа из тех, что работает с принтером) и посмотреть, какие файлы она пытается открыть:

lpstat -s
scheduler is running
system default printer: eaqvap21
aqvap21: unknown printer
aqvap21: unknown printer

Чтобы запустить программу и подсунуть ее PID скрипту на DTrace надо использовать ключ -c :

dtrace -n 'pid$target::fopen:entry {printf("%s",copyinstr(arg0));}' -c "lpstat -s"

dtrace: description 'pid$target::fopen:entry ' matched 1 probe
scheduler is running
system default printer: eaqvap21
aqvap21: unknown printer
aqvap21: unknown printer
dtrace: pid 11156 has exited
CPU     ID                    FUNCTION:NAME
 0  59882                      fopen:entry /etc/default/init
 0  59882                      fopen:entry /etc/lp/ppd/eaqvap21.ppd
 0  59882                      fopen:entry /export/home/filip/.printers
 0  59882                      fopen:entry /export/home/filip/.printers
 0  59882                      fopen:entry /export/home/filip/.printers
 0  59882                      fopen:entry /etc/printers.conf
 0  59882                      fopen:entry /export/home/filip/.printers
 0  59882                      fopen:entry /etc/printers.conf
 1  59882                      fopen:entry /etc/nsswitch.conf
 1  59882                      fopen:entry /export/home/filip/.printers
 1  59882                      fopen:entry /export/home/filip/.printers
 1  59882                      fopen:entry /etc/printers.conf

Вот и все: я забыл, что надо почистить файл .printers в домашнем каталоге:

rm /export/home/filip/.printers

Готово! Все работает на ура!

Замечание: подсовывать PID программы скрипту надо потому, что провайдер pid требует указания PID изучаемого с помощью DTrace процесса, а знакомый нам всем вызов fopen как раз относится к этому провайдеру DTrace.

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

pfexec dtrace -n 'syscall::open*:entry {printf("%s\n",copyinstr(arg0));}'

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

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

Вот этот скрипт:

#!/usr/sbin/dtrace -s
#pragma D option quiet
dtrace:::BEGIN
{
  printf("%-20s %-20s %-40s %-9s\n", "Who", "Database", "Query", "Time(ms)");
}
mysql*:::query-start
{
  self->query = copyinstr(arg0);
  self->connid = arg1;
  self->db    = copyinstr(arg2);
  self->who   = strjoin(copyinstr(arg3),strjoin("@",copyinstr(arg4)));
  self->querystart = timestamp;
}
 
mysql*:::query-done
{
  printf("%-20s %-20s %-40s %-9d\n",self->who,self->db,self->query,
         (timestamp - self->querystart) / 1000000);
}

Запустив его, можно наблюдать картину работы сервера (осторожно! там может быть очень много информации, если сервер сильно нагружен запросами!):

$ pfexec ./mysql.d
Who                  Database             Query                                    Time(ms)
root@localhost       data                 SELECT DATABASE()                        0
root@localhost       test                 show tables                              0
root@localhost       test                 SELECT DATABASE()                        0
root@localhost       mysql                select * from users                      0
root@localhost       mysql                select * from host                       0

C помощью измерения времени между срабатываниями датчиков query-start и query-done вычисляется время исполнения SQL-оператора, и DTrace позволяет строить графики распределения времени исполнения по операторам. Так можно найти те обращения к базе данных, которые отнимают много времени при выполнении конкретных приложений. Большое преимущество DTrace в том, что все эти измерения можно производить в условиях реальной нагрузки на сервер, так как накладные расходы на работу самого DTrace минимальны и не будут мешать работе сервера.

Замечание: время выполнения запросов меньше 1 ms, а в скрипте выполняется целочисленное деление, поэтому результат получается 0. Можно считать в микросекундах, а не в миллисекундах, тогда будет какое-то небольшое значение.

Из приведенных примеров видно, что датчики DTrace расставлены в системе и приложениях Solaris повсюду. Изучить, какие аргументы, связанные с датчиками, можно использовать так, как показано выше, можно в документации по системе (man) и в документации по конкретным приложениям (например, по серверу MySQL на сайте mysql.com).

Значительно больше примеров скриптов для dtrace можно найти в следующих источниках:

Тем, кто захочет попробовать DTrace на практике, важно помнить, что для использования dtrace надо обладать правами администратора системы; обычному пользователю dtrace недоступна из соображений безопасности.

Статья рассматривает вопросы, относящиеся к обработке исключительных ситуаций [exception handling] в языках, поддерживающих соответствующий механизм. В статье обсуждаются наиболее распространённые проблемы, с которыми сталкивается разработчик, применяя обработку исключений, а также возможные способы решения этих проблем. Основной акцент в статье делается на примерах и прецедентах использования исключений. Статья предназначена для разработчиков, знакомых с объектно-ориентированными языками и будет полезна при освоении этих языков.

Основные примеры в статье приведены на C++.

Введение

Идеализированный подход, использующий обработку исключений подразумевает следующее. Разработчик пишет код так, как если бы в нём не случались ошибки. За обработку же ошибок отвечает некоторый заранее определённый код, который знает, как обработать исключительную ситуацию. Подобное разделение между кодом, выполняющим основную работу, и кодом обработки ошибок должно упрощать взаимодействие отдельных компонент между собой, позволяя строить изолированные/слабо-связанные уровни абстракций, и как следствие, уменьшать стоимость разработки и поддержки.

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

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

Под термин “исключительная ситуация” не подводится теоретической базы – ситуация считается “исключительной”, если таковой её считает разработчик.

Помимо этих понятий, в статье широко используется термин “компонент”. Термин следует трактовать в самом широком смысле – он может ссылаться на класс, подсистему, программный продукт и т.п.

1 Стратегия

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

Посмотрим, жизнеспособна ли идея, если речь идёт о промышленном применении.

Для того, чтобы решение выглядело чем-то большим, нежели совет “пишите хороший код”, начнём со списка вопросов, которые встают перед разработчиком в момент обработки ошибочной ситуации:

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

1.1 Когда следует генерировать исключения

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

Два фактора влияют на выбор того или иного способа:

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

1.1.1 Внешние ограничения

Начнём с рассмотрения внешних ограничений. Подобные ограничения актуальны для языка C++, но подчас их приходится учитывать и для языков, для которых работа с исключениями является “врождённым” свойством. Вот основные случаи, в которых нам приходится использовать традиционные способы оповещения об ошибках.

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

 
LRESULT CALLBACK MyCallbackMethod(API_STRUCTURE*);
 
void DoSomething()
{
    API_STRUCTURE s = { 0 };
    try
    {
        API_Method(&s, MyCallbackMethod );
    }
    catch(const MyError&)
    {
        // #1
        Another_API_Method(&s );
    }
}
 
LRESULT CALLBACK MyCallbackMethod(API_STRUCTURE*)
{
    throw MyError( );
}

1.1.2 Выбери меня

Теперь, предположив, что внешние ограничения отсутствуют, давайте рассмотрим, что может повлиять на наше решение – воспользоваться исключением или вернуть из метода значение?

Обсуждение полезно будет провести на примере небольшого класса. Подобное обсуждение даст нам возможность поставить “правильные” вопросы, задав которые мы в значительной мере приблизимся к решению. Начнём с рассмотрения примера совместно используемого кода (для краткости назовём такой код “библиотечным”). Это позволит нам в дальнейшем упростить обсуждение “обычного” небиблиотечного кода.

1.1.2.1 Создание библиотеки

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

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

1.1.2.1.1 Функционально совместимый код

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

Одним из примеров функционально совместимой библиотеки может послужить набор классов, обеспечивающих тонкую (а иногда и не очень тонкую) обёртку вокруг функций API. Здесь уместно вспомнить Windows Template Library (WTL).

Другой пример – дополнение или расширение хорошо известной библиотеки. Здесь знакомой иллюстрацией может быть библиотека boost.

В случаях, подобным упомянутым выше, наилучшей стратегией является соблюдение “принципа наименьшего удивления” [principle of least astonishment] [principle of least surprise] (E.S. Raymond, The Art of Unix Programming, 1.6.10 Rule of Least Surprise). Сейчас мы ведём речь лишь об обработке исключений, но, в общем случае, этот подход хорошо работает и при реализации библиотеки в целом.

Класс CFile

В качестве примера обратимся к классу, который работает с описателем файла – объектом ядра операционной системы Windows. И попытаемся на этом примере проиллюстрировать условия, которые могут повлиять на выбор определённой стратегии распространения ошибок.
Объявив класс в некотором пространстве имён, для того чтобы минимизировать конфликты с другими классами “файл”, в дальнейшем будем опускать это пространство имён. Выдвинем основное требование к данному классу – облегчить, насколько возможно, жизнь разработчикам-пользователям данного класса.

Первое, что мы можем потребовать от класса – это взять на себя скучную работу по закрытию описателя объекта ядра. Всё, что нам понадобится – это пара функций: конструктор-деструктор.

 
// пространство имён опущено
class CFile
{
public:
    explicit CFile(HANDLE h);
    ~CFile();
    operator HANDLE() const;
private:
    CFile(const CFile&) throw();
    CFile& operator=(const CFile&) throw();
private:
    HANDLE m_h;
};

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

CFile::operator HANDLE()

Выше я немного слукавил. Сказав, что нам понадобится лишь пара функций – конструктор и деструктор, я, на самом деле, описал в классе 5 методов. Закрытые конструктор копирования [copy constructor] и оператор присваивания [assignment operator] мы ещё обсудим. Начнём же мы, пожалуй, с метода CFile::operator HANDLE().

Поскольку в классе не определено ни одной функции, через которую можно оперировать с описателем, нам понадобился метод CFile::operator HANDLE(). Метод позволит нам свободно передавать объект CFile в функции, ожидающие описатель. Также это позволит расширять класс постепенно, без необходимости реализовывать все аналоги функций API в момент создания класса.

С функцией CFile::operator HANDLE() дело обстоит проще всего. Имея приведённое выше описание класса, можно предположить, что функция не должна генерировать исключение.

 
inline
CFile::operator HANDLE() const throw()
{
    return m_h;
}

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

Либо, давая более развёрнутое пояснение, предположим, что в конструктор класса было передано недействительное значение описателя ядра. В этом случае конструктор может как возбудить исключительную ситуацию, так и инициализировать член класса m_h недействительным значением. Но какой бы из вариантов ни был выбран при реализации конструктора, это не должно повлиять на реализацию метода CFile::operator HANDLE() и вот почему:

Таким образом метод CFile::operator HANDLE() может быть написан так, как если бы приватный член m_h был проинициализирован должным образом.

CFile::~CFile()

Перейдём к рассмотрению деструктора. Наверное, не ошибусь, сказав, что нас приучили не инициировать исключение в деструкторе и с подозрением смотреть на классы, практикующие данный подход.

Деструктор класс CFile, не генерирующий искючений, мог бы выглядеть следующим образом:

 
#ifdef _DEBUG
inline
BOOL Verify(BOOL b) throw()
{
    if( !b )
    {
        DWORD nErr = ::GetLastError( ); nErr;
        ::DebugBreak( );
    }
    return b;
}
#else
inline
BOOL Verify(BOOL b) throw() { return b; }
#endif // _DEBUG
 
inline
CFile::~CFile() throw()
{
    Verify( ::CloseHandle( m_h ) );
}

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

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

Причина первая – в конструктор CFile был передан недействительный описатель. В этом случае нам необходимо повторить ту же цепь рассуждений, что мы провели для метода CFile::operator HANDLE() и прийти к выводу, что если исключение и должно возникнуть, то в конструкторе CFile:CFile, но никак не в деструкторе CFile::~CFile.

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

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

 
inline
CFile::~CFile() throw(CFileError)
{
    if( Verify( ::CloseHandle( m_h ) ) )
        return;
    if( std::uncaught_exception( ) )
        return;
    const DWORD nErr = ::GetLastError( );
    throw CFileError( nErr );
}

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

Проверка результата вызова std::uncaught_exception() необходима: она защищает код от попытки вызвать повторную генерацию исключения в процессе раскрутки стека, когда исключение уже существует. Если же позволить повторную генерацию, это будет считаться ошибкой механизма обработки исключений (ISO/IEC 14882:2003 раздел 15.5.1) и, по умолчанию, будет вызвана функция std::terminate(), которая, в свою очередь, по умолчанию, вызовет std::abort().

Нельзя назвать это и самым изящным способом оповещения об ошибке. Корень неоднозначности кроется в том, что в общем случае невозможно определить, можно ли проигнорировать одно исключение ради обработки другого. Именно поэтому стандарт настоятельно не рекомендует генерировать исключения в деструкторе объекта (ISO/IEC 14882:2003 раздел 15.2.3).

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

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

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

CFile::CFile(HANDLE h)

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

Рассматривая конструктор, невозможно сослаться на то, что обработка ошибки должна вестись где-то в другом месте (как в случае с CFile::operator HANDLE()). Также нельзя привести пример неоднозначного, или вводящего в заблуждение кода (как в случае с деструктором).

Таким образом мы стоим перед выбором:

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

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

Плюсом первого подхода видится единственный пункт:

try
{
    CFile file( ::CreateFile( /*...*/ ) );
}
catch(const CFileError& e)
{
}

Плюсов у второго подхода, как видится, больше:

Следующий пример поможет проиллюстрировать проблему, описанную в двух последних пунктах.

bool CMyClass::Foo()
{
    HANDLE h = ::CreateFile( /*...*/ );        // #1 CFile file( ::CreateFile )
 
    ToDoSomethingUnrelatedWithCreatedFile( );  // #2, эта строка
                                               // выполняется всегда
    if( INVALID_HANDLE_VALUE == h )
        return false;
    bool bRet = ToDoSomethingWithCreatedFile( h );
    ::CloseHandle( h );
    return bRet;
}

Предположим, что в приведённом выше коде мы заменили вызов функции ::CreateFile() (строка #1) созданием объекта типа CFile, который генерирует исключение в конструкторе.

В этому случае, функция CMyClass::ToDoSomethingUnrelatedWithCreatedFile() (строка #2) будет вызвана лишь в случае успешного открытия файла, что, в свою очередь, может неявным образом изменить результат действия функции CMyClass::Foo(). Данный код, безусловно, является результатом небрежного программирования, но, к сожалению, в “смешанном” коде могут встречаться подобные примеры.

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

Подведём итог. Плюсы второго подхода можно кратко сформулировать следующим образом – класс не навязывает обработку исключений. Подобное поведение хорошо согласуется с тем, что класс представляется ничем иным, как объектной заменой обычному описателю. Объект CFile может использоваться в любом месте, где может использоваться HANDLE, попутно предоставляя удобный сервис, которым славится объектный подход. И потому окончательный выбор будет сделан в пользу версии, не генерирующей исключений – класс CFile будет содержать конструктор CFile::CFile(HANDLE h) с пустой спецификацией throw().

CFile::CFile(const CFile&) и CFile& CFile::operator =(const &)

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

Оба метода объявлены как закрытые и с пустой спецификацией throw(). Таким образом, мы подразумеваем, что:

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

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

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

Если подвести итог, то определение класса теперь выглядит следующим образом (все функции объявлены с пустой спецификацией throw()).

 
class CFile
{
public:
    explicit CFile(HANDLE h) throw();
    ~CFile() throw();
    operator HANDLE() const throw();
private:
    CFile(const CFile&) throw();
    CFile& operator =(const CFile&) throw();
private:
    HANDLE m_h;
};

Семейство классов

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

Потому, если речь идёт о промышленном применении, то данная реализация выглядит несколько наивно. Очевидно, что она определяет политику распространения ошибок ключевыми функциями класса внутри реализации данного класса. Как только возникнет необходимость определить класс, обладающей подобной семантикой для другого объекта ядра, нам понадобится повторить всю цепь рассуждений. Или воспользоваться распространённым инструментом разработчиков – механизмом “copy-paste”. По-видимому, наиболее перспективным решением для долгосрочных проектов было бы решение, параметризующее политику распространения исключений (в статье мы данное решение рассматривать не будем).

CFile::Create(/*…*/)

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

Для начала, для уменьшения количества кода, необходимого для открытия файла, добавим в класс функцию CFile::Create().

 
class CFile
{
public:
    // новые методы
    CFile() throw();
    HANDLE Create(LPCTSTR lpFileName,
        DWORD dwDesiredAccess,
        DWORD dwShareMode,
        LPSECURITY_ATTRIBUTES lpSecurityAttributes = 0,
        DWORD dwCreationDisposition = CREATE_ALWAYS,
        DWORD dwFlagsAndAttributes = FILE_ATTRIBUTE_NORMAL,
        HANDLE hTemplateFile = 0) throw();
    // объявления “старых” методов остались без изменений
};
 
inline
CFile::CFile() throw() : m_h( INVALID_HANDLE_VALUE ) {}
 
inline
HANDLE CFile::Create(LPCTSTR lpFileName,
                     DWORD dwDesiredAccess,
                     DWORD dwShareMode,
                     LPSECURITY_ATTRIBUTES lpSecurityAttributes/* = 0*/,
                     DWORD dwCreationDisposition/* = CREATE_ALWAYS*/,
                     DWORD dwFlagsAndAttributes/* = FILE_ATTRIBUTE_NORMAL*/,
                     HANDLE hTemplateFile/* = 0*/) throw()
{
    assert( INVALID_HANDLE_VALUE == m_h );
    return m_h = ::CreateFile( lpFileName, dwDesiredAccess, dwShareMode,
        lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes,
        hTemplateFile );
}

Заметим, что добавление функции CFile::Create() заставляет нас добавить конструктор CFile::CFile() (к которому мы ещё вернёмся).

Из приведённого выше описания видно, что CFile::Create() объявлена с пустой спецификацией throw(). Обсудим это решение. Фактически, выбор в пользу распространения ошибок традиционным способом для всех функций класса был уже сделан при обсуждении конструктора. Описав функцию CFile::Create() как генерирующую исключение, мы оставили бы пользователя с несогласованным описанием класса:

 
HANDLE h = ::CreateFile( “file1.dat”, /*...*/ );
CFile file1( h );                                 // CFile::CFile(HANDLE h)
                                                  // не генерирует исключений
CFile file2;
File2.Create( “file2.dat”, /*...*/ );             // предположим, что
                                                  // CFile::Create()
                                                  // может инициировать
                                                  // исключительную ситуацию

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

CFile::CFile()

Как было отмечено выше, добавление функции CFile::Create() приводит к необходимости описать конструктор по умолчанию [default constructor]. Это, в свою очередь, приводит к тому, что приватный член класса получает инициализирующее значение, которое остальные функции могли и не ожидать. В общем случае, добавление (или изменение) инициализирующего значения приватного члена приводит к пересмотру и, возможно, модификации всех функций, использующих этот член класса. В данном случае, член m_h инициализируется значением INVALID_HANDLE_VALUE, что необходимо приводит к изменению реализации деструктора. После модификации он должен выглядеть примерно так:

 
CFile::~CFile() throw()
{
    if( INVALID_HANDLE_VALUE == m_h )
        return;
    Verify( ::CloseHandle( m_h ) );
}

До введения конструктора умолчания предполагалось, что приватный член m_h не может получить значения INVALID_HANDLE_VALUE иначе, как по невнимательности пользователя класса. Теперь же это значение становится разрешённым в контексте объявления конструктора по умолчанию. Более тщательный, можно даже сказать “маниакальный”, подход подразумевает добавление ещё одного члена класса, который указывал бы на то, был ли член m_h инициализирован в результате вызова конструктора по умолчанию, либо был изменён внутри какой-либо другой функции. Это дало бы нам возможность в деструкторе провести различие между разрушением переменной, созданной конструктором по умолчанию, и неверно инициализированной переменной (имеющей то же значение INVALID_HANDLE_VALUE).

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

Можно заметить, что после добавления конструктора по умолчанию, нет необходимости модифицировать функцию CFile::operator HANDLE(). Причины здесь те же, что приводились и раньше при обсуждении этой функции.

CFile::Close()

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

 
class CFile
{
public:
    // новый метод
    BOOL Close() throw();
    // объявления “старых” методов остались без изменений
};
 
CFile::~CFile() throw()
{
    if( INVALID_HANDLE_VALUE == m_h )
        return;
    Verify( ::CloseHandle( m_h ) );
}
 
BOOL CFile::Close() throw()
{
    // #1
    // if( INVALID_HANDLE_VALUE == m_h )
    //     return true;
    assert( INVALID_HANDLE_VALUE != m_h );
    BOOL bRes = ::CloseHandle( m_h );
    Verify( bRes );
    if( bRes )
        m_h = INVALID_HANDLE_VALUE;
    return bRes;
}

Обратите внимание, что следует противостоять искушению объединить “общий” код в деструкторе и в функции CFile::Close. Задача деструктора – попытаться закрыть описатель и позволить дальнейшее исполнение. Задача явного вызова CFile::Close – закрыть описатель и сигнализировать об ошибке, если закрытие прошло неуспешно. Отсутствие проверки на допустимость описателя при входе в функцию CFile::Close() – отнюдь не оплошность. Разработчик, который не поленился и пожелал явно закрыть файл, либо занимался оптимизацией (освобождение ресурса до выхода из области видимости), либо для него важен результат закрытия. В этом смысле не должно быть никакой разницы между вызовом CFile::Close() и непосредственным вызовом ::CloseHandle().

Если бы мы проверяли значение описателя при входе в функцию CFile::Close() (раскомментировав две сточки, ниже #1), пользователь мог бы наблюдать разницу в побочных эффектах. А именно, вызов CFile::Close(), для неинициализированного объекта, не модифицировал бы значение, которое возвращает ::GetLastError(), а вызов ::CloseHandle() с тем же неинициализированным объектом в качестве параметра заносил бы в thread local storage (TLS) значение 6 (The handle is invalid).

Общие замечания

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

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

Общая “проблема” подобных библиотек-обёрток состоит в том, что в подавляющем количестве случаев, они будут служить чисто утилитарной цели – уменьшение объёма кода в одной конкретной функции (классе, компоненте). И у библиотеки будет гораздо больше шансов быть повторно используемой, если пользователю не придётся изучать её структуру и сопоставлять поведение библиотеки с поведением “чистых” функций API. Генерация исключения и, соответственно, его перехват, могут рассматриваться как попытка навязать дополнительную и, возможно, ненужную пользователю работу.

Продолжение следует…

Вступление

В рамках любого проекта особняком стоит управление конфигурацией продукта (Software Configuration Management, SCM). С одной стороны, такое управление есть, с другой стороны, немалая часть разработчиков не выделяет его как отдельную «дисциплину». Иными словами, управление незримо присутствует и в то же время не существует. Между тем, практики SCM используются повсеместно. Иногда сообща, иногда разрозненно, но – используются. Присутствует ли SCM в вашем проекте? Попробуем предотвратить метания на тему «да или нет» и перечислим основные направления деятельности под общим названием «Управление конфигурацией продукта». К этому списку мы будем возвращаться на протяжении всей статьи.

Знакомые слова, не правда ли? Пусть вас не вводит в заблуждение слово «продукт». Продукт – это не только дистрибутив, за который компания-разработчик получит деньги. Это любой артефакт, создаваемый командой на всём протяжении жизненного цикла продукта. Файл с исходниками, документ со спецификацией требований, тесты, бинарники для установки у клиента – всё это продукты. А под конфигурацией понимается набор версий, то есть, “срез” состояния всего продукта.

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

Выбор инструмента

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

Скажем, многие разработчики стоят перед выбором: «Какую систему контроля версий использовать – git или Mercurial?» При детальном рассмотрении выясняется, что речь идёт о команде, в которой распределённая модель работы просто не нужна. К примеру, условия работы с кодом диктуют постоянную синхронизацию результатов работы между всей командой. Или же команда продолжает покупать лицензии на Perforce, хотя его использование выродилось в линейное складирование версий, без ветвления.

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

В общем, выбор порой надуман, особенно на первых этапах работы. Однако чаще всего бывает обратная ситуация – внедрение методик и инструментов просто не поспевает за потребностями.

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

Предположим, некоторый проект с серверной и клиентской частями начинается «на коленке», в глубине гаража или квартиры основателя проекта. Выбираются простые инструменты: багтрекером (bug tracker) служит лист в Excel, контроль версий реализован в традиционном Subversion, сборка проекта идёт простым нажатием кнопки в любимой среде разработки, а дистрибутив выдается в виде архива или заливается на сервер по FTP. Проходит время, проект зреет, появляются новые люди. Листик в Excel ещё удается расшарить по сетке, SVN (Subversion) пока хорошо справляется с коммитами (commit) в транк (trunk, по умолчанию – главная ветка в Subversion), ветки пока не нужны. Поскольку продукт теперь собирается под 2-3 разные операционные системы (клиентура растёт), приходится использовать пару разных сред разработки и на каждой новой машине тратить немало времени на настройку всех библиотек. Да и сама компиляция и линковка теперь – задача непростая, каждый раз вылазят специфичные для среды ошибки. При наличии нескольких человек трудно понять, кто и когда залил на сервер новый релиз и кто готовит инсталляционный пакет для клиентов. Проблемы пока решаются, ибо команда всё ещё невелика, и все находятся рядом. Однако давление уже изменяется: проект “всплывает”, последствия начального выбора процессов и инструментов скоро начнут «пузыриться».

Первый пузырёк появляется в системах контроля версий и багтрекинга. Всё чаще люди начинают непродуктивно тратить время на коммит новой версии на транк – ведь приходится по 2-3 раза делать update перед очередным коммитом. Классическая ситуация: три человека меняют один файл, первый делает commit, второй и третий, прежде чем сделать то же самое, вынуждены делать update. Далее кто-то из них двоих делает свой коммит, в результате чего третий вынужден опять упражняться в слиянии (merge) исходников. Начинается использование веток: сначала робко, для больших подсистем, потом всё чаще. При этом кто-то продолжает скидывать дельту (изменения в рабочем продукте) прямо в транк – ведь единой договорённости об использовании веток пока нет. Всё чаще возникают конфликты слияния, потеря дельты – сказывается разница в подходах между участниками команды. Всё больше ошибок при компиляции и тестировании появляется из-за несогласованности внесения изменений – слабо контролировалось вхождение новой дельты (новой функциональности или багфиксов). Листик Excel разросся, стало сложно управлять поступающими запросами, уже непонятно, кто за какие изменения отвечает. К примеру, кто-то решил вместе с очередным багфиксом сделать рефакторинг и «размазать» его на 4 последовательных коммита. Разумеется, это переплелось с плановыми изменениями – в итоге билд поломан, пытаемся выяснить, на каком основании что было сделано. Иными словами, “пузырёк” появляется там, где происходит наибольшая активность, а стало быть – наибольший перепад давлений.

Следующий пузырь появляется при сборке проекта и работе с настройками среды. Разные среды, компиляторы, настройки окружения – всё чаще появляются специфичные ошибки компиляции и линковки. Да тут ещё и одна из сторонних библиотек поменялась – всем разработчикам нужно ее установить и проверить на совместимость с их модулями. При этом текущая стабильная версия системы (она стоит у заказчика), использующая предыдущую версию библиотеки, требует сопровождения. А значит, приходится её переустанавливать и менять ключи компиляции каждый раз, когда делаются багфиксы. А если учесть, что теперь клиенту, работающую под Windows, надо устанавливать новую dll и регистрировать дополнительный COM-объект, становится понятен нервный смех того, кто делает инсталляционные пакеты. И вот уже очередной перепад давлений – политики и инструменты для сборки проекта и управления рабочей средой просто не справляются. Под словом “политика” (policy) в этом контексте обычно понимают свод договорённостей, правил и используемых практик, которые принимаются всей командой.

Худо-бедно, учась на своих ошибках, сменили часть инструментария (в первую очередь, систему отслеживания запросов), договорились о правильном взаимодействии при работе с ветками, написали скрипты для запуска отстройки, начали использовать CMake для поддержания кроссплатформенности. Но продукт не стоит на месте, он растёт, а значит продолжает увеличиваться перепад давлений. Вот уже к работе подключилась удаленная команда тестировщиков. Возникла необходимость разделения прав в системе отслеживания ошибок, нужны новые способы быстрой настройки рабочего окружения, надо куда-то и в каком-то порядке выкладывать релизы для прогона тестов разной интенсивности и глубины. И снова “пузыри”…

В нашем примере очень показательно и естественно добавление удаленной команды разработчиков. Это большое испытание для всего проекта, не говоря уже о его SCM-инфраструктуре. Надо решить вопрос распределенной работы с исходниками, понять кто, где и в какой момент интегрирует изменения, выпускает очередной релиз, куда его положить, как отдать на тесты и получить их результаты для дальнейшего закрытия «тикетов». В общем, очередной “подъём наверх” ставит всё новые задачи с точки зрения организации инфраструктуры. И редко кто бывает к ним заранее готов – всё меняется под нужны момента и редко кто заранее планирует все изменения.

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

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

На что ориентироваться при выборе инструмента? Итак, начался проект. Первое, с чем придётся столкнуться ещё до начала написания кода – запросы на изменения. Это пункт 1 в списке, рассмотренном в начале статьи. Даже когда единственным рабочим продуктом будет спецификация требований, её разработчикам уже нужен инструмент для отслеживания всего того, что происходит с требованиями, какие правки в них вносятся и зачем. Что уж говорить об исходном коде. Отслеживать изменения нужно научиться сразу – и научиться делать это качественно. Так что не экономим ресурсы, а постоянно оцениваем: хватает ли нам системы трекинга изменений и хватит ли на ближайшие пару месяцев.

Тут возникает проблема выбора, ведь система bug- или task-трекинга – это один из любимейших велосипедов программистов. За такие системы берутся многие, при этом доводят до презентабельного вида – сотни, и наибольшей популярностью пользуются десятки систем – от простых todo lists с галочками до сложных и безумно больших и гибких систем управления проектами. К слову сказать, разделение между bug-, task- и issue-tracking достаточно условно, однако task-трекеры ориентированы на более широкую аудиторию, не только разработчиков. Здесь очень велик риск внедрить одно, а через несколько месяцев захотеть уже сильно другое. Поэтому надо или быть заранее готовым сменить через год-два систему трекинга, или каким-то образом предвидеть направление роста команды и выбрать именно то, что не помешает маленькой команде и поможет – команде большой.

Не стоит забывать и о политиках использования. Ведь можно бесконтрольно плодить и закрывать запросы на изменения, а можно создать рабочую группу (change control board, группа контроля за изменениями), которая будет вести работу по приоритезации и отслеживанию выполнения этих запросов.

На данный момент мои фавориты – Redmine, eTraxis, Basecamp – каждый для своих классов задач. Basecamp, по сути, это сильно расширенный todo list. eTraxis – гибкая система трекинга чего угодно. В нём открытый код, и я, участвуя в его внедрении на крупном проекте, даже написал несколько улучшений и исправлений кода. Вообще, очень гибкая штука – горячо рекомендую. Ну а на Redmine смотрите, если нужна целая система управления проектами – для этих глобальных целей он хорошо подходит.

Следующий по значимости класс систем – контроль версий. Это пункт 2 в нашем списке SCM-задач. Такая система также выбирается в самом начале, поскольку рабочие продукты начинают появляться практически с первого дня работы. Тут ситуация отличается от систем трекинга. С одной стороны, инструментов не так много. Из бесплатных (open source) систем лидируют Subversion (SVN), git, Mercurial, среди платных – MS TFS, Perforce, IBM Rational ClearCase (и его потомки). Небольшой выбор компенсируется тем, что этими инструментами можно пользоваться по-разному. Можно использовать один и тот же SVN годами, однако в начале проекта работать только на транке, а уже через год вырастить увесистое дерево веток и меток. Так что с этим классом инструментов просто необходимо периодически пересматривать политики и практики их использования. При этом ничто не является догмой – вы можете сейчас активно ветвиться, а потом постепенно перейти к системе непрерывной интеграции (continuous integration), исповедующей частую интеграцию на транке. К примеру, немало копий, поломано при обсуждении того, как надо ветвиться (и надо ли вообще). Или священная война последних 3-4 лет – какие системы лучше, централизованные или распределенные. Что тут сказать, надо исходить из потребностей. Моя слабость – это IBM Rational ClearCase, но только не UCM, а его базовый функционал. Мощнейшая штука, несправедливо загубленная маркетологами IBM. Кстати, не так давно появился неплохой продукт PlasticSCM, одновременно имеющий распределённую природу и частично использующий идеологию ClearCase. С интересом слежу за его развитием.

Следующую немаловажную нишу занимают системы поддержки построения продуктов – это третий пункт нашего “хит-парада”. Ниша эта небольшая, однако без неё многие проекты немыслимы. Сюда входят как системы для описания кроссплатформенной компиляции и линковки (CMake), так и системы полного цикла сборки (Maven, ant). Общая цель – сделать построение продукта как можно более прозрачным. Зачастую такие системы специфичны для конкретного языка или технологии, а их выбор приходится на более поздние этапы развития проекта. Чаще всего их начинают внедрять когда ресурсы ручной сборки уже выработаны. Однако правильные архитекторы и СМ-инженеры думают о них уже в самом начале проекта :)

Это же описание справедливо и для систем управления рабочим окружением, выпуском и развертыванием продуктов. В нашем списке они выделены под пунктами 4, 5 и 6, однако потребность в них возникает практически в одно и то же время. Зачастую продукт сильно эволюционирует до того как доходит очередь до этого класса систем. Это правильно – только реальные потребности покажут, что и когда надо внедрять для подобных задач. Мало научиться строить продукт – надо его правильно выдать пользователям (в том числе, тестировщикам), убедиться, что при использовании или тестировании будет всё настроено так, как задумывалось разработчиком, и нам не будут лететь сообщения об одних и тех же ошибках каждый раз после выхода нового релиза. Подобные инструменты эволюционируют обособленно и, как правило, по времени ближе к середине проекта, когда есть уже что показать тестировщикам. Обычно же начинают с того, что просто выкладывают бинарники в расшаренную папку в сети, приложив release notes, где описано, какие изменения внесены и как настраивать окружение. Тем и ограничиваются долгое время.

Несколько слов о литературе по SCM. Книг на русском языке практически нет. Есть масса онлайн-материалов по конкретным инструментам, много HowTo, руководств, но не книг. Обзор имеющейся литературы можно найти здесь.

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

Типичные ошибки и заблуждения

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

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

Ещё одно заблуждение (скорее, позиция в священной войне), состоит в том, что распределённая модель может полностью заменить модель централизованную. Рискую навлечь на себя гнев апологетов git и Mercurial, однако считаю, что это далеко не так. Будучи активистом антиброуновского движения :), полагаю, что централизованная модель может и даже должна использоваться в проектах, имеющих жёсткую иерархию работы с изменениями. Перед глазами собственный пример. Я имел удовольствие работать в крупном проекте, распределённом между странами и часовыми поясами. У нас, бывало, проходила не одна неделя, прежде чем изменения попадали от разработчика в продукт, отгруженный “наружу”. При этом участники команды должны были иметь возможность смотреть изменения от любого разработчика вне зависимости от его местонахождения, времени суток и доступности его копии изменений. У нас использовался ClearCase с надстройкой Multisite, позволявшей централизованным хранилищам в локальных командах реплицировать между собой все нужные изменения. Таким образом я, находясь в России или США, мог видеть код, написанный в Индии или Италии – он становился доступным в течение получаса (максимум). С децентрализованной моделью это было бы трудно.

К заблуждениям отнесу и уже упоминавшийся отказ от использования веток. Я не имею виду непрерывную интеграцию, которая принципиально строится на использовании единой ветки для разработки – есть аргументы как “за”, так и “против” этого метода. Речь идет о непонимании механизма работы. Кто-то считает, что наличие веток отнимает кучу дискового пространства – это неверно, так как внутреннее представление большинства систем достаточно оптимально и там, как правило, хранятся только изменения, но никак не полная копия исходников для каждой ветки. Кого-то пугает процесс слияния изменений после окончания работы на ветке. Страх этот идёт отчасти из-за того, что в самой популярной на сегодняшней день системе контроля версий – Subversion – ветвление и слияние действительно сделаны… скажем так, не совсем хорошо :) В других системах это делается значительно проще, так что страхи пора забывать.

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

Нельзя не сказать и о метках – незаслуженно мало используемой возможности систем контроля версий. Метки позволяют работать с именованными версиями. Например, интегратор проекта слил воедино все изменения пары команд, которые параллельно работали над изменениями, получил тот срез, который можно считать стабильным. Он вешает на него метку, и теперь любой участник команды может взять этот срез путём извлечения одной-единственной метки. Чем это отличается от обычного номера ревизии? Тем, что метку могут “перевесить”, если вдруг выяснится, что произошел сбой и стабильной считается уже другая ревизия. Кроме того, не во всех системах контроля есть наборы изменений (changesets), и для них метки – это единственный способ каким-либо образом идентифицировать конфигурацию без перечисления всех версий всех элементов. В общем и целом, метки – полезная штука, от которой не надо отказываться.

Будущее SCM

Судя по англоязычным публикациям, будущее за системами класса Application Lifecycle Management (ALM). Это инструменты, соединяющие в себе функции контроля версий, поддержки билда, и, самое главное, сбора требований, отслеживания запросов на изменения, поддержки тестирования и оценки его результатов. Этакие швейцарские ножи. Уже сейчас существует некоторое количество таких продуктов. К примеру, Microsoft Team Foundation Server (MS TFS) – думаю, он в представлениях не нуждается. Чуть менее известно семейство IBM Rational Team Concert, в частности IBM Rational Jazz. Судя по описаниям и отзывам, команда IBM критически перетрясла разработки прошлых лет и оставила самое лучшее. Также на слуху AccuRev и Neuma.

Заметьте, все решения платные. Единственная альтернатива, которая приходит в голову – это сборка воедино бесплатных решений с открытым кодом. Многие системы багтрекинга имеют возможность интеграции с системами контроля версий. В общем, есть все предпосылки для объединения, однако, как правило, дальше объединения трекеров и контроля версий дело не заходит. Полные интегрированные системы если и существуют, то, как правило, это результат работы отдельных компаний или коллективов: и дальше внутреннего использования они не выходят. Думаю, здесь мы ещё увидим немало интересного.

Максим, сможете ли вы выделить факторы, которые влияют на успех/провал разработки и внедрения любого продукта (вне зависимости от его предметной области)?

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

Помимо рисков огромное влияние оказывает мотивация участников процесса. В случае отдельной незаинтересованности (неважно с чьей стороны – заказчика или исполнителя) велика вероятность краха проекта.

Каким образом методология работы позволяет учитывать риски?

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

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

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

Что нужно учесть с момента первого разговора с заказчиком (внешним или внутренним) и до выхода продукта в свет?

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

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

Третий аспект – целеполагание. Если цель проекта недостаточно четко определена хотя бы на уровне менеджеров проекта, то в итоге и результатом будет непонятно что. Цель, безусловно, должна быть достижима в разумные сроки и может быть пересмотрена в процессе проекта. Последнее часто является необходимой процедурой, поскольку локальные цели проекта (написание CRM-системы, например) могут быть следствием более глобальных целей (устранение бардака в клиентском отделе), и ожидания заказчика строятся именно относительно глобальных, а не локальных целей.

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

Как происходит разработка приложения после того как техзадание согласовано с заказчиком? Пишите ли вы псевдокод, создаете ли прототипы или сразу же приступаете к реализации «боевой» системы?

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

В разрезе создания большой системы: какой стиль разработки – нисходящий или восходящий – вы предпочитаете и почему?

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

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

Максим, какая из реализованных систем была наиболее интересной и технически сложной? Сможете ли вы описать ее жизненный путь с точки зрения выбора архитектуры и средств разработки?

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

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

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

Изначально задача была поставлена в виде «нам нужна база по клиентам с отслеживанием сроков исполнения». Вооруженный ею, а так же кратким описанием процесса, я попытался продумать интерфейс системы. Поскольку единственное ограничение от внутреннего заказчика состояло в том, что система должна быть веб-приложением, доступным из любой точки с интернетом, в качестве инструмента был выбран комплект LAMP, в рамках которого у меня был большой опыт и неплохое количество наработок. Была еще идея реализовать все в рамках Google Apps, но этот вариант был отвергнут, поскольку я не знал Python, а мой коллега, хоть и знал, никогда не работал с Google Apps API. В свете этого разработка могла значительно затянуться, а нужно было, как всегда, «еще вчера». Поэтому выбор инструмента был определен, на вооружение взята типовая архитектура веб-приложения (которой я придерживался уже несколько лет при реализации подобного рода проектов), а я занялся проектированием пользовательского интерфейса.

Пользовательский интерфейс во всех приложениях является бичем разработчика. Как ни странно, но почти во всех встречающихся мне задачах (в т.ч. и в задаче с театральными подъемами), на интерфейс, его реализация и связанные с ним вещи занимали до 75-80% времени проекта. Поэтому при создании приложений необходимо уделять максимальное внимание простоте и удобству пользовательского интерфейса. Это в дальнейшем сократит как нервы пользователя, так и временные затраты разработчика. Предполагалось, что в системе будет веб-интерефейс, основанный на HTML4 совместно с применением библиотеки jQuery. В качестве шаблонизатора использовалась технология XSLT: бэкэнд генерировал XML с данными, на который затем одевался XSL-шаблон, который мог быть разным в зависимости от условий, например, предназначены ли данные для передачи на сторону клиента посредством AJAX или же, наоборот, должны быть отправлены на печать.

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

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

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

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

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

О, баги! :) Вообще с возрастом начинаешь замечать, что есть много различных типов багов.

Первый – синтаксический, когда программист ошибается в названии оператора или забывает поставить разделитель. Это неизбежное зло – программисту как оператору свойственно ошибаться при вводе текста, и тут обычно только незамыленный взгляд способен найти ошибку (ну и вменяемое сообщение о ней от компилятора/интерпретатора).

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

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

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

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

Вторая история случилась совсем недавно. Я разрабатывал простенький веб-видеочат, для создания клиентской части использовал открытый Flex вместо традиционного Adobe Flash, а, поскольку знания платформы были недостаточно глубоки, всячески подглядывал в размещенный в сети код и исходники, идущие вместе с сервером для RTMP-трансляций erlyvideo. Чат в итоге был реализован и даже работал, но при тестировании обнаружился очень странный эффект – при ожидаемом поведении в браузерах ОС Windows и Mac OS X ответственный за вещание Flash-элемент категорически отказывался работать в Linux, даже не выдавая предупреждения на захват камеры. Попытки неоднократно переписать код, консультации с опытными Flex-разработчиками, один из которых и был автором того кода, на базе которого я строил тот элемент, не увенчались успехом. Окончательно разочаровавшись во всех испытываемых средствах я полез как можно глубже в документацию. Оказалось, что выдача окошка предупреждения безопасности – это свойство исключительно Flash-плагина, Air-приложения же сразу обломаются. Запустив отладку, я обнаружил – да, действительно, обламывается. Но у меня было не Air-приложение! Сразу пришло на ум, что, возможно, это указывается в параметрах компиляции. Прошерстив все параметры и вдоволь ими наигравшись до такой степени, что даже работающая компиляция перестала функционировать, я сдался, решив проверить последний шанс. Дело в том, что для Linux есть альфа-версия Flex Builder-а, продукта Adobe для удобной работы с Flex-ом. Создав на удачу в нем проект, я скопировал туда прошедший неоднократную переделку код и запустил. Каково было мое удивление, что все заработало! Появилась панель безопасности, заработал захват видео-потока с камеры. А вместе с удивлением пришло и озарение. Я начал проверять, как ролик вставляется в страницу и опасения подтвердились – библиотека jQuery SWFObject откровенно халтурила, пытаясь вставить Flash-элементы в Linux как и на других платформах через тег object, в то время как правильно это делать через тег embed (что и делает оригинальный SWFObject, который занял вакантное место библиотеки для встраивания). В результате чего браузер трактовал ролик как встроенное Air-приложение и применял соответствующую настройку безопасности. Для проигрывания было все равно, а вот с захватом и трансляцией получилось неудобно. В результате, стыдно признаться, но на этот вполне тривиальный баг я потратил почти неделю времени, правда, неполных рабочих дней, потому как делалось это параллельно остальным задачам.

Мораль обоих историй проста – «баги коварны» и «никому нельзя верить». :)

Максим, есть три базовых сценария приемочных испытаний: проверку системы осуществляет разработчик, выделенный тестировщик или вменяемый заказчик. При создании каких приложений/систем оптимален тот или иной сценарий? Исходя из вашего опыта, как организовать тестирование продукта наиболее эффективным образом в координатах “время-качество-деньги”?

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

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

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

Каковы признаки плохого кода? Можете ли вы привести примеры?

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

Технические ошибки на проекте можно подразделить на следующие:

• Неправильный выбор платформы

Здесь, скорее всего, будет все плохо: начиная от архитектуры и заканчивая локальными фрагментами кода, все будет сосредоточено на героическое преодоление нюансов разработки под выбранную платформу. В результате этого скорее всего получится дорогой в разработке и поддержке, но абсолютно неэффективный продукт. К счастью, в наши дни подобные ошибки встречаются все реже и реже. Наиболее абсурдный пример подобного решения – написание интернет-форума на Си в виде CGI-приложения (зачем, когда есть такие языки, как Python, Ruby, PHP, явно больше подходящие для веб-разработки).

• Ошибки архитектуры

Под ошибками архитектуры подразумевают неоправданные приемы, которые разработчики бездумно копируют из других проектов, не особо задумываясь о последствиях. Простейшим примером подобного может быть, например, хранение картинок для небольшого сайта внутри СУБД. При этом при запросе картинки веб-приложение должно будет запросить СУБД на предмет картинки, сформировать правильно заголовки и только затем отдать картинку пользователю, иными словами – это чревато неоправданной нагрузкой по сравнению с вариантом хранения этой же самой картинки как обычного файла (хотя стоит отметить, что иногда это решение тоже приемлемо).

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

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

• Неряшливое кодирование

Под неряшливым кодированием я обычно подразумеваю два явления – несоблюдение стиля кодирования и спагетти-код.

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

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

• Незнание алгоритмов и/или принципов функционирования инструмента

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

• Недостаточная или излишняя документация

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

Как сделать код более читабельным? Как обеспечить возможность его легкого изменения в будущем?

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

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

Если кратко, советы для достижения читабельного кода, думаю, можно свести к следующим:

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

• Используйте стили написания кода, такой проще читать.

• Как минимум, подписывайте назначение функций/методов (особенно если их назначение неочевидно из названия) и коммиты в систему контроля версий.

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

• Помните: возможно ваш код будете читать вы сами (лет через пять и бить себя по голове при этом), а возможно – психопат-убийца-маньяк. И не факт, что он не найдет, где вы живете. («Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.» – Martin Golding)

Максим, каковы признаки хорошего кода?

Их не так много:

На самом деле все гораздо проще:

Наверное такой код можно назвать хорошим кодом. Беда в том, что если пункт один можно обеспечить тестированием, а пункт три – грамотным проектированием и репроектированием, то пункт два исключительно субъективен. На практике хороший код написать с первого раза практически малореально. Хорошим получается код четвертой, пятой и последующих итераций (об этом писал Ф.Брукс в своей эпической книге «Мифический человеко-месяц»).

Табу для разработчика: каких ошибок не стоит допускать при создании программных продуктов?

При создании программных продуктов не нужно допускать двух ошибок:

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

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

Каковы, на ваш взгляд, наиболее важные навыки для эффективного программиста?

Наиболее важные навыки эффективного программиста:

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

Можно ли после этого спокойно спать? :)

Можно. Такие маньяки водятся только в телевизионных сериалах. :)

Максим, каких возможностей вам не хватает в современных языках программирования?

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

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

Что нового, на ваш взгляд, появится в языках и средах разработки?

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

В то же время на уровне генерации машинного кода, наоборот, произойдет интеграция всех платформ и систем под знамя LLVM, т.е. исходный и/или промежуточный код (CIL, байткод JVM) будут транслироваться в представление LLVM, а только затем – в бинарный код целевой платформы. Это упростит переносимость продуктов, позволяя модернизировать интерфейсы в зависимости от конечного устройства, оставляя код бизнес-логики неизменным. Впрочем, это весьма оптимистичный прогноз.

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

Максим, что вам хотелось бы изменить в развитии IT?

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

Максим, спасибо за интервью. Хочется пожелать вам новых интересных проектов, развивающихся эволюционным, а не революционным путем! :)

Максим, расскажите, пожалуйста, о рождении TrackStudio. Как возникла идея, каковы были первоначальные замыслы? Что представляла собой первая версия, и насколько она была успешна?

В 2001 году мы занимались заказной разработкой для крупного иностранного заказчика. После 11 сентября заказчик закрыл проект, часть сотрудников освободилась, и мы решили начать проект внутренней автоматизации и SaaS-сервис для других организаций на его основе – тогда это было очень популярным направлением.

На тот момент трекеры в виде сервисов были 2-х типов:

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

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

Основных проблем было две:

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

Рынок крупных компаний – лакомый кусок для многих разработчиков. Какой вам представлялась ниша для будущего продукта?

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

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

Наша архитектура позволяла решить эту проблему, возможности системы в плане организации задач и управления правами доступа были уникальными. Фактически, TrackStudio – это не трекер, а что-то вроде «виртуальной машины для трекеров», которая позволяет реализовать множество самых разных процессов в рамках одной системы. Сейчас клиенты используют TrackStudio не только для управления ошибками, но и для смежных областей (управление документаций, требованиями) и даже для управления процессами, не имеющими прямого отношения к IT (обработка заказов, слияние компаний).

Развитие продукта: c какими трудностями вы столкнулись при работе над первыми коробочными версиями? Какие уроки вы извлекли в тот период?

Главная техническая сложность – реляционные СУБД довольно плохо работают с ситуации, когда

Первые 2 условия означают, что СУБД должна уметь очень быстро обрабатывать большое количество простых запросов (десятки тысяч запросов в секунду), а третье – что у нас есть серьезные ограничения на выбор алгоритма хранения дерева задач и кеширования информации. Если первые версии TrackStudio целиком использовали возможности СУБД, то в настоящий момент большая часть информации постоянно хранится в памяти и записывается в БД только для долговременного хранения.

Уже после этого мы узнали, что у Microsoft были аналогичные проблемы при попытке реализовать файловую систему поверх реляционной БД (проект WinFS, был закрыт). Попытка переноса Exchange на реляционную СУБД так же закончилась ничем.

Если бы мы начали сейчас писать TrackStudio, то наверняка использовали бы какую-нибудь NoSQL СУБД.

Каких подводных камней следует избегать в процессе создания коробочного продукта?

Нашим самым большим открытием в первые годы работы над проектом было то, что стандарты де-факто гораздо важнее, чем официальные стандарты. Аналитика сильно преувеличивает важность и популярность дорогих коммерческих продуктов (ORACLE, DB2, WebLogic и т.п.).

Самый важный урок: не нужно ориентироваться на официальную статистику популярности платформ, серверов БД и приложений. Поддержка MySQL может сказаться на продажах больше, чем поддержка ORACLE и DB2 вместе взятых.

Самый необычный пользователь: чем он запомнился?

Это был директор городского парка, бывший программист, который использовал SaaS-версию TrackStudio для задач вроде «Нужно покрасить скамейку».

Самый тяжелый пользователь?

Клиент из Австрии, который очень плохо понимал и писал по-английски. За несколько месяцев он написал более 600 писем с вопросами.

Как вы отлаживаете код? Что представляет собой техпроцесс работы над продуктом?

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

С организационной точки зрения исправление багов для нас стоит на первом месте, обычно мы не выпускаем продукт с известными багами. Это не значит, что в TrackStudio нет глюков (конечно, есть), но найденные глюки обычно исправляются уже в следующей минорной версии. Для версии 3.5 таких минорных версий было 77, для 4.0 – уже 9. Образцом для подражания для меня является OS/2 2.1, для которой было выпущено больше 100 fixpack-ов.

Причем мы стараемся не столько найти больше глюков, сколько ускорить устранение найденных. Со временем такой подход позволяет значительно увеличить надежность приложения: если сразу после выпуска TrackStudio 3.5 пользователи присылали 6-8 багрепортов в неделю, то через несколько лет мы стали получать 1 багрепорт в 3-6 месяцев.

Наш процесс разработки выглядит примерно так:

Т.е. мы не привязываемся заранее ни к конкретным срокам («нужно выпустить релиз 1 марта»), ни к надежности системы («если ни одной критичной проблемы, можно выпускать»). Определяющий для нас фактор – скорость реакции на запросы пользователей. Одновременно этот подход позволяет выровнять загрузку команды и исключить авралы.

Маленькая команда и большой продукт: каким образом осуществляется тестирование TrackStudio и его саппорт?

У нас нет своей команды тестировщиков. Перед выпуском бета-версии мы инсталлируем новую версию системы на свой сервер и активно используем несколько недель. Параллельно разработчики занимаются тестированием с применением средств покрытия кода (code coverage), мы устраиваем соревнования «кто быстрее достигнет заданного уровня покрытия».

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

Особенность нашей ситуации в том, что

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

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

ТDD и автотесты: оправданы ли они в работе над TrackStudio?

Нет, автоматические тесты не применяем. Пробовали, но ничего хорошего из этого не вышло. Причины такие:

Разные части TrackStudio очень сильно сильно взаимосвязаны. Например, работа правил оповещения по e-mail сильно зависит от работы фильтров, настроек правил доступа, пользовательских скриптов. Ситуации когда что-то перестает работать «совсем» у нас возникают редко (т.к. даже обычное создание задачи затрагивает работу значительной части кода TrackStudio), а вот проблемы только на какой-то конкретной конфигурации пользователя бывают часто. Моделировать такие ситуации в тестах довольно трудно, а поддерживать эти тесты в актуальном состоянии – еще труднее.

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

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

В какой-то мере да, но главное даже не это. В TrackStudio нет изолированных модулей, таких как багтрекер, CRM, форум. Вместо этого, у нас есть модули для работы с правами, с процессами, с почтой или отчетами. Если программисту требуется добавить какое-то поле или исправить форматирование, то это нужно будет сделать во всем приложении. Если программист не знает про оповещения по e-mail, то он даже не догадается, что его задача подразумевает исправления и там тоже.

Также важна унификация приложения: если мы реализуем какую-то возможность, то очень часто требуется реализовать ее во всем приложении. Если это сделает один человек (а не каждый в «своем» модуле), степень унификации кода будет выше.

Кроме того, при таком подходе code review происходит автоматически.

Есть ли у вас внутренний Coding Style (документ или «устное» коллективное знание, которое определяет принятый стиль кодирования)? Сможете ли вы привести примеры хорошего и плохого стиля?

В TrackStudio довольно редко приходится делать что-то совершенно новое, в основном происходит улучшение и переписывание старого кода. Мы стараемся придерживаться следующих правил:

Что касается форматирования, то никаких особых требований нет, используем «стандартное» форматирование средствами IDE.

Каковы признаки хорошего кода? Как сделать код более читабельным? Как обеспечить возможность его легкого изменения в будущем?

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

Каковы, на ваш взгляд, наиболее важные навыки, знания для эффективного программиста?

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

Еще важно умение подавлять в себе желание переписать старый код просто потому, что он “кривой” и не очень понятно как работает. Сначала хорошо бы понять не только как работает старый код, но и почему он так был написан – этим мы убережем себя от ошибок предшественников при переписывании.

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

У нас в TrackStudio 3.0 была возможность создавать иерархию ролей пользователей. Причем у пользователей и задач, на которые эти роли накладывались тоже были свои иерархии, код там был весьма сложный (особенно разбор ситуаций, которые могли происходить при перемещении задач и пользователей по иерархии).

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

А самые сложные баги – это разного рода утечки (памяти, соединений, блокировок).

Каких возможностей вам не хватает в современных языках программирования? Что нового, на ваш взгляд, появится в языках и средах разработки?

Я жду прогресса в области средств разработки параллельного кода, сейчас в этой области очень просто совершать ошибки и сложно их искать.

Что вам хотелось бы изменить в развитии IT?

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

Например, одной из наиболее популярных СУБД сейчас является MySQL. За счет простоты первых версий эта СУБД выиграла у PostgreSQL, а инновации последних лет заключались в реализации функциональности, которая была сделана конкурентами много лет назад.

HTML/CSS стали популярными именно за счет своей простоты, на многие проблемы технологии изначально просто закрыли глаза, в итоге интенсивное «допиливание» этих инструментов продолжается до сих пор, а web-разработка стала неоправданно сложным делом.

Тенденции последнего времени скорее не ослабляют, а усиливают этот эффект. Agile-практики фокусируются на получении мгновенного результата в ущерб архитектуре. Считается, что наличие тестов позволит относительно безболезненно поменять архитектуру системы потом, но это далеко не всегда получается. В популярной книге Getting Real от 37signals также предлагается сфокусироваться на решении простых проблем, оставив сложные на потом.

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

Максим, большое спасибо за интервью. Успехов вам, системе TrackStudio и вашим клиентам вне зависимости от конъюнктуры в IT!

Алекс, как вы пришли в мир функционального программирования? Что послужило отправной точкой для изучения теоретических основ ФП и первых практических шагов?

Я пришел к ФП с практической стороны – теория до сих пор не самая моя сильная часть :-)

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

Затем, на несколько лет, примерно до 96-го я занимался только императивными языками – различные ассемблеры, Fortran (IV & 77), C, C++, немного Pascal (хотя я его не особо люблю), а в 96-м на кафедре появился интернет, и я получил доступ к разнообразию открытого ПО, включая Guile – особенно были интересны эксперименты в GIMP’е, хотя я пытался использовать guile и для обработки текста и подобных задач. Продолжались и эксперименты с Common Lisp. Где-то в 98 или в 99-м году я познакомился со статически типизированными функциональными языками в виде Caml Light/OCaml, примерно тогда и начал интересоваться теоретическими постулатами ФП. Хорошим стартом был курс Джона Харрисона «Введение в функциональное программирование», который актуален и сейчас и даже был сделан перевод этого курса на русский язык.

В 2001-м я перебрался в Москву и начал работать в компании Инфосистемы Джет в качестве одного из разработчиков продукта Дозор-Джет, который разрабатывался на языке Scheme (PLT Scheme), так что мои знания очень пригодились. В Джете собрался очень хороший коллектив, поэтому часто возникали дискуссии о языках программирования, теоретических основах и т.п. Я продолжал более серьезно заниматься основами функциональных языков, деталями их реализаций, читал много теоретической литературы и продолжал эксперементировать с разными языками – OCaml, Haskell, Common Lisp, ну и Scheme была для работы :-)

С 2007-го года я работаю в компании Secure Computing (потом она была куплена McAfee), и хотя основным рабочим языком является С++, я применяю функциональные языки для прототипирования. Большей частью задействованы Lisp’ообразные языки (раньше это был Common Lisp, теперь большей частью Clojure), хотя иногда используется и Haskell.

Одна из интересных особенностей, связанных с функциональным программированием: даже если ты не программируешь на языках ФП, концепции ФП позволяют улучшить твою работу на императивных языках. Например, отсутствие изменяемых глобальных состояний позволяет делать меньше трудноуловимых ошибок, да и тестировать такой код намного легче. А как показала практика, наличие read-only данных в некоторых случаях позволяет упростить код и улучшить производительность высоконагруженных систем. Про такое применение идей ФП в императивных языках очень хорошо пишет Евгений Кирпичёв, статьи которого можно найти в журнале Практика функционального программирования (ПФП). У него есть много хороших примеров.

В последнии годы я принимаю участие в различных проектах, связанных с популяризацией функциональных языков. Это перевод курса Джона Харрисона, перевод книги Practical Common Lisp и последние два года – журнал «Практика функционального программирования», в котором мы стараемся давать и теоретическую и практическую информацию о функциональном программировании, как оно может применяться и т.п. Также я стараюсь поддерживать в актуальном состоянии обзор существующей литературы по функциональным языкам программирования, который первоначально был опубликован в первом номере ПФП, а сейчас выложен на моем сайте со множеством дополнений. Я также несколько раз рассказывал о языке программирования Clojure – на конференции MarginCon 2010 (через skype), и тут, в Германии, на митингах для программистов на Java.

Алекс, в чем удобство применения функционального языка для прототипирования?

Для меня ФЯ удобны следующим:

Из собственного опыта могу сказать, что нормальные программисты достаточно быстро осваивают новые языки программирования – за время, сравнимое со стандартным временем вливания в проект – до месяца. Могу сослаться на лекцию Льва Валкина о том, как они используют функциональные языки (Erlang и OCaml) в компании JS-Kit.

Алекс, каковы самые распространенные мифы, связанные с ФП? Что этим заблуждениям можно противопоставить?

Типичные ошибки программистов, начинающих осваивать и практиковать ФП? Что им можно посоветовать?

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

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

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

А забавных даже не припомню – я обычно работаю с серверными решениями, и если там доходит до каких-то видимых эффектов, то дело плохо :-)

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

Какой баг проявлял себя самым непредсказуемым образом, и докопаться до его сути было наиболее трудно?

В основном это баги связанные с утечками и повреждениями памяти (я после очередного поиска даже написал небольшую серию статей на эту тему). Такие ошибки крайне тяжело искать, особенно если они проявляются только при высоких нагрузках и/или после долгой работы (больше 2-3 недель). Мы столкнулись один раз с ошибкой в сторонней библиотеке (open source), которая не обращала внимания на системные лимиты, а всегда выделяла массив фиксированного размера, но использовала максимальное кол-во file handles, полученное от системы. В итоге, при большом количестве подключений библиотека затирала память в произвольном месте, так что ошибки возникали в самых разных частях системы.

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

Как вы тестируете приложения? В чем особенности вашего стиля работы и каким образом они определяют методику тестирования?

Я стараюсь писать код таким образом, чтобы он имел как можно меньше зависимостей. Это сильно облегчает написание автоматизированных тестов. Для базовых библиотек пишется большое количество тестов для разных случаев (code coverage порядка 90-95%, не покрытыми остаются в основном такие вещи, как обработка не-выделения памяти или обработка ошибок чтения с диска), что позволяет минимизировать кол-во ошибок при внесении изменений.

Для более сложных вещей также пишутся автоматизированные тесты, которые гоняются перед каждым коммитом. Кроме того, я пишу достаточно большое кол-во коммандно-строковых утилит, которые позволяют выполнить конкретную задачу – распаковать/запаковать данные и т.п. Применение таких утилит вместе с использованием существующих программ, например, unzip, etc, позволяет проверять корректность разбора данных (с проверкой контрольных сумм и т.п.). Эти утилиты используются при еженедельном прогоне относительно больших объемов данных (десятки гигабайт архивов и документов), а также перед коммитом после большого рефакторинга. Эти же утилиты применяются при профилировании кода.

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

Каковы признаки плохого и хорошего кода? Можете ли вы привести примеры? Как сделать код более читабельным? Как обеспечить возможность его легкого изменения в будущем?

Признаки плохого кода:

Хороший код:

Такой код очень легко тестировать, использовать в других проектах и т.д.

Чтобы код было достаточно легко развивать я использую несколько подходов в зависимости от назначения кода:

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

Самые большие/тяжелые ошибки, которые я видел – ошибки сделанные на начальном этапе проекта, например, неправильный сбор требований, неправильная
архитектура (как следствие отсутствия требований). Такие ошибки очень тяжело исправлять когда проект уже вовсю разрабатывается, плюс, часто сталкиваешься с тем, что люди не могут отказаться от написанного кода и пытаются вытянуть систему с помощью различных костылей, локальных переделок и т.д. Даже если удается «выкатить» систему в production, ее тяжело менять – исправлять ошибки, добавлять новый функционал. Поэтому я сейчас стараюсь увеличить стадию сбора требований и проектирования, чтобы убедиться, что система будет отвечать всем заданным требованиям.

Еще одна из ошибок с которыми я встречался – неправильная оценка сроков разработки + ошибки в отслеживании работ по проекту. Оценка сроков – вообще сложная тема, особенно при разработке нетиповых проектов, которые часто требуют больших временных затрат на research. Тут помогает только практический опыт, и все равно необходимо закладывать достаточно большие риски. Плюс многие программисты – оптимисты по натуре, и могут все сделать «за неделю» :-)

Отслеживание хода работ по проекту – также необходимая часть работы, поскольку понятие «готово» у разработчика и у project manager/team leader может сильно отличаться, и крайне важно не допустить «запущенных» случаев, когда к релизу система (или конкретная подсистема) очень сырая, или вообще не работает. И тут многое зависит от конкретных людей. Некоторые дают правильные оценки состояния своих частей, а за некоторыми надо следить внимательно и вовремя принять конкретные меры – обсудить возникшие проблемы, понять что надо для их преодоления – добавить времени на реализацию, добавить ресурсов (не всегда наилучший выбор) или вообще отложить данную функциональность до следующего релиза.

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

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

Разработчикам я могу посоветовать только одно: безопасность системы должна быть заложена в начальную архитектуру системы, поэтому необходимо оценить потенциальные угрозы/атаки на систему и постараться избежать типовых ошибок. Ну и в процессе разработки должен регулярно выполняться анализ кода, как автоматический, так и ручной(мы, например, проводим регулярное code review и выполняем автоматическую проверку кода с помощью нескольких систем статического анализа кода).

Вообще существует достаточно много хороших книг, посвященных разработке программных систем с учетом защиты и т.п. вещей. Например,

В Microsoft’овской серии книг Best Practices несколько книг также посвящены этой тематике, начиная от моделирования угроз, и заканчивая советами по организации разработки на конкретных языках программирования:

Тестирование – также важная часть процесса разработки, и тут можно посмотреть на следующую литературу:

Ну и программистам на C & C++ можно посоветовать следующие книги (особенно первые две):

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

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

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

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

I. Регулярное резервное копирование – штука для всех полезная

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

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

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

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

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

Пожалуйста, обратите внимание на заголовок этого раздела – РЕГУЛЯРНОЕ резервное копирование – это штука для ВСЕХ полезная. Здесь умышленно выделены слова «регулярное» и «всех». И если со «всеми» всем все понятно, то о регулярности надо себя заставлять помнить. Если вы один раз в неделю не почистили зубы, зубы останутся целы. Если вы один раз в неделю не сделали резервную копию, может статься, что именно в этот раз вы создали (а затем потеряли!) документ, на который потратили много времени и сил. Вы должны решить, как часто (например, раз в день, или каждый раз, когда вы завершили новый важный документ) вы делаете резервные копии, и придерживаться этого правила неукоснительно. Считайте, что это также важно, как предохранение при случайном сексе с незнакомыми или страховка ОСАГО для автомобиля. Если эти аллегории вас не убедили, придумайте себе свое сравнение, такое, чтобы отказ от резервного копирования казался вам самым страшным, что может настигнуть вас на этом свете.

II. Как сделать полезную штуку беcполезной

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

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

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

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

Из этого опыта пришлось вынести три правила:
1) нет контроля – считайте, нет копирования
2) нет контроля надежности резервной копии – считайте, нет копии
3) исполнитель резервного копирования должен быть надежным, обученным и ответственным

III. Оценивайте риски трезво

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

Используйте быстрые и надежные носители. Если вы копируете данные на флэшки, помните, что флэшки могут сильно отличаться по скорости записи, покупайте более дорогие, но быстрые экземпляры. Для важных данных используйте две разные флэшки. Перестаньте доверять рекламе: количество циклов перезаписи, которые выдерживает флэшка, на практике – не десятки тысяч циклов, а всего лишь сотни циклов. Храните флэшки там, где они не могут перегреться. Флэшки нельзя гнуть, швырять или наступать на них, несмотря на то, что ронять их обычно можно без вреда. После года использования переставайте доверять флэшке: она может работать еще долго, но уверенности, что с нее точно можно будет прочесть данные, уже быть не должно. Не жалейте денег на новые резервные носители – диски и флэшки, терять данные и время – всегда дороже!

Храните данные в резервных копиях в таком формате, который вы везде сможете прочесть. Так, файловую систему ZFS не поймет никто, кроме Solaris, Mac OS X и FreeBSD, а более свежие ее версии – только Solaris 11 Express. Диск в формате NTFS прочтется в Linux, но только если в данном экземпляре Linux установлена поддержка этой возможности. Наиболее универсальный формат – FAT32, но не все версии Windows умеют форматировать большие диски в FAT32 так, чтобы они везде прочлись, может понадобиться специальная программа. Я одну такую однажды купил в Интернете, но забыл название. Впрочем, сойдет любая – Google расскажет о многих.

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

Если вы занимаетесь веб-разработкой, делайте копии каждого веб-сайта, за который вы отвечаете, ежедневно. Помните, что важно сохранять не только содержание сайта, но и информацию о том, какое программное обеспечение используется для его отображения – версию веб-сервера, интерпретатора php, perl, базы данных mysql или postgresql и прочего. Если ваш проект связан с установленной на сервере виртуальной машиной Java, знайте точно ее версию. Сотрудники хостинговой компании или ваши коллеги-сисадмины могут без предупреждения изменить версию, и вы должны быть готовы потребовать «вернуть, как было». Для этого надо знать, «как было».

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

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

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

Делайте достаточное количество резервных копий, и помните, где вы их храните.

IV. Простые решения

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

Это – очень дешевое решение. Оно требует только немного времени и внимания – всего от одного человека.

Если вы можете использовать в качестве хранилища данных компьютер с системой Solaris 10, OpenSolaris или Solaris 11 Express, надо использовать встроенные средства резервного копирования. Файловая система ZFS, на которую по умолчанию устанавливается OpenSolaris и Solaris 11 Express, и которую можно использовать и в Solaris 10, позволяет сделать снимок всей файловой системы за мгновение:

zfs snapshot <имя-файловой-системы>@<имя-снимка>

Например,

zfs snapshot rpool/home/filip@2010-11-16

После этого сделанный снимок можно передать по сети или записать на внешний диск командой

zfs send

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

Для хранения самых важных документов можно использовать сервис компании Amazon, s3.amazon.com. Сейчас хранение первых пяти гигабайт файлов там бесплатное, каждый следующий гигабайт обойдется в несколько центов в месяц. Для хранения важных документов и фотографий – годится. Фильмы, конечно, туда не закачаешь: и долго, и недешево обойдется. Однако «важные» здесь не значит «конфиденциальные». Передача по сети и размещение на чужих компьютерах, находящихся не под вашим управлением, любых конфиденциальных данных – дело крайне рискованное и неразумное. Для таких данных можно использовать флэшку с встроенным модулем шифрации, требующую аутентификации по отпечатку пальца. Такие давно есть.

V. Когда резервное копирование не помогает

Если вы случайно нажали кнопку «выйти без записи» после того, как целый день редактировали важный документ, и до того вы этот документ не записывали на диск – вам не повезло. От невезения резервное копирование не помогает.

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

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

Излишний консерватизм, постановка маленьких и жалких целей. Мне следовало больше рисковать, чаще пробовать что-то новое. Я жалею, что не прочитала раньше такие книги как «Рефакторинг» и «Программист-прагматик».

Алена C++ в своем первом проекте и Алена C++ сегодня: что изменилось в ваших подходах к созданию приложений, к стилю программирования?

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

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

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

Елена, сможете ли вы рассказать о наиболее значимой ошибке, которую вам доводилось видеть в проектах?

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

Какие выводы из подобных ошибок удалось извлечь?

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

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

Забавную багу как-то поймал мой коллега. У нас по уровню ходили глаза. Дело было в том, что юниты не убивались до конца и застывали на последнем кадре анимации, на глазах собственно. Это был простой баг, он быстро его поправил.

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

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

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

Применяете ли вы TDD? Оправдан ли этот подход в ваших проектах?

Нет. Я работала в основном со спокойными дисциплинированными специалистами. Практики вроде TDD хороши для команд, склонных к ковбойству.

Каковы признаки плохого (ковбойского) кода? Можете ли вы привести примеры?

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

Внешние признаки, которые мне встречались: несоблюдение стандартов кодирования или их полное отсутствие, вплоть до того, что отступы могут «гулять» в одной и той же функции. Сильная связность кода, нарушение инкапсуляции. Неправильно выстроенное наследование, нарушенное IS-A отношение. Волшебные константы (magic numbers). Странное именование переменных, полное отсутствие комментариев и документации. Как-то, распутывая кусок кода, наткнулась на комментарий //Fuck!!!!!. Это тоже плохой признак. :-)

В качестве примера могу привести код, который мне встречался в разных проектах и от которого я пыталась избавиться. Встречается у программистов, которые недавно перешли на С++ с С. Для того, чтобы обеспечить полиморфное поведение, они часто используют типично сишный прием: объявляют enum, в нем задают что-то типа TYPE_CIRCLE, TYPE_TRIANGLE и т.п. Потом в коде пишут длинный-длинный if.

if( type == TYPE_CIRCLE ){
... }
else if( type == TYPE_TRIANGLE ){
...}
else if ...

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

Как сделать код более надежным, более читабельным?

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

Если есть проблемы с читаемость и надежностью уже существующего кода, это лечится рефакторингом. Мартин Фаулер в «Рефакторинге» все отлично рассказал.

Как обеспечить возможность легкого изменения кода в будущем?

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

Выбор языка программирования для создания приложения: насколько он важен?

Язык важен. Важно и то, чтобы решение об использовании какого-либо языка принималось всей командой. Если вы придете к С++ программистам и скажете, что с завтрашнего дня мы все пишем на PHP, они несколько расстроятся.

Может ли тот или иной язык сделать код более качественным, а разработку более эффективной? Сможете привести примеры?

Очень наглядный пример: сегодня неразумно заниматься веб-разработкой на С++. На вебе сейчас популярны другие языки. Это Ruby, Python, PHP. Также ставятся эксперименты с языками типа Erlang. Эти языки и безопаснее, и разработка на них пойдет быстрее, и специалистов обучить будет проще. На С++ если и писать, то какие-то высоконагруженные куски.

Табу для разработчика: каких ошибок не стоит допускать при создании программных продуктов?

Никогда не говори «никогда». Я стараюсь действовать по обстановке, избегать карго-культа. Решения, над которыми я буду напряженно думать, прежде чем принять: использование сторонних библиотек без исходников, переписывание вместо рефакторинга.

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

Елена, что представляет собой конвейер разработки и почему важно, чтобы он не останавливался ни в коем случае?

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

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

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

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

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

Команда QA в большом проекте. Каковы сильные качества наиболее полезных тестировщиков? С какими тестировщиками наиболее комфортно работать? В каких условиях отдача от тестировщиков наиболее ощутима?

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

Гибкие методики (Agile, XP, Scrum): насколько они эффективны на практике?

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

Deadlines, авралы. Можно ли их избежать?

Deadline – это срок к которому должен быть сдан проект или часть проекта. Это нормально, они нужны. Авралы же – ненормальное явление. И они очень-очень сильно сказываются на морали и качестве кода. Как правило, признаки надвигающегося аврала видны задолго до. Часто их игнорируют. Недопущение авралов – это обязанность руководителей проекта. Я работала в авральных ситуациях, когда аврал был следствием ошибки менеджмента. Это нормально, все люди ошибаются. Задача программистов тогда: исправить это по мере сил. Но гораздо чаще бывает, что аврал – не следствие ошибки, а спланированная политика. Программисты работают дольше, а то и в выходные, и создается ощущение, что мы за те же деньги получаем больше.

Как вы планируете сроки (время, которое планируется на создание той или иной функциональности)?

Мне нравится метод Джоэла Спольски, он у себя в блоге учил оценивать время работы в часах. После некоторой тренировки это начинает хорошо получаться. Для того, чтобы можно было с такими сроками работать, требуется сильный менеджер, который четко знает чего хочет. С лучшим менеджером, с которым мне приходилось работать, мы работали над проектом с очень короткими и жесткими сроками, оценивали работу в часах и нам удалось очень хорошо попасть в наши оценки.
[От редакции: новая статья Елены на тему временных оценок в программировании].

Существуют ли какие-нибудь эмпирические коэффициенты?

А, да, я слышала про «умножай на три». Нет, это не работает. Если программист не умеет оценивать сроки, то подбором коэффицента эту проблему не решить.

Елена, каких возможностей вам не хватает в современных языках программирования?

Не хватает автоматического распараллеливания кода. Когда эту работу пытаются делать программисты, получается плохо, багов слишком много, баги неприятные, трудно воспроизводятся. Я сейчас наблюдаю за решениями, за языками, в которых пытаются это сделать. В этом смысле очень интересно выглядит язык Clojure, а также GpH (Glasgow Parallel Haskell). Возможно, транзакционная память поможет решить некоторые проблемы конкурентного программирования.

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

Что ожидает программирование и программистов в будущем?

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

Что нового, на ваш взгляд, появится в языках и средствах разработки?

На мой взгляд, нужны средства массовой групповой разработки. Речь идет о работе сотен, тысяч программистов, работающих удаленно. В основном это нужно свободным open source проектам. Текущие решения все равно требуют пристального внимания небольшого количества человек, к которым в итоге стекается весь код, и это становится узким местом. GitHub – хороший большой шаг в этом направлении.

Елена, что вам хотелось бы изменить в развитии IT?

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

Елена, большое спасибо за интервью. Успехов в ваших проектах!