Управление проектами и пакетные зависимости

Question

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

Подводя итог, автор перечисляет множество особенностей проекта и то, насколько эти функции способствуют «удовлетворенности» проекта отсутствием лучшего термина. Вы можете найти полную статью здесь: http://spot.livejournal.com/308370.html

В частности, я не понимаю позицию автора по объединению зависимостей с вашим проектом. Это:

== Комплектация ==

• Ваш источник поставляется только с другими проектами кода, которые зависят от [+20 баллов FAIL]

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

• Если ваш исходный код не может быть собран без предварительной сборки связанных битов кода [+10 точек ОТКАЗА]

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

• Если вы изменили эти другие биты связанного кода [+40 пунктов ОТКАЗА]

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

Итак, как бы вы ответили на эти комментарии, и какие моменты я могу не принять во внимание? Согласитесь ли вы с мнением автора (или моим) и почему?

Отредактировано для уточнения.

Answer 1

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

Мой проект требует проекта X.

Однако, поскольку мой проект зависит от тайных внутренних загадок X или предыдущей версии X, мой проект включает в себя копию X. В частности, выпуск n.m X. И никаких других.

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

Следовательно, оценка FAIL.

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

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

Если мой проект зависит от API для X, то для некоторых языков, таких как C или C ++, мой проект может компилироваться только с заголовками C или C ++, а не с двоичными файлами.

Для Java это менее верно, поскольку не существует независимого недвоичного заголовка. А для динамических языков (таких как Python) это не имеет никакого технического смысла.

Однако даже в Java и Python есть способы отделить интерфейс от реализации. Если я полагаюсь на реализацию (не на интерфейс), то я все равно создал ту же самую существенную проблему.

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

Отсюда и результат FAIL.

Если вы изменили эти другие биты связанного кода.

У меня есть два варианта при изменении X.

1. Получить его как часть X.

2. Исправить мою программу для работы с немодифицированным X.

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

Я, по сути, сделал их работу невозможной, изменив X.

Отсюда и результат FAIL.

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

На самом деле, они меня за это ненавидят. Они не хотят знать о таинственных изменениях в X. Они хотят построить X в соответствии с правилами, а затем собрать мои вещи в соответствии с правилами. Они не хотят читать, думать или быть уверенными в том, что комплект обновлений для mystery update был применен правильно.

Вместо того, чтобы шутить с этим, они скачают конкурирующий пакет. СБОЙ.

если ваша кодовая база зависит от конкретной версии библиотеки (которую вам также нужно откомпилировать для вашего проекта)

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