Вебкасты про Agile

http://www.autumnofagile.net/
http://www.summerofnhibernate.com/

User Group: Изучение качественного кодирования!

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

Цель встреч: изучение и углубление знаний в области design patterns. Мы практикуемся и обмениваемся опытом в сфере качественного кодирования, шаблонов, рефакторинга и т.п. (см. выше).

Study Group – помогает осилить сложные книги и идеи, может помочь там, где другие проваливаются, и он поможет тогда, когда в вашем окружении нету тех, кто хочет учиться и расти.



Место встречи:
Кафе в центре Москвы,
Каждую среду в 19 часов
Контакты: syspo_mail.ru
ICQ: 20079282
skype: denis_miller
+7 917 518 68 12 (Денис)

Практическая конференция "Agile дни" (Agile Day)

21 Июн	Agile дни в Москве г. Москва Сб, 28 Июня 2008 в 10:00

Agile в Ростове

Вчера вернулся домой из Ростова-на-Дону, где всю неделю с ребятами из команды eSignal работали на тему "Инженерные практики Agile". За 6 дней тренингов мы охватили такие направления как Design Patterns и Refactoring. В последний день провели результирующую очень мощную коучинг-сессию, в которой поговорили о тестировании, командном взаимодействии и разработали новую Agile-практику (которую обещали проверить в ближайшее время).

А в один из вечеров мы организовали открытый семинар на тему "Эволюционный дизайн" с точки зрения Agile. В обсуждениях приняли участия около 30 самых прогрессивных ИТ-ростовчан.

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

Так держать!

Соглашаемся на некачественный код

В предверьях семинара http://profyclub.ru/projects/seminars/2588/ я изложил свои мысли в виде статьи. Предлагаю ознакомиться и покомментировать :)

Соглашаемся на некачественный код
Денис Миллер

Что скрывается за качеством кода? Минимально количество ошибок? Правильно оформленные названия полей и методов? Жесткое распределение файлов проекта по папочкам? С точки зрения Стива Макконнела [2] качество системы снижает расходы на её разработку. Чем меньше мы усилий тратим на понимание своего же кода, тем легче мы добавляем новый функционал. Продолжая эту мысль – чем меньше мы допускаем запутанности кода, тем лучше качество. Часто разработчики говорят, чтобы в будущем было легче разобраться в коде, нужно выработать «Соглашение о наименовании». Ниже я покажу , что такое соглашение имеет смысл, но с качеством кода связанно косвенно.

В начале разработки сложных приложений ведущие разработчики и менеджеры проектов ставят перед командой вопрос о принятии «Соглашения о наименовании» (Coding & Naming Convention, сокращённо CNC). Фактически дав разрешение на религиозную войну. Соглашение есть способ документирования опыта, предпочтений и привычек одного из разработчиков. Преимущественно документируется (навязывается) опыт ведущего разработчика. Если бы было не так, то в команде в 7 человек, должно появиться как минимум 7 соглашений. Многие команды, чтобы избежать разногласий выбирают соглашение рекомендуемое авторитетным источником (Java [5], .Net [6]). Другой вариант, когда команда принимает соглашения уровня корпоративного стандарта.

Если посмотреть со стороны на процесс принятия соглашения. То можно заметить, что происходит парадоксальная ситуация. Команда забывает, что суть соглашения не в наименовании, не в авторитете, а в том, чтобы поддержка разработанного кода была легче и самое главное будет легко передан смысл кода. Когда любой разработчик сможет обратиться к написанному мною участку кода и этот участок будет понятен. Проведём аналогию с русским языком. Грамматика и орфография является неким соглашением. Но если так, ТО Сей4ас Я наPушИЛ соГлашеНИЕ По НАИМеноВанИЮ. Но смысл понятен и я легко могу внести изменения.

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

Важнее определить не соглашение. А принципы, из которых должны исходить разработчики, чтобы код был легок в поддержке, сопровождении и дальнейшем развитии. А таких принципов три[3]:
1. Коммуникация
2. Простота
3. Гибкость

Код пишется не для компьютера, а для человека. Первый принцип говорит, что разрабатывая код подумайте: сможет ли его прочитать другой человек? сможет понять его смысл? Второй принцип подсказывает, что требуется выбирать наиболее простое решение. А любую сложную функциональность (например, метод больше 10 строк [1]) декомпозировать на несколько простых. Гибкость – самый сложный принцип, за его реализаций предлагаю обратиться к шаблонам проектирования (design patterns)[7].

Исходя из указанных принципов можно строить уже не стилистическое соглашение CNC, а смысловое. Косвенно о таком соглашении идёт речь в книге «Совершенный код» Стива Макконнела[2] и ещё больше рассказывает о реализации трёх принципов Кент Бек [3].
В семинаре выбран другой, но не менее важный подход. Подход известный в математике «от обратного». Определив соглашение в виде положительных утверждений, мы не определяем случаи злоупотребления теми или иными конструкциями. Которые не несут ярко выраженного отрицательного эффекта для разработчика и даже соответствуют «соглашениям». Такие случаи только потенциально могут привести к сложности кода. Их называют - smells. Так если каждый программист будет допускать их появление, то они будут накапливаться словно снежный ком. И через буквально 1-2 месяца разработки корректный с точки зрения «соглашений» код будет совершенно нечитаемый с точки зрения смысла.

Семинар предлагает командам принять новое соглашение, которые должно сформироваться на основе каталога smells. "Code smells" сигнализирует о потенциальных сложностях кода. Правильная интерпретация этих сигналов позволит вам выявлять некачественный код, затрудняющий разработку и приводящий к удорожанию решений, а также трудности модификации существующего кода. Предлагаемая практика полезна как малым командам, так и крупным предприятиям, вовлеченным в промышленную разработку. На семинаре мы рассмотрим общий каталог Smells, включающий различные уровни: кодирование, базы данных и архитектуру. Особое внимание мы уделим каталогу некачественного кода и способа устранения smell’ов – рефакторинг. Один из первых авторов, кто поднял тему рефакторинга и работы со smell’ами является Мартин Фаулер [1].

Внедрение нового подхода в кодировании требует определённые усилия. Во-первых, нужно изменить порядок принятия соглашения. Заменить принятие правил как цельного документа на постепенное (итерационное освоение, см. принцип итерационного подхода в Agile-методологиях). Так предлагается построить приоритетный список некачественных решений по степени появления. После одобрения всей командой в течении одной итерации осмысленно и целенаправленно избегать пять самых приоритетных smell’ов и проводить рефакторинг над ними. Здесь можно использовать техники парного программирования, code review различного уровня. В завершение итерации добавить встречу для обсуждения (Smell Meeting). Во-вторых , требуется изменения режима разработки. Заменить устоявшуюся цепочку задача-модификация-тестирование на задача-рефакторинг-модификация-рефакторинг-тестирование. А в дальнейшем посмотреть на популярный на западе подход к самоорганизующимся и самообучаемым командам на основе Agile-подхода[7, 8] в разработке.

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

Дополнительно:
1. Мартин Фаулер. Рефакторинг. Улучшение существующего кода
2. Стив Макконнелл. Совершенный код. Практическое руководство по разработке программного обеспечения
3. Kent Beck. Implementation Patterns
4. Э.Гамма «Приемы объектно-ориентированного проектирования. Паттерны проектирования».
5. Code Conventions for the JavaTM Programming Language. http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
6. .NET Framework Developer's Guide Guidelines for Names.
http://msdn2.microsoft.com/en-us/library/ms229002.aspx
7. Российское Agile сообщество.
http://agilerussia.ru
8. Рассылка «Инженерные практики Agile».
http://subscribe.ru/catalog/comp.soft.prog.agile

Семинар "Гибкие методологии Agile. Эволюционный дизайн"

13 Фев	Гибкие методологии Agile. Эволюционный дизайн. Бизнес-центр «Купеческий двор» Ср, 13 Февраля 2008 в 19:00

Инфекция Agile обнаружена в Сибири!

В начале ноября при поддержке Учебного Центра «Люксофта» в городе Омске состоялись тренинги, посвящённые применению гибких методологий в разработке программного обеспечения, а так же техникам повышения личной эффективности.

Тренинги проводил Agile-евангелист Денис Миллер.

 

 

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

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

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

 

Knowledge Transfer with SCRUM

| View | Upload your own

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

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

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