практика управления версиями
Вышеупомянутые решения действительно велики, но если словарь ключевых слов длинный, он может легко стать беспорядочным (возможно, не реализуемым).
Я предлагаю хранить ключевые слова в дереве (который использует избыточность) и более эффективен в пространстве.
Если ключевые слова ["art,"at","atm","bus","can","car"], словарь выглядит следующим образом:
.
^
/ ¦ \
/ ¦ \
a b c
^ ^ ^
/ \ \ \
r t u a
^ ^ ^ ^
/ / \ \ / \
t m /0 s n r
^ ^ ^ ^ ^
/ / \ \ \
/0 /0 /0 /0 /0
Я сделал его двоичным, поскольку его было легче рисовать. Узел "/0" имеет значение конца слова (виртуальный символ), а "." является корнем.
Я реализовал этот простой класс дерева для построения дерева и необходимых функций
class Tree(object):
def __init__(self, name='root', children=None):
self.name = name
self.children = {}
if children is not None:
for child in children:
self.add_child(child.name,child)
def __repr__(self):
return self.name
def add_child(self, node):
assert isinstance(node, Tree)
self.children[node.name] = node
def has_child(self,name):
return name in self.children
def get_child(self,name):
return self.children[name]
def print_tree(self,level=0):
sys.stdout.write('-' * level)
print self.name
for childTag in self.children:
self.children[childTag].print_tree(level+1)
С учетом ключевых слов мы можем построить структуру с использованием кода, подобного этому
keywords = ["car","at","atm","bus"]
keywordsTree = Tree('')
for keyword in keywords:
keywordsTreeNode = keywordsTree
for character in keyword:
if not keywordsTreeNode.has_child(character):
keywordsTreeNode.add_child(Tree(character))
keywordsTreeNode = keywordsTreeNode.get_child(character)
keywordsTreeNode.add_child(Tree('/0'))
. Наконец, мы ищем вход для ключевых слов. Ниже приведенное решение предлагает для данной позиции во вводе все ключевые слова, совпадающие с этой позиции.
inputWords = "xyzcarbusabccar8hj/0atm"
output = []
lengthInput = len(inputWords)
for position in range(0,lengthInput):
##add by default the character
# allMathcedKeyWords = [inputWords[position]]
allMathcedKeyWords = []
keywordsTreeNode = keywordsTree
searchPosition = position
curMathcedWord = ''
while searchPosition < lengthInput and keywordsTreeNode.has_child(inputWords[searchPosition]) :
keywordsTreeNode = keywordsTreeNode.get_child(inputWords[searchPosition])
curMathcedWord = curMathcedWord + inputWords[searchPosition]
if (keywordsTreeNode.has_child("/0")):
allMathcedKeyWords.append(curMathcedWord)
searchPosition += 1
if len(allMathcedKeyWords)==0:
allMathcedKeyWords = inputWords[position]
output.append(allMathcedKeyWords)
print output
Этот код выводит этот
['x', 'y', 'z',
['car'],
'a', 'r',
['bus'],
'u', 's', 'a', 'b', 'c',
['car'],
'a', 'r', '8', 'h', 'j', '/', '0',
['at', 'atm'],
't', 'm']
Важно для кода выше заключается в том, что виртуальный символ в конце слов - это две буквы ("/0") и никогда не будет согласован (даже если комбинация появится во входной последовательности, как описано выше). Кроме того, он обрабатывает любой строковый символ (для ввода и ключевых слов - также не нужно вводить escape-символы, как в re.findall())
Из этого выходного списка вы можете решить, что вы хотите сделать. Если вы хотите, чтобы решение re.findall находило самое длинное совпадающее слово для позиции (или на основе логического порядка слов) и перескакивало вперед количество символов, содержащее это слово.
Принимая эту проблему еще дальше, каждый символ на входе - это вершина, и когда вы найдете слово, добавьте ребро из этой позиции в соответствующую следующую вершину после последнего символа совпадающего слова. Алгоритм кратчайшего пути даст вам снова решение выше.
Пример: с ключевыми словами "car" и "art", а также с художественной и входной последовательностью "acart" результирующие графики выглядят следующим образом:
______________
¦ ¦
- a -> c -> a -> r -> t ->
¦______________¦
Анализ сложности
Space : longest_word_length * number_of_letters_in_keywords
input_length + input_length * input_length (worst case-fully connected graph)
Time : input_length * longest_word_length
input_length + input_length * input_length (worst case-fully connected graph)
11 ответов
Можно использовать различные способы обработать эту ситуацию, в зависимости от системы управления исходным кодом.
Частные ответвления: Позвольте Вам регистрироваться и работать над кодом, в то время как Вы идете, объединяясь назад и вперед в подходящее время.
Shelvesets/pacakaged changesets: Позвольте Вам хранить changesets и отправлять их вокруг за обзором - обеспечение, они - производство, готовое перед регистрацией.
Относительно того, является ли это соответствующим способом работать, мы не позволяем регистрацию основным ответвлениям без предшествующего обзора. Для передачи обзора код должен передать различные автоматизированные инструменты и затем должен быть приемлем для рецензента однорангового узла. Для некоторых определений "производства, готового" - это - это. Поэтому мы делаем что-то как то, что Вы делаете. Однако мы используем частные ответвления, чтобы гарантировать, что регистрации могут все еще быть сделаны, в то время как это происходит, и что другие регистрации не должны вмешиваться.
Если производство готовые средства, протестированные в среде интеграции, то это походит на Вас, возможно, нуждается в ответвлениях подготовки или чем-то подобном.
Код, в котором регистрируются, должен быть протестированной единицей, но, мне, "производство, готовое", подразумевает, что прошло интеграционное тестирование и тестирование системы. Вы не можете сделать этого до замораживания кода, таким образом, я не вижу, как можно сделать это перед каждой регистрацией.
разве это не была бы хорошая идея иметь ответвление тестирования repo, который может иметь не "производство готовый код, в котором" зарегистрировались после того, как изменения сделаны и протестированы?
основная соединительная линия никогда не должна иметь кода, зарегистрировался, который повреждает сборку и не передает модульные тесты, но ответвления не должны иметь в распоряжении все те ограничения.
Запустите путем переключения далеко от VSS до чего-то более надежного и многофункционального. Посмотрите, Как убедить компанию переключать их Управление исходным кодом
Затем подайте заявку известный - хорошие методы:
- Регистрация часто
- Берите изменения других часто, для упрощения слияния
- Используйте быстрые модульные тесты, чтобы удостовериться, что каждое изменение встречает минимальную панель
- Потребуйте, чтобы это зарегистрированный код всегда создавало и всегда проходило тесты.
Теперь Вы не будете "производством, готовым" в этой точке: Вам будет все еще требоваться пару недель, чтобы протестировать и зафиксировать, прежде чем можно будет развернуться. Снижение того времени является потрясающим для Вас и потрясающим для Вашего клиента, поэтому вложите капитал в:
- Высокое качество автоматизировало приемочные испытания.
Я лично не одобрил бы это, потому что иногда это - лучший способ поймать проблемный код с менее опытными разработчиками (путем наблюдения его, поскольку они работают над ним), и когда Вы "регистрируетесь рано и часто" можно откатывать к более ранним изменениям, которые Вы внесли (поскольку Вы разрабатывали), если Вы решаете, что некоторые изменения, которые Вы внесли ранее, были на самом деле лучшей идеей.
Я думаю, что это может быть управление версиями мы пользователь, VSS в сочетании с отсутствием времени для изучения ветвления. Мне действительно нравится, когда идея ночной проверки ins помогает с разработкой и старается не 'Идти Темный'. Я вижу, что он является стойким к соединительным линиям, но возможно создать разработку SS и когда код является производством готовое перемещение он к производству SS.
Регистрация рано и регистрация часто по двум главным причинам -
1 - это могло бы помочь интегрировать код
2 - в случае, если Ваш компьютер взрывается, Ваши недели работы не не стал
Предположение, что Вы работаете в централизованной системе управления версиями (такой как Подверсия) и предполагаете, что у Вас есть понятие "соединительной линии" (где последний хорошо рабочий код живет):
Если Вы работаете над новыми возможностями в "ответвлениях функций" / "экспериментальные ответвления", то нормально фиксировать код, который совсем не закончен. (Когда функция сделана, Вы фиксируете хорошо ведущий себя результат в "соединительную линию".)
Но Вы не выиграете конкурс популярности при фиксации non-compiling/obviously нерабочего кода в "соединительную линию" или "ответвление выпуска".
У Прагматически настроенных Программистов есть книга под названием Прагматическое Управление версиями с помощью Подверсии, которая включает раздел с советом об ответвлениях.
От методов я видел, что производственное качество термина используется в качестве 'frightener', чтобы гарантировать, что люди боятся повреждения вершины дерева, не плохой вещи быть честными, потому что вершина дерева должна всегда работать, если это возможно.
Я сказал бы, что лучшая практика - то, что необходимо только объединяться отличный (т.е. отдельные) функциональные компоненты на вершине дерева. Если у Вас есть значительное перекрытие на дельтах к тем же исходным файлам, я думаю, что это 'могло' бы указать, что где-нибудь вдоль строки управление проектами потерпело неудачу, и что те разработчики должны были объединить свои изменения для разделения ответвления интеграции перед входом к основным источникам строки. Отдельный разработчик, говорящий, что они единица протестировали свой материал, не важен, потому что вещь, которую они протестировали, изменилась!
Попытка решить проблемы интеграции на Вашей основной строке кода строки неизбежно остановит другие несвязанные представления.
Подход, который я особенно люблю, должен иметь различные версии жизненного цикла в складе. Таким образом, например, имейте dev версию кода, который является, где разработчики регистрируются в коде, который находится в том, чтобы быть работавшимся на; затем у Вас могла быть бета-версия, где Вы могли добавить, что бета прикрепляет к Вашему коду; и затем производственная версия.
Существует очевиден служебный в этом подходе, таком как то, что у Вас будет большая рабочая область на Вас локальной машиной, то, что Вам будет нужно, должно иметь процесс миграции в место для перемещения кода от одного этапа до следующего (что означает замораживание кода при выполнении интеграционного тестирования, которое идет с миграцией), и что в зависимости от сложности проекта (проектов) Вы, возможно, должны были бы иметь инструменты, которые изменяют настройки, переменные среды, ключи реестра, и т.д.
Все это - боль для установки, но Вы только делаете это однажды, и после того как Вы имеете в распоряжении все это, делает работу над различными этапами кода бризом.
@bpapa
Ночные резервные копии папок работы к серверам предотвратят потерю больше чем дневной работы.
@tonyo
Давайте посмотрим, что документы требования были завершены на следующий день после того, как мы закончили кодировать. Это говорит Вам о нашем управлении проектами?
Мы - небольшой магазин поэтому, в то время как Вы думали бы, что изменение легко существуют некоторые здесь, которые несгибаемы к старым путям.