Экран кинотеатра на мгновение погас и показал первые титры. Из темного зала стали доноситься весьма скудные аплодисменты. Начинает казаться, что закончившийся фильм мало кому понравился: по звуку можно насчитать десяток аплодирующих зрителей… Но тут свет загорается и оказывается, что фильм понравился всем. В полупустом зале сидит редкая группа зрителей, и хлопают все… Это был закрытый показ, который обычно именуют как «кино не для всех».
Какое отношение это имеет к C++? Пожалуй, самое прямое…
Язык C++ очень многолик и вариативен, что дает огромный простор для творчества. «Искусство программирования» — фраза, которая часто встречается в статьях и литературе по C++. Но насколько это хорошо? Разработка программного продукта отдельными разработчиками начинает походить на соревнование в мастерстве между самими разработчиками… Создаются конструкции и взаимосвязи, которые становятся понятными только редкому числу «опытных» программистов, знакомых с передовыми тенденциями развития языка. Применение того, что, возможно, скоро войдет в стандарт… куда же без этого?! Итогом всего этого является плохо сопровождаемый программный продукт.
Усложнение конструкций неизбежно ведет к ошибкам, а исправлять их может только высококвалифицированный программист. Но весь парадокс в том, что «звезды C++» не любят заниматься сопровождением кода и уж тем более чужого. И вот компания, потратив существенные средства на разработку, становится обладателем чего-то вроде уникального автомобиля, в котором для замены свечей дешевле выкинуть весь двигатель и поставить новый, так как мастера по замене свечей очень дорогие и их непросто найти.
Конечно, то, что я описал несколько гипертрофировано, но это то, с чем, наверняка, сталкивался каждый руководитель команды С++ разработчиков. Когда разработка продукта идет уже не ради самого продукта, а ради его внутренней красоты, понятной только самим разработчикам. Порой доходит до абсурда. На элементарные задачи тратится такое количество ресурсов, чтобы сделать все «правильно». Так как советуют Гуру. А потом оказывается, что это настолько увеличивает объем и количество ошибок, что на отладку требуется еще больше времени.
Я не могу совершенно точно назвать причину происходящего с точки зрения психологии или здравого смысла. Но я могу привести одну аналогию. Думаю, что многие смотрели мультфильмы студии Дисней. А знаете ли вы, что среди художников эти мультфильмы считаются чем-то вроде ширпотреба. Мол, они не являются искусством. Потому, что в свое время Дисней разработал сильно упрощенную и формализованную технику производства таких мультфильмов. Именно это позволило создавать полнометражные ленты над которыми трудились сотни разных художников и не вызвать у зрителя вопросы почему в разных эпизодах герои отличаются.
Также и в производстве программных продуктов. Для того чтобы команда могла работать над большим проектом — требуется упростить подход к разработке. Требуется минимизировать искусство одного программиста и перейти на качественно новый уровень. Когда восхищение вызывает не то, что сделал один человек, а то, что сделала слаженная команда. Мне кажется, что именно в этом должна быть мотивация. Создание продукта, который станет успешным среди простых людей, а не только среди профессионалов.
Лично я не хочу быть режиссером того фильма, о котором рассказано в самом начале. Всю жизнь он преподавал как снимать кино, и за все это время снял пару фильмов «не для всех». Искусство. Среди своих он, возможно, добился почтения. Но для меня, как человека далекого от «профессионального» кино его слова о том насколько ужасен и вульгарен «Аватар» и его создатель Кэмерон звучали, мягко говоря, смешно. И, уверен, что многие на моем месте испытали бы подобные эмоции. Как может рассуждать о популярном кино человек, который за всю жизнь снимал кино не для всех? И точно также среди программистов. Желание сделать что-то особенное самостоятельно перебивает желание работать в группе и получить работающий продукт. Вместо того, чтобы пойти по простому и известному пути получения результата многие стремятся найти свою дорогу и по нескольку раз изобретают велосипеды: “Я сделал свой XML парсер. Он в 3 раза быстрее открытого TinyXML”. И плевать человеку, что для загрузки настроек при старте программы данная скорость никому не нужна и никому не будет заметна.
У нас очень много талантливых людей, но каждый талантлив по-своему, каждый стремится к самореализации, не всегда обращая внимания на остальных членов команды. И это, пожалуй, одна из самых сложных задач при разработке ПО. Балансирование на грани между проявлениями талантов отдельных программистов и стандартизации процесса. А как вы решаете эту непростую задачу? Как одержать победу над самим собой и как указать правильный путь другим разработчикам?
