История всегда начинается с жалобы. Исполнительный директор жалуется, что ПО слишком дорого стоит и долго разрабатывается.
Некая яркая личность предложит возможность сэкономить деньги, если писать ПО, которое можно повторно использовать. Правда, это потребует немного вложений вначале для создания компонентов, которые могут быть использованы для разработки в будущем, экономя на этом деньги и усилия.
Директор клюет на это, так как каждый проталкивает эту идею как ответ на цену и проблему с производительностью. И замирает в ожидании получения плодов.
Каждый берет участие в выявлении и создании полезных компонентов или переделывает существующий код, делая его повторно используемым. Новые проекты вдохновляются преимуществами и создают новые приложения, которые, кажется, прям вылетают в эксплуатацию.
Некоторые люди отмечают, что компоненты - практически то, что нужно или требуют небольшой доделки или небольшой конфигурации, возможно с дополнительным слоем абстракции, который позволит более широкое использование. Определенно нужен кто-то, кто будет поддерживать компоненты, поэтому создается новая организация, которая управляет ими и обеспечивает качество и удобство использования.
Вскоре новая команда начинает контролировать доступ, так как, позволяя многим командам делать изменения, они могут влиять на других. Создается доска для контролирования и одобрения использования компонентов для того, чтоб убедиться, что они используются правильно.
Растущая зависимость на повторно использованном коде еще больше усложняется иерархией зависимостей, включая разные открытые библиотеки, которые сами по себе имеют паутину зависимостей, что требует тщательного контроля. Изменения проходят все дольше и дольше, так как каждое изменение требует тестирования всех приложений, а новый функционал отходит на задний план. Открытые и закрытые зависимости становятся все более устаревшими, создавая шквал все медленных и медленных обновлений.
Теперь основными жалобами опять становится то, что разработка дорого стоит и требует много денег. Теряются рыночные возможности, так как новые зависимые библиотеки и функционал ОС не могут быть использованы. Исполнительный директор, который поддерживал идею с самого начала, теперь должен искать новые пути, и что-то бормочет о просроченных сроках для обеспечения повторного использования. В конце концов, все это начинает звучать бессмысленным.
Теперь индивидуальные группы начинают отделятся и строить приложения независимо от компонентов, и разрабатывать быстрее нежели "зависимая братия". Вскоре от компонентов все отказываются, за исключением, конечно, тех, кому запрещено отказаться. Те руководители, которые вернули преуспевающие команды, получают повышение, а остальные покидают компанию.
Знакомо? Возможно, не совсем так, как описано выше, но часто в больших компаниях этот тип сценария пройденный этап. Это не значит, что повторное использование - это плохо само по себе, просто делать все в компании повторно используемым - глупо.
Основная проблема в том, что мир не останавливается, и когда вы начинаете создавать повторно используемое ПО в больших масштабах, то оно в конечном итоге становится не преимуществом, а препятствием. Представьте себе, что несколько лет назад решили создавать повторно используемые компоненты на основе Backbone. Мы в туристической компании 4 года назад использовали JavaScript фреймворк Backbone для создания мобильного веб приложения. Теперь же никто его не использует. Если вы одновременно создадите множество компонентов для iOS, и предполагая использовать iOS 6, то конечно же, все радикально измениться с выходом iOS 7. Конечно, вы могли быть осторожным и создать идеально обновляемый код, но выше упомянутый сценарий очень вероятен: слишком много зависимостей, которые не могут быть обновлены без нарушения существующих приложений и тотального регрессионного тестирования.
Некоторое ПО живет намного дольше, и, конечно, вы можете указать приложения на Cobol, которые родом из 60-ых и практически никогда не изменяются, или системы резерваций воздухоплавания с тех же лет, что все еще занимают свою нишу. Это ужасные примеры, они работают только потому, что чрезвычайно сложны и дороги, и вследствие этого редко изменяются. Вы вероятно не захотите, чтоб было так сложно обновить код в вашей компании что ваши конкуренты оставят вас далеко позади.
Бесспорно, иногда повторно используемый код имеет рыночные преимущества: сложно работать с тем, с чем могут работать только высоко оплачиваемые профи.
Часто новые языки программирования, фреймворки, техники и идеи создания, позволяют делать ПО легче, нежели повторно использовать что-то, что реально негибкое, старое и скрипит. Вы можете использовать преимущества Swift, вместо копания в пятилетнем Objective-C, который уже никто не понимает. Вы можете использовать Rust вместо всяких там PHP. Вы можете использовать Unreal вместо одного из тех 18-летних движков (один из них изучен мною лично). Все же, новые вещи не всегда лучше, но эта отрасль постоянно приходит к новым невероятным возможностям.
Иногда правильный ответ - переписать все заново. Не всегда можно утверждать, что существующие компоненты не должны быть переписаны, потому что вы знакомы со всеми их причудами и багами, что написание новых слишком рискованно. Вы можете реально прийти к чему-то, с чем проще работать и сделать продукт быстрее, чем другие. По мере увеличения риска того, что изменение будет вас тормозить, риск использования нового может быть не так страшен.
Одну вещь, которую я говорил уже много раз, относительно личного самообучения чему-нибудь новому - гигантский технологический каток мчится прямо за вами, ожидая того, что вы споткнетесь, работая в больших или малых компаниях. Немного задержитесь на месте, и вы тотчас же станете частю дизайна в асфальте. Конечно, вы можете уйти далеко вперед и обжечься, новое не обязательно будет лучше, но если появляется множество вещей, то некоторые из них стоит использовать.
Задача состоит в том, чтоб найти путь, который сделает разработку более экономически эффективной и продуктивной, но не создавать массивные лодочные якоря. Иметь дело с изменяющимся миром - не легко, но в любом случае нужно двигаться, и это иногда значит, что нужно жертвовать повторное использование в целях поддержания гибкости.
