OpenQuality.ru

В кругах профессиональных разработчиков Елена Сагалаева (Алена C++) широко известна благодаря своему блогу и докладам на конференциях. Нюансы С++, алгоритмы, геймдев, будущее индустрии, стартапы, обзоры книг – вот далеко не полный перечень тем, которые Елена поднимает в своих публикациях. Поднимает и раскрывает с присущей ей глубиной и основательностью. Программирование для прагматиков – название блога Елены и предмет нашего сегодняшнего разговора.

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

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

Алена 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?

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

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