Крайне общий вопрос по проектированию систем

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

Предположим, что глобальная цель - стабильно работающая система. Тут можно ее достичь например, сделав рефакторинг одного модуля и покрыв его тестами, попутно обнаруживается, что то плохо и это бы надо переделаться, все затягивается в итоге ты получаешь за время X один модуль более менее качественный, но в то же время ты мог бы в каждом из трех модулей сделать небольшие изменения в плане работы друг с другом, и в 1 и во 2 случае ты внес в систему улучшения, в каком случае получится более эффективно. Направить все силы на 1 модуль или все объекты системы должны быть сбалансированны.

каждый модуль доводить допустим до твердой 4+ по 5 бальной шкале, а потом переходить к другому

В реальной жизни так практически невозможно. Вся эта махина несется на ходу и невозможно так просто заменить ей одно колесо с шоссейки на MT.

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

Обычно это итерации мелкими шажками по всем модулям. Например, в одном модуле добавил новое API, потом в остальные перевел на него, и уже после этого ты можешь удалить старое. И то, это в идеале и так тоже не часто бывает.

Вопрос не про проектирование а про воркфлоу.

Первый шаг это получить цельную систему.

Второй шаг это сделать MVP.

Потом все остальное.

Первый шаг нужно сделать как можно быстрее. Главное правило программирования: если можно что-то сделать потом, это надо делать потом.

Как все это сделать с минимальными усилиями это задача уровня планирования архитектуры.

Ключевые вещи нужно делать аккуратно и детально, а те, которые не дают зависимостей можно сделать говнокодом, а потом, когда будет MVP и станет понятно какой реально продукт нужен ЦА, то переписать.

каждый модуль доводить допустим до твердой 4+ по 5 бальной шкале, а потом переходить к другому или действовать итерационно и циклически

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

мелкие итерации. при радикальных переделках можно утонуть в проблемах, и забросить работу в конечном итоге, не имея понятия, как из всего этого вылезать.

если ты точно не понимаешь обьем и план работ - лучше всего двигаться короткими шажками.

Как показывает жизнь, водопадная модель ЖЦ крайне редко где работает хорошо. Итерации - наше всё.

Зависит от твоего характера. Если ты воспринимаешь все в жизни через какие-то схемы и шаблоны, то могу посоветовать что-нибудь почитать на эту тему от тех авторов, кто такие же по складу как и ты.

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

Но я так понимаю, что тебе ближе первый путь. Может быть, здесь кто-нибудь и посоветует какую-нибудь вумную книгу типа «чистого кода» или еще чего-то такого подобного

Как показывает жизнь, водопадная модель ЖЦ крайне редко где работает хорошо. Итерации - наше всё.

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

Итерации - наше всё.

Ужас же совсем не в этом, а в том что вы не понимаете о чем говорите, когда рассуждаете о «водопаде»:

https://pragtob.wordpress.com/2012/03/02/why-waterfall-was-a-big-misunderstanding-from-the-beginning-reading-the-original-paper/

И «автор» не это имел в виду:

https://www.reddit.com/r/agile/comments/q03epd/waterfall_was_iterative_but_no_one_read_the/

И чистого водопада никогда не было:

https://daedtech.com/there-is-no-such-thing-as-waterfall/

И вы таки понимаете не то:

https://changelog.com/posts/waterfall-doesnt-mean-what-you-think-it-means

а бэк это сервер на плюсах или Php или go, состоящий из нескольких модулей.

а что бэк не на Qt, ежели и фронт на нем ?

Я имел в виду вот что, на опыте вижу, что системы в которых модули максимально не отлажены, например слабая диагностика ошибок или где-то углы срезали или возможно они уже на старых версиях фреймворках или с очень старыми либами начинают создавать головную боль, буквально приходится много времени и сил тратить что бы погрузиться в контекст, но если система состоит из 3 модулей (для примера) даже над двумя одновременно сложно работать. Возможно тут задача оптимизации, какая система стабильней, проще для модификации, надежней, где все элементы примерно одинаково развиты или возможно более эффективно развивать элементы один за одним, что бы потом уже к ним не возвращаться. Для военной техники мы когда то использовали подход «метод анализа иерархий»

1. MVP (из каловых масс и палок)
2. выкинуть нахер, сделать новый MVP
3. повторять до полного удовлетворения
4. стабилизировать пока это кому-то надо
5. PROFIT!!!

1. отключать в себе перфекциониста это полезно. Есть категория «достаточно хорошо». На втором круге, если приходится возвращаться к этому коду, то тогда да можно уже серьезно подойти к задаче. 80% того что напишешь так и останется висеть нетронутым, либо часто потом просто удаляется в результате очередной фантастической идеи продакта.

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

3. Делать небольшими спринтами, согласно плану. Писать надо не «помодульно», а отдельными фичами, багфиксами.

Очень часто «достаточно хорошо» превращается в «так сойдет», а с учетом того, что код всегда нужен был вчера, «так сойдет» превращается в «тяп ляп лишь бы прокатило».

Очень часто «достаточно хорошо» превращается в «так сойдет», а с учетом того, что код всегда нужен был вчера, «так сойдет» превращается в «тяп ляп лишь бы прокатило».

Зависит от контекста. Если от софта зависят жизни человека, то я первый буду за растрел через повешение в случае «тяпляпства». С другой стороны, если рынок еще не занят приложениями и сегодня релизнутое с ошибками и багами занимает 70-80% рынка, или завтра уже 20-30%, то с т.з. бизнеса пофиг на ошибки.

Тут всё просто. В процессе реализации могут выясниться нюансы, которые потребуют внести корректировки. А значит, если покрывать тестами сразу, то возможно потребуется переделывать сами тесты. А это лишняя писанина. Поэтому следует модифицировать все с минимальными тестами и когда уже будет уверенность в стабильности реализации тогда уже более плотно покрывать тестами.

Стесняюсь спросить, при чём тут системный анализ?

Domain Driven Design с гексагональной архитектурой тебе в помощь, черт не так страшен на самом деле, как его малюют, а то ща набегут и будут рассказывать, что оно только про кровавый Ынтырпрайз, не верь им! Если умеешь готовить ООП - вообще щикарно, а так и на модульно-процедурном системы пилят. Там еще такая техника-вкусняшка есть как EventStorming, с помощью которой можно сложную систему накидать прямо в каком-нить drawio ввиде цветных стикеров и стрелочек, а потом и в код удобно переносить. Domain старайся писать на одном языке, как для клиента так и для сервера, golang прекрасно подойдет. Морды уже на свое усмотрение. QT с golang через cgo прекрасно работать будет, не забывай про рассово правильные паттерны типа MVVM+Coordinator. Примерно, такое реализовывали в 3.5 человека: домен на go, морды на десктопе gtk4+libadwaita, причем под линь\вынь. гошку можно собрать и под мобилку. Сервер - go. EventStorming проводили с людьми чей бизнес автоматизировали, они в нотации разобрались минут за 20.

Да и самое главное в DDD - это «язык предметной области», в итоге получается, что пишешь на чистом ЯП и описываешь бизнес процессы.

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

Спасибо за развёрнутый ответ. Этим вопросом я и занимаюсь. На научной основе.

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

Предочитаю вести разработку наподобие как строится дом.
Сначала хроший фундамент (core API), а потом …

Пошучу
«Широка страна моя родная. Много в ней разного хорошего API, …»

Хорошо, что компьютера ныне «шустрые».
Это много скрашивает … (ну вы поняли).

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

Какой подход на ваш взгляд более оптимальный …

На твой вопрос развернуто ответил Маттиас Нобак в своей книге «Принципы разработки программных пакетов. Проектирование повторно используемых компонентов».

Если от софта зависят жизни человека,

В этом случае к разработке софта подходят особым образом, но даже в этом случае программист не управляет процессом. Он, в основном, винтик большой машины управления над ним и стратегических вопросов не решает. Конечно, есть и маленькие конторы на два человека, где каждый сам себе и швец, и жнец, и на дуде игрец, но сколько ты наразрабатываешь с 2 FTE?

Тут всё просто. …

Поэтому следует модифицировать все с минимальными тестами и когда уже будет уверенность в стабильности реализации тогда

ты уже работаешь над другим проектом, а то и в другой компании и стабильность этого кода больше вообще не твоя забота.

Крайне общий вопрос по проектированию систем

Для разных проектов, разный подход.
ИМХО самый лучший - системный, так как тем самым ведёшь разработку не «сиюминутную», а которая поможет при разработке иных проектов.
Можно ли так?
НУЖНО!