Станислав Макаров

std::vector<std::vector<int>> vector_of_vectors;
vector_of_vectors.push_back({ 1,1,1,1,1 });
std::cout << vector_of_vectors << std::endl; // [[1,1,1,1,1]]
vector_of_vectors.push_back({ 1,1,1,1,2 });
std::cout << vector_of_vectors << std::endl; // [[1,1,1,1,1],[1,1,1,1,2]]

https://ideone.com/GIV9dW

Разработчики объясняют это тем, что они используют TypeScript, и он находится в папке src, поэтому вот так все собирается

Логично, нормальное решение.

Не нравится идея копировать dist и все вложенные папки

А в чём проблема? В dist не должно быть лишнего хлама, .git и прочего добра, по сути это готовая сборка приложения для деплоя, почему бы её не скопировать?

Не рекомендуют запускать npm install заново на сервере, так как по их мнению могут подтянуться совсем другие версии

А нехрен позволять npm-у ставить нефриженную версию в package.json. Нам вот уже настохорошело что проект ломается сам по себе из-за выхода новых версий библиотек, и мы зафризили все пакеты. Это нормальная ситуация, если у вас не библиотека, а конечное приложение. package-lock.json пытались использовать, но потом отказались - в версиях NPM 5.0-5.2 он работал отвратительно, сейчас уже может получше, не знаю.

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

Более правильная реализация:
https://developer.mozilla.org/en-US/docs/Web/JavaS... , Emulating private methods with closures

проблема у такого подхода - всё это делается ценой рантайма - на каждый объект будут свои инстансы методов. Хотите нормальную инкапсуляцию? Берите TypeScript.

проверка "правильности/соответсвия" возвращаемых данных определенными функциями

Это есть модульное тестирование, см. Catch.

проверка на используемую память(сколько используется, было использованно за весь цикл существования приложения)

Погуглите "memory profiler" (например, valgrind.org/docs/manual/ms-manual.html ). Я обычно в Студии профайлю, с автоматизацией этого процесса пока не сталкивался, но думаю возможно.

проверка правильности порядка записи в бд

проверка того что в сеть уходят данные которые ожидаются от программы

Тут вам нужно замокать клиента к бд и сетевой сокет/поток (в зависимости от того как это всё реализовано, без подробностей сложно советовать), и вместо реальной отправки данных/записи в базу делать нужные вам проверки.

Нет, прежде всего потому что дженерики в шарпе - это не шаблоны, и работают они не на уровне AST, как в плюсах.

Вы не можете вызвать "функции одного потока в другом". Каждый поток должен сам вызвать то, что ему нужно.

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

Более конкретно ответить можно только зная какими библиотеками и API вы пользуетесь в вашем проекте.

У вас стоит тэг Windows - поэтому конечно RDP, о чём тут можно говорить-то. Зачем вообще в локальной сети задумываться о TeamViewer и аналогах. Этот TeamViewer я смотрю хорошо заходит - все уже и забывают про "родные" протоколы.

А разве в вашей таблице "Личности фильма" первичный ключ не появляется естественным образом? Зачем ещё нужен суррогатный?

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

1. Низкоуровневые задачи, где нужно иметь минимум абстракции от оборудования. Я лично хоть и не разделяю анти-C++ настроений Линуса, вполне согласен с тем что ядру полезно быть написанным на Си. В C++ есть довольно много абстракций, влияющих на исполнение кода, есть некоторые вещи "под капотом", которые могут быть недопустимы в низкоуровенвом коде.

2. Большие проекты, где сложно форсировать code-style. С++ - это такой язык... Он настолько разнообразен, что прежде чем некая команда сядет писать код, она должна выбрать некоторое ПОДМНОЖЕСТВО языка, и использовать его. Иными словами, Плюсы - это большой ящик с инструментами, и вовсе не обязательно (даже вредно) использовать сразу все. Важно отказываться от каких-либо возможностей или практик, особенно устаревших (а таких в C++ немало, "идиоматический" код на C++03 и C++17 - очень разный). Кто не хочет со всем этим заморачиваться (вспомним опять таки Линух - огромный проект с огромным числом участников) - вполне могут выбрать Си. Ведь можно считать, что выбор языка Си - это выбор только необходимого инструментария из того что предлагается в C++ (только помните что сейчас это всё-таки разные языки).

3. Программирование в сильных ресурсных ограничениях. Например под микроконтроллеры. Хоть в С++ программист "не платит за то чем не пользуется", иногда стандартные реализации различных механизмов недопустимо тяжелы или неэффективны. Например, если у вас очень медленный чип или мало памяти, возможно вы заходите свою собственную реализацию полиморфизма. Какой тогда смысл говорить что вы пишете на C++, если не сможете использовать его механизмы и то, что предлагает компилятор.

Вместо searchWindow.searchType.employByRoom
нужно Search.searchType.employByRoom

И дайте уже всем нормальные имена.

Заказчик хочет чтобы разработчик сделал сложное приложение.

Причина 1: обычно заказчик хочет, но не знает чего конкретно. Фишка в том, что разработка приложения, у которого ещё нет аналога - это... не только разработка приложения. Это ещё и выяснение того, что действительно нужно, начиная с пожеланий по UX, и заканчивая оптимизацией бизнес-процессов во всей компании (это когда заказчик внезапно говорит "слушайте, и правда, на кой чёрт мы печатаем эту накладную каждый раз").

КПД получается крайне низок.

Причина 2: вы не учитываете причину 1 при расчёте КПД и думаете, что проделали мало работы. Да, приложение ещё не готово или делается очень долго, но это не потому что вы мало работаете, а потому что работы намного больше, чем казалось.

но идёт на удаление или переделку из-за того, что что-то не так.

Причина/особенность 3: иногда это неизбежно: бизнес меняется, потребности - тоже.
Иногда этого можно избежать, не заводя требования слишком "далеко" - очевидно, нет смысла реализовывать то, что УЖЕ СЕЙЧАС кажется неподходящим под требования, НО это далеко не всегда вовремя замечают. Над проектом работает много людей, у всех немного разные представления о задаче, или ещё хуже: не все и далеко не всегда говорят о проблемах с системой, которые уже виднеются "на горизонте", говоря что "в ТЗ всё написано, а мы делаем по ТЗ". Можете погуглить статьи о стоимости ошибок на разных этапах разработки.

Причина 4: заказчик, разработчики или и те и другие не умеют останавливаться и выбирать необходимый и достаточный функционал для первого или очередного релиза. Я в последнее время убеждаюсь, что это целая наука - вовремя остановиться и не расширять список "супернужных" фич, из которых треть окажется почти невостребованными. Особенно часто это бывает, когда бизнес уже работает как-нибудь (например, на экселевских табличках или Access-овских базах), а теперь пришла пора автоматизации, но релиз постоянно откладывается, потому что "и это хочется, и то бы сразу сделать". Иными словами, иногда нужно решиться на гарантированные переделки в будущем ради релиза сейчас. Оценка возможности и стоимости таких "переделок" - т.е. подождать и переделать сейчас или зарелизиться и переделать потом (соответственно, с удорожанием "переделок") - и есть та самая наука. Разработчик обычно видит только архитектуру, и раньше понимает её недостатки/ограничения, ему сложно решиться на релиз того, что не будет идеально решать поставленную задачу.

На чем написать — REST API?

написать ПО которое работает с REST API.

Это конечно не взаимоисключающие вещи, но вы уж конкретизируйте - таки сервис вы пишете или клиент.

Language Standards Supported by GCC, опция -std=...