Просмотр исходного текста страницы Software Best Practices-2007

<blockquote>
Конференция Software Development Best Practice прошла в 2007 году. Сайт конференции http://www.sdexpo.ru/ уже недоступен, но анонсы остались: [http://www.silicontaiga.ru/home.asp?artId=6755 один] и [https://www.crn.ru/events/detail.php?ID=1555 другой]. Далее - мой отчет о конференции, опубликованный тогда внутри компании -  публичного блога у меня еще не было.
</blockquote>

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

Ключевая вещь, которая заинтересовала и вдохновила - Agile programming и ее проявления в виде extreme programming, scrum и композитных методов. Для меня, собственно, было ново и интересно выступление менеджеров, команды которых практически используют эти методики в реальных успешных проектах. В том числе сертифицируя их применение по ISO 9000. А это означает, что имеются готовые технологии и методологии, и можно основываясь на них строить процесс производства. На уровне общих слов они сильно пересекаются с прогрессивной частью имеющихся у нас в компании методик и тенденций, однако тут важны нюансы и комплексность подхода. Поэтому было бы интересно оценить, и, возможно, претворить в практику. Во всяком случае, правильно изменения в нашей компании вести в этом русле, а не вопреки ему.

Далее по докладам.

; Bruce Eckel : Набор концептуальных фрагментов, посвященных путям программирования и месту человека в этом процессе. Такая вот мозаика, ну он мэтр, может себе позволить. Воспроизвести не берусь. Из основных мыслей: смотрите по сторонам, на побочные ветви процесса, там бывает много интересного.

; Simon Monk, Momote ltd : Доклад по Agile Programing в виде Extreme programming. Основная идея - это хорошо и применимо на практике. У них небольшие этапы или проекты: 10 дней маленький, 20 - средний, 40 - большой. Это астрономический срок разработки, к этому есть стандартные времена на постановку (2-4-5) и на внедрение (3-4-5). Группы по 7 человек - менеджер, 4 разработчика, 2 тестера. Реально используют парное программирование. Говорил, что много чего меряют по самому процессу разработки и внедрения, считают структуру затрат на проект, представляют ее заказчикам. 

; Alexey Kovyazin GodeGear :  Развитие software, 1 трек. Достаточно полный и скучноватый обзор истории развития ПО для PC, хоть и вызвавший (у меня) воспоминания по прошлому. По современным тенденциям - слабо. Очевидное противостояние .Net и Java как платформ, и как стоящих за ними корпораций, с рассуждениями, что может они договорятся, а может - нет. Но была интересная мысль, что действительно новые решения. определяющие тенденции. всегда рождались не внутри гигантов, а приносились со стороны, после чего кто-то из гигантов это, как правило, перекупал и далее развивал. То есть идеи приходят сбоку. А еще очевидная мысль, что разработчики не лояльны, и выбирают средства по текущему состоянию, а не за исторические заслуги.      

; Круглый стол по Agile : Участники (StarSoft, Motorola в России, Artezio) - действующие менеджеры компаний, в которых успешно все это применяется. Собственно, этим и интересно, хотя сам разговор - не очень. Они обсудили некие темы по практике применения этих методик. Из интересного - сертификация этого процесса по стандартам ISO, то есть можно вынимать нормативно положенную документацию и метрики, характеризующие качество процесса, не взирая на его экстремальный характер. Звучала цифра, что применение SCRUM удваивает производительность по сравнению с традиционными методиками. По оплате - уход от fixed cost к target cost, с делением рисков пополам с заказчиком.

; Bertrand Meyer : К полностью автоматическим тестам. Доклад хорошо описал Игорь Беспальчук в своем отчете, и я не вижу смысла повторяться. Хотя меня как программиста всегда интересовало тестирование, выходящее за рамки модельных примеров, с которыми и так все понятно. И тут мне не очевидно, что из автоматических вызовов может нечто разумное получится.

; Olga Ananko, Security testing : Увы, оказалось что это Web. Хотя на уровне общих слов все это применимо всюду, но с нашей практикой связано слабо. То, что они тестируют - понятно. Это ввод неверных параметров, попытки сделать незаконные по бизнесу действия или превысить границы своих прав. Я надеюсь, что наши тестеры тоже это делают, но далеко не уверен. Во всяком случае, судя по широкому и произвольному предоставлению прав в СМ, это не является большой заботой заказчика. Но конкретные примеры в докладе ограничивались Web-приложениями, и это не интересно.

; Roman Elizarov : Практически доклад был о некоей системе обработки сообщений, которая должна переваривать их со скоростью до 1 млн. сообщений в секунду. Причем очень важно было избежать катастрофического падения производительности при превышении каких-то порогов. Очень интересно рассказанный, были убрана специфика конкретной системы и оставлена методологическая суть. Первое - не надо использовать MiddleWare. Потому что они реализуют некий сложный стандарт, который по природе не может быть быстрым и давать более 10K сообщений. При этом в конкретном приложении полный функционал этого стандарта обычно не нужен, на чем и экономим. Второе - если нужна хорошая производительность, это надо закладывать в архитектуру. Показаны два тонких места - синхронизация, то есть переключение процессов, и выделение памяти, которое надо мерить со сборкой мусора, а не отдельно. Ну и соответственно, как пример: для обработки сообщений оптимален типовой шаблон с итератором, позволяющий обрабатывать их пачками с внешней или внутренней синхронизацией не по каждому сообщению, и не диктующий способа выделения памяти. В общем, шаблоны полезны не только по стилю, но и по сути. Кстати, с выделением памяти: свой пул объектов, скорее всего, будет медленнее стандартного, он может быть полезен только для больших объектов, а никак не для скорости. Они добились требуемого 1M сообщений, ограничением стала 10Mb сетка, которую они грузят полностью. 

; Sergey Belov, StarSoft : Guerilla XP. Что делать, если заказчик не хочет extreme, а команда работает именно так. Тогда менеджеру приходится работать за заказчика. Ну и рассказывался пример проекта, история 2.5 года, 18 итераций, 17 человек команда, сейчас 1500 пользователей. По срокам итераций: ошибались пару раз на пару дней для месячной итерации. Сложнее всего - аналитику, так как он фантазирует. При планировании итерации оставляют резерв для изъятия, чтобы заменить это доработками, если аналитик не угадал. плюс усиливают команду тестеров, она тоже работает за заказчика. Используется парное программирование, задания режутся по дню, пары каждый день меняются. Плюс используется карусельный codereview - один программист из команды смотрит и рецензирует заливки за день, плюс тех.лидеры соседей. Общая идея: у программиста 3 продуктивных часа в день, пусть эти три часа он и программирует, но остальное время он тоже может приносить пользу. Используется ежедневная сборка и проверка - unit test, module test + high level test. Как-то так.

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



[[Категория:Конференции]]