И вот теперь к преимуществам и недостаткам... с чего всё и началось:
Olej писал(а):
2. технология удалённых рабочих мест.
Именно в этой технике
я бы учил на сегодня (приучал!) студентов и начинающих программистов ... будь на то моя воля.
В явных плюсах:
1. Независимость и от аппаратной и от программной платформы. Хороший пример то как: в OS Solaris на аппаратной платформе SPARK можно программировать с рабочей станции Linux из пользуясь привычной, например, в том же Linux IDE Solaris Studio (в удалённой X11 сессии).
2. На сложном или уникальном оборудовании может работать много разработчиков со своих Linux рабочих станций... очень неплохо для комплексных групповых проектов.
3. Место отрабатываемого стенда может быть удалено на 1000 км. от разработчика ... таким образом можно вести диагностирование, тестирование и доводку удалённых комплексов без необходимости выезда к ним.
4. ... очень любопытно смотрится копи-паст целых фрагментов кода, логов, конфигов ... с сервера А на сервер Б через буфер обмена рабочей станции В - в открытом окне слева А, в открытом окне справа Б
... Элементарно простой способ тиражирования информации по LAN.
Минусов за этой техникой работы я явных и не вижу ... не считая того, что нужно определённый труд и время положить на приобретение привычки к такой работе.
Как ни странно, минусом является
субъективная нелюбовь программистов-разработчиков к такой форме организации ... из-за большей подконтрольности состояния дел руководству проекта. Но руководство проекта должно просто сломить такую нелюбовь и возможный саботаж - для целей реализации преимуществ метода.
Olej писал(а):
3. технология использования виртуальных машин.
1. Так же как предыдущий случай - независимость от аппаратных платформ и ОС ... любой каприз.
2. Лёгкость простота и скорость перезагрузки, когда в процессе отработки "положили" систему.
3. Возможность развернуть целую "сетку" виртуальных машин, например, отличающихся ОС, дистрибутивом, версией ядра... - для сравнительной отработки ПО. Это недостижимо практически ни в каких реальных условиях. Совершенно не все виртуальные машины должны быть одновременно активными (запущенными), поэтому такое широкое комплексное тестирование не требует существенного повышения ресурсов.
4. Совершенно уникальная возможность
сравнивать результаты выполнения на 1-м, 2-х, 3-х ... процессорах, просто перепределяя настройками в конфигурациях виртуальной машины число процессоров (например на 4-х ядерном хосте можно определить для VM 1,2,3,4 процессора). На реальном оборудовании такое теоретически возможно проделать, но практически недостижимо.
5. Очень часто упускается из виду, что большинство инструментального программного обеспечения на рабочей станции
не умеет использовать многопроцессорность (для этого ПО должно быть написано специальным образом, как многопоточное, что чаще всего делается только для серверного ПО массового обслуживания, ... таких как Apache). А нынешние рабочие станции повально многоядерные. Поэтому отработка на VM во многих случаях даже не приведёт к снижению суммарной производительности (работа VM на своих процессорах, работа разработчика - на своих).
Из минусов:
1. После такой отработки всё-равно должен иметь место финальный этап тестирования на реальном железе - могут быть мелкие артефакты.
2. Достаточно хлопотная техника установки и администрирования виртуальных машин, а ещё больше - виртуальных сетей виртуальных машин... но это освваивается один раз, а потом только многократно эксплуатируется.
3. На технически слабых рабочих станциях виртуальные машины могут существенно "жрать" ресурсы ... реально это заметно только по памяти RAM.
Olej писал(а):
4. технология использования удалённых виртуальных машин.
Объединение технологий даёт суммирование достоинств. И нивелирует недостатки.
Кроме того, такой подход позволяет создать и использовать мощный кластер из
нескольких виртуальных машин на едином хосте, консолидирующий сетевые сервера и службы, для отработки комплексных сетевых и распределённых проектов (без наличия, собственно, сетевого стенда). Это то, что ещё в Solaris появилось как зоны. Такой единый сетевой стенд должен быть доступен всем удалённым разработчикам, и стать ядром групповой работы. Это сильно большое преимущество.
Я не трогал здесь преимущества-недостатки 1-го,
локального способа отработки... но это только потому, что преимущества-недостатки могут быть только относительными, и я выше их предполагал именно относительно локального способа организации работ.
Вот это то, что я могу вспомнить по
систематизации преимуществ-недостатков способов организации работ.
Помогайте кто ещё что существенное может добавить.
Что забыл?