Артем Кисленко

Все упирается в объемы данных. Если предполагаемое количество записей не будет исчисляться миллионами или даже десятками миллионов, то лучше придерживаться нормализации. Бардака будет меньше. Иначе да, денормализация или всякие решения типа nosql.

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

Нет такого, что рекомендуют или не рекомендуют. Все зависит от вашего проекта. Те доводы, которые здесь перечислены насчет CI итд - правильные. Дополнительным аргументом в пользу deploy-скриптов может быть, например, необходимость изменения схемы БД на проде с очередным апдейтом, чего git не сделает сам по себе. Плюс, обновление через git - не очень рабочий вариант в случае компилируемого кода. Конечно, можно навернуть поверх гита каких-нибудь билдеров, но этому уже точно на проде не место.

Но если, например, проект простой, компилируемого кода нет, и в команде есть договоренность о том, что в master попадает только протестированный код, то никакого криминала в том, чтобы сделать git pull, нет.

Действительно, это довольно удобно. Но в такой простоте есть риск выкатывания на production не протестированного должным образом кода. Использование системы continuous integration с настроенными автотестами дает некоторый уровень гарантии.

Распределить работу покомпонентно.
Любые макеты можно разобрать на следующие компоненты и этапы.

0. Создается общий репозиторий для проекта.
Все работы ведутся сразу в нем. Чем чаще делаются коммиты, тем раньше вылезут и будут исправлены проблемы. У каждого компонента есть свой css/less/sass файл, чтобы легче управлять кодом и избегать merge-конфликтов.

1. Основные строительные блоки:
- Типографика и стили для контента (таблицы, цитаты)
- Элементы форм + стили валидации
- Декоративная графика (иконки, плашки)
- Модульная сетка (сразу респонсив)

Каждый верстальщик отвечает за свой кусок работы и создает демо-страничку с перечнем компонентов, которые он сверстал. Работа верстальщиков не пересекается.

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

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

После этих двух этапов у команды готов UI-kit проекта.

3. Предварительная сборка всех шаблонов страниц с реальным контентом

Работа распределяется постранично. Каждый верстальщик копипастит блоки из UI-кита и наполняет реальным контентом. В конце команда оценивает, где что еще нужно доделать.

4. Редкие кастомные компоненты и модификации

На основе проблем, которые вылезли на третьем этапе, каждый верстальщик допиливает блоки, за которые он отвечает.

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

Обо всем этом говорят Atomic Design, ITCSS и многие другие методологии.

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

1. Самое очевидное, простое и правильное (при условии, что для вас этот вопрос все еще актуален и насущен) - связаться с этими людьми повторно и уточнить лично у них, о каких именно знаниях идет речь. Как калька: "Добрый день! Меня зовут Артем, тогда-то я был у вас на собеседовании, мне отказали, сославшись на нехватку теоретических знаний. Вы не могли бы мне помочь советом, каких именно знаний мне не хватает? Эта информация помогла бы мне их приобрести...." Ну как-то так...

2. На будущее, при возникновении подобных ситуаций, задавайте такие вопросы прямо на собеседовании. Иначе потом снова будут эти "гадания на кофейной гуще".

3. По каким критериям вы собираетесь выбирать источник знаний, предложенный вам мнением людей, каждый из которых представляет собой уникальную смесь возраста, знаний и опыта, а, соответственно, свое видение ситуации?

4. Обучения для себя, обучение в ВУЗе, и обучение для конкретной работы - суть разные вещи. Вам нужно третье, насколько я понял. Для этого нужно четко понимать, что нужно работодателю. И вариантов хорошего результата собеседования есть два - вас взяли на работу; вас не взяли на работу, но вы знаете, что конкретно вам еще нужно сделать (чего вам не хватило), чтобы вас взяли.

Смоделируем ситуацию:
Вы пришли на собеседование. Вам отказали: "У вас недостаточно теоретических знаний". Вы сказали "Ок" и ушли. Задали вопрос на Тостере, вам предложили 15 вариантов ответа - надо учить такие-то алгоритмы, такие-то паттерны и прочее... Вы перезваниваете рекрутеру, задаете вопрос, а вам отвечают, что вам не хватает теоретических знаний о протоколах передачи данных... Ну к примеру...

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

Такова моя точка зрения. Удачи!

P. S. Немножко юмора, касательно знаний, заказчиков и инструментария для решения конкретной задачи.

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

Советую прочитать любую короткую книгу по алгоритмам и структурам данных.
Есть видеокурсы на эту тему:
6 лекций по 1.5-2 часа
https://habrahabr.ru/company/abbyy/blog/251561/