Исправление Syncro, (текущая версия) :
то есть, проект не развивался кем попало.
он не мог развиваться кем попало, потому что кто попало не осилит даже конфигур, мейк, мейк инсталл. Он не превратился в говно, потому что у собственно ядра ограниченный спектр задач, а остальное все находится во всяких дбасах, системд и так вплоть до файлового или оконного менеджера, которые уже писались хоть на скриптовом тикле
ты мешаешь в кучу работу с памятью, которую можно организовать на банальных умных указателях, с объектами-классами
если нет объектов, вся сложность размазывается прямо в коде, методы обрастают десятками аргументов, которые не всегда надо передавать все, появляется миллион мусорных структур данных, для хранения всяких промежуточных состояний, проверок на целостность и валидность данных внутри методов и все это либо не имеет контрактов, т.е. типобезопасности для ссылочных типов и является сразу минным полем либо из-за обилия перекладываний структурок общие интерфейсы отсутствую как класс и логика начинает везде дублироваться. Когда надо восновном фигачить байтиками в поток тяжесть таких решений для поддержки и развития может быть не так заметна, но когда у тебя бизнесовые модели с нескольким десятком свойств и разными ветвлениями обобщений и конкретизаций и проект постоянно их развивает, процедурный код становится помойкой в которую страшно лазить и которую можно только наращивать дальше добавляя свое говнецо скраешку или переписывать без конца
Исходная версия Syncro, :
то есть, проект не развивался кем попало.
он не мог развиваться кем попало, потому что кто попало не осилит даже конфигур, мейк, мейк инсталл. Он не превратился в говно, потому что у собственно ядра ограниченный спектр задач, а остальное все находится во всяких дбасах, системд и так вплоть до файлового или оконного менеджера, которые уже писались хоть на скриптовом тикле
ты мешаешь в кучу работу с памятью, которую можно организовать на банальных умных указателях, с объектами-классами
если нет объектов, вся сложность размазывается прямо в коде, методы обрастают десятками аргументов, которые не всегда надо передавать все, появляется миллион мусорных структур данных, для хранения всяких промежуточных состояний, все это либо не имеет контрактов, т.е. типобезопасности для ссылочных типов и является сразу минным полем либо из-за обилия перекладываний структурок общие интерфейсы отсутствую как класс и логика начинает везде дублироваться. Когда надо восновном фигачить байтиками в поток тяжесть таких решений для поддержки и развития может быть не так заметна, но когда у тебя бизнесовые модели с нескольким десятком свойств и разными ветвлениями обобщений и конкретизаций и проект постоянно их развивает, процедурный код становится помойкой в которую страшно лазить и которую можно только наращивать дальше добавляя свое говнецо скраешку или переписывать без конца