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

Question

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

Рефакторите безжалостно и надейтесь на лучшее.

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

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

Answer 3

• Иметь структуру, которая активно поддерживается.

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

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

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

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

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

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

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

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

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