Если существующее решение развесисто и вписано в технические процессы по самые гланды, то переписывание его с нуля может, конечно, оказаться дешевле поддержки.
Но внедрение этого переписанного, да так, чтобы ничего не сломать - уже не может.
camradee, тут вопрос, какая у вас логика выбора этих классов.
Если код ими осознанно манипулирует, представляя, какой за что отвечает - тут много вариантов.
А вот если они чисто механически, по айдишнику выбираются и исполняются вслепую - логично и выбор унести в тот же нэймспейс, сделав фабрику. Во уменьшение связности.
1laibach1, я предполагаю, что винды на ноуте уже стоят во всю ширину. Если устанавливаете все с нуля - конечно, просто оставляете нужное место. И обязательно Линукс после Окошек, чтобы потом не восстанавливать похеренный загрузчик.
1laibach1, тогда стоит загрузиться в LiveCD и (например, gparted) ужать раздел винды гиг на сорок - Линуксу этого вполне хватит. Виндовский диск из Линукса виден, так что медийное барахло можно держать на нем.
Уж не знаю, как там сейчас жрет Десяточка, а когда-то Семерка с Убунтой у меня делили пополам 120 гиг, вообще не жужжа.
Особенно Убунта. Собственно, она и сейчас на этом же SSD, только единолично, ибо всякая нужда в Винде отпала.
Если все эти классы в одном нэймспейсе - как бы не проблема и полное имя собрать, без псевдонимов.
Либо сделать в этом же нэймспейсе класс с таблицей [ ID => Class::class ] и брать имена из него.
Jacen11, окей, уточнение: для усугубления производительности байт-код МОЖЕТ быть переведен в машинный. Но, в отличие от С/С++, это отнюдь не обязательный этап.
Jacen11, это значит, что он не переводится в машинный код под конкретную архитектуру. Собственно, для того он и придуман, чтобы этим не заморачиваться. Исполняется машинный код уже написанной виртуальной машины, для которой этот байт-код - просто данные, подставляемые в готовые функции VM.
Jacen11, в байт-код, исполняемый виртуальной машиной. И все.
Процессор, конечно, в конце концов все равно выполняет машинные инструкции, но для них этот код - уже не алгоритм, а данные.
Drno, по описанию все-таки похоже, что ваша ситуация - по максиме "автоматизируя бардак, ты получаешь автоматизированный бардак".
И что, у вас предоставляющий VPS хостер не дает возможности в веб-морде загнать образ, с которого устанавливается система? Прописать preseed... на таком оборудовании установка займет минут десять.
rPman, не болтайте ерундой. Какой дурак организует работу так, чтобы сотрудникам приходилось напрямую работать с питоном и БД?
CRM с веб-мордой - и никаких rocket science с оверскиллами.
rPman, естественно, не только архивации. Важен весь жизненный цикл данных.
А вот если ставить во главу угла удобство чайников и низкий порог вхождения - получаешь бардак и захлестывающий технический долг. Проверено многими и многими организациями.
rPman, я прекрасно понимаю причины стабильной популярности Ёкселя среди чайников.
Но они ни разу не оправдывают его применение там, где решаются вопросы архивации, например.
rPman, весь класс таких документов желательно архивировать не мастурбацией с повторяющимися частями, создающей головную боль на ровном месте, а конвертацией в тот же PDF. И размер уменьшится, и, буде тот архив реально понадобится, не нужно будет искать ту версию офиса, в которой оно последний раз корректно открывалось.
Сделайте функцию, которая принимает массив, координаты первой точки, последней точки, шаг изменения координат и число m. В этой функции - простой цикл, в котором от первой точки до последней с заданным шагом подсчитывается длина текущей цепочки и возвращается true, если она не меньше m.
Вся остальная логика распишется легко и наглядно.
Но внедрение этого переписанного, да так, чтобы ничего не сломать - уже не может.