2010-11-02 2 views
10

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

Я знаю, что могу описать все это в описании класса, но мне интересно, есть ли способ, более тесно связанный с самим объявлением (has_many, validates_presence_of и т. Д.), И как насчет атрибутов?

ответ

3

Я лично предпочитаю ДВОР - http://yardoc.org, так как он лучше справляется с документированием ИМХО. Я не знаю, есть ли какой-либо конкретный обработчик для Rails, но его довольно легко написать - http://yardoc.org/guides/extending-yard/writing-handlers.html Хорошим примером может быть обработчик атрибутов - часть жемчужины двора: lib/yard/handlers/ruby ​​/ attribute_handler .rb

+0

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

2

Помните, что ваши тесты являются частью документации (для разработчиков), особенно если вы используете Cucumber, где сценарии легко читаются. Если вы держите свои методы очень короткими, и существует метод тестирования с описательным именем, например. «должно указывать имя пользователя». Мне кажется, что мне не нужны комментарии к методу.

Подтверждения или другие части Rails Я бы не документировал. Часть разработчиков Rails понимает, как это работает, я считаю, что справедливое предположение, что другой сопровождающий вашего кода, читающий его по дороге, будет знать проверки или другие вещи, встроенные в Rails. По той же логике, если вы можете использовать функции фреймворка или счастливые пути (не сильно отклоняйтесь) с [документированным] сторонним кодом, для вас будет написано много документации.

+0

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

+0

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

Смежные вопросы