Ruby on Rails - Самые распространенные ошибки новичка. Часть 4 - Общие ошибки
Всем привет. Это завершающая статья из цикла "Ошибки новичков". В этой статье все ошибки, которые я не определился куда отнести. Но, знать их не менее полезно, чем все остальные.
- Модели и база данных (11 ошибок всего, из них 4 важных)
- Контроллеры (6 ошибок всего, из них 3 важных)
- The Ruby Way и качество кода (15 ошибок всего, из них 5 важных)
- Общие ошибки без категории (8 ошибок всего, из них 4 важные)
Немного об оформлении. Все ошибки разделены на 4ре категории. Кроме того, есть Особо важные ошибки выделенные красным цветом. Эти ошибки могут критично сказаться на работе проекта и команды.
Итак, новички:
Путают ключи в хешах
Нельзя забывать, что символьный и строковый ключи в хешах - это 2 разных ключа
hash = {‘a’ => 1, a: 2}
hash[‘a’] # 1
hash[:a] # 2
Неправильное использование картинок в CSS
Нужно помнить, что при деплое на продакшн ассеты компилируются и поэтому для указания пути нужно пользоваться хелперами. Используем хелпер image-url, указываем только имя файла, остальное подхватится автоматически.
################################
## Это плохо! ##
################################
body .container {
background: url(‘assets/images/my_image.jpg’)
}
################################
## А вот это хорошо ##
################################
body .container {
background: image-url(‘my_image.jpg’)
}
Не заморачиваются с именем коммита
Нельзя писать коммиты, которые не соответствуют или не описывают решаемую им задачу.
В коммиты нужно вставлять идентификатор задания, подробное описание. Использовать ‘общие’, краткие описания можно только для мелких изменений.
################################
## Это плохо! ##
################################
git commit -m ‘Subscriptions’
################################
## А вот это хорошо ##
################################
git commit -m ‘[#123456] Allow user to subscribe to the course’
Не знают (забывают) о лог файлах при дебаге.
Можно часами дебажить приложение в дебаггере, заменять входные данные и гадать на кофейной гуще. А можно, посмотреть в лог.
В логах нет магии рейлс!! Они показывают то, что происходит на физическом уровне.
tail -f log/development.log
tail -f log/test.log
Оставляют ненужные файлы
Оставлять файлы, которые больше или вообще не используются нельзя. Самой частой ошибкой является не удаление сгенерированных файлов.
Как это обычно бывает.
Я программист, которому нужно найти нужный JS код. В папке assets около 30 файлов, но все они остались после генерации. Мне придется приложить усилия, чтобы найти нужный мне файл
А как хотелось бы
Я программист, которому нужно найти нужный JS код. В папке assets около 3-5 файлов, я быстро нашел нужный файл по названию и уже в нем ищу свой код. Я не потратил ни секунды на открывание и закрывание пустых файлов.
Забывают удалять пароли, ключи и прочую инфу из репозитория
Очень часто новички забывают, что публичные ключи и пароли не должны попасть в гит репозиторий. Но, при этом так же неплохо создать example файл, который поможет Вашему коллеге установить проект.
config/database.yml обычно должен быть добавлен в .ginignore. Кроме того, создан файл config/database.template.yml, который останется только скопировать и вставить туда Ваш локальный логин и пароль. Ну и коллеги будут Вам чрезмерно благодарны, если вы добавите команды для копирования всех таких файлов в readme
Переопределяют базовые методы rails
Хотя ruby и позволяет переопределить почти все, для базовых методов этого лучше не делать. Ваши коллеги ожидают, что методы работают ровно так как должны, без сюрпризов.
################################
## Это плохо! ##
################################
class Article
def save
unless some_my_condition?
return false
end
super
end
end
################################
## А вот это хорошо ##
################################
class Article
def save_with_condition
unless some_my_condition?
return false
end
save
end
end
Плодить ветки условий с проверками "На всякий случай"
Не стоит делать повторные проверки, на случай, если что-то пойдет не так, лучше получить ошибку и внести исправления. Код должен работать так, как вы его задумали. Поэтому, лучше максимально рано получить эксепшен и доработать его, учитывать кучу непонятных ситуаций. Не ракету же вы на ruby программируете=)
Кулстори #1
Как некоторые делают...
Я пишу максимально “надежный” код, в котором обрабатываются все ситуации, любые входные данные, который никогда не упадет. В один момент получаю отчет от клиента, что пользователь приложения потерял очень важные данные. Они не сохранились в его приложении. Я трачу кучу времени, нахожу еще одну ситуацию, которую не предусмотрел, но данные уже не вернуть.
Как надо бы.
Я пишу код, который не обрабатывает разные ситуации на всякий случай. Я знаю все возможные варианты и их запрограммировал. В один момент пользователь сайта вводит данные которые я не предусмотрел. Мой код падает с ошибкой, а пользователь видит сообщение “Что-то пошло не так, попробуйте позже”.
Я получаю сообщение об ошибке с сервера, чиню ошибку и выкатываю апдейт. Следующий раз у пользователя все получится.
Кулстори #2
Как обычно бывает =(
Мне достался проект после 7ми индусов и 2х лет разработки. Я в нем лишний чих боюсь сделать, видя сколько там условий и ветвлений в коде. Перед изменениями трачу кучу времени на покрытия кода тестами, чтобы чего лишнего не сломать. Но, и с тестами, не спешу удалять лишний код, а кто их индусов знает, что я задену.
Как хотелось бы =(
Мне достался проект после 2х лет разработки. Код в нем не идеален, но это и понятно; 2 года разработки, изменяющиеся требования, где-то времени немного не хватило. Но, в нем нет каши, все вполне логично. Новые изменения выкатить довольно просто. Мне такие проекты доставались, только если какой-то наш клиент вдруг через год или два вдруг решил оживить свой проект. Это что-то настолько же мифическое, как и идеальный код. Не надо так((
На этом все. Надеюсь, что материал был Вам полезен! Успехов в code review=)
P.S. Если у кого-то еще что-то болит, не стесняйтесь делиться в комментариях.
Комментарии