Максим Кузнецов

По-хорошему нужен движок для моделирования и контроля бизнес-процессов. С учётом их версионирования. На Java в своё время пользовался Alfresco Activity ( https://www.alfresco.com/products/business-process... ). Есть comunity-редакция. В .NET есть WWF ( https://msdn.microsoft.com/en-us/library/jj684582.aspx ), но я сам им не пользовался.

Есть такая вещь, называемая фокус-фактором. Фокус-фактор показывает, какую долю времени в среднем тратит работник на действительно полезную деятельность. В самых лучших случаях значение этого коэффициента достигает 0,7, но можно считать хорошим результатом, если фокус-фактор достигает 0,6. В средних командах он близок к 0,55 (отсюда и "принцип умножения на 2").

Это очень важно учитывать при планировании работ. Так, если на выполнение некоторой задачи требуется 4 "идеальных" часа, когда исполнителя никто не отвлекает, то при фокус-факторе 0,6 он затратит на эту задачу не 4, а без малого 7 часов. Чувствуете разницу?

При этом у каждого члена команды фокус-фактор свой. И, если сроки критичны, нужно в планировании учитывать не среднее значение по больнице, а значение конкретных исполнителей конкретных задач. Но этого никто не делает.

Первый подход требует постоянной доступности внешнего стороннего сервиса. Без этого работать не будет совсем. Я бы делал кэш нужных данных в своей системе, обновляемый с заданной периодичностью клиентом, подключающимся к сервису на стороне ФИАС (лезть в БД, особенно чужую, напрямую не комильфо). Плюс такого кэша в том, что ваша система будет работать независимо от того, доступен ли источник данных на стороне ФИАС, или нет. Ещё один плюс - слой абстракции от внутренней инфраструктуры ФИАС: сервис будет меняться гораздо реже структуры БД. Дополнительно можно контролировать версии передаваемых данных.

А дальше - полёт фантазии. Кроме указанных вариантов можно рассмотреть ещё несколько решений. Например, по расписанию в БД заполнять некоторую таблицу-"витрину" нужного формата, из которой уже напрямую отдавать данные куда угодно. Такое решение удобно, если построение "витрины" происходит долго из-за объёмов данных. Заранее готовите данные и потом моментально отдаёте.

Вариантов много. По всей видимости, старая версия уже включала компоненты для .NET Framework 4. (1) Не переходите на новые компоненты только ради поддержки .NET 4.5, используйте старые версии. Либо (2) используйте конфигурацию для биндинга нужной версии компонентов. Либо (3) сделайте динамическую компоновку (плагинами, например), зависящую от используемой ОС. Либо (4) сделайте установщик, который будет ставить версии компонентов, зависящие от ОС. (5) Компоненты можно вынести в отдельное программное средство (сервис, консольное приложение), сделать такое средство специально для XP, и использовать редакцию либо для Win7/8/10, либо для XP... Вот уже 5 решений. Не считая принудительного перевода пользователей на Win7 ;)
Короче, проблема решаемая. Но придётся немного попотеть.

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

Architecture Skills Framework
Грубый перевод таблиц был здесь: Что должен знать и уметь архитектор

В целом, похоже, что у вас в команде есть несколько проблем.
Во-первых, либо есть проблемы с архитектурой, либо неверно составлен план разработки. Это может быть связано с игнорированием ограничений agile. Мне кажется, что присутствует и то, и другое.
Во-вторых, программисты не сильно мотивированы писать качественный код, либо не имеют возможности этого делать. Возможно, у них не складывается модель предметной области, и, исправляя одну бяку, они тут же вносят новую. Есть смысл подумать о специализации конкретных разработчиков (или небольших групп разработчиков) на конкретных направлениях. Попробуйте разбить крупный проект на несколько отдельных "изолированных" проектов, в каждом из которых следует рассматривать смежные подпроекты как внешние системы. Каждому подпроекту нужна своя команда. Это сделает проект управляемым и понятным всем участникам.
А дальше, соглашусь с Сергей Протько , "Тесты, TDD, рефакторинг, SOLID".

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

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

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

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

Мы используем Enterprise Library. Она позволяет реализовать комплексное решение для инфраструктуры проекта, включая логирование, мониторинг, контроль состояния, рассылку уведомлений и кучу других полезностей.
Подход к логированию описан здесь.

Ещё есть библиотечка для ASP.NET под названием Elmah. Тут есть небольшая статья.

Объективность требует более сложную оценку по структуре. Один фрилансер хорош при работе с криптографией, другой - с web-сервисами. Редко бывает то и другое одинаково хорошо. Нужно разработать более комплексную систему оценок. Мы оцениваем участников проекта по нескольким важным для нас параметрам с вариантами оценок для каждого параметра "не взаимодействовал с данным участником/80/90/100/110/120" Оценка 80 - у сотрудника нет достаточной компетенции. 120 - уровень эксперта с большим практическим опытом.

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

На события подписываются несколько наблюдателей: логгеры (журналирование в файл/БД/system event log), агент системы мониторинга (контролирует работоспособность системы), контроль состояния бизнес-процессов и другие. Каждый наблюдатель реагирует на свой набор событий, состав которых определяется настройками. Например, в файл логируются все события, а в event log - только критические ошибки и важные события. Наблюдателей можно отключать (например, можно отключить отсылку уведомлений на почту администраторам или в систему мониторинга), настраивать (менять размещение и название файла журнала, например) и т.д.

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

Как вариант, например, для JavaScript, JScript, VBScript:
"Использование Jint для динамического выполнения кода" (m-i-kuznetsov.livejournal.com/16260.html)
"Использование MS Script Control для динамического выполнения кода" (m-i-kuznetsov.livejournal.com/14114.html)
И да, DLR, как сказано AxisPod

Поищите книгу "Инфраструктуры открытых ключей" (О.Ю. Полянская, М. ИНТУИТ, 2007 г.)
Или пройдите одноимённый бесплатный курс www.intuit.ru/studies/courses/110/110/info