если есть большой магазин под рукой и пара часов - идем туда, и начинаем читать книги

берем что понравится

имхо как введение - лучше всего, и приятно

Присоединяюсь к вопросу ТС.

http://www.htdp.org/ однозначно.

Макконнелл — Совершенный код
http://www.ozon.ru/context/detail/id/3159814/

про антипаттерны в вики почитай

Хорошая книга Кента Бека по Extreme Programming

Можно еще про Mind Maps глянуть. Это ДО проектирования, когда надо объять задачу разумом и набросать черновик какие фичи вообще нужны.

Я вот этим пользуюсь http://www.xmind.net/

Для архитектурного дизайна есть UML. Какие там нынче методики модные ХЗ.

Книжки - фик знает. Макконела Code Complete уже упоминали. У дядьки вообще вагон интересных книжек. С более менеджерским уклоном - Rapid Development.

Копипащу из джаббера:

Хорошая книга Кента Бека по Extreme Programming

Кент Бек --- это круто, но это про оптимизацию процесса разработки, а не про проектирование. Он пишет про то, как надо взаимодействовать с постановщиками задач и про общение внутри команды разработчиков.

По сабжу --- про само проектирование почитай Э. Гамма, Р. Хелм и др.: Приёмы объектно-ориентированного программирования. Паттерны проектирования. --- СПб. Питер, 2004. — 366 с.

Структурное проектирование надежных программ встроенных ЭВМ / А. А. Штрик, Осовецкий Л.Г., Мессих И.Г. - Л. : Машиностроение. Ленингр.отд-ние, 1989.

Чудная книжка. Я по ней написал несколько курсовых по экономике и половину диплома по специальности «финансы и кредит».

> Как многие, возможно уже в курсе, я не учился программированию в ВУЗе. Но я люблю программировать, это мое хобби. Так как я не учился этому профессионально, я, возможно, могу не знать многих тонкостей сего дела.

В наших ВУЗах профессионально программировать и не учат. ВУЗ дает необходимый минимум знаний для работы по этой специальности: дискретная математика, теория автоматов и т.п. Дальше, имея необходимую базу, необходимо развиваться самостоятельно. После учебы человек приходит на позицию junior'а и под присмотром опытных коллег из него выколачивается вся дурь. ;-)
Могу посоветовать следующую литературу (список получился с уклоном в сторону ООП):
С. Макконнелл - Совершенный код (как уже ответили выше)
Г. Буч - Объектно-ориентированный анализ и проектирование
Ну и GoF конечно же:
Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес - Приемы объектно-ориентированного проектирования

>Ну и GoF конечно же:

Мне казалось, что если человек хочет научиться поектированию, он должен научиться думать сам. А эти шаблоны проектирования в основном лишены процесса думания.

шаблон проектирования задает точку зрения при решении задачи - и в этом его главная польза. а думать придется в любом случае.

>шаблон проектирования навязывает точку зрения и терминологию при решении задачи

fixed?

>пришел к проектированию.

Если освоишь вышеназванные книги, то станешь «Программистом», а если выучишь всего_один_ГОСТ http://www.csrs.ru/gost/19_102_77.htm , то станешь «Большим_Начальником» :)

впрочем, я неосилятор, и половина этих паттернов для руби не имеет смысла..

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

аминь

> В наших ВУЗах профессионально программировать и не учат.

Я бы четвертовал всех, кто навязывает мнение, будто в ВУЗе должны учить языкам программирования.
Программирование != использование языка программирования.

> Мне казалось, что если человек хочет научиться поектированию, он должен научиться думать сам. А эти шаблоны проектирования в основном лишены процесса думания.

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

Паттерны хороши, если надо объяснить на пальцах кому-то еще, как решал задачу, или как рефакторил, или еще что такое. 10 минут разговора уходят в емкое название.

Как у стругацких подмечено: ученый обретет покой только тогда, когда ему на каждое явление будет повешен ярлычок. Сказал «гравиконцентрат» — и все ясно, все хорошо.

Паттерны, сцуко, слишком привязаны к языку реализации.

http://www.faqs.org/docs/artu/

Эй, специалисты!

Кто что может сказать про книгу Eric Raymond «The Art of Unix programming»?

? Вы с дуба упали, простите. Назовите хоть один паттерн проектирования, который привязан к языку.

По теме:
Бери всё что есть в теме и имеет в названии слова «паттерн» и «проектирование». Это то что нужно.
Зачастую паттерны это абстрактные понятия, которые в книгах стараются не показывать на примере языков чтобы не делать из читателя слишком тупого болванчика.
Поняв, скажем, паттерн MVC, можно самому ему найти применение и по своему его реализовать(к примеру в джанго разработчики его интерпритировали как MVT).

Вот эти не вздумай читать:

Иан Грэхем «Объектно-ориентированные методы. Принципы и практика»

Мартин Фаулер «Шаблоны корпоративных приложений»

Джошуа Кериевски «Рефакторинг с использованием шаблонов»

Кент Бек «Шаблоны реализации корпоративных приложений»

Поль М. Дюваль, Стивен М. Матиас III, Эндрю Гловер «Непрерывная интеграция: улучшение качества программного обеспечения и снижение риска»

Джерард Месарош «Шаблоны тестирования xUnit: рефакторинг кода тестов»

Грегор Хоп, Бобби Вульф «Шаблоны интеграции корпоративных приложений»

Иначе программирование для тебя превратиться в рутину и не будешь получать удовольствие от собственных открытий.

Паттерны, сцуко, слишком привязаны к языку реализации.

А ничего, что банда четырёх написала книгу классических образцов с использованием по крайней мере трёх языков программирования?

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

Команда, Визитор, да практически все. Даже в Смолтоке часть паттернов GoF не имеют смысла; в Хаскеле смысл теряют почти все.

А ничего, что банда четырёх написала книгу классических образцов с использованием по крайней мере трёх языков программирования?

С++ и Смолток они явно считают почти одинаковыми (что, вообще-то, не так) и одинаково на них пишут. Какой там третий, я уже не помню?

Замечательная книга. Перечитываю уже в который раз с удовольствием

Это чушь :) Просто не надо плоско мыслить, дабы не привязывать паттерны к ЯП. И вообще, паттерны - не панацея.

> Паттерны, сцуко, слишком привязаны к языку реализации.

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

Просто не надо плоско мыслить, дабы не привязывать паттерны к ЯП.

Просто не надо мыслить шаблонами.

Basic Programming for Dummies

Порой надо

> Порой надо

Порой = в редких случаях, ведь так? Выходит, всё-таки не нужно.

Мне она дико понравилась.

Не, все зависит от проекта, команды и прочих нюансов. Паттерны - не панацея, но говорить, что они «не нужны» по меньшей мере недальновидно и ограничено.