Я мог бы перечислить больше, если бы захотел.

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

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

1. Рубокоп не установлен

Rubocop — инструмент статического анализа ruby, основанный на Руководстве по стилю Ruby. Я не думаю, что кто-либо, кто использовал Ruby, знает об этом. Кроме того, при изучении Ruby необходимо прочитать Руководство по стилю Ruby.

Выражения в Ruby очень гибкие, и даже если выполняется один и тот же процесс, внешний вид может быть совершенно разным в зависимости от того, кто его пишет.

Это одна из сильных сторон Ruby, но если каждый будет реализовывать ее по-своему, возникнут проблемы с читаемостью и ремонтопригодностью.

Если вы пишете в одиночку, вы можете писать свободно, но если вы используете это для работы, вы не являетесь владельцем, и если вы осознаете, что кто-то кроме вас прочитает это, это будет естественно. Это приведет к желанию унифицировать стиль команды. Говорят, что вы тратите больше времени на чтение кода, чем на его написание. Высокая удобочитаемость — лучший способ продолжать приносить пользу пользователям, даже когда вас нет.

Руководство по стилю Ruby было создано в результате обсуждения нашими предшественниками. Он по-прежнему постоянно совершенствуется. Другими словами, можно сказать, что это учение наших предшественников о том, что так легче читать. Большинство инженеров, в том числе и я, — карлики, так что стоит встать на плечи гигантов.

Машина может легко обнаружить ошибку, даже если человеку трудно ее заметить. Например, если один и тот же ключ существует более одного раза в Ruby’s Hash, он становится рассадником ошибок, которые люди могут обнаружить, если внимательно присмотрятся, но машины могут легко обнаружить. Rubocop укажет, что даже если переменная, определенная как необходимая во время разработки, оставлена ​​как есть, даже если она не использовалась в конце. Несомненно, если машина научит вас тому, что вы можете заметить механически, это поможет улучшить качество.

Репозиторий без простых в развертывании инструментов статического анализа пренебрегает качеством.

2. Контроллер имеет логику

В Rails дизайн и бизнес-логика должны быть написаны в модели, а не в контроллере. Если вы знаете базовую концепцию MVC, вы не будете писать сложную бизнес-логику в Controller. Я видел, как все это обрабатывалось одним действием. Более того, итоги немного отличаются для HTML, CSV и JSON, и каждый пишется отдельно, так что это было очень долгое действие. Если бы Rubocop был установлен, то были бы указаны длинные методы, но типичный для плохих приложений Rails, robocop не был установлен.

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

Более того, шаблон становится огромным и громоздким, если одно и то же действие имеет 3 или 4 логики. Поэтому с точки зрения тестируемости важно разделить код до минимальной степени, чтобы можно было написать модульные тесты.

3. Никаких тестов

Теперь немного о тестировании. Я думал, что оставлю «без тестов» в одном из антипаттернов. Я не думаю, что создание тестов на ранних стадиях — хорошая идея, когда бизнес-требования не определены.

Также на ранних стадиях, если само приложение простое и масштаб понятный, я думал, что можно будет расставить приоритеты релиза, а не писать тесты.

Однако, когда я писал это, я подумал, что это должно быть включено. На ранних стадиях разработки может не быть тестирования, которое еще не выпущено. Но мы создаем веб-приложения, потому что хотим, чтобы компьютеры выполняли более сложные задачи.

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

Часто релиз идет первым, а тестирование отходит на второй план. Я думаю, что тест должен быть градуированным. Другими словами, мы пишем тесты для критичных частей системы, но не пишем тесты для не столь важных частей.

Примерами критических областей могут быть те, которые связаны с платежами и выставлением счетов. Например, в случае с сайтом, если есть проблема с ценой или биллинговой системой, все продажи будут снесены. Это жизненно важно для выживания компании.

С другой стороны, в основном статическая страница, такая как страница описания сайта, вероятно, менее критична и менее сложна, поэтому не стоит тратить много времени на ее тестирование.

Другая точка зрения заключается в том, легко ли заметить дефекты. Например, если функция часто используется пользователями, если установлен такой механизм, как уведомление об ошибке, при возникновении проблемы ее можно заметить сразу. Увеличивать. Извините, но я думаю, что иметь первого человека в качестве испытуемого, увидевшего проблему и оперативно ее исправившего, — это ход, который следует рассматривать как средство.

С другой стороны, пакетная обработка, которая выполняется всего несколько раз в месяц, обычно требует времени, чтобы заметить ее. Есть только шанс увидеть его несколько раз в месяц.

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

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

4. База данных не нормализована

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

Однако нарушать нормализацию на ранних стадиях разработки — не лучшая идея. Не будет слишком поздно, пока количество записей не увеличится и не возникнут проблемы с производительностью. Хотя вывести нормализацию из нормализованного состояния несложно, обычно бывает сложно нормализовать из ненормализованного состояния.

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

Такое происходит потому, что разработка идет без должного бизнес-анализа. Конечно, в современном быстро меняющемся мире невозможно установить 100% требования.

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

Базу данных можно рассматривать как крайнюю абстракцию бизнеса. Вы можете назвать это зеркалом, которое отражает ваш бизнес. Моделирование базы данных расскажет вам о вашем бизнесе, если у вас есть хороший дизайн базы данных.

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

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

5. Под видом ускорения, вставка в кеш, не притворяясь

Раньше я работал и поддерживал систему, которая использовала кеш (Redis) для ускорения. В этом продукте Model.all.select { |m| м.хоге? } Был такой код, и во многих проектах говорилось: «Вы можете сделать это с помощью SQL».

Был также случай, когда я не смог получить нужную мне информацию и сказал: «Ну, вы можете сделать это с помощью реляционной базы данных». Я пытался исправить это, но это была основная часть системы, и если бы я подумал о ее настройке, это повлияло бы на широкий спектр вещей, поэтому я не мог это исправить.

Возможно из-за того, что объем информации увеличился и на ее обработку требуется время, в крайнем случае соответствующая часть кэшируется, чтобы процесс после второго раза не вызывался. Таких мест было много.

Некоторые выпуски включали дополнительную информацию YAML, поэтому мне приходилось каждый раз очищать кеш. Что еще хуже, ключи кеша были непоследовательны, и даже если бы я хотел очистить кеш только для соответствующих частей, я не мог этого сделать, и мне пришлось удалить запас и для несвязанных факторов.

Постепенно обработка после очистки кеша стала тяжелой, загрузка страницы стала медленной после релиза, сумка стала временно высокой, и, наконец, страница вылетела.

Кэширование простое в использовании, но может стать громоздким, если оно распространено в вашей системе. В тех случаях, с которыми я столкнулся, до создания кеша, когда один и тот же запас вызывается несколько раз за один доступ, увеличивается нагрузка на пропускную способность сети или ключи кеша хранятся в переставленной комбинации, поэтому одна и та же информация была зарегистрированы как разные вещи в зависимости от порядка в то время, и это съело емкость Redis.

Подпишитесь на DDIntel Здесь.

Посетите наш сайт здесь: https://www.datadriveninvestor.com

Присоединяйтесь к нашей сети здесь: https://datadriveninvestor.com/collaborate