Новая рассылка

Для придания динамизма теме качественного кода я открыл рассылку http://subscribe.ru/catalog/comp.soft.prog.agile

Присоединяйтесь!

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

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

Training Refactoring

28 Янв	Тренинг Рефакторинг Офис Люксофт Пн, 28 Января 2008 в 09:00

Научное исследование эффективности методологии TDD

Сразу с цитат:

We found that test-first students on average wrote more tests and, in turn, students who wrote more tests tended to be more productive. We also observed that the minimum quality increased linearly with the number of programmer tests, independent of the development strategy employed.

За счёт TDD были достинуты:
- лучшее понимание задачи
- лучшее фокусировка на задаче и повышенное внимание к задаче
- лучше обучаемость
- низкий процент переделки

Отчёт: Proceedings of the IEEE Transactions on Software Engineering, 31(1). January 2005.
Ссылка: источник

Инструкция превращения Junior Developer'a в Agile-профи

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

Начинаем
Первым делом нужно дать сводные понятия о таких вещах как
# Agile Software Development
# Scrum
# Domain Driven Design
# Test Driven Development
# Object Oriented Design
# Enterprise Design Patterns
# Secure Development Lifecycle
# Дальше конкретные технологии (ASP.NET/BizTalk/SharePoint/WCF/WPF/etc)

Важные понятия
Чтобы стать сильным Agile объектно-ориентированным разработчиком вам обязательно нужно будет ряд простых понятий:
Separation of Concerns
Liskov Substitution Principle
Law of Demeter
Single Responsibility Principle
Open/Close Principle
Interface Segregation Principle
Dependency Inversion Principle

Закупаем литературу
Чтение статей и участие на форумах не сделает из вас сильного разработчика. Нужно обратиться к фундаментальным работам.
# Agile/Development Principles
  * Code Complete: A Practical Handbook of Software Construction (Steve McConnell)
  * Agile Software Development, Principles, Patterns, and Practices (Robert C. Martin)
  * Agile Principles, Patterns, and Practices in C# (Robert C. Martin)
  * Agile Software Development with SCRUM (Ken Schwaber)
  * User Stories Applied: For Agile Software Development (Mike Cohn)
  * Practices of an Agile Developer: Working in the Real World (Andrew Hunt)
# General Development
  * Release It!: Design and Deploy Production-Ready Software (Michael Nygard)
  * Ship it! A Practical Guide to Successful Software Projects (Jared Richardson)
  * The Pragmatic Programmer: From Journeyman to Master (Andrew Hunt)
# Design Patterns
  * Head First Object-Oriented Analysis and Design (Brett McLaughlin)
  * Patterns of Enterprise Application Architecture (Martin Fowler)
  * Design Patterns: Elements of Reusable Object-Oriented Software (GoF)
  * Head First Design Patterns (Elisabeth Freeman)
# Domain Driven Design
  * Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans)
  * Applying Domain-Driven Design and Patterns: With Examples in C# and .NET (Jimmy Nilsson)
# Test Driven Development
  * Test Driven Development: By Example (Kent Beck)
  * xUnit Test Patterns: Refactoring Test Code (Gerard Meszaros)
  * Pragmatic Unit Testing in C# with NUnit, 2nd Edition (Andrew Hunt)
# Refactoring
  * Refactoring: Improving the Design of Existing Code (Martin Fowler)
  * Refactoring to Patterns (Joshua Kerievsky)
# Secure Development Lifecycle
  * The Security Development Lifecycle (Michael Howard)
  * Writing Secure Code, Second Edition (Michael Howard)

И специализированная литература:
# C#/.NET Framework
  * CLR via C#, Second Edition (Jeffrey Richter)
  * Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Krzysztof Cwalina)

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

Источник: Starting Junior Programmers on the Right Agile Track Guidance

FxCop 1.36

Качество кода конечно же невозможно без всевозможных тулзов. Сегодня я хотел бы обратиться к уже известной программе FxCop. А причина довольна проста - её реанимация. Буквально недавно Microsoft выпустил вторую бету новой версии FxCop 1.36. Будем надеятся, что скоро будет релиз :)

FxCop is a code analysis tool that checks .NET managed code assemblies for conformance to the Microsoft .NET Framework Design Guidelines. It uses MSIL parsing, and callgraph analysis to inspect assemblies for more than 200 defects in the following areas:

Library design
Globalization
Naming conventions
Performance
Interoperability and portability
Security
Usage

Ссылка: Microsoft FxCop 1.36 Beta 2

Видео "Lean: cовершенствование процессов разработки"

Доступно видео "Lean: cовершенствование процессов разработки"!!! Пока есть только первый семинар из двух, проходивших 26-го декабря. Второе видео будет скорее всего готово на следующей неделе

 

Lean и роль менеджера в Agile. Бесплатный семинар.

12:25 pm - Семинары "Lean и роль менеджера в Agile"

26 Дек	Семинары "Lean и роль менеджера в Agile" Luxoft Ср, 26 Декабря 2007 в 19:00

Мэнеджмент проекта vs JIRA

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

http://confluence.atlassian.com/display/JIRAEXT/Agile+Wall+Report
http://confluence.atlassian.com/display/JIRAEXT/Agile+Velocity+Tracking+plugin
http://confluence.atlassian.com/display/JIRAEXT/JIRA+Charting+Plugin
http://confluence.atlassian.com/display/JIRAEXT/Timecharts
http://confluence.atlassian.com/display/JIRAEXT/Links+Hierarchy+Reports
http://confluence.atlassian.com/display/JIRAEXT/Laughing+Panda+JIRA+Agile+Report+Plugins

И дальше по ссылкам. Очень порадовало заточка ряда плагинов на Agile практики. Так что дерзайте!

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

Personal Sprint

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

1. Vision. Общие знания о проекте, стратегия его развития, фундаментальные принципы декомпозиции и т.п. То что почти не меняется. Стратегические цели. Оценивается бизнес-значимостью.
2. User Stories. На первом месте требования пользователей. Это самые крупные, можно сказать тактические цели в рамках проекта. Оценивается бизнес значимостью и Story Points. Что такое story points? Это сипульки. Условное обозночение трудозатрат, оценивается разработчиками.
3. Tasks. Задачи для разработки. Конкретные задания, которые должен выполнить участник команды. Оценивается в часах. Продолжительность от 1 часа до 1 дня.
4. Personal Sprint (Checklist, TestList). Записи в блокнотике. Каждый разработчик разбивает Task на мелкие шаги. После каждого шага вычёркивает пукнт из List. Для практикующих TDD см. паттерн Test List. Это список тестов, которые нужно написать. Продолжительность от 10-20 минут до одного часа.

Последний пункт может выглядить примерно так. Я хотел сделать "тупой маленький чеклист" для рефакторинга перемещение поля:
1. модифицировать все установки поля (setter)
2. модифицировать всех читателей поля (getter)
3. удалить объявление поля
4. и так далее в таким же простым способом

Можете наконец-то в своём IDE воспользоваться окошком TODO ;)

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

Плюс от таких бумажек следующий - МАТЕРИАЛИЗАЦИЯ. Голова хорошо, но простой список задач проще. Профессиональные медики (см. фильмы зарубежные) ходят с checklist'ом и отмечают галочками выполненные задачи (приём таблеток, процедуры и т.п.). И этому учат их в институте. Так почему такая простая практика отстутствует в арсенале профессионального разработчика? Вы не знаете чем заняться глянули в список и выбрали. Не знаете чем убить минутку до совещания. См. в список.

На закуску пару интересных ссылок не по теме :)
1. Visual Studio Team System 2008 Team Foundation Server Power Tools
http://msdn2.microsoft.com/en-us/tfs2008/bb980963.aspx
2. Год MSDNWiki
http://blogs.msdn.com/sandcastle/archive/2006/09/06/742352.aspx
3. Google.vs.Wiki
http://itblogs.ru/blogs/kav/archive/2007/12/21/24329.aspx

А вы Agile команда?

Ответьте на 4 вопроса Скотта Амблера и вы поймёте Agile-команда вы или нет.
Вопрос 1. Покажите свои Unit-тесты.
Вопрос 2. Познакомьте меня со своим заказчиком
Вопрос 3. Покажите ваш CM (configuration managenet)
Вопрос 4. Покажите вашу самоорганизацию.

Если на все четыре вопроса я увижу в вашей команде ответ, то вы Agile-команда!

Показ мод от Microsoft 2008

ADO.Net Entity Framework beta 3. Решение ORM от Microsoft.

ASP.NET 3.5 Extensions Preview - MVC каркас

Определите национальность

Определите национальность автора кода

//--------
boolean b;

if(b.toString().length() >4){...}
//-------

Dream Team: Первый шаг

Сегодня провели первый старт. Микро-отчёт.

1. Повешана White Board + Status Board
2. Рассмотрены следующие практики:
2.1. Dialy Scrum Meeting
2.2. Атрибутика для DSM: мечь кладенец, банка для добровольных пожертвований.
2.3. Коллективное притяние решение из Базового Протокола.
2.4. Niko-niko календарь.
2.5. User Story в формате "As a user ..." (см. Mike Cohn)
3. Поговорили о целях, целеполагании.

Сложности были в обсуждении п.2.3. Не все решения могут коллективно приниматься. Например, административные. В п.2.1. было сложно договориться во сколько же собираться. Решили договориться на 13 часов. Основной аргумент, чтобы до обеда порешать задачи, которые могут возникнуть после митинга. Сложность в п.2.2. это сама концепция штрафа (банка) была неудобна одному участнику. Согласились действовать по принципу "кто что сможет"; то есть штраф за опоздание на планёрку не строго типизирован: конфетки, деньги и т.п. а гибче "кто что сможет". Niko-niko календарь в основном все поддержали, не поддержавший сказал детские игры. И пришлось признать себя большими детьми :)

Провели ретроспективу на практики и решили заиспользовать в течении следующей недели.
Продолжительность первого шага: 1 неделя.

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

TeamCity 3.0

Похоже команда Jetbrains решила захватить рынок традиционным способом - БЕСПЛАТНО.

Now available for free, TeamCity 3.0, delivers multiple improvements in different areas and extends support for both Java and .NET software development teams. To name just a few: a new licensing policy, per-project roles and permissions, build statistics charts, .NET code duplicates search, VCS integration enhancements, upgraded performance, and a better user experience.

The key new features of this release include:

• Per-project access rights with project roles – an exclusive feature of the Enterprise edition
• Build statistics charts, with declarative pluggable charts for user-defined metrics
• Pre-tested commit from Visual Studio for Subversion
• StarTeam support
• .NET Duplicates finder for catching similar code fragments of your C# and Visual Basic .NET code
• Java Inspections and Duplicates for Maven2 projects
• Version Control labeling for Subversion, CVS, Perforce, StarTeam, ClearCase
• “Hanging” builds auto-detection and thread dump capturing, for quick feedback on Java and .NET builds’ problems
• Display of build start/finish estimations in the build queue
• Build tags for organizing and quickly filtering builds

To learn more about new features in TeamCity 3.0, please visit
www.jetbrains.com/teamcity/features/newfeatures.html?tc30a.

For additional details about the new licensing scheme for Professional, Enterprise and Open Source licenses, see http://www.jetbrains.com/teamcity/buy/?tc30a .

Existing TeamCity users qualify for a free upgrade to the most feature-rich Enterprise edition. For details, go to http://www.jetbrains.com/teamcity/buy/index.html#upgradeuser?tc30a.

Agile Practices

Сегодня причесал вики сайта http://AgileRussia.ru. Основной упор сделал на разделение всего Agile мировозрения на две вещи: 1) практики и 2) методологии.
Соответственно в практиках будет накапливаться информация о всевозможных Agile-практиках, которые планируется собрать со всего интернета. Кстати, подключайтесь, дел много, заодно узнаем много нового.
Во втором разделе классификация этих же практик с точки зрения авторов методологии.

Сам ресурс доступен по адресу: http://agilerussia.ru/wiki/index.php?title=Practices

PS. В середине недели дам доступ :)

Dream Team: Создание новой Agile-команды

Буквально со следующего понедельника стартует подготовка новой Agile-команды. На страницах своего блога я собираюсь поведать как всё будет происходить. Фактически, команда собрана и уже давно успешно работает. А нам остаётся только прийти на готовенькое и внедрить самое-самое.

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

Итак, жду вас на следующей неделе. Буду сообщать с фронта событий.

Мы делаем новости!

Dependency Injection Application Block

Ребята в Microsoft решили обзавестись своей реализацией Spring.Net. Дали ей название Dependency Injection Application Block. Такое творение ожидается в следующей версии Enterprise Library.

Более подробно читайте об этом слухе - здесь

Функциональный стиль C# 3.0 в помощь качекодуру

Качкодер (сокращённо качёк) - человек, которые пишет качественный код.

В блоге Ивана появилась первая статья о функциональном программировании. Вырежу самые приятные слова, за остальным заходите к Ivan'у :)

Polygon triangle =
  new Polygon {
    new Point { X = 3, Y = 5 },
    new Point { X = -5, Y = 4 },
    new Point { X = -1, Y = -6 }};

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


В чем же цимус от использования неизменяемых объектов, вместо обычных переменных? На самом деле мы получаем целый ворох конфет:
- Отсутствие побочных эффектов. Работа любой функции гарантировано зависит только от входных параметров и результатом ее работы являются только выходные параметры.
- Мы можем совершенно безопасно отдавать свой объект наружу во временное пользование, у нас есть 100% гарантия, что его никто не испортит.
- Отладка упрощается в разы. Все с чем будет работать функция лежит в стеке вызова.
- Повышается эффективность тестирования.
- Колоссально упрощаются алгоритмы синхронизации доступа из разных потоков.
- Появляется возможность автоматически распараллеливать выполнение задач.
- Существенно упрощаются алгоритмы хэширования и выявления эквивалентности.
- Реализация Undo/Redo, причем не только структур данных, но и хода выполнения программы становится тривиальной.
- Появляется возможность заменять произвольные функции не останавливая всей программы. (Реально существуют приложения на Erlang-е, работающие годами без остановки, код которых был заменен целиком)
- ... и много других приятных плюшек.

Джимми Нильссон. Применение DDD и шаблонов проектировани - пример некачественного перевода.

Буквально два дня назад купил долгожданную книгу Нильссона в переводе издательства Вильямс. Тема книги и автор очень уважаемые люди :). Но вот перевод не вышел.

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

"Кроме опечаток есть и просто неправильный перевод профессиональных терминов, что несколько раз меня уже вводило в ступор"

А теперь мой собственный комментарий. Зелёную полосу называют провалившимся тестом. TestFixture — обозвали тестовой конфигурацией на схеме. Mock объект имитацией. А самовольная замена DDD на ППО, а TDD на РПТ — бесчинство и яркое неуважение к читателю.

Пару ярких цитат: "Тест компилируется, но даёт положительный результат (красную полосу)" (стр.464) в оригинале "It compiles, but it turns red.". А от этого плакать хочется: "Теперь тест даёт наконец-то отрицательный результат (зелёную полосу)!" (страница 467 внизу)

Вывод: НЕ ПОКУПАЙТЕ!!! ЧИТАЙТЕ ОРИГИНАЛ!!!