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

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

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

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

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

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

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

Предложение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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