Артем Воронов

Какие инструменты знаете - такие и используйте.

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

Более правильный способ - совмещать и пробовать все.

Воспользуйтесь поиском по форуму, подобных вопросов множество.
Не обязательно иметь реальное устройство. На первое время Genymoution будет достаточно

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

Зависит от качества туториалов.
Если будете постить там примитивные вещи, типа "учимся подключать %random jQuery plugin% и делать с его помощью примитивную фигню", то толку почти никакого не будет. Ну как максимум зачтут как плюс на интервью, и то не в серьёзной конторе.
А вот если будете постить какую-то реальную и возможно даже уникальную годноту, аля "создаем реалтайм визуализацию невероятной херни с помощью d3.js с динамичной подгрузкой данных", то от этого будет дофига профита. Во первых будете пиариться как специалист (я как бы подразумеваю что будет все на английском, ибо на ру слишком малая аудиторя по сравнению со всем остальным миром), во вторых любой адекватный работодатель/клиент на фрилансе увидев такой хардкор с хорошим объяснением будет истекать слюнками (тут естественно подразумевается нормальный работодатель/клиент). Круче хардкорных и классных туториалов обычно бывают только какие-нибудь награды и выступления на известных конференциях.

Все можно сделать.... (как бы странно это не звучало....)
1. Нужно составить схему архитектуры, создать список классов и их методов, функций и т.д..
2. Наложить файлы на архитектуру, чтобы понимать где что делается.
3. Затем, рефакторинг архитектуры и кода (если необходимо и есть время).
Продолжать работу.

PS: не очень приятная работа, однако без неё однозначно всё встанет в ближайшем будущем на этом решении без необходимого понимания и документации разработчика.

Не волнуйтесь, вас уволят и правильно сделают. И вот почему.
Начну со стороны хорошего бизнесмена:
У него уже есть cms и crm, которую он пилил 5 лет, умеет продавать и знает. Да, так получилось, свой велосипед, ужасно написанный, но это его не волнует до тех пор, пока она кормит и его и всех его подопечных. Отказаться от неё означает не только огромные временные затраты на смену всего, начиная от обучения программистов как её пилить, заканчивая обучением всех, кто будет её касаться. Так же это означает поддержка уже двух систем, старых клиентов со старой и новых с новой. Но самое главное - это высокий риск того, что продавать её будет тяжелее.

Со стороны хорошего разработчика:
А хорошему разработчику вообще до фени, с чем ему работать. Спросите у опытных. Эмоционировать при виде говнокода и велосипедов - это максимализм юного программиста. Разработчики с опытом умеют погружаться в любой велосипед, в любой говнокод и работать с ним. А потому что они уже навидались и в своё время тоже кричали и пытались перевернуть мир, но, кому это надо? Вы - наёмный работник, вы не должны писать красивый код, вы должны решать бизнес задачи. Бывалые так и делают, просто иногда про себя вздыхая, т.к. чувство прекрасного всё же не убить :)

Уходить.

Не очень понял.
Напрямую ссылку с объекта из процесса в процесс не передать. У процессов память разная. Процессы объекты друг друга не видят.

Если вам нужно только состояние объекта: например, в одном процессе тем или иным способом инициализировали и передаете во второй процесс. То тут достаточно, чтобы в процессы были загружены сборки с типом вашего объекта, и через сериализацию склонировать ваш объект.

Но поскольку вы пишите, что вам сериализация не подходит, могу предположить, что вы хотите из одного процесса обращаться к методам и свойствам объекта другого процесса, чтобы это вызывало некий отклик в первом процессе (ну допустим через события генерирующие при изменении состояния объекта). Тогда во втором процессе нужен некий прокси-объект, который, когда обращаются к его методам и свойствам, будет посредством некой системы сообщений обращаться к методам и свойствам исходного объекта. Это похоже на .NET Remoting или WCF.

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

По сабжу - форумы.

Посоветую определиться зачем вам знать "языки" и какая область интересна.

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

Как всегда, идет идет логика, потом бац - подменя понятий.
Где пруф или как из вашего поста вытекает, что:

стремятся сделать все без программирования на чистом css?

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

JS - это язык программирования. Он предназначен для вычислений и передачи контроля. Хоть это и язык общего назначения, но анимации и стиль - явно не его первоочередная задача. И решается она с его помощью не лучшим образом.

Не знаю, что вы имеете в виду под "перейти в область", если вы программист, то вам стоит не "переходить", а специализироваться, если вам это интересно. Я это говорю как человек, который сейчас плотно занимается ГИС-системами - опыта в этом направлении пока маловато, но также как и у вас - есть большой интерес и обоснованное ощущение полезности разрабатываемых проектов (в противоположность многим другим разработкам в IT). Поэтому просто продолжайте программировать и постигайте карты, начиная с простейших вещей. Вы много с чем столкнетесь, для меня самым сложным пока были системы координат и неевклидова геометрия с ними связанная. Собственно, в этом и вся геодезия.
При всем этом я не берусь называть себя геодезистом, я по прежему программист, ГИС это скорее специализация. Ничего нереального в вашей задумке нет, область большая и востребованная (особенно сейчас, когда наконец проснулись отечественные информационные системы, желающие перевести побольше дореволюционных бумажных сведений в удобоваримый вид).
Высшее образование вам понадобится (это по закону так), только если вы захотите плотно заняться именно картографическими данными - межеванием, измерениями, подготовкой документов и прочими делами. Лично мне это пока не нужно было.
Могу вам накидать кучу аббревиатур и технологий, с которыми успел столкнуться за 3+ лет (я дотнетчик, поэтому и набор соответствующий):
1) PosgtreSQL + PostGIS - некоторое врпмя сидели на MySQL, но потом перекатили проект сюда, возвращаться и не думали, все-таки это стандарт де-факто в ГИС СУБД
2) NetTopologySuite - дотнетовский клон JTS - библиотеки, реализующей основные примитивы и алгоритмы обработки геометрии (точка, линия, полигон, поиск пересечений, касаний, расчет площади и т.д.) - пока хватает за глаза;
3) NHibernate в комбинации с NHibernate.Spatial - ORM №1 для нас. Начинали разработку, когда EF еще пешком под стол ходил, но и сейчас я бы выбрал ее, очень мощная либа, особенно с плагином Spatial для поддержки маппинга Geometry-полей
4) SharpMap - движок карт. Качество среднее, но с учетом того, что он некоммерческий (LGPL), то вполне сойдет.
5) QGIS - гис-система, важный инструмент, помимо Visual Studio.
Это наш стек. Ну а вообще можете еще погуглить: WFS/WMS, GeoJSON/TopoJSON, GeoServer (пока не пользуемся, подключим, если понадобится WFS-сервер).