Выполняет ли кодирование по правилам гибкость?

Question

Во-первых, я на 100% в пользу соглашений и всей команды. Тем не менее, я рассматриваю рамки (в основном различные PHP, но также Ruby on Rails и другие), которые в значительной степени обеспечивают кодирование по соглашению. На первый взгляд это кажется отличной вещью, поэтому URL-адреса напрямую переводится на /controller/action. Модели называются после таблиц DB, и система точно знает, где загрузить все файлы с помощью действительно простого автозагрузчика.

Однако мы используем платформу с белой этикеткой, и то, что работает для большинства клиентов, не обязательно работает для других. Некоторым может потребоваться определенный шаблон URL, поэтому нам нужно настроить маршруты. Некоторым может потребоваться, чтобы страницы имели совершенно другой формат для других клиентов, поэтому мы получаем автозагрузчик, который всегда проверяет, существуют ли версии файлов, специфичные для конкретной зоны, и при необходимости отбрасываются по умолчанию. Это делает разработку ДЕЙСТВИТЕЛЬНО легкой для нас, потому что мы просто бросаем файл с соответствующим именем и размещаем его на месте. Но поскольку это меньшинство случаев, когда это требуется, мы обнаруживаем, что автозагрузчик тратит чрезмерное количество времени на проверку файлов, которые почти гарантированно будут отсутствовать.

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

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

Answer 1

Rails работает в основном так. У вас есть соглашение, но все идет с необязательными параметрами, которые позволяют вам изменять вещи по мере необходимости. Есть ли унаследованная база данных, где уникальный идентификатор не указан id, поскольку Rails этого ожидали? Просто скажите Rails имя. Ваши маршруты разные? Вы все равно можете написать свои собственные матчи. Есть что-то сделать, прежде чем сохранить запись? Просто зацепите before_save.

Для всего остального вещи просто работают. У вас есть немного больше работы, чтобы объявить все вещи, которые отличаются друг от друга, но вам все равно придется писать какой-то код.

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

Но, очевидно, это имеет смысл только в том случае, если имеется достаточно большое ядро ​​вещей, которые имеют все системы, особенно если вы намерены написать что-то совершенно с нуля. Добавление гибкости, которая не нарушает все это время, требует тщательного планирования.

Answer 2

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

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

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

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

Answer 3

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

- Hal Абельсон Структура и интерпретация компьютерных программ

Вы, возможно, не нравится то, что Я собираюсь сказать, но иногда производительность не вызывает беспокойства. Я бы придерживался решения, которое делает разработчиков счастливыми. Если есть простое соглашение, вам следует придерживаться его, а не создавать сложный механизм конфигурации. Здесь нет серебряной пули, но, на мой взгляд, вы просто замените одно соглашение (место, где здесь и там) с другим (разместите здесь эти конфиги, а здесь - здесь). Будет ли труднее следовать? Вероятно. Это в ваших руках, чтобы сделать его простым в использовании.

И, как всегда, держите своих коллег счастливыми. Или они найдут тебя. И съел тебя. И накройте свой код неприятными комментариями (это худшая часть).