В гостях у DevClub побывал Михаил Мухин из компании JetBrains, который рассказал о системе MPS (Meta-Programming System).

На хабре уже была парочка статей про MPS, а теперь это можно увидеть более наглядно на видео с живой демонстрацией кода: www.devclub.eu/2011/12/02/mihail-muhin-mps-intro/

Что имеем

Начну с того, что расскажу немного о проекте, в котором работаю и как там все пишется. Может не у одних нас так…

Проект представляет из себя CRM систему, разрабатываемую специально для клиентов одного сегмента бизнеса. Проекту лет 6 и команда разработчиков состоит из 10 человек. Язык: C++ и PL/SQL.

Наша система исползует Plain Old XML, так уж повелось. И на используемые XML нет схем, по большей части. Что тут говорить, если юнит тесты прививаются здесь только второй год и менеджер до сих пор упрекает за время, потраченное на их написание. Да ладно…

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

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

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

По науке, тесты являются документированием системы. Грамотно написанные тесты дают понять, как работает система, как ведет себя, причем читаться все это должно как готовая спецификация на поведение системы. Т.е. в идеале должен получаться связный и понятный текст. Это идеал, к которому постепенно приближаются методы тестирования, начиная от юнит тестирования и наиболее явно проявляясь в поведенческом/приемочном тестировании, когда сами тесты уже пишутся на языке бизнеса (в этом моменте вспоминаем Fitnesse).

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

В общем, все должно быть направлено на максимальную ясность и четкость тестов, чтобы явно было видно все взаимосвязи. Чтобы можно было восстановить логику программы по одним лишь тестам. В дело читабельности пойдет не только Assert DSL (Domain Specific Language), но и именование файлов, подход Arrange Act Assert. Все это не новые подходы как оказывается, но широкой известности пока не получившие, судя по тому, что я вижу в окружающих меня проектах. Да и сам я натолкнулся на новые темы случайно, изучая исходные коды StructureMap.

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

• Именовать тестовые файлы по основному методу, который тестируется.
• Использовать DSL  для создания объектов, чтобы методы делать максимально лаконичными.
• Стараться писать тесты в стиле «один тестовый метод – один assert».
• Структурировать внутренности теста.
• Создать и использовать Assert DSL.

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

Как часто вам приходилось видеть или писать одни и те же несколько строчек кода, которые постоянно используются вместе для решения одной и той же задачи? Взять, например, перебор или сортировку (некоторую манипуляцию) коллекций. Такие участки кода программистам приходится писать каждый день. Конечно, есть различные IDE, в которых можно использовать snippet'ы и шаблоны. Тем не менее, подобные конструкции загромождают код, делая его более подходящим для обработки компьютером, а не для восприятия программистом.

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

Рассмотрим пример использования LambdaJ. Найдём возраст самого юного покупателя, который совершил покупку более, чем на 50'000.

Классический (итеративный) способ:

int age = Integer.MAX_VALUE;
for (Sale sale : sales) {
  if (sale.getCost() > 50000.00) {
    int buyerAge = sale.getBuyer().getAge();
    if (buyerAge < age)
      age = buyerAge;
  }
}


LambdaJ способ:

int age = min(forEach(select(sales, having(
  on(Sale.class).getCost(), greaterThan(50000.00)).getBuyer()))),
  on(Person.class).getAge());


DSL (Domain Specific Languages) — языки, специфичные для решения задач какой-либо предметной области (в противовес языкам общего назначения типа Java или C#). Более подробное описание и примеры есть на википедии, я же хочу написать про то, как довольно легко встроить в приложение (C#) свой собственный DSL на базе языка Boo.

Скоро создатель Scala Мартин Одерский (Martin Odersky) сможет удвоить численность своей группы разработчиков, сказано в официальном блоге. Команда Scala, которая базируется в EPFL (Федеральная политехническая школа Лозанны), в ближайшие пять лет получит 2,3 млн евро финансирования от Европейского исследовательского совета. Им удалось выиграть пятилетний грант в рамках конкурса «Popular Parallel Programming». Таким образом, Scala обзавелась надёжным источником финансирования на ближайшие годы.