Какие методы вы используете для максимального повторного использования кода?

рефакторинг беспощадно и надеюсь на лучшее.

обновление (4 года спустя и, надеюсь, мудрее)

• как Комментарий С. Лотта говорит: Обратите внимание на именование. Расскажите всем 'исполнители' в команде. Хорошие имена делают вещи доступными для поиска и тем самым уменьшают дублирование.
• есть один способ сделать что-то и сохранить его доступным и доступным для поиска.
• написать код для среднего (К. Л. Д.) программист.. Не умничай, где достаточно просто. (Это включает в себя Дизайн-Шаблон обуви-Хорнинг принуждение и связанные с ним расстройства)
• принять общий набор соглашений, стилей, стандартов, ДВ.все рано. Обеспечьте бай-ин и тем самым соответствие внутри команды. (Это означает, что все используют вкладки (или пробелы)!). Неважно, что вы выбираете - цель состоит в том, чтобы код выглядел согласованным
• есть привратник (уважаемый командой), который следит за всеми регистрациями красный флаг.
• напишите тест кода-сперва / снаружи-внутри. Обычно это гарантирует, что ваш код может использоваться несколькими клиентами. (См. пули ГСНО в контексте независимости)

• есть фреймворк, который активно поддерживается.

• знать существующую базу кода / заставить других разработчиков знать базу кода. Если ваша группа / компания достаточно велика, попросите кого-нибудь, кто знает кодовую базу и может попросить руководства.

• документ, документ, документ. Недокументированный код бесполезен для повторного использования, потому что для понимания его внутренней работы требуется слишком много времени.

• хорошие межфазные границы. Легкие типы, легкие структуры или классы. Чем сложнее что-то, тем меньше оно будет использоваться в другом проекте.

• оптимизация и отладка кода для повторного использования. Разработчики, которые испытывают ошибки в чужом коде в n-й раз, начнут кодировать уже существующий код заново.

попробуйте использовать TDD Если вы еще не являетесь моим первоначальным повторением.

Я думаю, что использование TDD-отличный способ сохранить соединение кода низким, среди других преимуществ. Хотя это по своей сути не препятствует тому, чтобы одно и то же поведение реализовывалось дважды, это делает его намного проще, когда вы определяете область, в которой вы можете удалить дублирование.

другое преимущество, TDD имеет шаг для удаления dupication (рефакторинга) в рамках ездить на велосипеде.

кроме того, тесты являются частью документации по кодам, что облегчает идентификацию дублированного поведения.

организация является ключевым фактором. Если пространства имен и intellisense доступны, правильная функция может быть сужена и в конечном итоге найдена. Если они не найдут то, что им нужно, они могут найти что-то близкое или связанные. Код, который просто смешивается в одну огромную группу, позволяет легко найти, но люди никогда не найдут метод, который они хотят достаточно быстро.

согласованность также имеет решающее значение, как с именованием, так и с местоположением. Если вы решили изменить свой стиль в какой-то момент во время проекта вернитесь и измените все, чтобы соответствовать этому стилю. Это может быть очень долгий и скучный процесс, но это лучше, чем пытаться использовать непоследовательную библиотеку.

профиль всего приложения и начать рефакторинг из более тяжелого раздела кода. (80% времени, затраченного на 20% наиболее часто используемого кода)

используйте инструмент профилирования, который имеет возможность идентифицировать утечки памяти, повторные вызовы, длительные вызовы, несвободная память,неиспользуемые ресурсы и т. д.

по правилу новый код всегда использует наилучшую практику.

Как вы (граждан и организаций) Управление источник его легче повторно использовать? Вы специально поддерживаете библиотеку повторного использования? И если да, то как вы индексируете его, чтобы максимизировать скорость попадания?

У меня нет, и у меня есть, по общему признанию, спорное мнение здесь, но я нахожу идею максимизации повторного использования кода контрпродуктивной (я интерпретирую "максимизацию" как приоритизацию его над всеми другими вещами, а не рассматриваю его как имеющий как плюсы, так и минусы сбалансировать в рассмотрении). Я предпочитаю вместо этого позволить здоровому количеству избыточных усилий в командах скользить в пользу развязки и изоляции модуля каждого разработчика лучше. Во-первых, прежде чем все начнут не соглашаться со мной слева и справа, я думаю, мы можем договориться о некоторых вещах:

1. повторное использование кода багги, который заставит вас тратить часы на отладку кода других людей, нежелательно.
2. повторное использование кода, который балансирует такой широкий спектр разрозненных потребностей, что он с трудом удовлетворяет свои потребности и требует от вас, чтобы прыгать через много обручи, чтобы в конечном итоге получить неудобное и неэффективное решение нежелательно.
3. повторное использование кода, который постоянно требует изменений в дизайне и проходит через устаревания рода, который потребует от вас переписать код, используя его каждые 6 месяцев нежелательно, если вы могли бы просто реализовать решение самостоятельно в течение получаса способами, которые не нуждаются в изменениях дизайна в будущем, так как это только служит вашей точные потребности.
4. кодовая база, заполненная чужеродным кодом, нежелательна по сравнению с той, которая использует больше языка и стандартной библиотеки идиоматическими и знакомыми способами, даже если для этого требуется немного больше кода.
5. разработчики переступают через пальцы друг друга, потому что оба они хотят внести несовместимые изменения в один и тот же дизайн, сражаясь и споря и внося изменения, которые вызывают ошибки в реализациях друг друга, нежелательно.
6. бросать boatload зависимостей к незрелым конструкциям которые не доказывали (не имели тщательный охват испытания, не имели время реально звукоизоляционный дизайн и убеждаться что он эффектно удовлетворяет потребностямы потребителя-конца без требовать более дополнительных изменений дизайна) нежелателен.
7. включать / импортировать/связывать лодку библиотек и классов / функций с самым сложным скриптом сборки, чтобы написать что-то простое, нежелательно.
8. больше всего, повторно используя код таким образом, что стоит гораздо больше времени как в краткосрочной, так и в долгосрочной перспективе, чем не использовать его повторно нежелательно.

надеюсь, мы можем согласиться на эти точки. Проблема, которую я обнаружил в максимальном повторном использовании кода от чрезмерно увлеченных коллег, заключалась в том, что это часто приводило к одной или нескольким из вышеперечисленных проблем. Фундаментальной проблемой был не энтузиазм по поводу повторного использования кода, а то, что приоритеты были смещены в сторону повторного использования кода, а не тестового покрытия, звукоизоляции, убедиться, что вещи достаточно зрелые, прежде чем мы будем использовать их как сумасшедшие, и так далее.

естественно, если бы весь код, который мы повторно использовали, работал красиво, имел тщательный тестовый охват, был доказан, чтобы удовлетворить потребности всего, используя его способами, которые были гораздо более продуктивными, чем не использовать его повторно, и не пришлось бы проходить какие-либо изменения дизайна в течение многих лет подряд, я был бы в восторге от повторного использования кода. Но мой опыт часто обнаруживал, что вещи далеко не дотягивают до этого идеала способами повторного использования кода возможно, это становилось проблемой обслуживания, а не решением.

Как вы (граждан и организаций) Управление источник его легче повторно использовать? Вы специально поддерживаете библиотеку повторного использования? И если да, то как вы индексируете его, чтобы максимизировать скорость попадания?

Итак, снова я не стремлюсь "максимизировать" повторное использование кода среди проприетарного кода, написанного внутри команды. Я стремлюсь к тому, чтобы команда не тратила огромное количество времени при избыточных усилиях, но я позволяю вещам скользить совсем немного, если и физики, и ребята рендеринга реализуют свой собственный выровненный по оси класс ограничивающей рамки, например, это не обязательно даже это избыточно, так как физик может использовать представления min/max, которые более эффективны для его цели, в то время как разработчик рендеринга может использовать представления Центра/половины размера. Я пытаюсь убедиться, что мы используем как можно больше стандартной библиотеки, когда это возможно, потому что это повторное использование кода практически гарантировано быть твердым, ультра-хорошо протестированным и не требовать дальнейших изменений дизайна (другие команды тратят кучу своего времени, чтобы убедиться в этом).

вместо этого я переключаю внимание на тестирование. Модуль, дублирующий немного кода здесь и там, совершенно прекрасен, если вы спросите меня, работает ли он красиво так, что пользователи действительно счастливы, имеет тщательный тестовый охват и не требует бесконечных изменений. Мы принимаем такое дублирование все время, когда мы используем третий партийные библиотеки, которые, вероятно, дублируют некоторый код, который мы также имеем в нашей внутренней кодовой базе. Это не проблема, когда избыточность не приводит к избыточным усилиям по обслуживанию.

поэтому я предлагаю просто немного ослабить идею максимального повторного использования кода. Но если вы хотите максимально упростить повторное использование действительно твердого, хорошо протестированного, нетривиального кода, то я нашел гораздо более полезным организовать библиотеки очень особого назначения, такие как" математическая "библиотека," изображение" обрабатывать библиотеку, etc. -- вместо того, чтобы пытаться объединить их во что-то вроде "ядра" или "общего". Последние типы, как правило, соблазняют разработчиков бросать все виды эклектичных функций полезности, которые едва приносят пользу команде, использующей их, и в основном это имеет тенденцию становиться грязным способом, когда становится трудно найти что-либо интересное.