Следует ли ожидать, что разработчики скомпилируют внутреннюю библиотеку перед самой программой?

10

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

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

rjzii
источник

Ответы:

15

Этот аргумент старшего разработчика не имеет смысла для меня.

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

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

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

17 из 26
источник
Во-вторых, вы должны легко получить исходный код используемой вами версии библиотеки. С какой стати вам нужна «окончательная версия» библиотеки? Это просто добавляет потенциальную энтропию в проект ..
jlemos
1
Я согласен только частично. ИМХО это зависит от политики разработки для lib. Если библиотека активно разрабатывается второй командой, вы на 100% правы. Если библиотека может быть изменена кем-либо из текущей команды И если политика гласит, что библиотека должна быть обратно совместима каким-либо образом, то использование всегда самой новой версии помогает быстрее выявлять проблемы интеграции, что хорошо.
Док Браун
Док Браун - согласен. Мой ответ был основан на том факте, что вопрос был сформулирован так, что единственная причина, по которой требовалась get & compile, заключалась в том, чтобы разработчики могли читать исходный код.
17 из 26
4

Предложение

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

Вы могли бы сделать альтернативное предложение

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

MarkJ
источник
Это было опробовано, и аргумент состоял в том, что разработчики библиотеки были слишком заняты добавлением новых функций.
rjzii
2
Думаю, ты мог бы сказать это. Предположительно библиотека существует, чтобы помочь разработчикам на стороне клиента , и не является ли это самоцелью? Тем не менее, я ценю, что вы, возможно, не имеете политической власти (влияния на менеджеров, клиентов или старших разработчиков), чтобы заставить разработчиков библиотеки справиться со своими обязанностями. Возможно, разработчик на стороне клиента мог бы документировать библиотеку? Запустите вики и создайте документацию по мере необходимости? Может потребовать некоторого чтения исходного кода, но не требует постоянной компиляции последней версии.
MarkJ
3

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

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

TMN
источник
1

Раньше я работал в крупной софтверной компании, которая постоянно «поддерживала» свое собственное программное обеспечение внутренними бизнес-системами.

Они видели это как еще один уровень тестирования.

Я согласен с тем, что для компании это хорошая вещь.

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

Ozz
источник
Он развернут как часть продуктов; однако я пытаюсь решить эту проблему с двух сторон: разработчики, работающие на своих машинах, и серверы непрерывной интеграции.
rjzii
1

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

В настоящее время я работаю над проектом, который не подключен к агенту сборки, который требует создания подпрограммы перед сборкой основного приложения. Это серьезная боль в моей задней части; Чтобы внести изменения во вложенное приложение, я должен сначала собрать весь проект, затем перейти в папку вспомогательной сборки, извлечь из него скомпилированный продукт и скопировать его в другую подпапку, прежде чем собирать весь проект СНОВА. убедиться, что последняя версия вспомогательного приложения включена в сборку основного приложения. Это НЕ так, как это должно быть сделано; по крайней мере, должен быть скрипт MSBuild, который автоматизирует этот процесс, и я бы предпочел, чтобы агент сборки обновлял внешние компоненты всякий раз, когда новый код фиксируется в транке.

Keiths
источник
1

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

  1. Вы часто используете библиотеку и нет документации. Таким образом, каждый должен иметь источник для справки. Если это библиотека, которая используется очень часто, полезно иметь справку

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

    • Это может произойти из-за того, что многие библиотеки далеки от совершенства, и хотя мы все хотим работать со «стабильным» выпуском, все же могут возникнуть проблемы.
    • Возможно, вы получаете плохие результаты из-за неправильного понимания того, как следует использовать API. Даже с документацией люди часто делают неправильные предположения
    • Ваш старший парень, вероятно, устал от новых людей (и иногда гораздо больше новых людей, чем тех, кто знает проект изнутри и снаружи), бросающих руки в воздух всякий раз, когда происходит сбой / какая-то другая ошибка из библиотечного кода. Поэтому вместо того, чтобы приходить к вашей машине, а затем к парню, сидящему рядом с вами, они хотят ответить на следующие вопросы: 1) где именно происходит сбой? какой модуль / файл / строка? 2) вы это отладили? что вы нашли?
    • Ваши старшие ребята работали с этой базой кода (приложением и вашей основной библиотекой) достаточно долго, и, возможно, он мог заметить, что когда код уже находится на компьютере и готов к отладке и прохождению, это облегчает его жизнь и помогает людям изучить базу кода быстрее. Поэтому по этой причине он заставляет вас взять на себя первоначальные затраты на создание библиотеки на вашем компьютере.

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

DXM
источник
1

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

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

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

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

  • Что, если библиотека в порядке, а ошибка сборки была вызвана ошибкой в ​​коде проекта? Или, что если сбой сборки был вызван временным несовместимым изменением, которое должно быть исправлено через день или два? Что если сбой сборки указывает на сложную проблему интеграции, на решение которой уходит неделя или месяц? Для проблемы интеграции, использование библиотеки более ранней версии может обойти или нет?
     
    Какова бы ни была причина, предварительный анализ ошибки означал бы напрасную трату времени разработчика на работу, которую должны выполнять тестировщики.

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


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

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

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

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

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

Какой репозиторий артефактов вы используете? Вы должны иметь возможность развернуть jar-файл для каждой версии, чтобы он располагался рядом с скомпилированной библиотекой. Большинство IDE тогда позволят вам присоединить это к скомпилированной библиотеке для просмотра исходного кода. Затмение с плагином Maven сделает это автоматически.

Если вам нужен самый последний код, вы можете просто развернуть снимки версий.

smp7d
источник
Maven используется в качестве репозитория, и большая часть проекта использует либо это, либо Ivy для управления зависимостями.
rjzii
@RobZ Вы не используете центральный репозиторий артефактов, такой как Artifactory или Nexus?
smp7d
Мы используем Archiva.
rjzii
@RobZ Хорошо, тогда вы можете настроить poms для развертывания src jar и присоединить его к библиотеке в IDE, если это не произойдет автоматически. См. Maven.apache.org/plugins/maven-source-plugin
smp7d
0

Это должно просто произойти в вашем скрипте сборки:

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

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

back2dos
источник
С точки зрения серверов непрерывной интеграции, сама библиотека не маленькая и ее сборка занимает пару минут.
rjzii
@RobZ: Так? Пока библиотека не меняется, вам не нужно ее перестраивать, не так ли?
back2dos
Сейчас он все еще находится в стадии активной разработки.
rjzii
@RobZ: Да, может быть и так, но если команда библиотеки помечает версию каждые 10 минут, значит, она делает это неправильно. Непрерывная интеграция - это хорошо, но релиз должен включать какое-то тестирование юзабилити. В случае библиотеки это обзор кода. Это не может быть автоматизировано. Однако процесс получения последней проверенной и помеченной версии может быть автоматизирован, и если проверки выполнены правильно, а тегирование выполнено ответственно, я не вижу проблемы, а на самом деле является улучшением.
back2dos