Хотел сделать сравнение двух ORM ответом на пост «Встреча казанской UserGroup 9.12.2009». Выписал все плюсы и минусы в таблицу. Взвесил все «за» и «против» и сделал вывод, какая ORM все-таки лучше.
Потом все это удалил, потому что в таком сравнении нет смысла. Во-первых, уйма народу это уже сделали. Во-вторых, лучшей ORM быть не может, т.к. в каждом проекте свои нюансы и их надо учитывать. Вместо этого я напишу причины, из-за которых мы отказались от LLBLGen и перешли на NHibernate.
Формулировка:
Сейчас мы создадим и отрефакторим приложение. Будем двигаться по шагам и я покажу применение принципа инверсии зависимостей в действии.
Что это?
Суть в том, чтобы из хранилища кода SVN собрать историю работы над проектом. В эту историю могут входить количество строк кода, время комитов, активность авторов комитов и т.д.
Зачем?
Вообще я не любитель собирать такие метрики, но меня заинтересовало наблюдение Сергея Архипенкова. Я говорю о принципе цикличности при становлении команды.
Сергей заметил, что графики количества строк кода и фаз становления команды выглядят очень похоже. Дело в том, что сначала команда собирается и происходит разработка основных компонентов (формирование команды). В этот период пишется «скелет» системы, кода мало. Потом команду «штормит» и все приходит в норму. Здесь пишется основной код. И, наконец, команда выходит на максимальный уровень производительности. А вот тут уже все написано, остается только рефакторить и исправлять ошибки. Это то самое место, когда количество строчек кода уменьшается.
Вчера вернулись с конференции «Гуру на Урале», где выступал Сергей Архипенков. Атмосфера была отличная, к тому же с практической точки зрения узнал интересные вещи.
По ходу выступления Сергея записывал себе ссылки на ресурсы, которые он рекомендовал. Думаю они будут интересны и вам.
Интернет ресурсы
Статьи и аналитика на сайте Игоря Ашманова
Гильдия менеджеров программных проектов
С. Архипенков: Как нанимать людей?
Книги
Роберт Гласс «Креативное программирование 2.0»
Роберт Гласс «Факты и заблуждения профессионального программирования»
Том ДеМарко, Тимоти Листер «Человеческий фактор. Успешные проекты и команды»
Стив Макконнелл «Профессиональная разработка программного обеспечения»
Формулировка: клиенты не должны зависеть от методов, которые они не используют
Как и при использовании других принципов проектирования классов мы пытаемся избавиться от ненужных зависимостей в коде, сделать код легко читаемым и легко изменяемым.
17-18 ноября в УрГУ состоятся открытые лекции Сергея Архипенкова.
Делегация от нашей компании уже пакует чемоданы :) До встречи в Екатеринбурге (кстати, кто еще собирается?) и спасибо проекту «Гуру на Урале».
Формулировка №1: eсли для каждого объекта o1 типа S существует объект o2 типа T, который для всех программ P определен в терминах T, то поведение P не изменится, если o2 заменить на o1 при условии, что S является подтипом T.
Формулировка №2: Функции, которые используют ссылки на базовые классы, должны иметь возможность использовать объекты производных классов, не зная об этом.
Короткая версия: Derived classes must be substitutable for their base classes
5-ого ноября в 18-00 я буду рассказывать о нашем опыте внедрения экстремального программирования (XP). Пройдет эта встреча в ЮУрГУ в аудитории 240, корпус 3Б. Содержание будет такое же как и на июньской встрече в ЧелГУ.
Участие бесплатное. До встречи!
Формулировка: программные сущности (классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для изменения
Какую цель мы преследуем, когда применяем этот принцип? Как известно программные проекты в течение свой жизни постоянно изменяются. Изменения могут возникнуть, например, из-за новых требований заказчика или пересмотра старых. В конечном итоге потребуется изменить код в соответствии с текущей ситуацией.
Формулировка: не должно быть больше одной причины для изменения класса
Что является причиной изменения логики работы класса? Видимо, изменение отношений между классами, введение новых требований или отмена старых. Вообще, вопрос о причине этих изменений лежит в плоскости ответвенности, которую мы возложили на наш класс. Если у объекта много ответвенности, то и меняться он будет очень часто. Таким образом, если класс имеет больше одной ответственности, то это ведет к хрупкости дизайна и ошибкам в неожиданных местах при изменениях кода.
Принципы проектирования классов облегчают работу программиста. Уметь их применять очень важно. Умелое использование этих принципов избавляет проект от тяжелого бремени технических долгов, облегчая его поддержку и расширение.
Принципы проектирования классов:
Ссылки
HanselMinutes:SOLID Principles with Uncle Bob - Robert C. Martin
SOLID Software Principles - Presentation And Code
Хороший дизайн должен быть SOLID: TOP-5 архитектурных принципов
Я хочу помочь программистам, которые только начали делать первые шаги в профессиональной карьере, а также студентам, которые хотят выйти за рамки учебных дисциплин.
Если вам хочется узнать как строить карьеру в IT, я написал об этом в статье по ссылке http://blog.byndyu.ru/2011/04/it.html
Цель
Для чего понадобилось создавать этот роутер:
Случайно наткнулся на интересный документ — Программа дисциплины: Разработка интернет-приложений для электронного бизнеса. Один из вопросов на очном экзамене: «Что фиксирует документ, названный Agile Manifesto, для разработчиков программных проектов и какие принципы он провозглашает?». Могу только порадоваться за будущие поколения программистов, которым эти знания даются в университетах. Мы выскребали их сами из интернета и книг ;-)
На сколько я знаю, модульное тестирование, итеративный процесс разработки и многое другое уже преподают. Например, в ЮУрГУ преподают тестирование. Тесты пишут под NUnit.
Я сам выступал в ЧелГУ на тему «Экстремальное программирование. Опыт внедрения». По ходу выступления мне задавали интересные вопросы, слушатели проявили большой интерес к этой теме.
Если так дальше пойдет, то гибкие методологии будут восприниматься как обыденное. Не к этому ли мы все стремились?
Идея пришла от заказчика. Суть в том, что кроме обязательных заливок в конце итерации, заказчик просит нас делать заливки после выполнения определенных карточек.
Выглядит примерно так:
Звездочкой отмечена карточка, сделав которую нам надо залить новую версию на сервер, чтобы ей могли пользоваться.
Теперь заказчик получает еще большую отдачу от разработки, а нам такие заливки ничего не стоят :-)
Если вы занимались спортом, то знаете, как важен ритм и дыхание. В борьбе очень важно сбить дыхание соперника, а при беге сбивать свое дыхание ни в коем случае нельзя.
Планируя разработку программного продукта, мы задаем ритм, дыхание команды. Каждые 2 недели (длина нашей итерации) мы обязуемся выпускать новую версию продукта, которая продвинет заказчика вперед, принесет ему прибыль.
Заметил интересный эффект при работе в паре.
Программисты привыкли заниматься разработкой по 40 часов в неделю. Но программируя в паре, получается держать с клавиатуру в руках только половину дня. Пока программист выполняет роль стратегического наблюдателя и просматривает код коллеги, он все больше хочет взять клавиатуру себе и попрограммировать. Момент, когда тебе передают каждые полчаса-час клавиатуру и называется «дорвался». У «дорвавшегося» до клавиатуры программиста глаза горят, руки чешутся и голова переполнена идеями.
Классное состояние, лично мне оно нравится... с одним замечанием. Тот, кто отдает клавиатуру не должен расслабляться, отдыхая после сессии программирования, а взять стратегическое наблюдение под свою ответственность. Если оба входят в кураж - рождаются многочисленные технические долги.
Фактически мы делали выбор между доской и Trac. Оба инструмента обладают рядом достоинств и недостатков.
Недавно увеличили полезную отдачу от TortoiseSVN.
Добавили русские словари
Мы начали писать все комментарии к коммитам по-русски. По-умолчанию TortoiseSVN не использует русские словари. Если писать по-русски, то весь текст комментария подчеркивается красным.
Добавить русский словарь очень просто. Советую.
Добавил интеграцию с Trac
Если вы используете Trac и TortoiseSVN, то будет очень полезно настроить их взаимодействие. Опять же минимум усилий и очень хороший результат.Вкратце. При коммите пишем номер ошибки в Trac.
При просмотре лога ревизий видим номера ошибок и ссылки на соответствующие страницы в Trac'е.
По инициативе проректора по научной работе ЧелГУ Мельникова Андрея Витальевича 11 июня состоится встреча на тему «Экстремальное программирование. Опыт внедрения» в 15:15, аудитория А17. Приглашаются разработчики и руководители проектов. Аудитория довольно большая должны поместиться все желающие. Вход свободный.
Я буду рассказывать про практики экстремального программирования (XP): о плюсах, которые мы получаем при их использовании и трудностях с их внедрением. Буду рад, если придут коллеги, которые тоже используют XP в своих проектах. Можно будет вместе отвечать на вопросы и делиться опытом.
До встречи!
Доклад на тему «Экстремальное программирование. Опыт внедрения» в ЮУрГУ
Первый способ внесения зависимостей я показал в прошлый раз. Сейчас хочу показать второй способ и сравнить оба подхода. На этот раз мы будем использовать модель push.
Никак не вычищается из памяти Excel.exe? Даже делаете все по шагам из статьи Office application does not quit after automation from Visual Studio .NET client? Уже решили убивать все весящие Excel-процессы командой Kill?
Путь, который должен пройти настоящий TDD-программист тернист и опасен. Чтобы не пасть духом и не повернуть назад, понадобится специальное снаряжение. Инструменты TDD-программиста должны быть легки, чтобы он мог преодолевать препятствия не уставая, и заточены как лезвие, чтобы смог справиться с любыми трудностями.
С недавних пор мы начали писать все комментарии в проекте по-русски. Все начиная от XML-комментариев, заканчивая комментариями к коммитам.
Раньше писали практически все по-английски. Английский язык в команде все знают, поэтому особых проблем с этим не было.
Что произошло? Можно сказать свершилась моя голубая мечта. Раньше частенько попадались немногословные комментарии к коммитам типа change, delete junk, fix bug. Сейчас все пишут развернутые комментарии! Бывает даже в несколько предложений. Например, "HtmlHelperExtensions - добавил создание статического листа InquiryUnitDropDownList для отображения списка единиц измерения в заявке на продукт"
Видимо, для написания этой фразы на английском не хватало терпения и знания языка.
Маленькая уловка, которая поможет команде осознать, что XML-комментарии в коде действительно обязательны.
После выставления этих опций в свойствах проекта на каждый публичный объект без XML-комментария (класс, метод, свойство и т.д.) выдается ошибка компиляции:
Надеюсь, что этот пример поможет вам, если вы, как и я, пытались внедрить в команду культуру написания XML-комментарием.
Сейчас мы активно используем ORM LLBLGen Pro в своих проектах. Я уже рассказывал, как мы решили проблему с тестированием DataAccessApater и запросов на Linq, которые по своему реализованы в этой ORM.
Артем Смирнов в статье База, знай свое место! выразил свое мнение по поводу места базы данных при разработке ПО. Даже назвал ее "простой утилитой". Заявления довольно резкие и стоят прояснения.
С чего начинать разработку ПО? С детальной разработки логики приложения или с проектирования базы данных для нашей системы? Это неправильный выбор из двух крайностей. В реальности решение лежит где-то посередине, отклоняясь к тому или иному полюсу в зависимости от обстоятельств.
Чем будет обусловлен выбор? Главное здесь это то, что в последнее время произошло смещение акцентов при разработке ПО. Разработчики и менеджеры стараются больше внимания уделять сопровождению приложения, его развитию в долгосрочной перспективе. Именно поэтому основное внимание (опять же не всегда) уделяется развитию и поддержанию гибкого и понятного дизайна в коде. С таким кодом проще работать, он содержит меньше ошибок, искать ошибки проще, новые программисты могут быстрее разобраться в исходном коде и приступить к работе в команде.
После последнего отчета The Standish Group "CHAOS Summary 2009" я нашел их предыдущие публикации и посмотрел развитие нашей отрасли за 15 лет.
На фоне постоянно улучшающихся технологий, создания новых методик разработки ПО рост незначительный. Возможно проблема не в технике, а в головах? Причем обвинять одних разработчиков и менеджеров в том, что они слишком инертные или не хотят расти над собой будет неправильно. Люди, которые выставляют бизнес-цели, причастны к провалам в такой же степени, как и исполнители.
Сами учредитель компании The Standish Group видят улучшение в индустрии производства ПО и являются большими поклонниками гибких методологий. Продвигаться вперед небольшими шагами - итерациями - вот возможное решение, которое снижает риски проекта оказаться в числе повалившихся.
При компиляции вашего проекта Visual Studio должна собрать больше 20 проектов? Значит вы, как и я, уже заметили, что эта операция занимает прилично времени. Сейчас у нас за раз компилируется 27 проектов и мы нашли способ, как ускорить этот процесс.
Посвящается всем потерянным человеко-часам, проведенным в дебаге и рефакторинге из-за халатного копипастинга.
Копипаст плодит дублирование, уничтожает дизайн системы, делает ее неповоротливой, расшатывает нервы программистов и портит отношения в команде.
В Международный день борьбы с копипастом каждый уважающий себя программист отключает сочетания клавиш Ctrl+C, Ctrl+V и пишет свой код самостоятельно.
Ты все еще копипастишь?
На сколько ваши тесты эффективны? Получаете ли вы максимум отдачи от создания тестов? Тесты должны экономить время, затраченное на разработку системы в целом. Время - это деньги вашего заказчика.
Уже более чем пол года наша команда постоянно работает с JavaScript (библиотека ExtJS), который используется вместе с ASP.NET для слоя отображения. За это время мы перебрали большое количество инструментов, с помощью которых пытались сделать свою работу наиболее комфортной. Сейчас мы собрали приближенное к нашим потребностям рабочее место. О нем подробнее.
Моя книга «Антихрупкость в IT»
Как достигать результатов в IT-проектах в условиях неопределённости. Подробнее...