ИТ блокнот /Николай Войнов/

Clerq Ruby Gem

2020-07-29T14:06:00.000+02:00

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

В прошлом году, пристут был навеян Clear Architecture и получился Clerq. И так мне он понравился что даже заморочился на красивое описание в github pages.

И снова Creq

2017-02-10T13:42:00.000+02:00

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

зря обвесил его дополнительным DSL, т.к. потребности его использования не было.
вопрос с публикацией не актуален, т.к. GitLab отлично понимает Markdown.
вопрос с трассировкой не был востребован, соответственно до рабочего инструмента доведен не был.

Поэтому в один прекрасный момент, я решил все это из Minireq убрать. Но вместо уборки, потратил пару недель и упростив код, заменил новым инструментом Creq. Фактически, это Minireq без DSL.

FPA и PERT DSL были вынесены в отдельный проект SeeCalc.

Дальше буду продолжать в сторону трассировки, но уже в рамках промо-проекта.

Вообще, кажется что подход Minireq/Creq для управления требованиями сработал, сам использую :)

SPI, API и ORM

2016-11-29T13:24:00.000+02:00

Немногим более полу года работаю как владелец продукта. На примере двух относительно простых проектов SPI (Angular) плюс API (Java, Spring, Hibernate...) заметил интересную штуку - во втором проекте команда разработки сразу выбрала Hibernate, хотя и сталкивалась с проблемами и ограничениями в предыдущем проекте. Проблемы возникают в половине случаев, как только задача отходит от стандартной функциональности типа CRUD.

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

Подобная задача за час решается средствами SQL - имеем плоскую выборку, которую от условий группировки оборачиваем внешней группировкой, что-то типа запроса ниже. Но такого нет в Hibernate ...

-- группировка
select month(sold_at), count(id)
from (
-- исходный запрос по продажам
select id, sold_at, machine_id, item_id, item_name
from sales s join items i on i.id = s.item_id)
group by 1, 2
order by 1 DESC

Вторым примером, сейчас команда разрабатывает общий механизм для серверной фильтрации, сортировки и постраничной выдаче (есть таблица на фронте, которая умеет все это делать). Задача также прямо ложится в SQL - простое дописывание where, order by, limit, skip. Но для каждого элемента свой объектный механизм :)

Как-то в целях самообразования, на примере простой мастер-детали я сделал две версии API (ruby + grape + sequel) первую просто через SQL, вторую через Sequel::Model. Для простых моделей выигрыш минимальный - можно вполне обосновано забить на модели и оставаться в известной 30 лет логике SQL. Можно рассматривать ОРМ только если много вложенных моделей или сложная объектная логика. Например, для различных отчетов ОРМ не нужен и скорее вреден.

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

Minireq 0.1.3 и Minireq-gitbook 0.1.2

2016-06-20T11:14:00.003+02:00

Найти время на проект все сложнее и сложнее. Но за последние пару дней удалось подчистить различные досадные недоразумения и выложить новые версии.

Minireq наконец научился делать из макросов [[requirement_id]] нормальные кросс-ссылки внутри документа а также определился с каталогом ресурсов. При создании / инициализации проекта создается каталог docs/assest в который складываются изображения и другие ресурсы. В текстах требований пишу ссылки через assests/resource - локально их не видно, но после сборки docs/requirements.md все встает на свои места. Начал было преобразовывать ссылки при сборке документа, но потом бросил.

Minireq-gitbook научился делать правильные ссылки на комбинацию ASCII (requirement id) и русского текста в заголовках. Также добавлена команда deploy, которая извлекает данные из репозитория, делает книгу и разворачивает на веб-сервере.

Немного побаловался с Git Hooks (это было довольно весело потанцевать на винде сразу с node js, ruby, git sh и Go) и сейчас выглядит процесс примерно так:

Commit и Push в удаленный репозиторий.
Git Hook вытягивает данные, строит и разворачивает книгу в сети.

Если проектов несколько, каждый проект нужно разворачивать на разных port и live reload port.

Сейчас собираюсь сделать АПИ для комментариев и возможно в ближайшее время появится плагин для комментирования.

Когда дойдут руки постараюсь вынести PERT и FPA в отдельные плагины. Они достаточно интересны сами по себе. Спасибо Роману за Gogs :)

Minireq-Gitbook. Публикация документа требований

2016-05-21T11:56:00.001+02:00

Последнюю неделю внедряю Minireq в компании. Пока просто пишу требования в Markdown и публикую на своей машине требования в виде статического сайта. На следующей неделе буду заниматься вопросами развертывания для всех заинтересованных лиц и комментированием. Третий этап трассировка и все остальное.

Для публикации используется GitBook и дополнительный "plugin" minireq-gitbook, который просто делает SUMMARY.md и еще какие-то мелочи. Соответственно, самый простой способ получить документ - преобразовать команды посредством gitbook pdf/epub/mobi.

Думаю вынести трассировку и оценки в отдельные проекты плагинов. Появляются также мысли по task management через интеграцию с Jira.

Еще один логичный ход - использование Gitbook для написания прочей документации, воде Architecture Design Document и различных руководств.

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

Minireq Ruby Gem - requirements management

2016-05-14T11:46:00.001+02:00

The Creq is dead, long live the Minireq.

Встречайте Minireq Ruby Gem для управления требованиями. Вся информация для старта есть в репозитории. Внутри есть Promo проект с требованиями к Minireq и даже выходной Markdown документ.

Грубо, главной целью проекта было построить простейшую систему для управления требованиями на следующих основных принципах:

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

Сейчас инструмент находится на стадии проверки концепции и есть уже несколько мыслей по расширению. Одна из сильнейших сторон решения - упаковка кода в Gem и расширение CLI проекта через Thor. Поэтому расширять проект уже сейчас крайне просто.

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

PS

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

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

Пока не совсем ясно как удобно организовать работу когда проект состоит из нескольких приложений и групп разработки соответственно.

Requirements Management on Ruby 2

2016-04-24T19:58:00.002+02:00

Решил продолжить работу по управлению требованиями посредством консоли, текстового редактора и git.

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

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

Таким образом все встает на свои места - все что относится к некоторой функциональности (feature) можно записать в одном файле и при этом не терять структуру требований и необходимый уровень точности.

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

Contents file:

# [func] Functional requirements
## [f.core] Core
## [f.ent] Entities
## [f.cmd] Commands
# [intf] Interfaces
# [nonf] Non-functional requirement

Requirement file:

# [f.ent.requirement] 'Requirement' entity
///
parent: f.ent
///
System shall have 'Requirement' entity....

## [f.ent.requirement.data] 'Requirement' data
System shall ...

## [f.ent.requirement.actions] 'Requirement' actions
System shall ...

EnParser Ruby Gem. Сегментация и извлечение словоформ

2016-04-19T00:17:00.005+02:00

В результате затянувшегося языкового страдания появился EnParser v0.1.0. Название конечно странное, но ничего более путного в голову пока не пришло. Может parsen?

Умеет сегментировать (разбирать на предложения) английский текст. При этом собирает его из plain text и позволят задать шаблоны регулярных выражений для пропуска лишних строк. Т.е. решает предыдущий вопрос с удалением тайминга из субтитров. Здесь вроде все просто, подробности в Readme.

lemma (linguistics) the basic form of a word, for example the singular form of a noun or the infinitive form of a verb, as it is shown at the beginning of a dictionary entry

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

Cначала баловался на субтитрах и предполагал использовать на мелких файлах. Но вот сейчас скормил ему 570 страниц "Agile Software Requirement" Dean Leffingwell (предварительно перевел из pdf в plaintext через xpdf). В течении минуты получил 5736 (однако дофига!) уникальных словоформ. Вот фрагмент для примера:

user 763 (users)
test 767 (testing, tested, tests)
feature 779 (features)
requirement 858 (requirements)
release 877 (releases, released, releasing)
agile 1032
system 1072 (systems)
story 1092 (stories)
product 1162 (products)
team 1914 (teams)

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

creq ruby gem

2015-09-26T16:45:00.000+02:00

И все-таки я его выпустил, пока первая и, конечно же, сырая версия ruby gem с именем creq.

Creq это интерфейс командной строки для управления требованиями (console for requirements).

На данный момент Creq умеет:

создавать структуру заголовков документа и структуру требований (подставляет шаблон EARS в тело требования);
генерировать различные полезные таблицы Приоритет-Риск-Усилия, PERT, FPA;
считать оценки для PERT и FPA таблиц (заполняется сгенерированная таблица руками);
генерировать выходной документ SRS в формате Markdown;
создавать структуру документа на основе шаблона Markdown, включены два шаблона IEEE-830-1998 и другой, кажется похожий на RUP.

Предполагается следующий поток работы:

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

Что дальше?

думаю над добавлением других полезных атрибутов для требований;
думаю над простеньким веб-приложением для согласования требований, в простейшем варианте только возможность комментирования, и возможно установки статусов.
думаю над добавлением Epic\UserStory, UseCase, TestCase и трассировкой;
думаю над трассировкой на элементы дизайна модуль, класс функция ... (реализованное в конкретном элементе кода и покрытое тестами требование, привет Николай :))
думаю над визуализацией трассировок через GraphViz (требование и все что с ним связано в цифрах)

ЗЫ

И чтобы дальше повеселить читателя, начинаю писать SRS на систему Creq в системе Creq :)

Истрия одного импорта объектных данных в СУБД

2015-08-21T15:37:00.002+02:00

Последние несколько недель занимался оптимизацией legacy кода импорта сложной структуры объектов в БД Oracle. Первоначально ставка была сделана на оптимизацию взаимодействия с RDBMS из JDBC за счет использования PrepareStatement.executeBatch(). Эффект получился довольно заметный, но не столь значительный как ожидалось. 30 минут, которые занимала операция на предыдущей версии кода удалось превратить в 20, и конечно 33% это уже кое что... НО

В общем получилось около 500 LOC лесов из различных вспомогательных классов для автоматизации работы с СУБД и пачками операторов, и около 2000 LOC основного кода импорта. Обнаружилось что большая часть конфигурации уже была оптимизирована под пачки. Также был обнаружен явно ошибочный фрагмент кода, который делал миллионы лишних обходов древовидной структуры. Но последний момент победить не удалось из-за нехватки времени и того простого факта, что другой legacy код загружал эту структуру и к нему я не прикасался. Поэтому мерилом успеха, или тестом, упрощенно считался тот факт, что таблицы СУБД после заливки legacy и новым кодом идентичны.

В течении работы были явно видны ошибки при проектировании схемы СУБД (около года назад я здесь что-то писал про хранение сложных деревьев), что приводило к значительному росту количества записей в БД для каждого уникального объекта. Грубо дублирование идентификатора и типа в двух разных таблицах, плюс отдельные таблицы для иерархических связей. И разобраться до конца во всех хитросплетениях этого Г так и не удалось. Два с половиной миллиона объектов все-таки это не шутка ... Oracle вполне себе их потребляет где-то за 10 минут.

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

В качестве сериализатора конечно же бы выбран Yaml и работа началась... И вот, после 18 часов работы я получил следующие результаты.
- 2500000 записей превратились в 80000 (~3% :))
- 10 минут непосредственно записи превратились в 1
- загрузка также около 1й минуты.

It works! И на будущее проектируйте БД более внимательно.

Считаем количество вызовов метда через StatckTrace

2015-08-09T22:23:00.002+02:00

Тот неловкий момент, когда присказка длиннее чем сказка. Поэтому сначала сказка, а если кому интересно, ниже присказка :)

В итоге родился класс CallCounter, который помогает считать количество вызовов функций. В моем случае было полезно для visit-методов шаблона Visitor. Как пользоваться смотрите javadoc.

Присказка
Две недели упорно упаковывал кусок адского унаследованного кода сохранения конфигурации объектов в RDBMS в вызовы batchExec(). Упаковал и получил в итоге порядка 2500000 вставок объектов через 40 уникальных insert into в БД.

Местами в существующем коде уже использовались batch-вставки, только это было совсем не очевидно в каких местах, плюс оригинальный код кроме вставки еще и занимался обновлением. Сократил время вставки где-то на 35%, хотя, признаюсь, ожидал большего :)

Ну и так нормальный результат, т.к. эти 35% в абсолютных цифрах на моем железе давали 17 минут вместо 25... Добавил ведение журнала и стал смотреть более внимательно. Обход одной из основных самых сложных (и специально запутанных .. и вообще весь Domain layer сборник анти шаблонов проектирования) деревянных структур занимает 9.5 минут ...

Начал ходить кругами вокруг, считать, обходить структуру и так и сяк ... потом вспомнил, что здесь нужен классический Visitor. Сделал первую попытку и решил посчитать объекты. И тут как раз и появилась тема этого поста :) А полных обход проблемной структуры занял ах 11 секунд... конечно там еще добавится реальной работы и думаю с минуту потребуется. Но так чтобы как сейчас 9.5, это же сколько помощников было!?

PS.

Классная штука этот стекТрейс, чем хуже код - тем он полезней :)

AspectJ in Action

2015-05-10T11:24:00.001+02:00

Читаю понемногу в свободное время AspectJ in Action, 2th, 2009. Полный восторг и всем рекомендую ознакомится кто так или иначе связан с программированием. AspectJ, однозначно великий проект.

Как раньше уже рассказывал, это была задача ведения журнала событий в унаследованном большом пользовательском приложении. Сам поступил как "настоящим инженер" и сделал все наоборот - сначала решил задачу, теперь читаю книгу. Всем же остальным рекомендую сначала прочесть книгу, хотя бы базовые несколько глав по Pointcut и Advice. Это широченные возможности, которые сразу не видны по интернет заметкам. Или просто практические задачи, например, прекрасный простой пример с подмешиванием интерфейса в Java сразу с готовой реализацией (аспект с реализацией прямо в файле интерфейса).

На закуску несколько общих кусков из решенной задачи.

JComponentAspect.aj - отслеживаем создание "интересных" компонент и вешаем им слушателей событий, которые пишут в журнал.
JFileChooserAspect.aj - вызовы диалогов выбора файлов.
JOptionPaneAspect.aj - вызовы JOptionPane, немного сложнее т.к. много перегруженных методов.

Конечно, хотелось бы увидеть подобную поддержку crosscutting сразу в ЯП.

Polyglot для Maven и конфигурация на Ruby

2015-03-28T18:39:00.004+02:00

Продолжаю осваивать сборку проектов на Java. Как уже писал в прошлом посте - добавляю журнал действий в интерфейсе пользователя при помощи аспектов. Рабочий Java код был написан достаточно быстро, но с интеграцией в существующий проект до сих пор не разобрался. Проект большой, тяжелый, прядка 20 отдельных модулей с компонентами. Каждый модуль в своем проекте, вся система собирается при помощи Maven. Первая реакция на Maven - полнейшая XML аллергия. По началу начал даже смотреть в сторону Gradle, но так просто от Maven для текущего проекта все равно не избавится, и сейчас засел за чтение книжки и постепенно проникаюсь всей глубиной глубин :)

Сегодня искал что-нибудь чтобы избавится от конфигурации XML и попал куда надо - Maven Polyglot - теперь будем писать на привычном Ruby DSL :) Примеры можно посмотреть в свеженькой статье.

Итого, чтобы зажить новой понятной жизнью на новой платформе (смешно звучит) нужно прочесть книжку по Maven и поставить Полиглот :)
Нужен JDK7+, Maven 3.3.1+ и .mvn/extensions.xml

<?xml version="1.0" encoding="UTF-8"?>
<extensions>
  <extension>
    <groupId>io.takari.polyglot</groupId>
    <artifactId>polyglot-ruby</artifactId>
    <version>0.1.7</version>
  </extension>
</extensions>

Никакого Ruby ставить не нужно.

О трансляции существующих pom.xml в pom.rb смотрим здесь.

По стилю описания конфигурации можно посмотреть три различных стиля одинаковой конфигурации здесь, здесь и здесь.
XML ФТОПКУ!

Ruby 2.X TracePoint

2015-03-20T20:17:00.002+02:00

Когда осенью было время и я баловался с Ruby, после программирования бизнес-логики я собирался наконец попробовать AOP и дальше заняться многопоточностью и DRuby. Тогда я выбрал Aquarium и он у меня не взлетел на 1.9.3. Как обычно время кончилось, приоритеты изменились и эксперименты были отложены на неопределенное время.

В последний приход программазма я баловался с Gtk3 и поставил Ruby 2.1.5. И вспомнил про AOP ... погуглил-погуглил и понял что особо ничего нового кроме TracePoint на ниве AOP в Ruby за пол-года не случилось. Но это кажется как раз то что нужно.

ЗЫ

Что удивительно, случился такой расклад, что в настоящее время стал я ненадолго программистом. И первой же задачей свалился мне АОП (пол-года назад писал к ней ТЗ и до сих пор не сделали ... а последний комментарий разработчика боюсь и приводить). ПО на Java, которую последний раз видел месяца три в 2007м :). Нужен журнал работы пользователя в Swing GUI. Конечно сразу я требовал там АОП :)

Пока основной мой затык с Java - упаковка, с аспектом разбирался аж один день ... как же там все долго и сложно, удивительно как люди столько терпят это XML конфигурирование типа Maven :) Воистину, как сам Ruby так и его экосистема просто зовет к программированию ... но Java нет :)

Requirements management console

2015-03-14T23:18:00.000+02:00

"Все украдено до нас" (с) Unknown

http://www.flonatel.de/projekte/rmtoo/
http://doorstop.info/
https://github.com/jacebrowning/doorstop

Что-то после более плотного знакомства с Ruby, его консольными инструментами, использования текстового редактора в качестве IDE вообще потянуло на консольки. Вот совсем недавно на этой неделе баловался с Gtk3 и вроде довольно быстро и красиво получается ... но тянет на консольки и текстовый редактор.

В общем исследуется идея организовать управление требованиями прямо при помощи Ruby, Git, текстового редактора и файловой системы :) Что-то по аналогии с существующими системами для ведения простейших блогов на основе статического сайта.

Что-нибудь типа

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

Эх достану завтра Вигерса посмотрю по инструментам ...

Кто не в курсе трассировка зачем, можно почитать про реализацию в TFS

ЗЫ

И возможно даже инструмент попроще, с трассировкой только в формате
Требование -> Исходный код
Требование -> Тест кейс
Запрос на изменение -> касается изменения Требований -> Исходный код + Тест кейсы.
Запрос на изменение -> коммит в SCM -> список файлов и изменений в них

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

Ruby contracts gem

2015-03-13T01:15:00.001+02:00

А вот за что я люблю ковбоя

За то что все есть у него

Информация по Ruby появляется у меня хаотически, и иногда попадаются вещи которыми просто нельзя не поделится. И вот сегодня по наводке через Ruby weekly я увидел очередной очень полезный гем contracts. Гем который добавляет вам возможности проектирования по контракту, или как пишет автор "assert на стероидах". Собственно рассказывать тут нечего - лучше один раз почитаь в сети о "Design by contract" и посмотреть прекрасную презентацию конкретно по этому гему.

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

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

И действительно, хорошо бы добавить поддержку этого гема в YARD ...

Ruby DSL Handbook

2015-02-09T10:20:00.002+02:00

Курс по Ruby DSL, от автора Ruby DSL Handbook. Очень полезная и мощная техника. Уже успел немного побаловаться и понравилось. Считал функциональные точки, объявлял сложные свойства классов и делал классы для быстрого и удобочитаемого конфигурирования объектов в ISPS.

А вот и первый красивый пример использования - метод класса.

А вот и второй пример - переноса в модуль

Много материалов для бизнес-аналитика

2014-11-25T14:30:00.002+02:00

Подходит к концу К.Вигерс. Радует очень полезными ссылками

Seilevel Business Analysis White Papers - большое количество различных материалов с лучшими практиками; инструменты оценки затрат на работу с требованиями; сводная таблица ПО управления требованиями и их оценка.

INCOSE SE Handbook - книжка по инженерии ПО на 400 страниц - просто посмотрите содержание.

Также можно покопаться на Volere

CloudIDE и Bitbucked

2014-11-19T21:21:00.000+02:00

Решил Харта полистать, и вот в третьей версии учебника предлагается работать в облаке - CloudIDE! Все-таки в чем-то новаторский учебник :)

И вторая находка Bitbucket - unlimited private code repositories

Free for 5 users
Git or Mercurial
Lightweight code review
Mac and Windows client

Easy Approach to Requirements Syntax (EARS), от Alistair Mavin

2014-10-20T11:56:00.002+02:00

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

Итак, Easy Approach to Requirements Syntax (EARS), предлагает простой синтаксис для спецификации требований на естественном языке. Это только о формулировке требований на естественном языке. Не затрагиваются другие полезные инструменты как деревья и таблицы решений, взаимосвязь между сложными требованиями...

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

Все требования можно разделить на два больших класса - нормальное поведение (normal operation) и нежелательное поведение (unwanted behaviour). Все требования на естественном языке можно сформулировать при помощи пяти простых шаблона - 4 шаблона для нормального поведения и 1 для нежелательного.

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

# Общий шаблон

<optional preconditions> <optional trigger> the <system name> shall <system response>

# Безусловное поведение - определяет поведение системы которое должно работать все время. Нет никаких предварительных условий или триггеров.

The <system name> shall <system response>

Car. The car shall have a maximum retail sale price of XXX
Car. The car shall be compliant with the safety requirements defined in XXX
Laptop.The laptop shall have a mass of no more than XXX grams
Laptop. The laptop shall have a minimum battery life of XXX hours

# По событию (event-driven, When) - требование работает как реакция на событие, обнаруженное на границе системы. Часто позволяет понять границы системы.

When <trigger> the <system name> shall <system response>

Car. When the clutch pedal is depressed, the car shall disengage the driving force
Car. When the "turn indicator" command is received, the car shall operate the indicator lights on the front, side and rear of the vehicle, and provide audible and visual conf irmation to the driver

Laptop. When the laptop is off and the power button is pressed, the laptop shall boot up
Laptop. When the laptop is running and the laptop is closed, the laptop shall enter "powersave" mode

# По состоянию (state-driven, While) - требование к системе, которая находится в определенном состоянии.

While <in a specific state> the <system name> shall <system response>

Car. While the ignition is on, the car shall display the fuel level and the oil level to the driver
Car. While the key is in the ignition, the car alarm shall be inhibited
Car. While the handbrake is applied, the wheels shall be locked

Laptop. While the laptop is running on the battery and the battery is below XXX % charge, the laptop shall display "low battery"
Laptop. While an external audio output device is connected, the laptop shall mute the built-in speaker and send the audio output signal to the external audio output device

# По условиям (option, Where) - требования к системе, которая обладает конкретными свойствами

Where <feature is included> the <system name> shall <system response>

Car. Where the car has electric windows, the electric window controls shall be on the driver's door panel
Car. Where the car includes automatic windscreen wipers, the car shall sense moisture on the windscreen and operate the windscreen wipers without driver commands
Laptop. Where a "long life" battery is fitted, the laptop shall have a minimum battery life of XXX hours
Laptop. Where the laptop is a "lightweight" model, the laptop shall have a mass of no more than XXX grams

# Нежелательное поведение - похоже на требования по событию

If <optional preconditions> <trigger>, then the <system name> shall <system response>

Car. If the car detects attempted intrusion, then the car shall operate the car alarm

Car. If the car detects low oil pressure, then the car shall display a "low oil
pressure" warning

Laptop. If the incorrect password is entered, then the laptop shall display XXX warning message

Laptop. If the laptop is connected to a non-compatible device, then the laptop shall prevent transfer of data, prevent transfer of charge, display XXX warning message and not be damaged

System shall ...

2014-10-18T10:12:00.002+02:00

При формулировке требований с точки зрения системы следует использовать следующую форму:

EARS: The Easy Approach to Requirements Syntax, Alister Marvin, Rolls-Royse

[необязательное предварительное условие] [необязательный триггер события] Система должна [ожидаемая реакция системы]

<optional preconditions> <optional trigger> the <system name> shall <system response>

При формулировке требования с точки зрения пользователя, хорошо работает следующая структура:

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

или "Система должна позволять (или разрешать, или давать возможность)[название класса пользователя][делать что-то]

Также можно посмотреть ІSO/IEC/IEEE 2011

Сколько стоит плохой код

2014-09-15T20:37:00.002+02:00

Сколько стоит сопровождение плохого кода критической для бизнеса системы? На какие аспекты работы и сопровождения и как влияет качество кода? Что вообще такое плохой код?

Что такое плохой код? Собственно здесь вопрос не в вакууме, а скорее связан с сопровождением исходного кода - устранением дефектов и добавлением новой функциональности. С этой точки зрения, хороший код - это прежде всего хорошо документированный код покрытый модульными и интеграционными тестами. Хорошая документация позволяет (1) быстро найти необходимую точку приложения усилий (модуль или класс с необходимыми обязанностями), (2) убедится что код работает и увидеть ожидания от правильной работы, плюс просто посмотреть как правильно код использовать. И конечно же тестовое покрытие дает возможность рефакторинга.

Есть еще конечно и просто плохой код. Такой где не соблюдаются простейшие вещи типа разделения по слоям ГУИ - БизнесЛогика - Хранение, закона Деметры и прочих вещей типа SOLID. Но, думаю, такого кода в продакшене не много.

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

Особенно это важно, просто критично, когда система сложная с большим количеством объектов и сложной объектной иерархией.

Какое влияние оказывает?

Временная задержка, которая нужна для подготовки нового разработчика. Чем хуже код и больше нюансов - тем больше времени требуется чтобы из новичка получить полноценную единицу FTE. Еще очень важный момент, что новый разработчик некоторое время (зависит от степени сложности, плохости кода) начинает отвлекать полноценного FTE от его текущих задач - вместо единицы хорошо если остается четверть. Т.е. прямо по Бруксу - если вы хотите повысить скорость внесения изменений - простое добавление разработчиков вас только замедлит на время адаптации в коде новых разработчиков. Равно падении скорости минимум в два раза на период адаптации. Проблему команды разработки можно легко перенести на команду тестирования - все тоже самое.

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

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

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

Совсем тяжелый случай

Когда без существенного реинжиниринга существующей кодовой базы, начинается масштабная доработка вроде поддержки нового слоя взаимодействия. например просто СУБД или учетной системы, или второго ГУИ, типа мобайл или веб. Все просто - система работает, реинжиниринг придумали чтобы ничего не делать и т.п.

Что делать?

А нечего тут делать - нужно замораживать разработку новых фичеров и делать реинжиниринг. Или все равно делать реинжиниринг отдельной командой, параллельно с потоком поддержки. Бросить систему как есть нельзя - бизнес-критическая. "Переделывать нельзя поддерживать" запятые пусть каждый расставит сам.

Ruby defensive programming

2014-09-11T00:34:00.000+02:00

upate 12.09: статистика после добавления expect! Переписал проверку аргументов через expectation expect - 65 (было 83 - снижение на 22%) runs, 96 (было 117 - снижение на 18%) assertions, 0 failures, 0 errors, 0 skips. Также заменил attr_accessor на типизированное свойство - как следствие удалил несколько 'setters'. В сухом остатке - 20%-е снижение затрат на тестирование.

Вчера закончил модули ISPS::Core и ISPS::Data. Написаны все базовые классы, написаны тесты ("rake test" говорит о 83-х тестах и 117-ти проверенных утверждениях). В этой точке решено было сделать небольшую остановку и тщательно задокументировать (написать комментарии для генерации документации) все классы и добавить примеры использования. И насколько это возможно с сегодняшними знаниями Ruby, попытаться переосмыслить написанный код.

# Интерпретатор и текстовый редактор vs Компилятор и IDE.

Сразу скажу, что опыта плотной работы с интерпретаторами у меня до этого момента не было. Начинал программировать я в средней школе на интерпретаторе BasicA, вшитом в ПЗУ компьютера IBM PS/2 30 :) Но очень непродолжительный был этап, и подробностей не помню. А вот Turbo Pascal 5.5 помню :) Дальше было много всяких разных языков на которых работал и просто баловался - С++, Delphi, C#, Java (и докатился до Ruby). Все они строго-типизированные, и можно сказать, что подход не слишком отличается - компилятор - статическая проверка кода при компиляции выявляет синтаксические ошибки и несоответствия типов и тыкает в строку кода с ошибкой. ну и плюс разные вкусности CodeIntelligent - дополнение кода, рефакторинг, навигация по методам и т.п.

Вообще подобные достижения CodeIntelligent уже дошли и до интерпретаторов, возможно не настолько качественно как для Компиляторов, но все-таки дошли. Даже синтаксис как-то проверяется, например тот же Linter, который я все-же отключил :) Но несмотря на значительные успехи, до этапа запуска скрипта все ошибки отловить думаю просто невозможно (отладчиком в Ruby я также пока не пользовался, стремно как-то в командной строке дебажить :))

ИМХО, поэтому для интерпретаторов крайне важны модульные тесты - без них просто никак. Т.е. если не пройти каждую ветку исполняемого кода, не исполнить ее при помощи теста, уверенности в 100% работоспособности кода нету. Можно просто запустить интерпретацию класса, она завершится успехом и никаких ошибок не возникнет. НО они возникнут потом в конкретном куске кода, причем часто довольно смешные и нелепые :) Так что тестового кода нужно писать много. И если на Делфи я тестировал в основном корректность логики выполнения, то для Ruby прежде всего нужно убедится что он просто выполняется :) И возиться с этим стоит, т.к. Руби чертовски легкий, лаконичный, приятный и мощный язык с очень развитым сообществом и огромным количеством готового кода.

# Полностью объектный язык

В Ruby нет примитивных типов, вроде Integer, Boolean, String, Date, все это полноценные объекты, унаследованные от класса Object. В Ruby нет строгой типизации. С одной стороны это довольно удобно, упрощает многие задачи. Однако в моем случае отсутствие строгой типизации, и большая привычка к ней, возможно сыграли злую шутку. Около 10% кода - проверка на допустимый тип аргумента функций. Около 20% тестового кода - проверка того, что работают проверки на тип аргумента ... прямо фракталы какие-то :)

В общем пыхтел, писал и даже получилось что задумал, и даже получил удовольствие от процесса. Тестовый код проверки аргументов функций меня беспокоил, сама проверка также. И вот я смотрел справку по Yardoc и увидел объявление макроса для ... позже "узрел корень", что макрос создается для функции аля attr_accessor, которая кроме имени атрибута принимает параметром его тип - "property :my_property, String". Присмотрелся немного, идея понравилась и я тут же изобрел свой первый велосипед для атрибутов - стал передавать тип, и проверять соответствие в методах присвоения значений :)

Радовался не долго, т.к. решил только половину проблемы о которой раньше не сильно задумывался - просто увидел в сгенерированной документации, что все атрибуты имеют тип Object и побежал решать проблему. Второй, более актуальной частью проблемы оставалась проверка на соответствие типов аргументов при вызове методов (и тестирование, что проверка работает :)). Здесь я вспомнил про "защитное программирование" и про то, что все уже написано - ну и за пару минут нашел нужный гем на RubyToolbox - expectation. Тут же немного упростил код велосипеда и пошел листать презентацию.

Теперь можно вздохнуть спокойнее - если нужна более строгая типизация - это можно легко исправить. И если есть гем из коробки - можно вполне посчитать что он работает как нужно, и не писать больше тестового покрытия для проверки типов атрибутов :) Так что пора наверное сделать "git checkout -b maintenance/refactoring", где переписать утверждения на ожидания и избавится от части тестового кода.

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

Вот такие пока пироги.

Ruby internet provisioning persistence

2014-09-10T01:43:00.002+02:00

Только что закончил последние тесты к слою хранения. Это демо-продукт, и СУБД вообще не планировал трогать. Сейчас есть абстракция для базы данных и ее реализация для yaml. ИМХО, для Демо "за глаза" (картинки будут ниже). Но несколько соображений по теме хранения для реального проекта все-таки стоит привести.

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

# Несколько утверждений:

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

# Хранение объектов в RDBMS

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

OBJECT_TYPE(ID, NAME)
OBJECTS(ID, OBJ_TYPE_ID, OBJ_NAME, DESCRIPTON, PARENT_ID, INSTANCE_ID)
OBJECT_PARAMS(ID, OBJ_ID, PARAM_NAME, PARAM_VALUE)

Для нашей маленькой демо-системы, можно даже прикинуть. Пусть будет около 10 продуктов (4 ТП, и 6 услуг). Пусть в каждом продукте будет по 10-15 элементов и 3-4 экземпляра (разные ветви по различным условиям и состоянию абонента). У каждого элемента пусть будет 10 параметров (стандартные параметры, условия, ...) Получим около 3000-6000 объектов - даже для простой СУБД мелочь. Однако, если попробовать масштабировать на настоящую компанию и подобную систему - все будет немного тяжелее.

Будет несколько групп абонентов- часники\юрики\корпоративные клиенты - соответственно условия для них будут отличаться и по этому параметру количество продуктов увеличится грубо в три раза.
Будет реальная биллинговая система, где будет не 5 основных параметра, а 10. - в два-три раза увеличивается количество элементов в продукте

Итого, 10 продуктов * 30-50 элементов (добавим функции и их параметры!) * 4 экземпляра * 10 параметров = 12000 - 20000 ... ну тоже не критично - смешной объем для хранения, но этот объем нужно загрузить сразу при старте системы. А после загрузки, нужно будет собрать из этих трех таблиц реальные продукты ... на этой уйдет время.

Изменяться продукты будут крайне редко и только одним пользователем одновременно. ПРОЩЕ И ПРАКТИЧНЕЕ ХРАНИТЬ СРАЗУ ГОТОВЫЙ СЕРИАЛИЗОВАННЫЙ ОБЪЕКТ ПРОДУКТА, только в человекочитаемом формате, так чтобы можно было прочитать и внести изменения туда просто руками в текст. Плюс загружаться такой объект будет один на каждый продукт. Т.е. мне кажется подойдет некоторая гибридная схема (ниже) - думаю, 10 записей продуктов с десериализаций будет быстрее чем фетч 20000 строк и последующая сборка продуктов. И ГЛАВНОЕ не будет лишнего кода преобразования ООП-РДБМС

OBJECTS(ID, OBJ_NAME, SERIALIZED_OBJ)

PS

Вот так сел сначала с намерением рассказать ощущения от программирования на интерпретируемом ЯП в текстовом редакторе, но получился пост про слой хранения.

... А вот и обещанные картинки, которые нам построил GraphViz по файлу, который подготовил нам Yard ... и думаю может репозиторий переименовать в Ruby internet provisioning (RIP) ..

Какая красота этот Ruby Forwardable

2014-09-07T01:16:00.001+02:00

Думаю многие помнят про "Закон Деметры"? В Руби есть прекрасный модуль Forwardable который легко и не принужденно выведет методы внутренних объектов на поверхность родительского класса.

Самый простой пример коллекции ...

ЗЫ

Язык с каждым новым открытием нравится все больше и больше