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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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