Мы планируем изменить название нашей компании в ближайшее время. Все наши пространства имен, проекты и т. Д. Используют XYZ.ComponentName.Изменение названия компании ... мы меняем пространства имен?
Мой вопрос вам должен был бы изменить наши пространства имен? Измените все старые компоненты на ABC.ComponentName? Оставьте старые, но любая новая разработка станет ABC.ComponentName? Просто придерживайтесь старого имени?
От этого зависит.
Некоторые вещи, которые следует учитывать: если изменение пространства имен означает перемещение файлов в CVS, тогда существует штраф, потому что вы теряете историю. Если изменение пространства имен означает ручную работу, вы будете пропускать места и вызывать ошибки.
Кроме того, есть ли у вас внешние пользователи кода/библиотек? Если они должны изменить свой код, потому что вы переименовали компанию, они будут раздражены.
Я был бы склонен оставить код так, как он есть. Пространства имен бессмысленны, кроме как для предотвращения столкновений; на данный момент это только маркетинг. Но для новых продуктов я бы наверняка использовал новый namesapce.
Где я работал, у нас было несколько изменений названия компании или приложения, и это всегда было проблематично. Одно приложение было отложено на пару недель, в то время как в последнюю минуту они сглаживали ошибки глобального изменения пространства имен. Еще одно приложение никогда не принимало новые имена и всегда было внутренне названо устаревшим именем, потенциально запутанным для новых пользователей. Представьте, что все в Java все еще называлось «Дуб».
FYI: Если вы используете Perforce для контроля версий, вы не потеряете эту историю. Он отслеживает историю файла даже по ветвям (переименование фактически состоит из операций ветвления и удаления). Они добавили эту полезную функциональность в течение последних двух-двух лет. – raven
@Raven .. нанести удар также и VSS - для изменения .. lol –
@raven: Да, CVS является худшим нарушителем об изменениях файлов отслеживания переименований.Но это очень распространено. Мы застряли с ним на моей работе, пока ... вздох. –
Смешивание и совпадение пространств имен часто являются очень трудными и запутанными с точки зрения технического обслуживания. Я бы сказал, что это действительно зависит от количества компонентов, с которыми вы имеете дело, и от того, сколько приложений зависит от них.
Возможно, было бы целесообразно отобразить зависимости и почувствовать, сколько работы у вас на руках.
Это зависит от того, если компоненты стабильны, часто используется, если оно не слишком много времени, чтобы изменить, если есть время и деньги разработчиков, чтобы изменить его ...
Много ли годов.
Я бы, скорее всего, оставил их как есть. Их изменение создает кошмар в работе, тестировании и проверке, и если кто-то извне использует вашу библиотеку, они также должны изменить свои привязки, чтобы приспособить это изменение.
Когда Next был куплен Apple, они оставили префикс NS как есть, вы можете увидеть это сегодня с помощью фреймворков Apple. Это не убьет вас, чтобы оставить их как есть.
Для новых пространств имен вы можете изменить его на ABC, но тогда вы нарушите согласованность, что может смутить людей - особенно новых разработчиков.
Просто оставьте его как есть, и беспокоиться о других вещах :)
Кроме того, следить, если вы делаете какие-либо инъекции зависимостей, которая использует отражение, как то может сломаться.
Другой проблемой является сторонний код или другие проекты, которые используют ваш проект, если они есть, поскольку изменение пространства имен приведет к их разрыву.
Самый безопасный вариант - оставить пространства имен такими, какие они есть.
Какой бы выбор вы ни выбрали, не смешивайте два пространства имен с новой разработкой. Быть последовательным. Если вы решите придерживаться старого, новая разработка тоже должна его использовать. Если вы перейдете на новый, переместите все.
Может потребоваться некоторый анализ работы, связанной с вашим конкретным сценарием, чтобы решить, стоит ли ее переключать или нет.
Мы смешиваем наши пространства имен ... это абсолютно не вызывает проблем. Это отличный способ отличить устаревшие архитектуры от более новых архитектур :) – Precipitous
+1 для Precip, только потому, что он указывает на это. Как я уже упоминал ниже, я думаю, что вы не должны использовать пространства имен для этого, в первую очередь, и эта ситуация показывает, почему. –
Вы продаете эти компоненты третьим сторонам? Если нет, то это не стоит усилий. Если вы, то пространство имен является частью вашего маркетинга и поэтому должно быть изменено.
Это был мой опыт в таких сценариях, что лучше оставить пространство имен так, как оно есть в настоящее время. Любые новые разработанные библиотеки могут использовать новое название компании в пространстве имен.
Что касается текущего рассола, в котором вы оказались, я бы попросил некоторые $$ из бюджета изменения вывесок для исправления кода. Если они не дают его вам, оставьте старое имя.
Я думаю, что правильный ответ: не создают пространства имен с названием вашей компании в них. Почти все знают, кто подписывает их зарплату; вы не допускаете путаницы, закрепляя имя в коде.
У меня был один сотрудник, который однажды обнаружил пространства имен, и следующее, что я знал, что вся наша библиотека программного обеспечения должна быть доступна через несколько слоев пространств имен, обозначающих нашу компанию, подразделение и проект. Дело в том, что у нас действительно есть только один проект (хотя вы могли бы убедить меня в этом), другие подразделения не занимаются программным обеспечением, а код, который мы берем с других компаний, не следует его схеме. Так что на самом деле это просто бесполезная дополнительная набраковка, которую мы должны сделать. Да, мы можем «использовать», но тогда нет реального преимущества в пространствах имен вообще. О, и, конечно же, название нашего подразделения изменилось пару лет спустя, когда руководство решило, что «разделение» звучало как девизное, и теперь мы должны называться «командами». % - (
Пространства имен лучше всего использовать каждый раз, когда у вас есть несколько классов, на которые у вас возникнет соблазн назвать startimg с (или включенным где-то) той же строкой. Они не предназначены для зеркалирования текущей структуры отчетности управления вашей группой разработки программного обеспечения.
Ну, не используя название компании - это один из способов приблизиться к вещам, но иногда это не отраслевой стандарт: правила именования пакетов Java специально просят вас назвать свои пакеты после вашего TLD. Таким образом, класс SO, который отвечает за разбор комментариев, будет иметь имя com.stackoverflow.commenting.CommentHTMLParser. –
Я читал это в своих указаниях еще в конце 90-х, когда они впервые придумали Java. Я думаю, что их видение заключалось в том, что сеть будет заполнена пакетами, которые люди могут делиться (или покупать), и, следовательно, что-то вроде этого потребуется. В наши дни я не являюсь Java-парнем, но так не получилось, не так ли? –
Руководства по пространству имен Java - это то, как они есть, потому что таким образом существует простой путь для уникальных пространств имен, доступных по всему миру. Существует не совсем «веб-полный» пакетов, но есть множество различных организаций, которые выпускают java-библиотеки и от крупных организаций до небольших магазинов до отдельных разработчиков, все они знают, как убедиться, что их пакет не сталкивается с другое пространство имен. –
Какие языки или среды являются этими пространствами имен? Является ли XYZ легкоисследованным без (много) ложных срабатываний? Является ли ваш код внутренним или это повлияет на других людей? Сколько работы вы готовы вложить в это? –
You знаю, что это хороший вопрос и интерес к членам «/». «Но это не связано с программированием. Почему некоторые люди здесь закрывают такие вопросы? Я: 1) пытаюсь понять менталитет определенных , люди, и 2) понять, как я могу получить свой квази ответы на вопросы, связанные с программированием, вместо закрытых. Пища для размышлений. Для этого: http://stackoverflow.com/questions/1364304/what-companies-are-using-rowe-in-a-software-development-environemt-closed. Кто-то скажет мне, что моя ошибка. –
@ Don: Тот, с которым вы ссылаетесь, спорный. Однако этот вопрос даже не близок. Это проблема, абсолютно уникальная для программирования. В них могут быть другие внутренние документы со старым названием компании, но при плоском документе ничего не сломается, если вы только переключите некоторые ссылки. –