На моей практике Ruby и Ruby on Rails оказались самым тяжелым в изучении сочетанием языка и фреймворка. Те люди, которые начинали программировать с C, C++ или Java, обнаружат в Ruby абсолютно другой (и более правильный!) подход к ОО-дизайну, а в Rails — много интересных решений, которые необходимо понять и осознать. И хотя изучение Ruby заняло у меня много времени (и я уверен, что еще очень многое предстоит узнать), я люблю эту технологию и не собираюсь возвращаться назад.
У меня есть опасение, что по мере роста популярности Ruby и Rails будет появляться все больше разрабочиков, изучающих Ruby через призму закоренелого Java-подобного мышления. С одной стороны это хорошо. Но с другой стороны это плохо тем, что некачественный код, когда он становится общедоступным, порождает еще больше некачественного кода.
Так как ThriveSmart (компания автора — sotakone) берет на работу все больше программистов (причем не все они являются Ruby on Rails ниндзя), нам необходимо постоянно проверять качество кода и архитектуру разрабатываемых проектов, чтобы поддерживать их на высоком уровне. Вместе с моим хорошим другом Дэном мы составили перечень требований к коду, под которым будут подписываться все наши разработчики. Хотя список еще дополняется, вы можете взглянуть на текущую версию.
Я подтверждаю, что все это верно для моего проекта.
[Имя разработчика] [Подпись]
Дальше в оригинале статьи идет довольно большой раздел с объяснениями этих пунктов. Я начал его переводить, но очень быстро мне это надоело, так как рассказываются там очевидные вещи. Если какой-то из пунктов списка кажется вам спорным или непонятным, я предлагаю обсудить его в комментариях.
У меня есть опасение, что по мере роста популярности Ruby и Rails будет появляться все больше разрабочиков, изучающих Ruby через призму закоренелого Java-подобного мышления. С одной стороны это хорошо. Но с другой стороны это плохо тем, что некачественный код, когда он становится общедоступным, порождает еще больше некачественного кода.
Так как ThriveSmart (компания автора — sotakone) берет на работу все больше программистов (причем не все они являются Ruby on Rails ниндзя), нам необходимо постоянно проверять качество кода и архитектуру разрабатываемых проектов, чтобы поддерживать их на высоком уровне. Вместе с моим хорошим другом Дэном мы составили перечень требований к коду, под которым будут подписываться все наши разработчики. Хотя список еще дополняется, вы можете взглянуть на текущую версию.
Перечень требований к коду Ruby on Rails приложения
- Экшн контроллера должен вызывать только один метод модели после начального #find или #new. Если есть потребность, сделайте у модели дополнительный #new или #update метод, который будете вызывать в контроллере.
- Контроллер должен передавать в вид одну или максимум две переменные.
- Все имена классов и переменных должны быть понятны даже новому разработчику. Избегайте длинных имен и аббревиатур.
- Все выборки модели, которые делаются в контроллере больше одного раза, должны быть объявлены как named_scope.
- В виде никогда не вызываются @model.find*.
- Код приложения никогда не дублирует функциональность Rails.
- Во время разработки код усиленно DRY-ится.
- Весь функционал, общий для двух или более моделей, выносится в отдельную библиотеку/модуль. (данное правило справедливо так же для контроллеров — sotakone)
- Весь функционал, используемый в двух или более приложениях, выносится в отдельный gem-плагин (не обязательно в gem, но в плагин точно — sotakone).
- В коде приложения не используется STI.
- Архитектурные решения должны быть наиболее простыми. Не нужно закладывать в приложение зачатки будущей функциональности.
- «Верхний» уровень приложения (код контроллеров) должен быть обложен тестами вдоль и поперек. Чем чаще код используется конечным пользователем, тем больше на него должно быть тестов.
- Код вливается в основную ветку только если проходят все тесты.
- Чтобы предотвратить повторное появление багов, на каждый исправленный баг создается тест.
- Код каждого установленного плагина предварительно изучается.
Я подтверждаю, что все это верно для моего проекта.
[Имя разработчика] [Подпись]
Дальше в оригинале статьи идет довольно большой раздел с объяснениями этих пунктов. Я начал его переводить, но очень быстро мне это надоело, так как рассказываются там очевидные вещи. Если какой-то из пунктов списка кажется вам спорным или непонятным, я предлагаю обсудить его в комментариях.
