Ruby on Rails - Самые распространенные ошибки новичка. Часть 4 - Общие ошибки

Всем привет. Это завершающая статья из цикла "Ошибки новичков". В этой статье все ошибки, которые я не определился куда отнести. Но, знать их не менее полезно, чем все остальные.

Немного об оформлении. Все ошибки разделены на 4ре категории. Кроме того, есть Особо важные ошибки выделенные красным цветом. Эти ошибки могут критично сказаться на работе проекта и команды.

Итак, новички:

Путают ключи в хешах

Нельзя забывать, что символьный и строковый ключи в хешах - это 2 разных ключа

Неправильное использование картинок в CSS

Нужно помнить, что при деплое на продакшн ассеты компилируются и поэтому для указания пути нужно пользоваться хелперами. Используем хелпер image-url, указываем только имя файла, остальное подхватится автоматически.

Не заморачиваются с именем коммита

Нельзя писать коммиты, которые не соответствуют или не описывают решаемую им задачу.В коммиты нужно вставлять идентификатор задания, подробное описание. Использовать ‘общие’, краткие описания можно только для мелких изменений.

Не знают (забывают) о лог файлах при дебаге.

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

В логах нет магии рейлс!! Они показывают то, что происходит на физическом уровне.

tail -f log/development.logtail -f log/test.log

Оставляют ненужные файлы

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

Как это обычно бывает.

Я программист, которому нужно найти нужный JS код. В папке assets около 30 файлов, но все они остались после генерации. Мне придется приложить усилия, чтобы найти нужный мне файл

А как хотелось бы

Я программист, которому нужно найти нужный JS код. В папке assets около 3-5 файлов, я быстро нашел нужный файл по названию и уже в нем ищу свой код. Я не потратил ни секунды на открывание и закрывание пустых файлов.

Забывают удалять пароли, ключи и прочую инфу из репозитория

Очень часто новички забывают, что публичные ключи и пароли не должны попасть в гит репозиторий. Но, при этом так же неплохо создать example файл, который поможет Вашему коллеге установить проект.

config/database.yml обычно должен быть добавлен в .ginignore. Кроме того, создан файл config/database.template.yml, который останется только скопировать и вставить туда Ваш локальный логин и пароль. Ну и коллеги будут Вам чрезмерно благодарны, если вы добавите команды для копирования всех таких файлов в readme

Переопределяют базовые методы rails

Хотя ruby и позволяет переопределить почти все, для базовых методов этого лучше не делать. Ваши коллеги ожидают, что методы работают ровно так как должны, без сюрпризов.

Плодить ветки условий с проверками "На всякий случай"

Не стоит делать повторные проверки, на случай, если что-то пойдет не так, лучше получить ошибку и внести исправления. Код должен работать так, как вы его задумали. Поэтому, лучше максимально рано получить эксепшен и доработать его, учитывать кучу непонятных ситуаций. Не ракету же вы на ruby программируете=)

Кулстори #1

Как некоторые делают.

Я пишу максимально “надежный” код, в котором обрабатываются все ситуации, любые входные данные, который никогда не упадет. В один момент получаю отчет от клиента, что пользователь приложения потерял очень важные данные. Они не сохранились в его приложении. Я трачу кучу времени, нахожу еще одну ситуацию, которую не предусмотрел, но данные уже не вернуть.

Как надо бы.

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

Кулстори #2

Как обычно бывает =(

Мне достался проект после 7ми индусов и 2х лет разработки. Я в нем лишний чих боюсь сделать, видя сколько там условий и ветвлений в коде. Перед изменениями трачу кучу времени на покрытия кода тестами, чтобы чего лишнего не сломать. Но, и с тестами, не спешу удалять лишний код, а кто их индусов знает, что я задену.

Как хотелось бы =(

Мне достался проект после 2х лет разработки. Код в нем не идеален, но это и понятно; 2 года разработки, изменяющиеся требования, где-то времени немного не хватило. Но, в нем нет каши, все вполне логично. Новые изменения выкатить довольно просто. Мне такие проекты доставались, только если какой-то наш клиент вдруг через год или два вдруг решил оживить свой проект. Это что-то настолько же мифическое, как и идеальный код. Не надо так((

На этом все. Надеюсь, что материал был Вам полезен! Успехов в code review=)

P.S. Если у кого-то еще что-то болит, не стесняйтесь делиться в комментариях.

Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit.

📎📎📎📎📎📎📎📎📎📎