Мы планируем изменить название нашей компании в ближайшее время. Все наши пространства имен, проекты и т.д. Используют XYZ.ComponentName.
Мой вопрос к вам должен был бы изменить наши пространства имен? Измените все старые компоненты на ABC.ComponentName? Оставьте старые, но любая новая разработка станет ABC.ComponentName? Просто придерживайтесь старого имени?
Зависит.
Некоторые вещи, которые следует учитывать: если изменение пространства имен означает перемещение файлов в CVS, тогда существует штраф, потому что вы теряете историю. Если изменение пространства имен означает ручную работу, вы будете пропускать места и вызывать ошибки.
Кроме того, есть ли у вас внешние пользователи кода/библиотек? Если они должны изменить свой код, потому что вы переименовали компанию, они будут раздражены.
Я был бы склонен оставить код так, как он есть. Пространства имен бессмысленны, кроме как для предотвращения столкновений; на данный момент это только маркетинг. Но для новых продуктов я бы наверняка использовал новый namesapce.
Где я работал, у нас было несколько изменений названия компании или приложения, и это всегда было проблематично. Одно приложение было отложено на пару недель, в то время как в последнюю минуту они сглаживали ошибки глобального изменения пространства имен. Еще одно приложение никогда не принимало новые имена и всегда было внутренне названо устаревшим именем, потенциально запутанным для новых пользователей. Представьте, что все в Java все еще называлось "Дуб".
Вы продаете эти компоненты третьим сторонам? Если нет, то это не стоит усилий. Если вы, то пространство имен является частью вашего маркетинга и поэтому должно быть изменено.
Что касается текущего рассола, в котором вы оказались, я бы попросил некоторые $$ из бюджета изменения вывесок для исправления кода. Если они не дают его вам, оставьте старое имя.
Я считаю, что правильный ответ заключается в том, что вы вначале не создаете пространства имен с именем вашей компании. Почти все знают, кто подписывает их зарплату; вы не допускаете путаницы, закрепляя имя в коде.
У меня был один сотрудник, который однажды обнаружил пространства имен, и следующее, что я знал, что вся наша библиотека программного обеспечения должна быть доступна через несколько слоев пространств имен, обозначающих нашу компанию, подразделение и проект. Дело в том, что у нас действительно есть только один проект (хотя вы могли бы убедить меня в этом), другие подразделения не занимаются программным обеспечением, а код, который мы берем с других компаний, не следует его схеме. Так что на самом деле это просто бесполезная дополнительная набраковка, которую мы должны сделать. Да, мы можем "использовать", но тогда нет реального преимущества в пространствах имен вообще. О, и, конечно же, название нашего подразделения изменилось пару лет спустя, когда руководство решило, что "разделение" звучало как девизное, и теперь мы должны называться "командами". % - (
Пространства имен действительно лучше всего использовать, когда у вас есть несколько классов, которые у вас возникнет соблазн назвать startimg с (или включая где-нибудь) той же строкой. Они не предназначены для зеркалирования текущей структуры отчетности текущего отдела разработки программного обеспечения.
Какой бы выбор вы ни выбрали, не смешивайте два пространства имен с новой разработкой. Быть последовательным. Если вы решите придерживаться старого, новая разработка тоже должна его использовать. Если вы перейдете на новый, переместите все.
Может потребоваться некоторый анализ работы, связанной с вашим конкретным сценарием, чтобы решить, стоит ли ее переключать или нет.
Смешивание и сопоставление пространств имен часто очень затруднительно и запутывают с точки зрения обслуживания. Я бы сказал, что это действительно зависит от количества компонентов, с которыми вы имеете дело, и от того, сколько приложений зависит от них.
Возможно, было бы целесообразно отобразить зависимости и понять, как много работы у вас на руках.
Также следите за тем, выполняете ли вы какую-либо инъекцию зависимости, которая использует отражение, поскольку это может сломаться.
Другая проблема - сторонний код или другие проекты, которые используют ваш проект, если они есть, поскольку изменение пространства имен приведет к их повреждению.
Самый безопасный вариант - оставить пространства имен такими, какие они есть.
Это зависит от того, стабильны ли компоненты, очень много используются, если это не так много времени для изменения, если есть время и деньги, и разработчики меняют его...
Множество if.
Я бы просто оставил их как есть. Их изменение создает кошмар в работе, тестировании и проверке, и если кто-то извне использует вашу библиотеку, они также должны изменить свои привязки, чтобы приспособить это изменение.
Когда Next был куплен Apple, они оставили префикс NS как есть, вы можете увидеть это сегодня с помощью фреймворков Apple. Это не убьет вас, чтобы оставить их как есть.
Для новых пространств имен вы можете изменить его на ABC, но тогда вы нарушите согласованность, что может смутить людей - особенно новых разработчиков.
Просто оставьте это как есть и подумайте о других вещах:)
Это был мой опыт в подобных сценариях, поэтому лучше оставить пространство имен таким, каким оно есть в настоящее время. Любые новые разработанные библиотеки могут использовать новое название компании в пространстве имен.