?

Log in

No account? Create an account

Ср, 9 янв, 2013, 00:51
Книги: декабрь

«Избранные произведения Леонардо да Винчи»

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

Вот, например, в прекрасном рассказе «Сода-солнце» Михаила Анчарова говорится о том, что Московский Кремль проектировал малоизвестный Пьетро Антонио Солари, который, оказывается, был учеником Леонардо да Винчи, построившего Миланский Кремль:

Но почему именно ученик? Мало ли в Милане жило мастеров в то время, как Леонардо строил Кремль? Да и Леонардо не один его строил. Нужно хоть какое-нибудь прямое доказательство. Представьте себе — оно было.

Если вы пройдете у стены, которая тянется вдоль Москвы реки, то на самом верху ее вы обнаружите странные отверстия. Странные они потому, что они не в зубцах, как обычно, а между зубцами, ниже их подножия. Зубцы — это не украшения: за ними стояли воины, а в отверстия они лили кипяток и смолу. А тут отверстия находятся между зубцами, в кирпичном барьерчике, за которым даже лежать нельзя — такой он низенький. Бессмысленных отверстий в крепостной стене быть не может.

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

И действительно, есть такой рисунок!

P. S. Не откажу себе в удовольствии сослаться и на другой рассказ — труды Леонардо хранят еще много тайн для пытливых умов.

Jared Richardson, William Gwaltney Jr., «Ship It! A practical guide to successful software projects»

Авторы делятся теми практиками и инструментами, которые, по их опыту, неизменно подтверждают свою пользу и эффективность. Мне показалось интересным сравнить их предложения с тем, что используется у нас в компании.

  • Разработка в «песочнице» — каждый разработчик ведет разработку так, чтобы не мешать другим
    У нас про это говорят с иронией: «каждому разработчику по инстансу». Увы, система слишком велика и прожорлива, чтобы оправдать поддержку такого количества сред. Но по возможности, конечно, стараемся не мешать друг другу.
  • Система контроля версий
    Да, конечно. Хотя я еще помню смутные времена, когда исходный код был только в базе.
  • Автоматизированная сборка
    У нас нет такого понятия, как сборка. Система не пересобирается, изменения выкатываются на нее в виде патчей. А вот процесс сборки патчей — да, практически автоматизирован. Хотя тут есть еще над чем поработать.
  • Автоматическая сборка — a.k.a. непрерывная интеграция и тестирование
    Сборка у нас лишена смысла, см. выше. Вот что не лишено смысла, так это тестирование. Даже те немногочисленные тесты, которые у нас есть, никто никогда не прогоняет, и теперь я понимаю, как это исправить. Надо прогонять их автоматически после перекомпиляции любого объекта в базе данных! Надо подумать, как это сделать технически, в частности, отправку результатов почтой.
  • Ведение задач и дефектов
    Да, JIRA. К сожалению, в JIRA невозможно заниматься планированием, поэтому много времени уходит впустую на перекладывание из Excel или Project в JIRA и потом поддержание в ней актуального состояния. Как с этим бороться — не знаю.
  • Ведение требований
    Да. Чаще всего это Excel, но в последнее время пытаемся вести в JIRA.
  • Автоматические тесты
    Тут наше слабое место, тесты мы практически не пишем. Во-первых, платить предпочитают за поддержку, а не за отсутствие дефектов, а во-вторых есть технические трудности.
  • Список (с большой буквы) — перечень задач: выложен на видное место; приоритезирован; с временными оценками; отражает реальную текущую картину; содержит пункты, про которые можно точно сказать «выполнен» или «не выполнен»; предназначен как для всей команды, так и для каждого в отдельности
    Раньше был действительно Список в Excel, но он не был «выложен на видное место» и работал плохо. Сейчас это JIRA. Над приоритезацией надо подумать: сейчас мы ориентируемся скорее на предполагаемую дату готовности, чем на приоритет как на таковой.
  • Технический тимлид
    Да, хотя у авторов этот человек выполняет роли как нашего технического тимлида, так и функционального. Возможно, объединить их и имеет смысл, но где взять таких мегамонстров?
  • Ежедневные общие встречи
    Мы практикуем еженедельные встречи (по времени порядка часа). На мой взгляд, это оправдано, поскольку в наших реалиях задачи и код пересекаются не настолько, чтобы встречаться ежедневно. Авторы сильно агитируют, но я не проникся.
  • Ревью кода
    У нас ревью в основном делают тимлиды, и происходит это после коммита в репозиторий кода. Авторы предлагают, чтобы ревью делали все (над этим надо подумать, но пока не вижу, как это организовать с пользой) и чтобы в комментарии к коммиту стояло имя ревьюера (у нас коммит не ломает сборку, так что не страшно). Ценная мысль: ревьюить небольшие изменения, не доводя до того, что придется пересматривать тысячи строк кода.
  • Рассылка изменений в коде
    Нет, но идея интересная. Надо подумать, как это сделать, и попробовать на практике.

Эдвард Йордан, «Путь камикадзе: как разработчику программного обеспечения выжить в безнадежном проекте»

На эту книгу часто ссылаются (в том числе и авторы Ship It!), а я, хоть и читал ее когда-то, ничего не запомнил, кроме отвращения от перевода и типографики. Не то, чтобы сейчас я стал терпимей к издательству Лори, но появился кое-какой опыт, на который эта книга хорошо ложится. Йордон определяет безнадежный проект, как тот, которому не хватает как минимум 50% какого-либо ресурса, и рассуждает о 90-часовых рабочих неделях. У нас нет «безнадежных проектов» в таком смысле, но 10-20% и 50-60 часов — это сплошь и рядом. А от сгущения красок картина видна только яснее, отмасштабировать потом всегда можно.

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

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

  • Формальное управление рисками
    Вот это несколько мутная для меня тема. Надо будет почитать что-нибудь.
  • Планирование, основанное на данных, полученных в предыдущих проектах
    С этим плохо, таких данных обычно просто нет, и не очень понятно, как их собирать — проекты-то все разные.
  • Двоичная оценка завершенности — «да» или «нет»
    Стараемся, но иногда, если не уследить, казалось бы по завершенной задаче начинают меняться требования и пошло-поехало. Это надо пресекать.
  • Ежедневная сборка проекта
    Йордон имеет в виду ежедневную готовность к сдаче работы, и в таком смысле эту идею надо обдумать. Сейчас у нас более длинные циклы и я не уверен в необходимости их укорачивания.

И еще пара ценных мыслей:

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

Ср, 9 янв, 2013 15:26 (UTC)
egorius

Фиговая политика. С такой политикой я и сам бы не исключено_что.