Я должен сохранить плохие соглашения о присвоении имен?
Я в настоящее время работаю над сайтом, который прошел бога, знает сколько рук разработчиков. Одной из вещей, мне не нравится приблизительно он, является способ, которым каждая таблица в базе данных имеет префикс "tbl _" и каждое поле "fld _".
Я запустил работу над новой возможностью, и я сталкиваюсь со следующей проблемой: мои новые таблицы должны продолжить старую конвенцию, или нет?
Я предполагаю, что я должен, но я чувствую себя глупым, делая его:)
12 ответов
Я бы придерживался того же соглашения .. Независимо от того, плохо это или нет, по крайней мере, оно будет согласованным. А согласованность будет очень важна для следующего разработчика, которому достанется код.
Как подрядчик, я часто сталкиваюсь с этой проблемой. Вот мои 2 цента:
Если он не сломан, то клиент зря тратит свои деньги, заставляя меня это менять. Если я не переписываю все приложение, я обычно придерживаюсь старых (плохих) стандартов (по крайней мере, так, у вас нет части приложения с одним соглашением, а другие части используют что-то другое - это сохраняет код читаемым другим разработчиков).
У вас есть два варианта.
- Измените все неправильные соглашения об именах на новые.
- Используйте старые соглашения.
Кто-то будет просматривать этот код позже, и ему понадобится чтобы справиться с любыми создаваемыми вами различиями. Это означает, что вам нужно знать, что это решение повлияет на других людей. Делайте правильные вещи, если у вас есть время, делайте уродливые вещи, если у вас нет времени ... но держите это постоянно.
Если это будет постоянный стиль во всем приложении, я буду следовать соглашению об именах, это упростит задачу следующему разработчику.
Я обычно смотрю на задействованный масштаб. Согласованность неправильного соглашения об именах для меня предпочтительнее множества различных таблиц в той же кодовой базе или базе данных.
Если существует несколько таблиц, и вы можете безопасно изменить их, я считаю, что внести изменения . Но что-либо масштабное или приложение, в котором вы только исправляете ошибку, скорее всего, не стоит затраченного времени и усилий.
Выбирайте любой маршрут, который стоит меньше денег и ресурсов. Если это не поможет вам сэкономить деньги на повторной обработке земли, тогда не стоит. Просто стисните зубы и двигайтесь вперед.
Я думаю, вам следует предпочесть последовательность и следовать уже используемым соглашениям.
Подумайте о бедных разработчиках, которые приходят за вами и вынуждены иметь дело с двумя разными соглашениями об именах ( исходный и ваш новый), ни один из которых не нравится новым разработчикам.
Добро пожаловать в мир обслуживания. ;)
Кто сказал, что следующий человек, работающий на сайте, не будет презирать то, как вы это делаете?
Любое соглашение об именах лучше, чем отсутствие / несовместимое соглашение об именах.
Я предлагаю изменить это, если есть существенная разница между старым и новым кодом. Например, если старый способ был ужасно тупиковым, а новый полностью независимым, тогда начинайте новое соглашение.
Хорошо быть визуально согласованным, если новый материал структурно и семантически согласован, но если то, что вы делаете, является полным отходом от того, что было раньше, еще более важно, чтобы разные вещи выглядели по-разному.
Как все говорили, оставайся с плохой конвенцией, так как ты не пишешь ее с нуля. Тем не менее, используйте "хорошую практику", если в этом есть острая необходимость (так же известная как и в противном случае, это негативно скажется на конечном пользователе). Например, если "плохое соглашение" заставляет пользователей API использовать бокс, изменяйте значение строк и другие показатели производительности в значительной степени; не усугубляйте проблему! Конечной целью программного обеспечения и API является не облегчение жизни разработчиков, а облегчение жизни конечного пользователя. Разработчики, которые долгое время остаются в бизнесе, прекрасно это понимают, и вы хотите быть одним из таких разработчиков.