Evolve Your Hierarchy
May. 30th, 2006 04:38![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
aruslanПрочёл сабжевую колонку про Tony Hawk из мартовского Game Developer, что начиналась словами
"Until recently, game programmers consistently used a deep class hierarchy to represent game entities.
The tide is beginning to shift from this use of deep hierarchies to a variety of methods that compose a game entity object as an aggregation of components."
Меня раньше было довольно просто вывести на интересный спор, если проявлять достаточную упёртость.
Например, настаивать на ровно одном прочтении и ровно одной интерпретации.
Ровно одной точке доступа. Ровно одном паттерне взаимодействия.
Особенно сильно меня заводили намертво сцепленные код и данные, синглтоны, фиксированные форматы с запретом частично-вычисленных данных, старательный школьный data-driven типа "строго данные, никаких схем", псевдо-"классический" ОО в стиле "наследование-полиморфизм-инкапсуляция" и т.п.
Недопущение взгляда со стороны или другой точки отсчёта - как попытка оставить систему механистичной и мертвой.
Как противоположность wabi sabi.
Как противоположность живым, приспосабливающимся системам.
Я, конечно, понимаю, что идеи тэгирования достигли критической массы только с появлением тэгов в ЖЖ.
И inplace загрузкой заинтересовались только когда петух клюнул.
И идеи композиции и делегирования достигли умов широкой аудитории только с появлением вопросов по GoF на собеседованиях.
И многократно-прошитые коллекции и join против тупых иерархий потребуют WinFS, не иначе.
В последнее время я чрезвычайно ("по-постмодернистски") толерантен и циничен по этому поводу.
Особенно циничен, поскольку, наконец, вижу (с ужасом), что - окупается short term, и что - приносит доход даже long term.
Но, блин, ребята, ведь 2006 год идёт?..
"Until recently, game programmers consistently used a deep class hierarchy to represent game entities.
The tide is beginning to shift from this use of deep hierarchies to a variety of methods that compose a game entity object as an aggregation of components."
Меня раньше было довольно просто вывести на интересный спор, если проявлять достаточную упёртость.
Например, настаивать на ровно одном прочтении и ровно одной интерпретации.
Ровно одной точке доступа. Ровно одном паттерне взаимодействия.
Особенно сильно меня заводили намертво сцепленные код и данные, синглтоны, фиксированные форматы с запретом частично-вычисленных данных, старательный школьный data-driven типа "строго данные, никаких схем", псевдо-"классический" ОО в стиле "наследование-полиморфизм-инкапсуляция" и т.п.
Недопущение взгляда со стороны или другой точки отсчёта - как попытка оставить систему механистичной и мертвой.
Как противоположность wabi sabi.
Как противоположность живым, приспосабливающимся системам.
Я, конечно, понимаю, что идеи тэгирования достигли критической массы только с появлением тэгов в ЖЖ.
И inplace загрузкой заинтересовались только когда петух клюнул.
И идеи композиции и делегирования достигли умов широкой аудитории только с появлением вопросов по GoF на собеседованиях.
И многократно-прошитые коллекции и join против тупых иерархий потребуют WinFS, не иначе.
В последнее время я чрезвычайно ("по-постмодернистски") толерантен и циничен по этому поводу.
Особенно циничен, поскольку, наконец, вижу (с ужасом), что - окупается short term, и что - приносит доход даже long term.
Но, блин, ребята, ведь 2006 год идёт?..
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: May. 28th, 2006 22:00 (UTC)Хороший код - код, который хорошо выполняет свои задачи. А пидерастичность архитектуры какой-нибудь Unr. Engine - только повод пофлеймить, не более того.
no subject
Date: May. 28th, 2006 22:58 (UTC)У меня - только риторика и ссылки, уж извини.
Гнойники в подходах - это не повод флеймить, а повод задуматься.
Меня давно интересует вопрос - почему вирусный дизайн более живуч.
Почему кондовый дизайн завсегда победит хороший, но требующий чуть большей культуры.
Я пробовал и то, и это.
И могу на полном серьёзе сказать, что да, тупой незамутнённый подход не позволит per se выйти на above averages. И обойдётся он, в конечном итоге, дороже.
Зато он более приспособляем и гораздо более хакопригоден.
То есть когда по локоть в говне - как-то не замечаешь, что говна прибавилось.
И если вся работа построена на "дожить до релиза" -- количество говна актуально только как мера рисков.
И вот люди, отвечающие за тот самый "хороший код" либо вообще ничего не читают по специальности, либо читают, но "жёлтую" прессу.
Либо пишут, что "вот недавно, пять лет назад".
Из чего у меня, например, в своё время назрел вопрос - а что советовать читать своим?
И пока я пришёл к выводу, что давать читать что-то не из mainstream - противопоказано.
Ибо хорошие мысли вызывают правильную реакцию в мозгах, но - часто - неправильные последствия.
Вот тэгирование, композиция и замыкания стали mainstream механизмами, и можно их вкручивать в мозги.
Потому что распространённость достигла критической массы.
Что и наполняет меня оптимизмом.
no subject
Date: May. 29th, 2006 07:18 (UTC).
no subject
Date: May. 29th, 2006 08:44 (UTC)с цитатой или с её продолжением?
no subject
Date: May. 29th, 2006 09:44 (UTC)no subject
Date: May. 29th, 2006 10:17 (UTC)Про хакопригодность и по локоть в каловых массах.
no subject
Date: May. 28th, 2006 23:48 (UTC)Хорошо, если изменение архитектуры одной из подсистем не требует изменения архитектуры системы.
Хорошо, если изменение реализации одной из подсистем не требует изменения её архитектуры.
Хорошо, если изменение алгоритмов нижнего уровня не требует изменения реализаций каких-либо подсистем.
Но за 5 лет изменятся даже данные. А если нет, то "эта программа на Коболе проработает ещё пару десятилетий".
Т.е. ещё вопрос, делать "хорошую архитектуру", или "вроде как подходящее решение для данного момента времени", учитывая, когда именно придётся архитектуру менять (_в любом_, из этих двух случаев). Если использовать "вирусный дизайн", то остаётся только второй случай. Это хуже. Но проще.
no subject
Date: May. 29th, 2006 00:14 (UTC)То есть embrace change - не самое сложное, вообще говоря, в дизайне.
Вирусный дизайн - это не "выбери самое простое, но не проще".
Это штатная мозговая установка.
Объёмы copy-paste, плохой (по-настоящему плохой) код и т.п.
Видя "хороший" код, программист предполагает, что он будет вести себя адекватно. Но как только появляются хаки, всё становится сильно хуже, поскольку "хороший" код создаёт иллюзию, что вокруг безопасно, cozy and warm.
А говнокод с кучей copy-paste и минимумом параметризаций - не страшен.
Потому что "на войне - как на войне".
no subject
Date: May. 29th, 2006 09:50 (UTC)Если тебе сейчас напишут так, как ты сам писал "хорошую архитектуру" лет 5 назад, вполне возможно, что это тоже сейчас окажется говнокодом.
Т.е. мне кажется более важной возможность _быстро_ заменять архитектуру "хорошую тогда" на "хорошую сейчас". Потому что иначе говнокод гарантируется, как бы ни была хорошо спроектирована старая система.
no subject
Date: May. 29th, 2006 10:20 (UTC)Архитектуру можно только с людьми поменять.
Или со временем (оттого, что люди развиваются).
Никак не от требований.
То есть смена требований в первую очередь должна химическую реакцию в людях вызвать.
А уж там - хоть архитектура, хоть говнокод - без разницы.
Если есть реакция - будет результат. Разной степени дороговизны.
Если её нет - не будет ничего.
no subject
Date: May. 29th, 2006 17:43 (UTC)Что же касается меняющихся требований, то в таких условиях архитектура стареет намного быстрее. Проверено.
no subject
Date: May. 29th, 2006 00:40 (UTC)no subject
Date: May. 29th, 2006 10:52 (UTC)Только они вот не считают это достижением.
И стараются вменяемо решать встающие проблемы.
Кто как. DSEL, кодогены и т.п.
no subject
Date: May. 29th, 2006 11:11 (UTC)Все таки это действительнно нечто в голове. Думаю можно и на асме писать с компизицей и делегированием :-)
no subject
Date: May. 29th, 2006 12:00 (UTC)no subject
Date: May. 29th, 2006 11:15 (UTC)no subject
Date: May. 29th, 2006 02:56 (UTC)Ну и как бы да, есть такая альтернатива - на компонентах писать. Выпушенные продукты ты знаешь, делающиеся тоже знаешь, смысл худо бедно есть. Нет, я конечно всю статью не читал, но сомневаюсь, что там категорично все.
А про гибкость... Думаю, самые удачные системы - имеющие концепт, а не гибкость. Иметь разумный набор констрейнов для задачи, которые формируют на нее такой взгляд, чтобы было ясно что делать. Как пример - Крейтовый двежок
no subject
Date: May. 29th, 2006 07:13 (UTC)Что гибкость и универсальность нахер никому не нужны - это как бы очевидно.
Достаточно, чтобы было понятно, почему и что.
Скажем, у меня в Тахионе - No allocation, жёсткий in-place, статический scene graph, и т.д. и т.п.
Но я как бы не про это немножко говорю.
Я скорее про то, что народ - спит.
no subject
Date: May. 29th, 2006 07:20 (UTC)"кризис очевидно в головах" (ББ). И что? Я бы задумался над вопросом "кризис в головах и как заработать на этом денег".
no subject
Date: May. 29th, 2006 08:43 (UTC)Кризиса-то особо нет, для кризиса почва нужна.
То есть некоторое число вменяемых людей.
Когда стадо ведут на забой, это не называют "кризисом в стаде".
А вот с твоим вопросом - согласен на все сто.
no subject
Date: May. 29th, 2006 12:33 (UTC)no subject
Date: May. 29th, 2006 13:11 (UTC)no subject
Date: May. 29th, 2006 07:32 (UTC)no subject
Date: May. 29th, 2006 08:40 (UTC)Можно спать в майнстриме, можно - перпендикулярно.
Хуже - когда спишь и упираешься в "несовершенство" тека.
И потом, сонный, начинаешь с "несовершенством" бороться.
Вот здесь нужно аккуратно думать и катить фичи или людей.
no subject
Date: May. 29th, 2006 08:49 (UTC)Если наезд - я вздохну и обижусь.
no subject
Date: May. 29th, 2006 10:22 (UTC)Одна из характеристик main stream - течение.
Но русло - разной степени извилистости.
То есть весла ломать не стОит ;)
no subject
Date: May. 29th, 2006 12:04 (UTC)no subject
Date: May. 29th, 2006 13:14 (UTC)"Всё нахер переделать" - это не джедайская мысль, кстати.
Ибо leads to suffering.
no subject
Date: Aug. 4th, 2006 15:23 (UTC)жжёшь, определённо :) и да, не джедайская вовсе.
no subject
Date: May. 29th, 2006 13:30 (UTC)Везет... :-) А у меня что не день, то новый велосипед :-)
no subject
Date: Aug. 4th, 2006 15:25 (UTC)Семён Козлов, это вы?
no subject
Date: Aug. 4th, 2006 15:43 (UTC)no subject
Date: Aug. 4th, 2006 16:47 (UTC)Да, я.
no subject
Date: Aug. 4th, 2006 19:10 (UTC)no subject
Date: Aug. 5th, 2006 05:11 (UTC)Всегда пожалуйста.
P.S. А как получилось, что ты в Японии?
no subject
Date: May. 29th, 2006 07:18 (UTC)Ну и почему Bilas есть, а Дюрана - нет.
no subject
Date: May. 29th, 2006 05:04 (UTC)no subject
Date: May. 29th, 2006 07:10 (UTC)no subject
Date: May. 29th, 2006 07:15 (UTC)no subject
Date: May. 29th, 2006 07:14 (UTC)В конкретной индустрии - всем.
И каждый следующий год - делает отличие всё более выраженным.
no subject
Date: May. 29th, 2006 07:39 (UTC)что технологии и прочее очень интересное черным обезьянам меняются - это понятно...
no subject
Date: May. 29th, 2006 08:37 (UTC)Просто бабки начинают считать иначе.
И вместе с ними - стоимость инструментария.
И сколько игр делать одновременно, и на одном ли инструменте.
И насколько риски быть above averages окупят себя.
И можно ли нормально пропиарить-продать то г, которое пишут уже три года.
И то, что слепили за четыре месяца.
no subject
Date: May. 29th, 2006 09:07 (UTC)я о том, что ситуация как на рынке сбыта, так и на рынке инструментов может меняться сколько угодно, но принцип "стриги бабло по всей земле" стар как мир.
соотв-но до тех пор, пока технологии не сильно мешают принципу...
no subject
Date: May. 29th, 2006 10:32 (UTC)Сделать и удержать сервис или стандарт de facto куда как выгоднее, чем сделать продукт. XNA как брендинг мне куда более интересен, чем яйца или Cell.
no subject
Date: May. 29th, 2006 12:35 (UTC)no subject
Date: May. 29th, 2006 13:15 (UTC)Пока, во всяком случае.