Владислав Килин

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

Пользовательские запросы, таким образом, будут отправлять сообщение каким-то высокоуровневым акторам, которые в свою очередь будут отправлять новые сообщения, создавая граф действий. Любой процесс можно будет наглядно представить в виде такого графа.

Что касается вашего конкретного кейса, у меня создалось впечатление, что вас скорее интересует работа с единым хранилищем данных игровых объектов. Для этого тоже есть масса интересных решений, например Unidirectional Data Flow.
Хранение состояния игры в одном единственном месте, обращение к нему через прослойки-мапперы. Есть несколько вариантов реализации перехвата изменений - это может быть иммутабельное состояние, для которого достаточно будет считать дельту между старым и новым, публикуя изменения глобально, так чтобы участки программы, которым эти изменения интересны, сами их подхватывали, либо реактивное состояние, которое запоминает, кто к ней обращался за какими данными и уведомляет их о конкретных изменениях непосредственно в момент их применения.

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

Но в любом из этих случаев, как грамотно сказал один программист: "Архитектуру легко придумать сложной", имея в виду, что нужно стремиться ее упрощать.

Простой знак равенства в C-подобных языках - это оператор присвоения. Как правило, он возвращает результат присвоения. Двойной знак равенства - это оператор сравнения, и возвращает он bool.

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

В вашем конкретном коде очевидно, что вам знакома операция присвоения (len = len + 1), но в этом случае достаточно воспользоваться операцией инкремента (len++).

Попробуйте:

var inputs = $(".control-group .control-group input").not(".control-group .control-group .control-group input");

Не самое оптимальное решение, но хоть так. А вообще говоря, я бы рекомендовал вам пометить нужные вам инпуты своим классом. Если они генерируются на сервере, это будет проще простого, если на клиенте - не менее просто, а если вы их пишете руками - то тогда вообще задача становится тривиальной. Тогда вам достаточно будет выбирать их как-нибудь $(".control-group-input") так.

Странное ощущение, что это троловопрос. Тем не менее.

Вы же понимаете, что методология БЭМ именования классов касается лишь постольку поскольку? Никто из тех, кто пользуется БЭМ в жизни не пишет все эти названия классов вручную, код на выходе может быть тяжеловесным, но та его часть, с которой работает разработчик - лаконичная и адекватная. Хотя, конечно, это зависит от вашего навыка проектирования и разработки. В самом Яндексе, уверяю, далеко не всегда код симпатичный и удобный.

Если вы собрались переводить ваш сайт с одного подхода на другой, вы так или иначе встанете перед дилеммой: переписывать все или переписывать не все. Другой вопрос, что двойственный подход может стоить вам куда больше полной переписки.

Исключительно в ваших силах не превращать все в выгребную кучу. Я, например, пользуюсь совершенно тривиальным подходом в верстке, который на достаточно серьезных проектах так и не скатился в тартарары.
1. Побольше частичных представлений данных. Конечно, не на каждый чих, но на каждую более-менее абстрактную часть модели.
2. На каждое частичное представление - свой css-файл.
3. Каждый элемент взаимодействия с пользователем - свой js-компонент.

Обычный todo-mvc превращается с таким подходом вот в такую структуру:

todo/
todo.view
todo.css
todo.js
todo_test.js
todoitem/
todoitem.partial
todoitem.css
todoitem.js
todoitem_test.js

Каждое представление состоит из маленького куска верстки, редко больше 50 строк. Каждый css- и js-файл - аналогично. Последний проект, который я делал по такой схеме пережил два года, примерно 10000 коммитов верстки, представлял собой мастер оплаты, веб-приложение и три админки к нему, и до сих пор адекватно функционирует и изменяется.

Я бы все-таки настоятельно не рекомендовал вам использовать селекторы ID именно в CSS по одной простой причине.

Движки рендеринга Gecko и Webkit при формировании Reflow и Layout соответственно строят индексы по ID ровно таким же способом, как и по имени класса. В качестве побочного явления - вы можете написать примерно то же, что и здесь, и код будет работать именно таким образом. Как по мне, это несколько неочевидное поведение, что стили применяются ко всем элементам с таким идентификатором, а не только к первому.

Многие разработчики, да и начинающие верстальщики путают концепцию CSS и их селекторов с особенностями языка XML. Надо понимать, что ID в XML - это строгий параметр, по которому строится индекс с BST, который позволяет быстро находить первое совпадение идентификатора (то же происходит и в JS при вызове document.getElementById("test")), но в CSS и при построении лайаута все гораздо менее строго. И следует заметить, что сами разработчики браузеров решили так сделать, основываясь, вероятнее всего, на концепции того, что верстальщикам нередко приходится повторно пользоваться стилями, описанными для селекторов ID.

Таким образом, с точки зрения быстродействия "#" ничем не отличается от ".", по крайней мере, в современных вебкитах и фаерфоксах. Теперь что касается точки зрения good practice.

Я лично занимаюсь версткой уже почти десять лет, и точно для себя определил, что в работе, когда речь заходит о чужой или смежной с чужой области ответственности (а CSS - это смежная с дизайном область верстки), ничего уникального не бывает в принципе. А раз так - идентификатор может и запутать.

В своей практике я всегда использую идентификаторы для тех нод, которые участвуют в JavaScript, и в уникальности роли которых я уверен. Конечно, там тоже иногда приходится менять, но гораздо реже, чем в CSS. Но для визуального отображения я всегда использую классы, чтобы иметь полное право не писать код повторно, если вдруг дизайнер захочет вставить "тот самый единственный на весь сайт хэдер, его точно больше нигде не будет" в другую часть страницы.

Ну а что касается аргументов про "больше кода", могу предложить таким борцам за лишний десяток знаков перейти на шаблонизаторы; или перенять даже целиком концепцию БЭМ, тогда код совсем в разы уменьшится.

Очевидно, самописное что-то, там же урл явно проглядывается.

$(window).load(function(){
	$('.fixBlock').liFixar({
		side: 'top',
		position: 0,
		fix: function(el, side){
			el.addClass("fixed");
			el.liFixar('update')
		},
		unfix: function(el, side){
			el.removeClass("fixed");
			el.liFixar('update')
		}
	});
})

.hr li {
    background: #FFF;
    color: #000;
}
.hr .fixed {
    background: none;
    color: #fff;
}
.hr .fixed:hover {
    border-bottom: 1px solid #aa5;
}

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

Можно написать как-то покороче, ИМХО:

arr = arr || [];

Это, конечно, попахивает немного, но для сведущих в JS код вполне прозрачный.