coodan

Программировать, конечно. В первую очередь.

Уже потом придет чувство стиля, чувство красоты решения. С++ в этом смысле очень хорош, очень много возможностей.

Поизобретать велосипеды, конечно. А потом смотреть как эти задачи решаются эффективно. Заценить мудрость и красоту чужого решения, сравнив его со своим. Шишек понабивать. Ночами посидеть, отлавливая ошибки и глюки. Отлаживая код. Потом почитать о хороших практиках в программировании. Переписать корявый, но рабочий код так, чтобы он им соответствовал. Получить эстетическое удовольствие от получившегося. Почитать чужой код. Восхититься или поплеваться, в зависимости от автора кода.

Для профессионала программирование, конечно, это чистая практика, ремесло. Для любителя может быть искусством. Но вряд ли для кого-то, кроме академической среды, может быть наукой.

Присоединяюсь, если Вы недовольны качеством своего кода и думаете над тем, как его улучшать, то он будет улучшаться. Он уже улучшается.

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

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

Например, С++ с его STL. В основе STL - так называемые контейнеры. Контейнер в понимании STL - это некоторый объект, который содержит другие объекты. А к этим контейнерам есть так называемые алгоритмы. Алгоритм в понимании STL - это некоторый код, который будет работать с объектами из контейнера в заданном диапазоне. То есть, одной строчкой натравливаешь нужный алгоритм на нужный контейнер и говоришь - копать от сих до сих - и все, дело в шляпе. Самые нужные алгоритмы уже заданы - та же сортировка различными способами, например. Сомневаюсь, что можно сделать ту же сортировку более надежно и эффективно, чем это сделали разработчики библиотеки. При желании можно задавать собственные алгоритмы.

Ориентация языка на работу с алгоритмами не поможет, конечно, более глубоко их понимать и создавать. Но от изобретения велосипедов убережет. И мысль в нужном направлении направит.

Сразу возникает вопрос - а надо ли оно Вам, коли неинтересно? А индусов слушать, как они там на кривом английском свои кривые творения объясняют - дело последнее.

Единственное, что могу посоветовать - пойдите в большой хороший книжный магазин и попытайтесь там найти себе интересную книгу по программированию. Если ничего не заинтересует - бросайте эту блажь. Чтобы этим заниматься, от этого нужно балдеть. Иначе пытка.

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

Конечно, Вам стоит изучить подходы, связанные с generic programming. Boost в значительной степени основан на этой парадигме. Действительно, там, как и с паттернами вообще, возможны трудноулавливаемые ошибки. Но этот подход сильно меняет суть и облик С++, поэтому может быть важен для Вас.

Начинать generic programming стоит с его основ - с того, чтобы по-новому взглянуть на STL и контейнеры. Effective STL, по-видимому, самая простая и хорошая книга об этом:
www.amazon.com/Effective-STL-Specific-Standard-Tem...

P.S. На конкретном простом примере. Когда мне понадобилась работа с графами, изучил вопрос и просмотрел библиотеки, которые обеспечивают данную функциональность. Некоторые из них заброшены не поддерживаются. Другие вроде бы и ориентированы на ООП, но их интерфейс производит впечатление какой-то запутанности, недостаточно ясного понимания, что порождает сомнения в цельности и безошибочности их реализации. Лучшим решением в этой области на тот момент, по моему мнению, оказалась библиотека boost::graph. Но это чистое обобщенное программирование, как оно есть. Без понимания того, что это такое, умения это использовать и на этом писать, делать там нечего. С ООП это не стыкуется вовсе. Это другое.

Так, необходимый функционал может подтолкнуть Вас к необходимости использования парадигм, которые Вы мало знаете и не в полной мере разделяете. И так boost будет толкать Вас в этом направлении, и чем дальше, тем больше.

Раз уж вопрос задан - то никакую. Вам вообще не надо читать книги. Вас от чтения, очевидно, ломает :)

Здесь есть несколько аспектов, в котором Вы могли бы задать этот вопрос, оттого он может иметь несколько значений.

Ломание копий здесь выявило две следующие крайности. Крайность академическая (к которой отношусь и я) считает, что главное - это понимание языка, чувство красоты решения. Это, конечно, крайность, потому что, хотя и позволяет делать идеально надежные вещи, но требует на это значительного времени. Крайность ремесляников убеждена, что качество кода и глубина понимания и владения языком не имеет значения, академическая школа не нужна, главное, быстро писать, потому что это выгодно, так как этого хочет заказчик.

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

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

Чисто академический путь в наших условиях крайне проблематичен. Впрочем, наверное, в Вашем университете есть аспирантура. Если же рассмотреть вариант, когда Вы сохраняете академический интерес к проблеме и поддерживаете академические ценности (стремление к познанию вне практического применения полученных знаний, любовь к истине), но при этом работаете в практической сфере, то ответ становится не таким очевидным. Вы упоминали о тестировании софта. Эта работа непрестижна. Но тем не менее, очень важная - довольно избито, что тестирование сейчас лимитирует разработку. Довольно утомительная и однообразная работа. Бессмысленная при низкой квалификации разработчиков. Но, может так оказаться, что в силу дефицита тестировщиков, Вы, приложив к этому силы и отбрасывая все неквалифицированные коллективы, сможете найти место, где пишут код, который определенно стоит того, чтобы его отлаживать. Может так оказаться, что лучше быть мальчиком для битья у чемпиона по боксу, чем тренироваться с плохим тренером среди неумех.