Ниже следует моя попытка перевести (надеюсь, не испортить) на русский язык вырезки из статьи, сильно впечатлившей меня, Michael Abrash'а "Being a successful game developer" (Увы, источник в инете не могу привести — мне оригинал пришел по почте).
Привожу некоторые размышления о быстром коде, программированию игр, разработке программного обеспечения и т.д. и т.п.:
Вот три секрета для достижения успеха:
1. Тяжелый труд,
2. Тяжелый труд и
3. Тяжелый труд.
Изучаем создавая. Думать – это прекрасно. Однако действительно изучаешь что-то досконально, только когда создаешь это, и, частично, когда доводишь свое творение до победного конца! Второе, на самом деле, оказывается гораздо труднее в жизни, чем на словах, ведь создание программного обеспечения бросает вызов законам природы, являясь далеко не естественным процессом. Вот вам реальность: программа никогда не станет совершенной и ее завершение — ни что иное, как бесконечно убегающая линия на горизонте. Примите неизбежные компромиссы и дайте жизнь своему творению.
Успех – это нечто большее, чем чек на большую сумму, или, как его представил John Carmack: "The Ferraris are only gravy, honest!". Ты хочешь быть кредитоспособным, так почему бы не заниматься тем, что любишь? Делая свое любимое дело, работая старательно, со всей душой, — ты строишь фундамент достойной жизни, которая окупит твои усилия сполна, и, в конечном счете, ты преуспеешь во всех начинаниях, которые будут важны для тебя.
Если угодно: Разработка игр – то место, где живет лучшая работа для программиста. Она касается практически всех областей программирования. Это одно из немногих мест, где код может оставаться чистым, вместо правленых-переправленных, скроенных в кучу кусочков. И это одно из тех немногих мест, где оптимизация все так же существенна.
Метить высоко, думать глубоко. Именно сегодня исключительно подходящее время для разработки игр, претендующих на оригинальность. Благодаря современным процессорам и 3D-ускорителям открылись не виданные никогда ранее возможности.
Потрясающие программы это нечто большее, чем просто потрясающий код. Во-первых, необходим отличный замысел. Не пишите код до тех пор, пока не получите четкое представление о том, что хотите создать. Отведите время для кристаллизации и ни в коем случае не хватайтесь за первую попавшуюся рабочую идею.
Проектируйте и оптимизируйте с высших уровней модели до нижних, акцентируя внимание, в первую очередь, на высших архитектурных проблемах. Преждевременная оптимизация, как и преждевременный низкоуровневый дизайн – корень зла.
Ищите новые, лучшие подходы к решению задачи, будьте готовы постоянно изменять и изменяйте модель по мере того, как вы осваиваете что-то новое, более того, будьте готовы полностью выбросить ее. До тех пор, пока на то есть время, думайте о текущем дизайне, каким бы он ни был, как об отправной точке для нового – лучшего дизайна.
Знайте, что делает ваш код, пробираясь через абстракции. Профилируйте по всем направлениям: профайлеры, NULL drivers, замеряйте время выполнения основных мест программы, вываливайтесь в отладчик в любой момент и смотрите где вы находитесь. Если вы ничего этого не делаете – вы просто догадываетесь, как работает код.
Знать, что оптимизировать значит так же много, как и знать, как оптимизировать. Иначе, вы будете оптимизировать не в том месте, и, в конце концов, получите действительно быстрый медленный код.
Когда вам кажется, что вы выжали из кода все, что можно, а нужно еще больше, попробуйте изменить свое отношение к задаче. Может, вы решаете абстракцию задачи, вместо самой задачи. Terje Mathisen сказал: «Практически все программирование может рассматриваться, как упражнения в кэшировании». David Stafford рассматривал программирование как один из видов компрессии. Есть бесконечно много возможных перспектив программирования – используйте их!
Проверяйте ваши допущения.
Не допускайте что-либо. Всегда спрашивайте себя, критикуйте свои предположения. Смейтесь и будьте счастливы, когда вы узнаете, как могли бы сделать что-то лучше, чем сделали.
Используйте доказавшие себя решения. В мире не так и много совершенно новых идей. Читайте о достижения других людей, вместо того чтобы изобретать все своими силами. Большая часть успеха в программировании заключается в проектировании, интегрировании, завершенности и гибкости, а не в голом изобретательстве. Конечно, изобретать велосипед — это весело, но, увы, реальность такова, что сейчас есть много вещей, которые необходимо знать. Поэтому одному человеку сложно сделать все в одиночку. Кроме того, есть множество интересных вещей, которые предстоит еще постигнуть после того, как освоите то, что уже решено.
Учите математику столько, сколько можете осилить. После этого учите ее еще. Индустрия движется от простого, доморощенного программирования к преобладающему программному обеспечению, основанному на глубоких знаниях в предметных областях, таких, как, например, физика. Программирование само по себе – просто. Мастерство в наукоемких областях будет все больше и больше выделять программистов в будущем.
Будьте терпеливы. Для того чтобы стать сведущим в новой области понадобится год. Три года понадобится для достижения уровня эксперта.
Будьте гибкими. Не зацикливайтесь на своих идеях и коде. Будьте готовы выслушать новые точки зрения, соглашайтесь с ними, когда вы не правы и меняйте свои взгляды должным образом.
Примите перемены... или смотрите, как они обгонят вас, оставив позади. Цели, технологии и правила будут непрерывно изменяться. Примите это.
Единственная вещь, которая стоит между Вами и Великим идеями ПО — это Вы.
TANSTATFC: There Ain't No Such Thing As The Fastest Code
Включите правое полушарие мозга. Пробуйте много разных идей. Пробуйте даже бредовые идеи. Слушайте свой внутренний голос. Расслабьтесь. Позвольте себе быть творческим человеком. Смиритесь с тем, что многие идеи провалятся. Это единственный путь изучать и прогрессировать.
Если код становится все сложнее и сложнее, значит, вы вдаетесь в детали. Сделайте шаг назад и посмотрите на общую картину для более глобальных решений. Попробуйте изменить правила, и вы можете преуспеть, не прогибаясь под текущими ограничениями.
Не чувствуйте себя слишком удовлетворенным. Стремитесь к совершенству. Боритесь за обретение того самого чувства удовлетворенности своим кодом, постоянно спрашивая себя, как его можно улучшить. Боритесь с энтропией кода.
Упрощайте. Попробуйте сделать лучшее из меньшего, разными способами.
Программирование – это не односторонний процесс. Делитесь тем, что изучили, и изучайте то, что изучили другие, конечно, если вам не запрещается это законом или контрактом. Когда нам приходится объяснять что-либо – мы сами крепче усваиваем материал, это делает нас известными и приводит к интересным благоприятным последствиям.
Веселитесь. Речь идет о самой лучшей в мире работе, но, как и все остальное, разработка игр может превратиться в работу, если вы это допустите. Не допускайте. Вы – одни из самых счастливых людей в истории планеты, Вам посчастливилось получать невероятные вознаграждения за востребованную, интересную, любимую работу, приносящую радость. Помните об этом и чтите эти благословенные дни. А потом пойдите и напишите какую-нибудь великолепную программу!
PS: Этот перевод не преследует и не должен преследовать никаких коммерческих целей
. Буду рад, если кому-то он покажется полезным.
PPS: Это моя первая попытка перевода, так что, все пинки приветствуются и пропускаются мимо ушей, наматываясь на ус. Если кто-то заинтересуется — приведу текст оригинала. Надеюсь, я не нарушил никаких копирайтов, ибо мне оно пришло уже без них.
Здравствуйте, anvaka, Вы писали:
A>Проектируйте и оптимизируйте с высших уровней модели до нижних, акцентируя внимание, в первую очередь, на высших архитектурных проблемах. Преждевременная оптимизация, как и преждевременный низкоуровневый дизайн – корень зла.
Вот объясните мне, дураку набитому, что это есть умно и мудро. Я безусловно согласен, что для всех тривиальных задач — это так. Но в мире есть много таких задач, где алгоритм первичен, а дизайн — дело наживное и в общем-то тривиальное. Типичный пример —
http://www.focusmagic.com/
Вот, скажем, задумали проектировщики подобный проект. И чего они сделают без алгоритмов? Кстати, UI в этой программе — ужос какой-то, юзабилити около нуля. Но если мне надо — то я готов и потерпеть. А вот если бы там был самый-самый красивый UI и вся структура программы была бы просто блеск но без алгоритмов — то кому это надо?
Это я к тому, что не всегда утверждение, процитированное выше, верно. Часто бывает так, что есть некий стержень, если угодно, вампитер (см гугл), вокруг которого вертится все остальное.
В моей пафосной библиотеке (см профайл) таким вампитером является алгоритм растеризации (изначально не мой, кстати), и все остальное проектирование так или иначе отталкивалось именно от него. Конечно, там много и других алгоритмов и сейчас именно этот растеризатор не обязателен. Но именно он и являлся отправной точкой и весь пляс шел от этой печки. Я допускаю, что совет проектировать сверху — правильный. Но мне не понятно
почему он правильный? На мой взгляд, утверждать так однозначно нельзя. Еще раз повторю, в случае тривиальных задач так оно и должно быть и большинство задач именно тривиальными и являются (при этом они могут быть очень объемными). Более того, некая алгоритмическая база может перевести некий круг задач в облать тривиальных, легко поддающихся проектированию сверху. Но до тех пор, пока нет этой алгоритмической базы, ни о каком "проектировании заранее" не может быть и речи. Другой яркий пример —
http://www.merl.com/people/perry/perry.html
На основе этой базы можно сделать (и делается) множество конкретных прикладных задач, но как можно "спроектировать с высшего уровня" сам алгоритм?
Здравствуйте, McSeem2, Вы писали:
MS>Вот объясните мне, дураку набитому, что это есть умно и мудро. Я безусловно согласен, что для всех тривиальных задач — это так. Но в мире есть много таких задач, где алгоритм первичен, а дизайн — дело наживное и в общем-то тривиальное.
МакКоннел, кстати, рекомендует не зацикливаться на проектировании сверху вниз. Равно как и снизу вверх
Задачи бывают разные, и надо всегда думать своей головой, а не кивать на указания авторитетов.
У него кстати еще много разных вариантов приводится, кроме этих двух — сверху вниз наискосок, слева направо по спирали и так далее
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Здравствуйте, dimon0981, Вы писали:
D>Верхний уровень. Нижний уровень. Это смотря откуда смотреть
D>Если в задаче алгоритм первичен, значит это и есть верхний уровень абстракции.
D>Будет лучше если заменить "высший уровнь модели" на более общее "высший уровень абстракции".
Совершенно верно. В задаче анблюра "проектирование и оптимизация сверху вниз" означает как раз алгоритм в качестве начала (а не выбор, скажем, между SSE и MMX.)
Это, кстати, вообще типичное заблуждение — считать "библиотечные" разработки принципиально отличающимися от UI-задач. То же самое, вид сбоку. Если ты пишешь какой-то тулкит, то просто пользователем выступает не Everyone, обрудованный Устройством Координатного Ввода+Устройством Символьного Ввода+Устройством Графического Вывода, а внешний код (в лице разработчика этого внешнего кода). Usability меняет свой вид, но никуда не девается: точно так же, как корявое неочевидное UI-приложение не имеет шанса найти своего пользователя, так и корявая неочевидная библиотека будет плохо распространяться.
1.1.4 stable rev. 510
