LuciferOverLondon

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

Перспектива «переписывать все, поняв, что с данной архитектурой приходят какие-либо ограничения» и «что за ******* это написал?» — неизбежна. Другое дело, что, если вы будете двигаться методично, а не перескакивать к DI, не разобравшись с ООП, то вы сами увидите, почему и для чего вам нужна другая архитектура, и сами будете критично смотреть на свой и чужой код.

Вы ещё не понимаете смысла классов — это ясно из того, что вы вообще рассматриваете вариант «функции и неймспейсы».
Сделайте сначала самый простой вариант: разделяйте код по смыслу на классы и вызывайте их напрямую — либо создавая объекты там, где они используются, либо передавая через аргументы и сеттеры. Тогда (я надеюсь) вы разберетесь, зачем нужны классы и, со временем, — для чего придуманы DI и прочее. Ибо каждая методология в кодинге нужна для решения конкретной проблемы, а если вы не знаете проблему, то не сможете правильно применять технологию.

увидел бурундука только после пары минут медитации на картинку

По поводу «откуда брать данные для объектов — заполнять руками в конструкторах для тестов или как?»

Базу забить можно и автоматически, генерируя объекты/записи со сколько-нибудь адекватными данными. Строки можно генерировать либо просто случайные, либо по словарю, либо — библиотеками для генерации псевдоосмысленных строк (на хабуро недавно пролетала такая в q&a, кажется).

Другое дело, что в тестах вам нужно тестировать поведение кода при определенных условиях, а значит — нужно прямо в них класть в базу то, что будете тестировать. С учетом граничных условий, обработки ошибок и т.д. Следовательно, надо либо прописывать вручную то, что должно попасть в базу перед тестом, либо, если в тесте нужен большой объем данных — сгенерировать его заранее, и переносить, например, из подготовленного xml/json в тестовую базу.

Тоже интересуюсь этим вопросом, но пока не видел особо интересных решений. По ощущениям, хорошо тестируемая связь с БД это ActiveRecord. Либо, более гибко, но с теми же минусами — конструктор запросов (а-ля, для PHP, $db->select()->where()->...).

Основная проблема — потеря гибкости и эффективности: все варианты записи и выборки приходится сводить к тем, которые понимают базовые классы, и которые, соответственно, тестируются. Т.е. не получится использовать для отдельных случаев расширенные фичи СУБД, если они не заложены в методах класса (FORCE INDEX? подзапросы?). ActiveRecord, в случае PHP, ещё и получается накладен для процессора и памяти.

Есть, конечно, вариант реализовать стандартные методы в базовых классах, а для особых случаев определять в классах конкретных объектов и тестировать уже там.

Выборка из нескольких таблиц, как мне кажется, — не принципиальное препятствие для ActiveRecord, т.к. можно определить для этого в коде стандартные средства.

Другой вариант, как развитие конструктора запросов — это собственный язык запросов, вроде того, что есть в Doctrine. У меня не дошло до его использования, но могу предположить, что в свой язык/конструктор можно закладывать последовательно всё больше функционала, бесконечно приближая его к SQL (и, соответственно, идеал — это полностью покрытый тестами парсер нужного диалекта SQL, переводящий запросы в методы языка программирования).

Не знаю, как в .net'е с собственными языками запросов. Слыхал, что там для этого есть нечто под названием LINQ.

По причинам прагматического (медленно и объемисто) и личностного (зачем мне этот геморрой) характера, ни ActiveRecord, ни конструкторы/языки запросов в текущих весьма нагруженных проектах не применяю, а других выходов не встречал. Поэтому остается только тестировать конкретные модели, дублируя методы с выполнением в памяти.

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

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

Возможно, вам нужна вот эта книга www.ozon.ru/context/detail/id/126954/
Хотя я сомневаюсь, что кто-то, интересующийся веб-интерфейсами, её не читал.
Плюс у Нильсена есть ещё несколько книг с более конкретными заголовками, на том же озоне.

как насчет реддита?

Я по опыту самообучения вывел для себя лично одно правило, которым, как мне кажется, пренебрегают и в школе, и в вузах, и в самостоятельных попытках освоения чего угодно.
Нужна обратная связь. Надо понимать, к чему можно прийти в результате, и где находишься сейчас. Желательно ещё до первой написанной строчки и первой прочитанной книги. А в процессе проверяем, продвинулись ли вперед и что умеем теперь. Причем это не в дневнике и не голове преподавателя, а в своей. Иначе нет понимания происходящего и нет мотивации.

Я, к сожалению, осознал этот процесс только на десятом году после того, как меня перестали учить и я стал учиться сам. Поэтому могу только предположить, что стоит рассказать, к чему приводит знание алгоритмов, например, а к чему — изучение юзабилити сайтов.

Ну а дальше — по веб-программингу, например, я поглощал всю литературу, пока не начал чувствовать, дает мне очередная книга что-нибудь новое или нет. И практика, да.

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

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

Система контроля версий нужна, потому что с ней жизнь в тысячу раз лучше, чем без неё.
Это не очевидно сразу, зато становится ясно, когда она пару раз поможет при крупном факапе, и когда разработчиков будет больше одного.
Про SVN ничего не слушайте. Двадцать первый век на дворе, изучать SVN сейчас это маразм.

решение попроще — sorted set
ключ — <название>_<дата>_<час>, значение — число, прибавляется через zadd
в случае с setbit нужны будут блокировки, насколько я понимаю. с zadd — не нужны
старую статистику можно скидывать в базу, например