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

Пару лет назад в СМИ было много всяких статей о том, как идея повторного использования кода является простым способом повышения производительности и качества кода.

Из блогов и сайтов, которые я регулярно проверяю, кажется, что идея «повторного использования кода» вышла из моды. Возможно, все сторонники «повторного использования кода» присоединились к SOA-толпе? :-)

Интересно, что при поиске «повторного использования кода» в Google второй результат называется:

«Повторное использование внутреннего кода считается опасным»!

Для меня идея повторного использования кода - это просто здравый смысл, в конце концов, посмотрите на успех проекта Apache Commons!

То, что я хочу знать, это:

  • Вы или ваша компания пытаетесь повторно использовать код?
  • Если да, то как и на каком уровне, т.е. API низкого уровня, компоненты или общая бизнес-логика? Как вы или ваша компания повторно используете код?
  • Это работает?

Обсудить?


Я полностью осознаю, что существует много доступных библиотек с открытым исходным кодом и что любой, кто использовал .NET или Java, повторно использовал код в той или иной форме. Это здравый смысл!

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

Я изначально спросил;

  • Вы или ваша компания пытаетесь повторно использовать код?
  • Если да, то как и на каком уровне, т.е. API низкого уровня, компоненты или общая бизнес-логика? Как вы или ваша компания повторно используете код?

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

Если у вас есть фрагмент кода, который потенциально может быть распространен среди организаций среднего размера, как бы вы сообщили другим членам компании, что этот lib / api / etc существует и может быть полезным?

10.12.2008 14:37:25
16 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

10
10.12.2008 14:50:58
«Название статьи, на которую вы ссылаетесь ...» Я не имел в виду что-то конкретное, это звучало как колокольчик с тем, что вы читали раньше? Карл
Karl 10.12.2008 14:59:41
Второй результат вы увидели в гугле. «Повторное использование внутреннего кода считается опасным». Это документ, который я прочитал некоторое время назад.
Joseph Ferris 10.12.2008 15:45:26
Для тех, кто заинтересован, вот ссылка на Интернет-архив (относительно короткая) ссылочная статья (я думаю).
martineau 18.02.2020 20:18:39

Мы повторно используем код.

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

Обычно код разрабатывается для одного приложения. И если он достаточно универсален, он продвигается в библиотеку. Это работает отлично.

1
10.12.2008 14:41:46

Я думаю, что повторное использование кода в основном осуществляется через проекты с открытым исходным кодом. Все, что может быть повторно использовано или расширено, делается через библиотеки. У Java есть удивительное количество библиотек с открытым исходным кодом, доступных для выполнения большого количества вещей. Сравните это с C ++, и как рано все должно быть реализовано с нуля с использованием MFC или Win32 API.

2
10.12.2008 14:45:32

Идея повторного использования кода больше не является новой идеей ... отсюда и явное отсутствие интереса. Но это все еще очень хорошая идея. Вся платформа .NET и Java API являются хорошими примерами повторного использования кода в действии.

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

1
10.12.2008 14:46:04

Конечно, мы повторно используем код.

Существует почти бесконечное количество пакетов, библиотек и общих объектов, доступных для всех языков, с целым сообществом разработчиков, поддерживающим их поддержку и обновление.

1
10.12.2008 14:46:16

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

1
10.12.2008 14:57:13

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

3
10.12.2008 15:09:51
«... каждая библиотека более низкого уровня, которую вы пишете, должна иметь возможность адаптироваться к новому набору требований для другого приложения» Скажем, например, что вы пишете низкоуровневую библиотеку JMS и хотите поделиться ею с сообществом, как бы вы поступили? делиться этим? Его вряд ли найдут на вашем личном сайте.
Karl 10.12.2008 15:19:11
Для этого доступно множество сайтов, приложений и сервисов.
hmcclungiii 15.12.2008 21:29:45

Хотя я думаю, что повторное использование кода является ценным, я могу видеть, где укоренилось это мнение. Я работал над многими проектами, в которых много внимания уделялось созданию кода многократного использования, который затем никогда не использовался повторно. Конечно, повторное использование гораздо предпочтительнее дублирования кода, но я видел множество очень расширенных объектных моделей, созданных с целью использования объектов в рамках предприятия в нескольких проектах (таким образом, один и тот же сервис в SOA может использоваться в разных приложения), но никогда не видел, чтобы объекты использовались более одного раза. Может быть, я просто не был частью организаций, которые хорошо использовали принцип повторного использования.

0
10.12.2008 15:21:36

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

Кажется, что степень повторного использования кода A для создания кода B часто основана на том, насколько идеи в коде A, взятые для кода B, абстрагированы в шаблоны проектирования / идиомы / книги / мимолетные мысли / реальный код / ​​библиотеки. Сложная часть заключается в применении всех этих хороших идей к вашему действительному коду.

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

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

0
10.12.2008 15:29:04

Два программных проекта, над которыми я работал, были долгосрочными разработками. Одному из них около 10 лет, другому уже более 30 лет, переписанный в нескольких версиях Фортрана. Оба делают многократное использование кода, но оба очень мало полагаются на внешние инструменты или библиотеки кода. DRY - это большая мантра для нового проекта, который находится на C ++ и легче поддается выполнению этого на практике.

0
10.12.2008 15:26:13

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

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

Для эффективного повторного использования кода необходимы следующие вещи:

  • Код или сама библиотека
  • Спрос на код в нескольких проектах или усилиях
  • Передача функций / возможностей кода
  • Инструкция по использованию кода
  • Обязательство поддерживать и улучшать код с течением времени
5
10.12.2008 15:42:48

Уровень внимания СМИ к проблеме имеет мало общего с ее важностью, говорим ли мы о разработке программного обеспечения или о политике! Важно не тратить впустую усилия на разработку, заново изобретая (или повторно поддерживая!) Колесо, но сейчас это настолько хорошо известно, что редактор, вероятно, не будет в восторге от другой статьи на эту тему.

Вместо того, чтобы рассматривать количество текущих статей и постов в блоге как меру важности (или срочности), взгляните на концепции и умные фразы, которые стали классикой или вошли в жаргон (еще одна форма повторного использования!) Например, Google для использования СУХОЙ аббревиатуры для хорошего обсуждения многих форм избыточности, которые могут быть устранены в программном обеспечении и процессах разработки.

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

1
11.12.2008 13:15:53

Maven решил повторное использование кода. Я полностью серьезен.

-1
25.12.2008 08:36:47
Maven позволяет довольно просто описывать зависимости между программными элементами, но вы все равно должны знать о дублировании кода в том, что вы пишете.
Kwebble 17.11.2009 14:57:18

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

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

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

Решение заключается в следующем:
1. Разработать и написать код не только с учетом одного проекта, но и подумать о будущих требованиях и попытаться сделать проект достаточно гибким, чтобы покрыть их с минимальными изменениями кода.
2. Заключить код в библиотеки, которые должны использоваться как есть, а не изменяться в рамках проектов.
3. Позволить пользователям просматривать и изменять код библиотеки в рамках своего решения (не в рамках используемого решения проекта).
4. Разработать будущие проекты на основе существующих инфраструктур, внося изменения в инфраструктуру по мере необходимости.
5. Взять на себя ответственность за поддержание инфраструктуры для всех проектов, поддерживая тем самым финансирование инфраструктуры.

0
7.02.2009 14:11:34

Мой личный взгляд, основанный на практике в моей компании:

  • Вы или ваша компания пытаетесь повторно использовать код?

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

  • Если да, то как и на каком уровне, т.е. API низкого уровня, компоненты или общая бизнес-логика? Как вы или ваша компания повторно используете код?

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

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

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

  • Это работает?

Да, но не из-за потенциального или фактического повторного использования! На самом деле, за исключением нескольких базовых библиотек и компонентов пользовательского интерфейса, повторного использования не так много.

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

1
30.07.2009 11:41:23

Вы или ваша компания пытаетесь повторно использовать код? Если да, то как и на каком уровне, т.е. API низкого уровня, компоненты или общая бизнес-логика? Как вы или ваша компания повторно используете код?

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

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

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

Уравновешивание потребностей каждого

При проектировании этих обобщенно-обобщенных библиотек я обнаружил, что должен быть одержим потребностями каждого члена команды, и мне нужно было узнать, как работает трассировка лучей, как работает динамика жидкостей, как работает механизм ячеистой сети, как работает обратная кинематика, как анимация персонажей работала и т. д. и т. д. и т. п. Мне нужно было научиться выполнять почти все в команде, потому что я уравновешивал все их специфические потребности в дизайне этих обобщенных обобщенных библиотек, которые я оставил позади, когда шел по уравновешивающему балансу компромиссов в дизайне из-за повторного использования кода (пытаясь улучшить ситуацию для Боба, работающего над raytracing, который использует одну из библиотек, но не причиняя особого вреда Джону, который работает над физикой, который также использует его, но не усложняя дизайн библиотеки слишком много, чтобы сделать их обоих счастливыми).

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

Дизайн Комитетом

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

Я думаю, что вы можете поделиться большим количеством кода в команде единомышленников. Наши совсем не были единомышленниками. Это не настоящие имена, но я хотел бы, чтобы здесь был Билл, который является высокоуровневым программистом с графическим интерфейсом и сценаристом, который создает приятные пользовательские проекты, но сомнительный код с большим количеством взломов, но для этого типа кода это нормально. У меня здесь есть Боб, старый таймер, который программировал со времен эры перфокарт, который любит писать 10 000 строковых функций с гото в них и до сих пор не понимает суть объектно-ориентированного программирования. У меня есть Джо, который похож на математического мастера, но пишет код, который никто другой не может понять, и всегда делает предложения, которые математически выровнены, но не обязательно настолько эффективны с вычислительной точки зрения.

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

Компромиссы

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

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

Если у вас есть фрагмент кода, который потенциально может быть распространен среди организаций среднего размера, как бы вы сообщили другим членам компании, что этот lib / api / etc существует и может быть полезным?

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

В противном случае это может вызвать больше горя, чем на самом деле спасает.

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

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

Поэтому в эти дни я перенес свою нетерпимость в сторону отсутствия тестирования. Вместо того, чтобы расстраиваться из-за лишних усилий, я считаю гораздо более продуктивным расстраиваться из-за отсутствия у других пользователей модульного и интеграционного тестирования! :-D

0
5.02.2018 07:26:17