Записки около IT

DVCS Распределенные системы контроля версий

2012-02-18T19:48:00.000+04:00

В рамках встреч белгородского сообщества «ИТ завтрак» в Пыж кафе прочитал доклад по распределенным системам контроля версий.
Пришло семь человек, в следующий раз будем активнее проводить агитационные работы. Это уже второе по счету выступление, первым был Максим Гладких с темой «Микроформаты – зачем?». Следите за анонсами будущих встреч в группе на facebook.
Презентация и план выступления.

DVCS Distributed Version Control Systems
1. Обзор

Что такое DVCS
Преимущества
Ветвление/Слияние
Недостатки
Hg vs. Git

2. DVCS за 5 минут

Центральный репозиторий
Гибкий рабочий процесс
Развертывание
Иерархия доверия

3. Преимущества

Работаем offline
У каждого своя полная копия
Это быстро!
Ветвления/слияния

4. Слияние в SVN
5. Слияние в DVCS
6. Недостатки

Потеря простоты модели
Более, чем один путь сделать одно и тоже
Нельзя взять часть репозитория
Надо читать доки :)

7. Mercurial vs. Git: Who the FUCK cares? Use what YOU like
8. Спасибо! Вопросы?

После похожего обсуждения DVCS в нашей компании, немного улучшил презентацию, добавил пару фото слайдов и ярких образов из презентации «DVCS – будущее сегодня» (автор Сергей Калинец). Все-таки удачные фото воспринимаются аудиторией гораздо лучше, чем текст.
Ребята были весьма удивлены тому факту, что у нас в компании нет единого стандарта, а используемые инструменты выбирает руководитель проекта.
Что вынес для себя: есть над чем работать – во время выступления не смотреть по сторонам, стараться наладить зрительный контакт с аудиторией. Буду продолжать оттачивать навыки публичных выступлений. Добавил «Камасутру для оратора» в список на прочтение.

Пару ссылок на тему:

Итоги 2011 года

2011-12-29T09:40:00.000+04:00

Немного истории… 30 декабря 2010, последний рабочий день уходящего года. На ватмане А1 я рисую календарь с планами на год по заданию клуба ИТ-менеджеров «Стратоплан». А там уже налито.. :)

Пост содержит информацию личного характера и обильное выражение эмоций.

Сегодня 29 декабря 2011г., новостные порталы встречают нас темами «5, 7, 10(?) будущих трендов, лучших приложений, ожидаемых гаджетов», самое время подвести итоги 2011 года:

Принял участие в четырех проектах:

• Электронная очередь «Нотариус», руководитель проекта/разработчик. Теперь у меня есть знакомый нотариус.

• Информационная система Единый Регистр Застрахованных г. Санкт-Петербург, «old school edition = Oracle + stored procs + JBoss AppServer », разработчик.

• Типовая ИС ЕРЗ, «new wave edition = MS SQL Server + NHibernate + WCF Services», разработчик. Распределенные системы контроля версий git, разработка через тестирование TDD.

• Электронная очередь «МОТОТРЭР», руководитель проекта/разработчик. Каждый новый год мы с друзьями собираемся и внедряем электронную очередь.

Провел 2 месяца в командировке в Питере. Питер волшебный, наверное, в России больше нет таких красивых городов. Люблю командировки :)

Провел зимний отпуск в Карпатах. Съехал на сноуборде с черной трассы Буковеля.

Был свидетелем на свадьбе четы Кришталь. Моя любимая пара!

Провел летний отпуск в Гурзуфе. Свадебное путешествие с Кришталями.

Преодолел детский страх и узнал, как это - получать удовольствие от танца с девушкой. :)) Спасибо партнерше Танюше и тренеру Димке.

Влюбился и опять расстался. Надежды не теряю.

Прочитал/прослушал книги/аудиокниги:

Приемы объектно-ориентированного проектирования. Паттерны проектирования.
Глеб Архангельский. Формулы времени. Тайм менеджмент на Outlook 007-2010.
Мартин Фаулер. Шаблоны корпоративных приложений.
Роберт Гласс. Факты и заблуждения профессионального программиста.
Том Демарко, Тимоти Листер. Балдеющие от адреналина и зомбированные шаблонами. Паттерны поведения проектных команд.
Стивен Р. Кови. Семь навыков высокоэффективных людей.
Джоэл о программировании.
Джоэл и снова о программировании.
Кент Бек, Мартин Фаулер. Экстремальное программирование. Постановка процесса.
Roy Osherove. The Art of Unit Testing With Examples
Кент Бек, Мартин Фаулер. Экстремальное программирование. Планирование.
Эрик Синк. Бизнес для программистов.
Этюды на тему быстрой разработки программного обеспечения.
RTFM. Книга про ИТ-аутсорсинг. Как создать сервисную ИТ-компанию.
Rework. Бизнес без предрассудков.
Стас Давыдов. Не мешайте мне работать.
Слава Панкратов. Черная книга менеджера.
Эрик Эванс. Предметно-ориентированное проектирование. Структуризация сложных программных систем.
Глеб Архангельский. Тайм-драйв.
Бодо Шеффер. Искусство управлять своим временем.
Джек Уэлч. Победитель.
Ицхак Адизес. Идеальный руководитель.
Ларри Кинг. Как разговаривать с кем угодно, когда угодно и где угодно.

Посетил две конференции UNETA+ и NetWork в Харькове.

Завел блог. В подарок на НГ купил себе доменное имя и отпраздновал 1к посещений.

Завершил обучение в первом клубе IT-менеджеров Стратоплан. Перед началом обучения в клубе ставилась амбициозная цель «в IT-менеджеры за 1 год». Менеджером я, увы, не стал, получил наставление от тренеров «вам надо уезжать из города/переходить в другую компанию». Решил остаться в Белгороде, скорее по личным причинам. Тем не менее, участие в клубе дало огромнейший толчок в собственном развитии. Если бы не клуб, уверен, что многого из перечисленного здесь в моей жизни не произошло. Кому надо, могу помочь со скидкой.

Решил, что мне интересно в данный момент. Общаться с людьми, управлять проектами и командами, развиваться и измерять эффективность, осваивать новые практики и навыки, мотивировать и организовывать людей.

Взял ипотечный кредит. Теперь ~~сижу на хлебе и воде~~ экономлю, почти как в чудесные студенческие годы.

Классный был год, приятно вспомнить. Пост написал на одном дыхании, потом, правда, еще долго ошибки исправлял.

А чем вам запомнился уходящий год? Подведение итогов, кстати, залог успешного тайм-менеджмента. Буду очень рад вашим комментариям.

Ураа, ураа, улююлюю, парней уважаю, девчонок люблю!! :)) Всех с Новым Годом!!

Экстремальное программирование XP: планирование

2011-12-25T15:56:00.001+04:00

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

План должен отражать реальный ход проекта

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

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

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

Цели и задачи планирования

Решить, стоит ли сейчас заниматься именно этой задачей.
Координировать деятельность команды и других людей.
Оценивать последствия возможных неожиданностей.
Расставить задачи по приоритетам.

Права заказчика

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

Права разработчика

Знать, что делать и каков приоритет задачи.
Производить качественный программный продукт.
Самостоятельно оценивать объем трудозатрат по задачам, а потом вносить изменения в оценки.
Самостоятельно взять на себя ответственность за решение задачи.

Обязанности заказчика

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

Обязанности разработчиков

Определять трудозатраты по задачам
Предупреждать о технических рисках
Вычислять объем проделанной работы для оценки общего бюджета проекта.

Функциональные требования к системе оформляются в виде пожеланий.

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

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

Суть XP - поставить клиентам тот продукт, который в каждой своей версии отвечал бы требованиям и пожеланиям клиента. Им не нужна система, в которой реализованы неправильно истолкованные в начале проекта требования.

Планирование итерации

Выбрать и детализировать пожелания заказчика на итерацию.
Разбить каждое пожелание на конкретные задачи.
Добавить необходимые технические задачи.
Оценка разработчиками времени выполнения задач согласно своей скорости работы. Каждая задача не должна занимать более одного-трех дней работы.

Существует только два рычага для манипулирования: время и объем работ, качество системы должно оставаться неизменно высоким. Исправление ошибок в программе нужно планировать одновременно с планированием итерации. Клиент решит, что ему важнее - исправить ошибки или получить новую функциональность. Планирование должно показать, как отображается на сроках поставки системы всякое добавление в систему новых функциональных свойств.

Оценка хода работ

Пару раз в неделю наблюдатель проверяет, что происходит в ходе текущей итерации. Никаких совещаний - просто беседует с каждым разработчиком. Задает два вопроса относительно тех задач, которые взял разработчик во время планирования итерации:

Сколько идеальных дней ты уже потратил на эту задачу?
Сколько идеальных дней тебе понадобится, чтобы ее закончить?

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

Никогда не сдвигайте сроки!

Пропуск сроков поставки - потеря контроля над проектом.

Работа в каждой итерации при этом протекает с некоторой долей неуверенности в конечном результате. Нельзя терять возможность ясно понять, на какой стадии находится проект.

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

Сроки выпуска версии системы всегда устанавливаются исходя из коммерческих интересов.

Подробнее в книге Экстремальное программирование: планирование (Planning Extreme Programming) Кента Бека и Мартина Фаулера.

IT[Village]: Управление IT командами в компании HeadHunter

2011-11-25T11:06:00.001+04:00

Вчера в офисе gidBelgorod прошла Skype-конференция IT[Village] с президентом Юрием Вировцом и техническим директором Сергеем Никулиным компании HeadHunter.

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

Разговор начался с истории становления и развития компании. Коллеги рассказали, как родился и вырос отдел разработки HeadHunter: с трех разработчиков, способных выполнить любую задачу до нескольких распределенных команд в Москве и Минске.

Работа в HH выполняется автономными продуктовыми командами, работающими по Scrum. Во главе каждой команды стоит классический PM – связующее звено между разработчиками и заказчиками (не IT отделы HH).

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

По каждому функциональному направлению (разработка серверной части, верстка, тестирование) выделены лидеры, определяющие единые для всех команд стандарты разработки и используемые инструменты.

Официально введены и используются при общении с заказчиками понятия технического долга и технического налога. Задачи рефакторинга, оптимизации, исправления компромиссных решений непосредственно включается в беклог. Четко установлено ограничение: долги не должны увеличиваться более чем на 30% в месяц.

После этого обсуждение перешло к используемой в HeadHunter системе мотивации сотрудников.

Размер вознаграждения получаемого сотрудниками состоит из оклада(ставки) и бонусного фонда (премии) по умолчанию в равных размерах. Размер оклада фиксирован, размер бонуса может меняться.

30% премии сотрудники получают за выполнение бюрократических ограничений, например таких как (!!!) все 8 рабочих часов должны быть расписаны по задачам в тайм-трекере JIRA - оценки затраченного времени используются при планировании задач.

Устанавливается оценки за техническую дисциплину: проверка кода на соответствие введенным стандартам качества. Оценка определяет коэффициент от -50% до + 20% для оставшихся 70 % премии.

Оценка проводится каждый месяц, работа команды оценивается в целом . Бонусный фонд делится между командой пропорционально размерам ЗП. По результатам работы команды заказчик может внести необходимые коррективы.

Ответы на некоторые вопросы слушателей:

- Занимается ли HH инвестированием стартапов?

- HH заинтересован в перспективных проектах, но только в области основной компетенции компании - подбора и найма персонала. Например, не так давно HH инвестировал в стартап ITMOZG.

- В чем успех HH?

- Успех – угаданная потребность рынка, огромные инвестиции в offline рекламу и создание бренда. Проведена огромная работа над тем, чтобы, как только человек захотел сменить работу – он сразу же подумал про HeadHunter. HH уже в головах людей, а технологии легко скопировать.

- Идеи и перспективные области с вашей точки зрения?

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

В завершении подчеркну важность проведения подобных встреч разработчиков и

IT специалистов, очень хочется создать в Белгороде сообщество активных людей.

Таких, как Фёдор, например.

Марине салютую, выражаю благодарности, шлю приветы, все дела!

Так держать, всячески продолжать, сиять улыбкой и собирать нас всех вместе!!

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

А то в следующий раз придется запирать двери! :)

Следующую встречу организаторы обещают в январе.

Smart UI VS. Layered Architecture

2011-10-17T21:22:00.000+04:00

Случается так, что бизнес-логика предметной области часто реализуется прямо в элементах интерфейса пользователя и сценариях баз данных. Кроме того, код для реализации интерфейса пользователя, обращений к базе данных и других технических задач нередко вписывается напрямую в объекты предметной области.

В литературе встречаются определения подобного подхода:

Интеллектуальный интерфейс пользователя (Smart UI) в «Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем» Эрика Эванса
Сценарий транзакции (Transaction Script) в «Шаблоны корпоративных приложений» (Patterns of Enterprise Application Architecture) Мартина Фаулера

Проще говоря, если у вас «скрипты в формочках» - это оно и есть. :)

Когда код, относящийся к операциям предметной области, размазан по огромным объемам другого кода, его становится очень трудно разыскивать и анализировать. Поверхностные изменения в интерфейсе пользователя могут случайно затронуть операции алгоритмической части. Чтобы изменить какие-либо правила бизнес-логики, потребуется тщательная трассировка кода интерфейса, обращений к базе данных и других элементов программы. Автоматизированное тестирование становится фактически невозможным.

К сожалению, нужно признать, что данный подход имеет определенные преимущества.

Преимущества:

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

Недостатки:

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

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

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

Написано под впечатлением от просмотра исходного кода коллег, чтения великолепной книги Эрика Эванса, DDD (big blue book) и посещения самой крутой .NET конференции этой осени – NETWork, о ней в следующий раз.

Отчет о конференции Uneta+, Харьков 1 октября 2011г.

2011-10-05T22:56:00.000+04:00

1 октября 2011г. я и мои коллеги посетили Харьковскую конференцию .NET разработчиков Uneta+.

В метро доблестная украинская милиция (полиция?) решила проверить нас на наличие наркотических веществ, поэтому на начало мы немного опоздали. :)

Прошли регистрацию, попали в зал, где Дмитрий Никонов и Сергей Байдачный уже во всю обсуждали нововведения Microsoft Team Foundation Server 2011 и Visual Studio 2011:

обновленный web интерфейс TFS2011
обновленное окно Team Explorer
встроенные средства Code Review
новый test-runner , который будет поддерживать сторонние unit-test фреймворки
анализатор дублирующихся участков кода

TFS традиционно обещает полную интеграцию средств разработчика, а поддержка Code Review является фичей, заслуживающей внимания.

Coffee break

Далее выступал Владимир Юнев с докладом «ASP.NET MVC 4 Как светлое будущее веб-разработки». Рассказал об истории развития фреймворка и поддержке последних трендов web-разработки в MVC: мобильные платформы, HTML5, интеграция с VSTS2011, EF и т.д.

Дальнейший выбор пал на доклад Дмитрия Костылева «Оптимизация запросов в SQL Server». В первой части Дмитрий изложил основы работы оптимизатора запросов, анализа плана выполнения, во второй части привел примеры оптимизации и раскрыл техники написания быстрых запросов. Многие участники отметили, что это был наиболее полезный доклад конференции. Презентация и запись выступления Дмитрия доступны на TechDays.

Затем в первой секции выступал Diego Vega, Project Manager в команде разработки Entity Framework с докладами «Future of Entity Framework» и «Deep Dive on Entity Framework».

В следующей версии EF нас ждут Data Migrations, будет сделан дальнейший упор на разработку в стиле Code First, поддержка типов Enum и многое другое. Проголосовать за любимую фичу можно на портале. Доклад «Deep Dive on Entity Framework» оказался не таким уж глубоким и страшным. :) Практическое применение EF при реализации различных типов наследования (Table per Hierarchy, Table per Type, Table per Concrete Type), лучшие практики использования паттерна Repository:

Best Practices:

Make the repository’s interface as simple as possible
Create separate repositories for each “aggregate”
Keep other layers “persistence ignorant”
Multiple repositories can share same ObjectContext as “unit of work”

Popular additions:

Query methods return IQueryable<T>
Using “specification pattern”, e.g. repository.Find(c=>c.Id == id)
Repository<T> base class

В одном слайде Диего рассказал, как достичь высокого покрытия репозиториев тестами:

Best practices:

Build simple repository interface
Swap repository with in-memory test double
Alternate route: define simple interface for context
Still run tests against database often

Things to avoid:

Don’t try to mock the data access framework!

Последним выступал Вагиф Абилов «Теория и практика сервисов OData».

Главный посыл: создание полноценного RESTful сервиса на базе OData – это просто. Хотите создать сервис OData - смотрите исходники на GitHub. Вагиф – отличный докладчик, было очень приятно слушать. А гимн OData – превосходное завершение всей конференции.

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

Благодарю организаторов конференции Владимира Лещинского, Дениса Резника, Бауман Эвелину. Давно слежу за встречами группы Uneta (к сожалению, они проходят только по будням), наконец то получилось принять участие во встрече сообщества. Очень этому рад :)

До встречи на конференции NetWork 15-го октября.

Read the Diffs – Сравни изменения

2011-08-11T22:28:00.000+04:00

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

Используйте ваш любимый diff-tool, чтобы узнать обо всех изменениях в проекте, сделанных каждым участником команды за прошедший день.

Ежедневное сравнение изменений имеет три явных преимущества:

Код может быть улучшен.

Вы можете обнаружить проблемные места и ошибки еще до того, как сборка будет передана в тестирование. Чем раньше обнаружена ошибка, тем дешевле стоимость ее исправления. При этом сам процесс проведения инспекций обходится дешевле, чем тестирование, необходимое для обнаружения этих же ошибок.

Вы можете изучить что-то новое для себя.

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

Вы можете поделиться опытом с командой.

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

У лучших разработчиков это простое правило входит в привычку.

Р. Гласс, Факты и заблуждения профессионального программирования, Факт №37:

«Тщательные инспекции исходного кода - метод, в соответствии с которым весь программный код подвергается рассмотрению с целью обнаружения любых содержащихся в нем ошибок. Исследования, проводимые одно за другим, показали, что инспекции позволяют обнаружить до 90% ошибок в программном продукте до того, как будут запущены какие-либо эталонные тесты. А это показатель чрезвычайной эффективности процесса.»

Большинство систем контроля версий имеют встроенные утилиты просмотра изменений. Сервер непрерывной интеграции TeamCity позволяет осуществлять инспекции с привязкой не только к коммитам, но и к ежедневным сборкам проекта. Отлично работает с SVN и Git и имеет приятный интерфейс просмотра исходного кода с подсветкой изменений.

Из win-приложений для сравнения двух версий файлов мне больше всего нравится WinMerge. Если ваши инструменты не позволяют вам быстро и просто смотреть проведенные изменения - выбросьте их на помойку!

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

StyleCop + MSBuild: Принудительное соблюдение стандартов кодирования

2011-08-04T12:13:00.000+04:00

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

Стандарты кодирования нужны по двум причинам:

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

За основу стандарта кодирования для команды можно взять готовые примеры (например, в нашей организации были использованы соглашения по оформлению кода команды RSDN).

Но как показывает практика, подобные документы носят рекомендательный характер, к тому же в конкретных ситуациях среди разработчиков сразу рождаются споры (о наименовании переменных и методов, использования различных префиксов "m_", "_" и т.д.).

Принудительная проверка (например, в качестве одного из этапов сборки на build-сервере) — единственный гарант соблюдения стандартов. Тут-то такие инструменты как StyleCop и показывают себя во всей красе.

StyleCop анализирует исходные коды проекта, контролирует стиль и форматирование кода, вынуждая разработчиков соответствовать правилам и принятым стандартам. Предлагаемый StyleCop стиль используется некоторыми командами Microsoft. Проверка может быть запущена непосредственно из Visual Studio или выполняться при сборке проекта (интегрирована с MSBuild).

Правила StyleCop включают требования к расположению скобок, наименованию полей, методов и классов, написанию комментариев, отсутствию ненужных пробелов и многие другие.

Подробнее о правилах StyleCop написано в статье.

Интеграция StyleCop с MSBuild позволяет осуществлять проверку при каждой сборке проекта. Для этого в csproj-файл проекта необходимо добавить соответствующий тег:

 <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">  
 ...Contents Removed...  
 <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />  
 <Import Project="$(ProgramFiles)\MSBuild\StyleCop\v4.x\StyleCop.targets" />  
 ...Contents Removed...  
 </Project>

В статье рассматривается интеграция StyleCop c SVN, но все перечисленные достоинства справедливы для любого варианта автоматизированной проверки (в том числе интеграции с MSBuild):

Категоричность требования качества кода и соблюдение принятых стандартов
Отсутствие отвлекающих споров на тему «как правильно расставить скобки» между разработчиками и концентрация на рабочих задачах
Разгрузка старших программистов (нет необходимости объяснять младшим, как правильно оформлять код)

Совместное использование в паре с сервером непрерывной интеграции (мы используем TeamCity) позволяет достичь максимальных результатов.

Конечно, попытки натравить StyleCop на существующий проект обернутся двухдневным исправлением тысячи стилистических ошибок, но большинство из них Resharper может исправить автоматически (плагин для интеграции с Resharper вошел в официальную сборку StyleCop, начиная с версии 4.5 RTW).

А к использованию в новых проектах StyleCop настоятельно рекомендуется.

StyleCop

http://stylecop.codeplex.com/

Были использованы материалы из статей:

http://habrahabr.ru/blogs/net/111847/

http://msug.vn.ua/Posts/Details/4185

http://habrahabr.ru/blogs/programming/111463/

http://msug.vn.ua/Posts/Details/4164

Отзывы на прочитанные книги

2011-07-28T20:56:00.000+04:00

Давно уже заторчал нашей замечательной корпоративной библиотекарше :) целую пачку добрых книжек, исправляюсь, пишу отзывы.

Стивен Р. Кови. «7 навыков высокоэффективных людей»

Мировой бестселлер, самая лучшая в мире книга по личностному развитию.

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

Прочитал, пожалел, что мама не вручила мне эту книгу лет так в 15, глядишь, умный бы парень вырос. :)

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

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

Джоэл Спольски

«Джоэл о программировании»

«Джоэл и снова о программировании»

Как? Вы не читали Джоэла - Джоэла читали все! Вот и я наконец прочитал.

Джоэл со своими статьями на любые темы невероятно хорош.

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

Кен Ауэр, Рой Миллер

«Экстремальное программирование. Постановка процесса с первых шагов и до победного конца»

Книга из серии «Подарки от руководства» (никто из разработчиков не заказывал :) ). Приятно, если наше руководство заинтересовалось современными методологиями разработки ПО, но даже если нет, книге был очень рад - из тех методологий, о которых я имею представление, XP мне наиболее близка. Авторы позиционируют книгу как продолжение «Extreme Programming Explained»(« Экстремальное программирование») Кента Бека. Основной посыл - «если вы не нашли крутого консультанта XP, станьте им, и несите свет в массы». Большое количество жизненных ситуаций, эссе «вот так мы пилили XP» , масса советов как продавать XP руководству и разработчикам. За ваш мозг не переживайте, евангелистом XP становится не планирую, но…

«XP – реально крутецкая вещь, в которой наиболее полезные практики возведены в абсолют» . :)