Фото через Fotolia (нажмите для подробностей)
Когда в 1600-х годах астрономия была в моде в Европе, во многом благодаря изобретению и производству телескопов.
В результате разные люди смогли узнать больше и научить общество больше о звездах и тому подобном, и все это чудесно прогрессировало. Но астрономия не просто смотрит на красивые огни; Есть много расчетов. Кроме того, это не вычисления типа сто четырнадцать плюс двадцать шесть, которые вы делаете в своей голове; они тяжелые, с большими числами и пугающими цепями арифметики.
Предположительно, «аспирантам» астрономии в то время было поручено сидеть и разбираться в числах для более опытных астрономов.
Затем человек по имени Джон Нейпир все изменил. Немного снизив точность расчетов, он разработал (или, по крайней мере, внедрил в Европе) систему «логарифмов», которая значительно упрощает арифметику (это основная идея правила скольжения).
Это то, что Rails сделал с веб-приложениями. Делая небольшие предположения о том, как вы пишете свой код и как ваше приложение обслуживает своих пользователей, оно сделало процесс разработки и развертывания высококачественных веб-приложений гораздо менее болезненным процессом.
Но, похоже, это начинает меняться, когда вы заканчиваете свои первые семь или восемь месяцев с вашим веб-приложением. Шаблоны разбросаны, контроллеры раздуты, а модели сидят без дела, ничего не делая. Медленно, но верно время вашей разработки замедляется, функции доставляются все медленнее и медленнее, и, что хуже всего, удовольствие от разработки веб-приложений.
Вы определенно не хотите, чтобы это случилось с вами.
Если вы готовы потратить немного времени с самого начала, вы можете предотвратить это.
Итак, давайте начнем с некоторых вещей, которые вы должны иметь в виду при разработке кода для этого удивительного нового приложения, которое изменит мир.
Нет бизнес-логики в шаблонах
Шаблоны не предназначены для «хруста» вашего приложения! Хватит выдвигать весь свой код в шаблоны!
В частности, бизнес-логика — это все, что вы делаете с данными. Итак, если вы вычисляете возраст человека, это бизнес-логика.
Призыв сделать это присутствует; вам нужно иметь дело только с одним файлом за раз. Если вам нужно что-то исправить в / user / signup, вы знаете, что проблема в представлении, потому что контроллер и модель в значительной степени пусты!
Но есть и другие проблемы, которые убивают вашу производительность. Во-первых, читаемость кода сильно страдает, потому что вы выражаете все в терминах вывода HTML.
Во-вторых, это разрушает точку MVC, которая является модульностью. Большая производительность Rails исходит от MVC
структура, поэтому, делайте все возможное, чтобы сохранить и следовать ей.
Кроме того, размещение всей вашей логики в представлении очень затрудняет абстрагирование операций. Например, если бы я хотел вычислить возраст человека несколько раз в моем приложении, я мог бы написать метод для абстрагирования этого вычисления. Однако, когда вы заполняете все в представлениях, это не работает, и вы будете повторять чертовски из себя.
Рассмотрим этот шаблон:
| <% ps = Post.where(:author => , :blog => «Something», | |
| :language => «English», :market => «developers»)[0] %> | |
| <% if ps.time_posted.nil? %> | |
| Oops, using old system please revert. | |
| <% end %> | |
| <div id=«times»> | |
| <span class=«age»><%= Date.today — ps.time_posted %></span> | |
| <span class=»age_edited»><%= Date.today — ps.time_edited %></span> | |
| </div> | |
| <div id=«post-<%= ps.id %>» data—id=«<%= ps.post_id %>»> | |
| <div id=«author»>ps.author</div> | |
| </div> |
by Это так запутанно, я едва могу сказать, что здесь производится. Я не могу себе представить, как бы я отладил это, когда придет время.
Попробуем упростить это безумие.
Прежде всего, с какой стати вы делаете запрос к базе данных INSIDE THE VIEW ?! Мы должны создать переменные представления для всех вычислений, которые мы делаем внутри представления. Вот наш последний взгляд:
| <% if no_time_included %> | |
| Oops, using old system please revert. | |
| <% end %> | |
| <div id=«times»> | |
| <span class=«age»><%= @age %></span> | |
| <span class=«age_edited»><%= @age_edited %></span> | |
| </div> | |
| <div id=«post-<%= @id %>» data—id=«<%= @p_id %>»> | |
| <div id=«author»>@author</div> | |
| </div> |
Все, что мы сделали, это просто установили несколько переменных и перенесли нашу логику в контроллер (или модель, которая могла бы быть лучше), и это делает код намного чище.
Как вы можете видеть, вложив немного работы, вы значительно упростите свою жизнь в будущем, когда придется разбирать свое приложение, чтобы исправить эту одну досадную ошибку.
Ведение журнала важно!
Что вы делаете, когда ваш сервер выходит из строя? Panic? Крик? Все вышеперечисленное?
Когда ваш сервер выходит из строя, вы пытаетесь выяснить, почему это произошло, и исправить это как можно быстрее. Если вы хорошо ведете лесозаготовку, у вас будет намного лучше.
Вам необходимо зарегистрировать все следующее:
- Большие изменения базы данных
- Логин пользователя — выход из системы
- Серверные соединения
- Нерест подпроцесса
- AJAX-запросы и ответ
Обратите внимание, что это очень далеко от исчерпывающего списка! Подумайте о том, что вы хотите, когда у вас есть дождливый день.
Также поймите, что вы не хотите регистрировать так много, что тратите больше времени на регистрацию, чем на запросы к базе данных (если, конечно, вы не выполняете никаких запросов к базе данных)!
Изучение системного журнала — отличная инвестиция; ведение журнала — это круто, но вы не можете повредить пользовательскому интерфейсу.
Тощий Контроллер, Толстая Модель
Эта философия недавно подвергалась критике, но она хорошо сработала для меня, и я призываю вас попробовать и ее.
Идея состоит в том, что вы не помещаете всю свою бизнес-логику в контроллер, а вместо этого вставляете модель, которая должна быть лучше.
Например, если вы хотите узнать из базы данных, какие пользователи вошли в определенное время, добавьте этот метод в модель и вызовите его из контроллера.
Это будет модель:
| class User < ActiveRecord::Base | |
| … | |
| def self.find_logins_at_time(time) | |
| #method implementation | |
| end | |
| … | |
| end |
Это действительно делает ваш код модульным, потому что все контроллеры, использующие модель User, имеют доступ к этому методу (если вы этого хотите).
Просто кажется неправильным помещать весь ваш код в контроллер, который фактически предназначен для ответа на HTTP-запросы.
Rails все еще использует обычный старый Ruby
Рубин на рельсах. Вот как это называется. Это не просто Rails.
Это означает, что вы можете использовать старый добрый рубин, с которым мы все знакомы. Классы, методы, статические переменные и т. Д. Работают в основном одинаково, за исключением того, что Rails иногда входит и заставляет магию происходить. Например, Rails делает переменные класса доступными для представления из контроллера.
Что это обозначает? Ну, это означает, что не будьте ослеплены всеми «Rails» вокруг вас, вы все равно можете использовать свои знания Ruby.
Используйте методы и статические переменные там, где это необходимо, поскольку ruby - невероятно мощный язык, который вы можете использовать в своих интересах, чтобы повысить производительность и упростить обслуживание.
Стоит потратить время на то, чтобы больше узнать о ruby, его преимуществах и недостатках с другими языками.
В качестве примера, я недавно разрабатывал финансовое веб-приложение, в котором было множество вариантов конфигурации, которые не были хорошо выражены в YAML. Я смог использовать Ruby для разработки DSL (предметно-ориентированного языка), чтобы конфигурация проходила в десять-двадцать раз быстрее.
В целом
Есть все виды вещей, которые я не смог охватить; модульные тесты, тестирование JavaScript, конвейер активов, управление активами и т. д.
Это не полный список того, что вы должны делать, но вы обязательно должны делать то, что в списке.
Надеюсь, вам понравилось читать, и, надеюсь, ваш следующий баг будет легче исправить.