Максим Федоров

Обычно гуляю по папкам с командой:
du -sh ./*

Подходов масса, и все имеют свои недостатки и преимущества. Я обычно разбиваю на вменяемые "физические" сущности: адрес, телефон, компания, почта... в таком случае объединения в коллекции принадлежностей могут быстро сменять метод отношений от один ко многим к многие ко многим простым добавлением таблицы связей. В логике тоже будет всего 2-3 мелкие правки. Хранить все в одной таблице/сущности наиболее худший вариант.

Хорошей практикой служит написание прослойки или промежуточной модели между контроллером и моделью, которая и содержит в себе всю бизнес-логику
Её ещё называют сервисом
То есть контроллер управляет сервисом, который в свою очередь и дёргает модели

Экспертизы кода могут быть разные, зависит от того что за иск вам предъявили и что вы хотите доказать, например является ли код полностью аналогичным или происходил его рефакторинг.
Суд должен принимать любые доказательства относящиеся к делу, но оценивает он любые доказательства только на основании своего внутреннего убеждения, это закон.
В вашем случае 70% успеха будет зависеть от того какие вопросы вы поставите эксперту, и 30% от того куда попадет экспертиза. Сформулировать вопросы, на которые эксперт ответит в вашу пользу - это очень сложная работа. Просто спросите - есть ли заимствования кода получите полную экспертизу воды и возможно проигранный суд. Это аналогично вашему вопросу, вот наша ситуация - что будет. Общий вопрос - общий ответ. Вопрос является ли алгоритм обработки запроса программы Х от market.yandex.ru аналогичным и У. Является ли такой алгоритм общеупотребимым в аналогичном программном обеспечении? В зависимости от ответа требуйте предоставления доказательств разработки алгоритмов с нуля. Как вариант. Каждый вопрос эксперта оплачивается отдельно. Убедить суд включить вопросы в экспертизу надо тоже постараться, вообщем удачи вам, экспертизу типа истец-дудак никто вменяемый не даст.

Комментарии чень геморройная часть сайта. Это сложно реализовать, это грузит сервер, это спам. Я предпочитаю готовые решения:
https://disqus.com/
Самому надо писать то, что еще никто не реализовывал. А для новичка, так точно, комментарии не стоит делать. Вы вначале хоть немного yii и php подтяните.

unserialize()

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

Это как в шахматах средние игроки думают во время дебюта, а опытные просто играют по памяти свой любимый дебют и почти не думают над ходами во время дебюта. А такие мастера как Магнус Карлсен могут выиграть за 30 секунд у большинства средних игроков. Выглядит это пугающе(https://youtu.be/NTEj4moaay0 )

И примерно такая же разница между слабыми и сильными программистами. Это прежде всего физиологические различия и различия в уровне подготовки. Книги про продуктивность тут не увеличат производительность каким то радикальным образом. Скорее наоборот если человек со слабыми природными данными начнет много программировать то у него быстро наступит выгорание, потому что его ЦНС физиологически на это не способна и производительность в результате может упасть.

Со 100% вероятностью - никак

1. yii тут не при чем
2. Вы понимаете что then и when это принципиально разные слова?
https://docs.angularjs.org/api/ng/service/$q#when

На языке SQL такая операция называется LEFT JOIN

SELECT  product_features.feature_id, feature_values.value
FROM product_features
LEFT JOIN feature_values ON feature_values.id =  product_features.feature_value_id 
WHERE product_features.feature_id IN (1,2,3) AND  product_features.product_id = 1

Можно. Capistrano.

Вы пытаетесь объекта класса edBeanPHP\OODBBean сконвертить в int, смотрите строку 5199 в файле X:\home\recbook.ru\www\libs\rb.php

Имеем 4 колонки на kanban-доске:

1. Список заданий
   
2. В процессе
   
3. На проверке
   
4. Исполнено
   

Теперь о каждом чуть более детально.

Список задач, он же backlog - список того, что вообще надо сделать. Сортируется это дело по приоритетам, т.е. самая верхня задача самая важная, самая нижняя - самая не важная. Отдельно отмечу, что только в данный момент времени. Отметок "Важная", "Важная 1", "Важная 2", "Срочная", "Горящая" и т.п. быть не должно. Если задача есть в этом списке, значит она важна для команды. Ее исполнение необходимо для нормальной работы команды. Акцентирую Ваше внимание, что именно в данный момент. Как тимлид Вы можете сделать только одну доработку в этой колонке - присвоить цвет каждому подчиненному. Например, Иван берет только синие задачи, Николай только желтые и т.п. Срочнось задач в компетенцию тимлида не входит, это зона ответственности менеджмента.

В процессе - задачи, над которыми именно сейчас работают Ваши подчиненные. Не вообще работают, а вот конкретно в данный момент, когда Вы открывайте доску и смотрите на нее, Ваш человек сидит в IDE и пишет/отлаживает код. Колонка обязана иметь лимит. Все книжки рекомендуют начинать с 2n - 1, где N - количество людей в команде, а минус 1 потому что кто-то может с чем-то застрять и ему надо будет помочь. Порядок задач в этой колонке не важен. Важно только то, сколько они там находятся. У Вас должно быть какое-то время реагирования, т.е. если задача висит там 3-й день, то нужно спросить условного Николая, что у него там за проблема и не нужно ли ему там с ней помочь. Часто, это колонка разбивается на на две: в процессе и отложено. Вторая означает, что когда исполнитель начал работу над задачей, он не нашел, скажем, доступа к хостингу или данные к FTP/cPanel, предоставленные клиентом, оказались не верными. Колонка "Отложено" требует уже реакции менеджеров в духе "Звонок клиенту". Задачи от колонки "Отложено" менеджеры должны обрабатывать, дополнять и перемещать снова в backlog. Продуктовые команды, обычно, такую колонку не используют. Разного рода digital-агенства применяют это очень часто.

На проверке - думаю, из названия понятно. Ваш подчиненный завершил задачу, Вам/Менеджерам/Клиенту надо ее проверить. В эту колонку задачи могут переносить Ваши подчиненные, но из нее переносить задачи могут только менеджеры или Вы.

Исполнего или Готово - опять же, думаю понятно. Завершенные задачи. В конце рабочей недели по наполнению этой колонки можно оценить продуктивность команды или/и продуктивность конкретного разработчика, если Вы будите использовать схему "Человек - Цвет". Карточки из этой колонки отправляются в архив в пятницу в 19:00 или когда Вы там выгоняйте всех программистов из-за мониторов. Также, в конце каждой недели, должен чиститься backlog от более не актуальных задач. Помните что я писал выше? В первой колонке у нас только важные задачи, которые необходимы именно в данный момент. Если клиент "заглох" или "слетел" - его задачи из backlog должны быть отправлены в архив, вместе с завершенными задачами в пятницу в 19:00

Отдельно отмечу, что появление задач с метками "Важное 1", "Срочное", "Очень-Очень срочное" в любой системе управления, не только scram/kanban, говорит о том, что в компании слабый менеджмент. Есть задача. Ее либо надо сделать прямо сейчас или в ближайшее время либо ее нет смысла делать совсем.

Следует также помнить, что замена менеджмента и/или системы управления, ровно как и изменения в ней, должны исходить от собственика/директора либо при его одобрении и полной поддержки. В противном случае это очень быстро все заглохнет, окончившись не чем. Каким образом Вы донесете эту необходимость до своего Босса - уже вопрос отдельный.

Смотрите реализацию у крупных проектов на SPA. Поправьте если ошибаюсь, meduza.io, это SPA?