В не очень маленькой программе, когда у вас мало таких объектов, чтобы сохранить читаемость кода, общие термины и иным образом улучшить взаимопонимание между членами команды, нужно определить и поддерживать программный словарь ,Как вы поддерживаете словарный запас программы?
Как вы (или ваша компания) справляетесь с этой задачей, какая у вас дисциплина, какие меры вы вводите?
Большинство проектов разумного размера должны иметь документ стандартов для программирования/кодирования, который диктует общие соглашения и принципы наименования, которые должны соблюдаться.
Другой способ помочь с помощью обзоров кода. Очевидно, что требуется некоторая координация между рецензентами (документ также помогает в этом). Кодовые обзоры помогают сохранить более зрелые разработчики и старшие разработчики на ходу и выступать в качестве проспекта для обеспечения соблюдения стандартов кодирования.
Разделите свои пакеты/модули на логические группы и используйте описательные и сжатые имена. Избегайте общих имен, кроме случаев, когда они действительно являются счетчиками и т. Д. Создавайте соглашения для групп функций или функциональности и придерживайтесь их.
Проект, ориентированный на домен, интересен здесь, поскольку он побуждает программистов охватить словарь терминов. Кроме того, существуют некоторые соглашения по дизайну, которые позволяют вам ссылаться на части вашего приложения, используя известные термины, такие как службы, хранилища, фабрики и т. Д.
Сочетание словаря терминов и использования технических соглашений, приведенных выше, может быть хорошее решение.
Моя команда хранит эту информацию (условные обозначения/словарный запас и т. Д.) На вики. Это позволяет легко обновляться и делиться.
@Ilya Рыженков,
Боюсь, большинство компаний не имеют такой практики :) Я работал в не столь небольшой компании с многомиллионными LOC кодовой базы, и они не имеют какой-либо документация вообще (помимо общей директивы кодирования)
В одном из моих проектов мы поддерживали тезаурус общих терминов, используемых в нашем домене приложения, и использовали его во время обзора кода. Я время от времени анализировал документацию .NET XML diff, чтобы решить, какие сущности \ термины должны быть добавлены в тезаурус. Единственным средством обеспечения соблюдения тезауруса было руководство по кодированию.
Wiki подход оказался неприменим, потому что никто не заботится, чтобы регулярно обновлять его :)
мне интересно, какие методы вы используете в JetBrains? Я проверил код ReSharper в Reflector и был поражен количеством и названиями объектов :)
Вопрос был «HOw» не «WHAT» – 2008-09-21 21:10:26
Возможно, уточните в вопросе? Вы спросили, как, и Майкл сказал со стандартным документом. – 2008-09-21 21:12:27
Уильям, так что вы думаете, что просто наличие «стандартного» документа сделает программный словарь незаменимым? – 2008-09-21 21:15:15