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

Question

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

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

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

== Объединение ==

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

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

• Если ваш исходный код не может быть собран без предварительного создания связанных битов кода [+10 баллов FAIL]

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

• Если вы изменили другие биты кода в комплекте [+40 баллов FAIL]

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

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

Отредактировано для пояснения.

Answer 1

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

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

Однако, поскольку мой проект зависит от тайных внутренних тайн X или предыдущей версии X, мой проект включает копию X.В частности, выпустите номер 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 был применен правильно.

Вместо того чтобы шутить с этим, они скачают конкурирующий пакет.НЕУДАЧА.

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

Это очень плохо.Если я завишу от версии с пользовательскими компиляциями, они перестанут просматривать мой пакет.Они найдут что-то без внутренних загадок, специфичных для конкретной версии, и пользовательских компиляций, прежде чем приступить к борьбе.НЕУДАЧА.