Когда вы говорите компоненты, вы имеете в виду компоненты кода или компоненты инфраструктуры? Я бы сказал, что инфраструктура (поддерживающая сервисы и процессы), а не код, дает наибольшую пользу качеству, скорости и простоте разработки. Примеры, которые вы приводите, находятся сейчас в стандартных библиотеках большинства языков или сильно зависят от приложения / варианта использования.
Я также собираюсь предположить, что управление версиями - это данность, так как оно является неотъемлемой частью всей разработки.
Я бы сказал, что наиболее важной инфраструктурой будет непрерывная сборка / автоматическое тестирование . Это позволяет людям писать любой код, который они хотят, зарегистрировать его и убедиться, что он работает со всеми остальными.
Вторым по важности будет общие библиотеки . Они позволяют людям развиваться быстрее и устанавливать стандарты (надеюсь, хорошие) для внешнего вида, ощущения и дизайна. Поскольку общие библиотеки используются все больше, важность непрерывной сборки возрастает, поскольку небольшие изменения в них могут вызвать регрессию.
Одна проблема с общими библиотеками, однако, заключается в том, что им требуется много усилий для правильного проектирования - поэтому их стоит использовать повторно - и для их достижения требуется много времени. Большинство из них будут начинаться как специфичные для проекта, а затем кто-то взломает их в своем проекте, затем последует некоторое ветвление, затем копирование и вставка. Через несколько лет, возможно, кто-то проверит код и начнет объединять их в общее место. Должен быть составлен план обновления общих библиотек и того, как (или если) иметь две версии одновременно. Другим скрытым недостатком является то, что они обеспечивают более быструю разработку в краткосрочной перспективе, но препятствуют разработке в долгосрочной перспективе, так как люди становятся заблокированными в более старых версиях (это больше относится к сторонним библиотекам).
Третьим будет Инструменты сборки . Это означает общие инструменты для упрощения создания, извлечения, поиска и других действий, связанных с каким-либо образом взаимодействием с кодом. Вещи, которые автоматически помечают ошибки как исправленные, когда вы отправляете исправление, или уведомляете постоянных сборщиков об изменении зависимостей, или автоматически запускаете тесты перед отправкой теста, что упрощает (и ускоряет) тестирование.
Четвертым будет герметичная сборка , которая является простым расширением инструментов сборки. Это означает, что приложение является автономным. Это имеет два преимущества: 1) повторное использование машины проще и, что более важно, 2) разработчику невероятно легко начать работу - им не нужно устанавливать дополнительные библиотеки, или что-то менять в / etc, или устанавливать что-то в их окружение - оно просто строит и запускает.
Некоторые другие, о которых я могу думать:
- Мониторинг : Если все используют один и тот же метод мониторинга, то людям не нужно «черный ящик» контролировать общие библиотеки. Это также облегчает выявление проблем, поскольку все данные находятся в одном месте.
- Хранение журналов : Жечь и пахать бревнами - это боль. Наличие централизованного места, где все журналы хранятся в структурированном формате, облегчает поиск и поиск проблем.
- Управление ветвями : В большом проекте это позволяет разработчикам разрабатывать, тестировать тестеры и выпускать релизы, не наступая друг другу на ноги.