Всем известно, что для качественного ПО покрытие должно быть более 70%. Я не знаю, кто это придумал и причем тут качество, но мне не понятно какая польза от этой цифры. Ещё смешнее слышать, как менеджеры привязывают покрытие к качеству. Если рассуждать в плоскости менеджеров, что и на мелководье и рак рыба, то этого качества конечно же для успокоения самолюбия менеджера достаточно. Но истинные войны света должны понимать, что на этом качество не останавливается... Качество кода - это целая культура разработки, в которую вовлечены клиенты, разработчики, тестировщики и много других людей. Но об этом я уже писал неоднократно, а сегодня остановлюсь на новом подходе. Подходе дающим ещё один мощный инструмент разработчику (ни менеджеру, ни тестировщику) для написания качественного кода.
Я же хочу раскрыть другую замечательную вещь, которая повысит качество кода во много раз. Один нюанс - вам придётся делать 100% покрытие :)
Эту идея пришла во время парного программирования с Кириллом Медведевым в рамках одной из стади-групп.
Эту разработку я называл "100% Coverage Driven Design" (или сокращённо CDD). Суть этого подхода есть сложение TDD, общего подхода написания тестов (ключевая фраза здесь - TestLast) и инструмента покрытия кодом.
Напомню цикл TDD:
1. Пишем тест (формализуем ожидания от будущего кода)
2. Реализуем код
3. Рефакторим
В "100% Coverage Driven Design" цикл такой:
1. Тест
2. Код
3. Рефакторим
4. Добиваемся 100% покрытия
Какие бонусы даёт такой подход
1. Все бонусы TDD
2. Вы всегда контролируете, что ваш код используется и нету лишнего, мертвого, того кода, который будет тухнуть из-за дня в день. Покрытие будет следить, как только что-то лишнее появляется и не используется - сразу выкидываем.
Возникает вопрос. А что делать с тестами, которые устаревают. Ведь их с помощью покрытия нельзя выявить, а тем более сказать что код, который покрывается устаревшими тестами уже начинает потухать. А решение простое - смирение. Если тест устарел, то первым делом он начинает из зеленого превращаться в красное. И вы тут же решаете, что с ним делать. В красное он может превратиться по множеству причин. Но если одна из причин - устаревший и ненужный тест. Мы его удаляем. Запускаем Code Сoverage и проверяем, где произошли смещения от точки 100% покрытия.
Покажу на маленьком примере. С помощью TDD цикла создали библиотечку. Проверили её покрытие и выяснилось не 100%. Начинаем разбираться и видим, что появился тухлый код. Сначала комментирую тухляк, а потом лопатой все убираю.
Успешно справившись с продуктами собственной жизнедеятельности (удалив тухлятину), я сталкиваюсь с автогенерённым тухляком:
Мне приходиться напрячь мозги и понять, что components объект никогда и не используется! Такое открытие позволяет мне удалить столь запутанную тухлятину тоже.
Результат не заставляет ждать. Идеально чистый код! Я с уверенностью продолжаю дальнейшую разработку.
Теперь немного GUI-шного, про разработку через TestLast и как техника рефакторинга приводит ухудшению Code Coverage.
1. Конечно же, когда добавляется новый функционал, то используем TestFirst:
public void MainForm()
{
SetUpClass.PrepareTestFile();
var form = new MainForm();
var mocks = new MockRepository();
var dialog = (OpenFileDialog)mocks.CreateMock(typeof(OpenFileDialog));
Expect.Call(dialog.FileName).Return("filename.ew");
Expect.Call(dialog.ShowDialog()).Return(DialogResult.OK);
mocks.ReplayAll();
form.openFileDialog = dialog;
form.MenuItem_Open(null, null);
mocks.VerifyAll();
Assert.AreEqual(2, form.dicGridControl.Count);
}
2. Реализуем функцию
public void MenuItem_Open(object sender, EventArgs e)
{
if (openFileDialog.ShowDialog() == DialogResult.OK)
{
Dic dic = new Dic();
dic.Load(openFileDialog.FileName);
dicGridControl.Bind(dic.ToList());
}
}
Покрытие: 100%
3. Проводим рефакторинг Replace Nested Conditional with Guard Clauses (кстати, мой самый любимый)
public void MenuItem_Open(object sender, EventArgs e)
{
if (openFileDialog.ShowDialog() != DialogResult.OK)
return;
Dic dic = new Dic();
dic.Load(openFileDialog.FileName);
dicGridControl.Bind(dic.ToList());
}
Покрытие: 97%.
Проведение рефакторинга привело к снижению покрытия. Мы столкнулись с усложнением кода с точки зрения поддержки покрытия. Но в тоже время облегчили с точки зрения понимания, сделав линейность выполнения основного блока. То есть основной блок в первом примере разбился на два: проверка условия выполнения и основной код.
В общем снизили покрытие. Что делать. Я останусь верным принципам рефакторинга и оставлю проверку входного условия. Но я должен дотянуть покрытие до 100%. Тут на помощь приходит старая практика Test Last. Если раньше, эта техника была вызвана сообращениями разработки тестов для уже разработанного кода, сейчас эта техника изменит своё предназначение. Используя эту технику я подтяну покрытие до 100%.
После мелких рефакторингов я добавил второй тест, используя технику TestLast:
[Test]
public void MainFormCancel()
{
Expect.Call(dialog.ShowDialog()).Return(DialogResult.Cancel);
mocks.ReplayAll();
form.MenuItem_Open(null, null);
mocks.VerifyAll();
Assert.AreEqual(0, form.dicGridControl.Count);
}
Результат: покрытие 100%
В данном случае проведение рефакторинга не очень оправдано - так как и с ним и без него код выглядит очень простым и его можно сразу понять. Я преследовал цель показать , как рефакторинг может привести к снижению покрытия кода, даже если он прошёл без изменения функциональности.
Другой нюанс, если я пойду дальше и подстрахуюсь от проблем с файловой системой:
public void MenuItem_Open(object sender, EventArgs e)
{
if (openFileDialog.ShowDialog() != DialogResult.OK)
return;
try
{
Dic dic = new Dic();
dic.Load(openFileDialog.FileName);
dicGridControl.Bind(dic.ToList());
}
catch (Exception ex)
{
MessageBox.Show("Error: Could not read file from disk. Original error: " + ex.Message);
}
}
Этот кусочек кода пишется даже без теста легко. Я нарушил правило TDD и добавил строчку кода без теста. И кара настигла меня моментально - покрытие упало, плюс протестировать статический метод MessageBox.Show - это целая проблема (ни моки, ни что либо другое здесь не поможет - в морг). А представьте сколько проблем мы делаем, когда разрабатываем более менее серьезное приложение?
Что хотелось бы иметь в инструментах покрытия:
1. Механизм разметки - какие функции все же не стоит покрывать. Например, автогенерацию или какие-то ничего незначащие хитрые кейсы.
2. Историю покрытия, чтобы наблюдать диффы. Это понадобилось бы для работы над легаси-системами. В таких системах, если мы начинаем разрабатывать по TDD большая часть кода будем мешать нашему анализу. А анализ диффов позволил бы использовать этот подход даже там.
Вывод: Данную методику изобрёл буквально вчера. За вчера её опробовал, очумел от эффективности и продолжаю праведно работать по ней. Методика 100% покрытия стала для меня точно так же как запускать юнит тесты. Стала родной и без неё уже свет не мил. Теперь не то чтобы у меня тесты есть согласно TDD, но и код очищается от мертвого кода очень удобно и легко. Теперь я не только уверен в функционировании (этому мне помогает TDD), но и что код чистый (этому помогает 100% покрытие). В общем я доволен как маленький ребёнок от такой простои и в тоже время мощной игрушки. Сейчас нарабатываю опыт от применения, о чем буду делиться и буду ждать последователей, кто готов проверить предложенный метод.
суббота, 16 мая 2009 г.
100% Coverage Driven Design (CDD) - борьба с тухлым кодом
четверг, 30 апреля 2009 г.
Скобочки для if в одну строчку
(DRAFT)
Здесь расскажу про такое заблуждение как обрамление фигурными скобочками оператор if с одним простым действием.
if(condition)
{
return 0;
}
вместо
if(condition)
return 0;
Мифическая причина идущая от Стива Макконнела (Code Complete). К ней все обращаются, когда начинают мне её называть. Такое ощущение, что это единственная книга, которую горячие стороники скобочек читали :) Кстати, советую тогда заглянуть на http://agileconsulting.ru/wiki/Books - тут множество книг о качестве кода.
1. Защита от дурака, что кто-то в будущем добавит строчку и сделает баг в программе.
А теперь демистификация скобок. Итак, почему скобки это пережиток:
1. Отступы явно указывают на логический блок из одной строки.
2. Отступы проставляются автоматически средой разработки.
3. Тесты не дадут написать код неправильно. У вас нету тестов? Тогда улучшать качество кода начали не от туда :)
4. Скобки кушают 2 линии
5. Мы бизнес-разработчики, и должны свести к минимум все инженерные ухищрения. Ведь в любом языке фраза: "если наступит утро, то я проснусь" не содержит скобок.
А теперь мой аргумент за скобочки:
1. Визуально видно разделение условия от действия. Строка между условием и действием способствует отличию. Но минус в том, что такая конструкция нагружает, когда идёт проверка входных параметров. В таком случаем мне нужно локаничное полотно проверок, а не скобочки :) Поэтому вначале функции проверки без скобочек очень удобны, а вот чуть глубже в тело функции - нужно подумать.
Если вы используете современную IDE и TDD и утверждаете, что скобки полезны по названой мифической причине - просьба дайте конкретный пример. Иначе рассуждаем о коне в ваккууме.
среда, 29 апреля 2009 г.
вторник, 21 апреля 2009 г.
Строки-ресурсы или магические строки (draft)
В продолжение предыдущего поста возникли логичные вопросы. А что делать с
String.Format(StringResourse.TotalString, total)? Кстати, вам легко понять это? А я ещё не начал перечислять минусы :)
Итак, начну с переносом строк в ресурсы. Начнём сначала. Какой смысл был у строки? Если смысл кокатация строчек. То первичный вопрос - накой козе баян? Зачем делать форматирование строке "Всего: " + total + " штук"? А потом повышаем косвенность, закидывая строку "Всего: {0} штук" в ресурсы?
В отличии от string, StringBuilder, String.Format назначение ресурсов в предоставление вариационности. Вариационности в способе отображения, а для строк это либо другой язык, либо другая система отображения значений (пример: дата, дроби и т.п.). Вы часто имеете дело с мультикультурными приложениями? :) Да и там чуток по другому делают. Причем не на стадии программирования, а это свойство относится к всем процессу разработки. Другой нюанс - некоторое множество сообщений, которое на каждом углу программы используется. Некое постоянное магическое множество. Типа "Всего: {0} руб.". Тут ещё можно подумать. Но вредно. Для этого есть специальные классы. Которые должны сразу выплёвывать такие строчки и мы не должны волноваться как это получилось.
Другой сногсшибательный аргумент - если у вас есть технический редактор, и ему удобно работать с одним списком сообщений. Представляю я работу этого редактора. Вместо того, чтобы заранее написать текст, который он ожидает. Или с программистом договориться во время непосредственного написания кода. Он будет открывать файл ресурсов и не соображая, что за туча сообщений, править. Полностью оторвав от контекста применения. Кто нибудь так делает? Ух ты! Ну и как часто так делаете? Чаще чем пишете код? :)
А теперь какие бонусы мы получаем от такой системы (не для варианта мультикультурной платформы, а для нашей простой разработки)
Бонус 1. Попробуйте посчитать количество ваших действий, чтобы внести изменение в вашу строчку. Ужас на крыльях ночи. И это только ради того, чтобы внести маленькое исправление в строчку. Боюсь если вы уделяете столько внимания строчкам, то время на полезный код у вас не остаётся вообще :) Мне намного легче править то, что я вижу непосредственно.
Бонус 2. Даже если не менять. Чтобы читатель мог понял, что тут написано и что ожидается, вам прийдётся скакать как минимум по двум файлам. Кстати, поиск таких вещей и мест их потребления - это другая тема. А разговор идёт не об одной сущности, а просто об одной строчке кода. Да к тому же ещё среди кучи строчек вам нужно ещё вашу. Упасть не встать.
Бонус 3. Я молчу, насколько это эффективно программируется по сравнению с простой строчкой кода :)
Бонус 4. Нарушение ценностей и принципов Implementation Patterns и Simple Design.
Бонус 5. Программирование ради неопределенного будущего. Какой то технический
Задайте себе вопрос - что вы чаще меняете: кучу сообщений без привязки к месту использования или конкретное сообщение в конкретном коде. И из этого делайте вывод. Если вы днями программируете текст в ресурсном файле. То ресурс это ваше все. А если вы пишите код программы и добавляете в него сообщения - то вывод очевиден. Что данные (а строка это данные) должны быть в непосредственной близости от места потребления.
Следующий вопрос - Magic String. Звучит очень странно. Но давайте вернёмся к аналогии. У нас есть Magic Number. Пример: 12. Конечно, любой скажет, что нужно напрячься, причем очень сильно, чтобы найти СМЫСЛ этого. Поэтому СМЫСЛ мы заключаем в название переменной int interest = 12. Ещё раз подчеркиваю, чтобы не искать смысл числу 12 по крупицам в коде окружающем это значение мы вводим переменную, в название которой перенесли смысл числа. В нашем примере 12 означает interest (процент). Теперь взглянем на наши Magic String:
string errorMessage = "Произошла ошибка. Повторите операцию";
Вот скажите, а чего вам не понятно в исходном сообщение? Смысл? Там же по-русски написано :) Я понимаю, что фраза "@#$#@$^%$" может запутать и нужно ввести поясняющую переменную. Но в примере то чего сложного?
Теперь пошли нюансы Magic String:
Бонус 1. Переменная, у которой область видимости максимум круглые скобочки в качестве параметра вызова в MessageBox, почему то становиться видна всей нашей функции. Как будто без этого мало строчек кода.
Бонус 2. При чтение кода нам нужно прыгать сначала к тексту применения, а потом к определению. Хотите скачи - идите на ипподром.
Бонус 3. Некоторые умельцы ещё и форматирование туда запихивают. Мозг выносится напрочь, когда обнаруживается код типа:
string totalString = "Всего: {0} штук";
....
String.Format(totalString , total);
Итог, использование Magic String и ресурсов в большенстве своём плохой и неоправданный стиль программирования. Но когда же их исползовать? Ресурсы - когда вариационность текстовой составляющей (языки, отображение и т.п.), Magic String - ну когда одно и тоже в многих местах или ну совсем длинная или непонятная строчка :)
воскресенье, 15 марта 2009 г.
воскресенье, 22 февраля 2009 г.
Книги о качественном кодирование
Случайно решил проверить на сафари какие книжки от Diomidis D. Spinellis. Оказалось он написал ещё две новых! Теперь у этого автора три книги, которые рекомендую для чтения:
Diomidis Spinellis. Code Quality: The Open Source Perspective. Addison Wesley, 2006. ISBN 0-321-16607-8.
Diomidis Spinellis. Code Reading: The Open Source Perspective. Addison Wesley, 2003. ISBN 0-201-79940-5.
Diomidis Spinellis and Georgios Gousios. Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design. O'Reilly, 2008. ISBN 9780596517984.
Кстати, если тема книжек пошла, то хотелось бы добавить ещё пару ссылок на тему качественного кода:
Code Craft, 1st Edition by Pete Goodliffe
Clean Code: A Handbook of Agile Software Craftsmanship by Robet Martin
Эффективная работа с унаследованным кодом
Наконец-то появился русскоязычный перевод классической книги для разработчика "Working Effectively with Legacy Code" Michael Feathers. Как написать новую строчку кода, куда её помещать, как написать тест под наследованный код. Множество вопросов - и в этой книге ответы.
Аннотация:
Учитесь извлекать максимум пользы из унаследованных систем, повышая их производительность, функциональность, надежность и сопровождаемость!
Можете ли вы без особого труда изменить код и тут же получить ответную реакцию на внесенные изменения? Насколько понятен этот код? Если вы ответите на эти вопросы отрицательно, значит, вы имеете дело с унаследованным кодом и понапрасну тратите время и средства на разработку.
В своей книге Майкл Физерс предлагает полноценные стратегические приемы эффективной работы с крупными базами унаследованного нетестированного кода. В основу этой книги положен материал, подготовленный автором к известным семинарам, организуемым компанией Object Mentor, включая приемы, которым автор обучил сотни разработчиков, технических руководителей и тестирующих программное обеспечение подчинять себе непослушные унаследованные системы.
В этой книге освещаются следующие вопросы:
* Представление о механизмах внесения изменений в программное обеспечение, включая ввод новых свойств, устранение программных ошибок, улучшение структуры кода, оптимизацию производительности.
* Перенос унаследованного кода в средства тестирования.
* Написание тестов, препятствующих внесению новых ошибок в код.
* Применение методов, подходящих для любого языка или платформы, с примерами кода на Java, C++, C и C#.
* Точное выявление мест в коде, где требуется внести изменения.
* Работа с унаследованным кодом, который не является объектно-ориентированным.
* Обращение с приложениями, у которых, на первый взгляд, нет вообще никакой структуры.
Кроме того, в этой книге представлены 24 способа разрыва зависимостей, помогающих работать с элементами программного обеспечения обособленно, чтобы сделать внесение изменений в код более безопасным.
Майкл К. Физерс работает в компании Object Mentor, Inc., занимающей ведущее в мире место в сфере предоставления услуг обучения, повышения квалификации, распространения знаний и руководства проектами по разработке программного обеспечения. В настоящее время он занимается обучением разработчиков со всего мира методам разработки за счет тестирования, реорганизации кода, объектно-ориентированного проектирования, программирования на языках Java, C++, C и C#, а также экстремального программирования. Майкл является автором первоначального варианта среды тестирования CppUnit, перенесенной на C++ из среды JUnit, а также среды интегрированного тестирования FitCpp, перенесенной на C++ из среды FIT. Он состоит членом Ассоциации по вычислительной технике (ACM) и Института инженеров по электротехнике и электронике (IEEE), а также председательствовал на трех конференциях разработчиков программного обеспечения CodeFest и OOPSLA.
Эта книга посвящена практическим вопросам эффективной работы с унаследованным кодом. В ней освещаются механизмы внесения изменений в унаследованный код, включая ввод новых свойств, устранение программных ошибок, улучшение структуры кода и оптимизацию производительности; способы переноса фрагментов кода в среду тестирования, особенности написания тестов для безопасного изменения и реорганизации кода, приемы точного определения мест для подобных изменений, а также подходы к обращению с унаследованным процедурным кодом. Кроме того, в книге на конкретных примерах кода, написанного на Java, C++, C# и C, демонстрируются способы разрыва зависимостей для работы с обособленными фрагментами кода и безопасного внесения в них изменений.
Книга адресована тем, кто имеет опыт разработки прикладного программного обеспечения и его сопровождения.
Рекомендую к изучению: ссылочка
пятница, 31 октября 2008 г.
Подкаст для Study-Group
Создан подкаст сообщества самообучающихся профессионалов - http://study-group.rpod.ru
Присоединяйтесь к своему саморазвитию : http://study-group.net
Синхронизация работы, самые мощные заметки, ретроспектива на форуме.
Описание работы групп в вики.
Сейчас действует 4 группы: по шаблонам проектирования, архитектуре, agile и даже философии :)
вторник, 23 сентября 2008 г.
Обзор литературы (сентябрь 2008)
Мини-обзор литературы, попавшейся мне на глаза и достойной нашего внимания
Growing Object-Oriented Software, Guided by Tests by Steve Freeman
Многообещающее название
The ThoughtWorks Anthology: Essays on Software Technology and Innovation by ThoughtWorks Inc.
Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
Самая поздняя книга по качеству, смесь советов и smells, покрытых рядом рефакторингов. В общем ответ на моду выработки принципов кодирования уровня Code Style. Рекомендую как и остальные, но ставлю в конец моего списка :)
Самый последний список рекомендаций: http://agileconsulting.ru/wiki/Books
среда, 17 сентября 2008 г.
Кент Бек. Шаблоны реализации корпоративных приложений (Implementation Patterns)
Я решил, что несколько рассуждений, которые вырываются из моей души после прочтения этой книги, помогут вам избавиться от деревянных символов (рублей) и приобрести за бумажки что-то более важное. Читал я ещё английский вариант, поэтому рекомендую русский. Хотя ещё не ознакомился с качеством переводом.
Не секрет, что руководители и разработчики не против повышения качества кода. Например, руководители, чтобы уменьшить количество денег на дальнейшее развитие, а разработчики, чтобы просто гордиться результатами своей работы. Сколько бы мы не проектировали, не анализировали, не планировали, но последнюю жирную точку ставит разработчик. Он воплощает идеи многих людей в конечный код, конечный продукт. Крайне опрометчиво не замечать важности участия разработчика в процессе создания результата. А вы уверены, что жирная точка будет идеальной? А может быть это будет клякса? Я нет :)
Многие ведущие разработчики знают различные современные технологии, получают огромные зарплаты за свои знания (и это хорошо), но они создают такой код, в котором разобраться в здравом уме невозможно (а это плохо). Требуется погружать себя в медитативное состояние созерцания реализации мыслей творческого человека. Но не забывайте, каждая минута, час, сутки, которые я трачу на созерцание запутанного кода, выходит работодателю в огромные суммы. И простое исправление ошибочки становится грандиозным исследовательским трудом по лабиринтам спагетти кода и неограниченной фантазии автора исходного кода.
Почему мы вынуждены писать сложный код? Почему мы создаем код, цена которого увеличивается с каждой новой строчкой? Почему поддержка кода становится в порядки раз дороже его создания?
Ответ простой. Нас не учили писать качественный код. Мы прячемся за качественные собранные требования или детально проработанную архитектуру. А как же код? Это пустяк и не требует профессионального к себе отношения. Но были попытки многих авторов давать советы в области написания кода. Были попытки сделать уравниловку, предлагая оградить разработчика самопальной или скопированной с прошлого места работы "Конвенцией по наименованию".
Сообщество Agile-разработчиков стремилось решить эту диллему качественного кода. Ведущие эксперты максимально заостряли внимания на лучших практиках в мире программной инженерии. Они первые внедрили и продвигали идеи "Шаблонов проектирования", "Рефакторинга", TDD и др.. Постепенно гуру Agile мира приближались к тому, кто больше всего времени проводит над конечным продуктом. Конечного и настоящего создателя ПО - разработчика.
Книга "Шаблоны реализации корпоративных приложений" (Implementation Patterns) от Кента Бека заполняет самую важную нишу создания программного обеспечения. Теперь Agile покрывает весь цикл разработки и даёт отточенные мировым опытом самые современные практики. Эти практики начинаются с наименования переменной, до управления проектами разработки корпоративных приложений. Замечу, это не серебреная пуля, а всего лишь набор успешных практик и шаблонов, использование которых повышает ваш шанс на успех.
Я считаю, что книга "Шаблоны реализации" произведёт революцию в качестве кодирования. Она должна вытеснить неуклюжих бегемотов под названием "Coding and Naming Convention" (конвенции по наименованию и кодированию). Конечно, бегемотики не исчезнут полностью, но изменят масштабы, превратившись в настольные сувениры. Важность "Шаблонов реализации" в том, что качество кода определяется общим пониманием каждого разработчика единых ценностей и принципов высокопрофессионального кодирования, а не сухими структурными правилами (конвенцией) любителей излишней формализации.
Самый главный секрет создания качественного кода и проекта - это писать программы не для компьютера, а для людей. Это прописная истина, которая около сорока лет не имела реализации. Шаблоны реализации говорят как реализовать эту истину. Эта реализация состоит из трёх уровней: уровня ценностей качественного кода, уровня принципов и уровня паттернов.
Ценности качественного кода, которым мы должны следовать это:
- Коммуникация (communication) - разрабатываемый код должен явно отражать намерение создателя. Этот принцип подчёркивается и в рефакторинге.
- Простота (simplicity) - выбираются самые простые решения и алгоритмы. Не забывайте, мы пишем коммерческий код, где от нас зависит получение прибыли клиентам. И чем быстрее мы будем давать решения, тем довольней будет заказчик. И я гарантирую, что следующий проект он захочет реализовать снова с вашей командой.
- Гибкость (flexibility) - ценность, которая диктует нам выбор такого решения, которое будет самым простым, но в случае его развития наше решение с легкостью эволюционирует в нужную форму.
Эта книга будет достойным пополнением в коллекцию изданий для профессиональных разработчиков. Если вы хотите, чтобы каждый разработчик писал качественный код, то эта книга должна быть куплена из средств выделяемых на развитие персонала. Я работал в крупных компаниях, там всегда обещают, что компания гарантирует профессиональный рост своим работникам, но редко когда компании реализовывали свои обещания. Купив эту книгу каждому разработчику, вы сможете выполнить обещанное, а в отместку разработчики смогут улучшить архитектуру проекта, микродизайна и самое главное качество кода улучшится в порядки.
Материалы книги послужили мне хорошим источником для тренингов по качественному кодированию и сформировали багаж знаний, которым я делюсь во время проведения коуч-сессий.
Денис Миллер
Независимый Agile тренер и коуч.
Microsoft Certified Trainer
http://www.AgileConsulting.ru
пятница, 5 сентября 2008 г.
Проектирование по контракту
Интересный подход разработки - проектирование по контракту. Основы подхода заложил Бертрана Мейера. Чтобы быстро разобраться рекомендую классную статью:
http://habrahabr.ru/blogs/crazydev/38612/
Немного философии и сопряжения этой идеи с C#:
http://tagirovarthur.blogspot.com/2007/11/1.html
http://tagirovarthur.blogspot.com/2007/11/2.html
Ну и самого великого маэстро можно читать бесплатно здесь:
http://www.intuit.ru/department/se/oopbases/11/
воскресенье, 2 марта 2008 г.
Повышаем качество проекта и эффективность команды
Приглашаю в гости на новые тренинги:
Тренинг "Самодокументируемый код" - все о нём говорят, но никто не знает, что это такое. Повод разобраться.
Тренинг "Проектирование в стиле Agile" - тренинг развеивает мифы, что Agile - это хаос и полное отсутствие проектирования/документации, что Agile вне процессов, вне современных подходов проектирования. Вышеперечисленное - это недальновидные высказывание случайных людей в мире разработки.
В Agile есть процессы, в Agile есть проектирование. Agile берёт самое лучшее в современному мире разработки. Agile максимизирует эффективность следуя своим ценностям. А главная ценность - качественный продукт.
Тренинг "Шаблоны построения эффективной ИТ-команды" - простые практики, которые проведут вашу команду через формирование и шторминг, к нормингу и перформингу (4 стадии развития) в кротчайшие сроки. На выходе вы получите сплочённый коллектив.
Любой тренинг лишь раставляет цели. Тренинг - это начало пути. И только совместная работа с коучером (играющим тренером) сможет внедрить эти практики в ваш коллектив. Если вы заинтересованы - предлагаю встретиться и подумать над этими вопросами. Вопросами эффективности команды и качества продукта.
вторник, 29 января 2008 г.
Новая рассылка
Для придания динамизма теме качественного кода я открыл рассылку http://subscribe.ru/catalog/comp.soft.prog.agile
Присоединяйтесь!
пятница, 25 января 2008 г.
Инструкция превращения 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