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

Ответ 1

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

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

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

Ответ 2

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

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

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

• Сам код или библиотека
• Требование для кода через несколько проектов или усилий.
• Коммуникация функций/возможностей кода
• Инструкции по использованию кода
• Обязательство поддерживать и улучшать код с течением времени

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

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

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

Ответ 10

Мое личное мнение, основанное на практике в моей компании:

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

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

• Если да, то каким образом и на каком уровне, то есть на уровне api, компонентах или общей бизнес-логике? Как вы или код своей компании повторно используете?

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

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

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

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

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

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

Ответ 11

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

Ответ 12

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

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

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

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

Ответ 13

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

Ответ 14

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

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

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

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

Ответ 15

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

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

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

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

Балансирование потребностей всех

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

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

Дизайн по комитету

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

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

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

Компромиссы

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

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

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

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

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

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

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

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

Ответ 16

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