Андрей Хохлов

Получается, что я связующее звено между всеми отделами (Производство, Бухгалтерия, Логистика) - придумываю решение а индус все это дело кодит.

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

Code Review

По-русски это называется процессом рассмотрения кода, или просто проверкой кода командой. Появляется после того, как команда проходит через стадию говнокодерства редактированием файлов на сервере через FTP и начинает использовать современные средства управления версионированием кода, в которых можно делать Pull request (запросы на добавление вашего кода в общую базу, GitHub, GitLab).

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

Кроме code review, есть такая вещь, как стандарты. Она заключается в том, что существует некий общепринятый документ, который декларирует, как писать код, сколько делать отступов, табы или пробелы и т.д. Нередко он декларирует интерфейсы и тому подобное. В мире PHP это набор стандартов PSR. И все без исключений следуют этому стандарту.

Кроме этого существует ряд вспомогательных инструментов, таких как анализаторы кода, которые проверяют код на наличие потенциальных ошибок и прочие моменты. В мире PHP это Mess Detector и CodeSniffer.

В заключении отвечу, что такой должности нет и врядли она когда-нибудь появится.

Слежение за качеством кода это обязанность каждого разработчика.

Осознание этого приходит с повышением квалификации разработчика.

Ну вообще днище какое-то.
Для добавления таких привязанных к объекту сущностей обычно делают PATCH/PUT запрос с урлом типа /:resource_name/:resource_id/:entity_name.
В вашем случае что-то типа PUT /clients/:id/stocks

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

Я бы сделала так.
Страница со списком документов загружается как обычно, попутно подгружается список тэгов, который хранится как обычный массив строк, привязанный к профилю пользователя, сформированный как описано в вашем варианте номер 1. (Делать отдельную коллекцию для простых списков смысла не вижу, всегда лучше начинать с минимизации сущностей - бритва Оккама, ага :)
Когда мы загружаем страницу со списком, идет подгрузка тэгов. Все последующие обращения к другим страницам делаются асинхронно, следовательно, облако тэгов больше загружать не надо.
Я не знаю, что вы используете на клиенте, я работаю плотно с Angular, поэтому говорить могу только про него.
Технически это было бы сделано так - маршрут для списка документов прописан на сервере, идет возврат клиенту профиля со списком тэгов. А маршруты ангуляра содержат обращения к страницам. В случае первичной загрузки идет запрос на страницу номер 1 (как resolver для этого маршрута), последующие вызовы - просто асинхронно к выборке соответствующей страницы.

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

Ну дак обычнм селектом и сделать

1. Добавить бордер.
   
2. Отключить стрелочку
   

   -webkit-appearance: none;
      -moz-appearance:    none;
      appearance:         none;

   
   
   
   
3. Добавить background c вашей стрелкой
   
4. Остальное по вкусу
   

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

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

Какие проблемы можно предотвратить?
- запись в переменную другого типа данных
- перезапись константы
- затирание/перезапись метода
- чтение не обработанных данных напрямую
- чтения данных без разрешения
- и т.д.

Вариант 1, разные app для каждого домена:

'use strict';
const http = require('http');
const express = require('express');

const appWWW = express();
const appSub = express();

http.createServer((req, res) => {
  switch(req.headers.host) {
  case 'example.com':
  case 'www.example.com':
    appWWW(req, res);
    break;
  case 'sub.example.com':
    appSub(req, res);
    break;
  }
}).listen(8080);

Вариант 2, один app, переписываем url с помощью middleware:

'use strict';
const express = require('express');

const app = express();

const WWW_RE = /^www\./i;
app.use((req, res, next) => {
  const host = req.headers.host.replace(WWW_RE, '');
  req.url = '/' + host + req.url;
  next();
});

app.listen(8080);

Перемудрили. Всё должно быть очень просто. Что такое тип медиа? Музыка или видео? Так по

/movies/genre/{id}/film/{id} - фильмы
/music/albums/{id}/tracks/{id} - музыка

Далее. Если я знаю id трека или фильма мне надо дать возможность обратиться непосредственно к нему:

music/track/{id} - всё

Если я не знаю какой трек мне нужен я прошу все треки из направления музыкального, например rap у него id=13

music/style/13

По этому запросу выдаются пачки направления по 100, 300 или 1000 штук в зависимости от ресурсов и можно указать пагинатор

music/style/13/2 - вторую страницу направлений мне покажите

Именно поэтому параметры лучше передавать в явном виде в url типа style=13&page=2 потому что так не запутаешься что такое 13 и что такое 2.

Если я совсем ничего не знаю и жанры тоже должен быть вспомогательный метод для получения всех жарнов, как у ВК для получения городов например. Запрос вида:

music/allganre?page=0

отдаёт 100 пар вида "название жарнра -> id" так сделав 5 запросов с page=0/1/2/3/4 я в своём приложении смогу иметь всю базу возможных жанров. Можно сделать метод что бы получить жанр конкретной песни:

music/getganre?track=1456

И т.п.

music/getalbums/1456 - получить все альбомы исполнителя
music/detailalbum/1456 - получить все данные об альбоме (год выпуска и т.п.)
music/tracksalbum/1456 - получить список треков конкретного альбома

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