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

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

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

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

ОТВЕТЫ

Ответ 1

Сложный вопрос:

  • Некоторые части кода могут быть обобщены как библиотеки или API. У нас есть общая библиотека, которая постоянно обновляется с решениями общих проблем. Обычно: проверка, кеширование, классы доступа к данным, ведение журнала и т.д.

  • Некоторые части являются специфичными для приложения. Они не могут быть легко обобщены. Мы конвертируем их в HowTos и даем внутренние презентации. Код также перерабатывается с помощью легко просматриваемого SCM (в нашем случае SVN).

  • У нас также есть инструменты, которые генерируют код, который одна рука не может быть переработана, а с другой - всегда схожи (подумайте, чтобы вызвать хранимую процедуру).

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

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

Ответ 2

Рефтор безжалостно и надеемся на лучшее.

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

  • Как и комментарий С.Лотта говорит: Обратите внимание на Именование. Распространите слово всем "коммиттерам" в команде. Хорошие имена делают вещи доступными для поиска и тем самым уменьшают дублирование.
  • У вас есть один способ сделать что-то и сохранить его ДОСТУПНЫМ И ПОИСКОМ.
  • Введите код для среднего программиста (L.C.D.). Не будьте умны, где простого будет достаточно. (Это включает в себя дизайн-образцовое прикосновение к ужасу и связанные с ним расстройства).
  • Принять общий набор условностей, стилей, руководств, стандартов, et.all раньше. Обеспечьте бай-ин и тем самым соблюдение в команде. (Это означает, что каждый использует вкладки (или пробелы)!). Неважно, что вы выбираете - цель состоит в том, чтобы код выглядел последовательным.
  • Имейте привратника (уважаемого командой), который видит все отметки для красных флагов.
  • Введите код test-first/outside-in. Обычно это гарантирует, что ваш код можно использовать несколькими клиентами. (См. Марку GOOS о независимости контекста)

Ответ 3

  • Поддерживайте активную поддержку.

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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