Борьба со сложностью в программировании.

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

Начни с разбиения задачи на подзадачи и программы на независимые модули/библиотеки/классы.

Мы не думаем над этим. Мы вежливо называем людей так, как они хотят быть названными. Но в случае iron_bug она на аватарке.

Начальство — это кто?

Ну, и где этот UML теперь?

На месте. Иногда даже бывает полезным.

какой метод лучше выбрать

Есть утилиты для оценки «перенакрученности» кода:

pmccabe -v *.c*

Дядю Боба насколько иногда интересно слушать, настолько же иногда и уши вянут, когда он про тдд и аджайл втирает. Сектанство какое-то.

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

Шома её жирным бородатым троллем называет.

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

Вот это «сейчас» меня и настигло

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

Бывают конечно ситуации, когда всё ну очень резко меняется. Но это форс-мажор и тогда «переписать с нуля» одно из возможных и вполне адекватных решений.

Но вдруг старый, жирный и бородатый тролль хочет побыть маленькой и наивной девочкой. Мы же не столь жестоки и очень толерантны :-)

А если этот тролль оденет колготки в сетку и каблуки, то даже сойдет за Саныча.

рефакторинг и адаптация архитектуры <> полное переписывание архитектуры программы. Правильным выбором архитектуры надо было заниматься собственно перед тем, как начать писать программу, иначе проще новую с нуля написать, чем «адаптировать» тонны написанного кода.

рефакторинг и адаптация архитектуры <> полное переписывание архитектуры программы

Да, и в чём проблема? Это не означает переписывание всего кода с нуля. Когда добавляется новая фича, то общая задача в принципе не меняется. Т.е. старый код в целом остаётся рабочим, но он теперь решает только часть новой задачи. Т.о. нужно просто принять новую «архитектуру» в которой и новая и старая фичи будут являться частным случаем общей абстракции. По факту старый код либо рефакторится под новые интерфейсы, либо вообще берётся как есть и засовывается в адаптер.

проще новую с нуля написать, чем «адаптировать» тонны написанного кода.

Ещё раз повторю, что так не бывает, если это не тонны костылей вокруг давно устаревшей абстракции.

PS: я вообще не особо верю ни в какие проблемы, которые возникают «внезапно». В 90% случаев, это закономерный результат давно забиваемого болта. Оставшиеся 10% нужно принять как неизбежность, ибо ничего не поделаешь.

Не за что, а почему. А потому, что начальство.

Почему не «потому, что инженер» или «потому, что рабочий»?

Одно из когнитивных искажений, свойственных кожанным мешкам с мясом.

А вот это уже когнитивное искажение про «когнитивное искажение», особенно из-за фразы «кожанный мешок с мясом».

Наброшу, интересная статья про распределение денег https://habr.com/ru/post/424071. Вроде «справедливое», но «несправедливое».

уши вянут, когда он про тдд и аджайл втирает

Насколько я из его бложика понял, он как раз борется с теми, кто делает из аджайла карго-культ.

Выступления не смотрел, правда.

Вместо того, чтобы просто развенчивать эту тупую херню, он говорит о том, подход к ней неправильный. Одну дрянь подменяет второй. Есть видер его доклада с конфы GOTO; на эту тему, у меня аж прибомбило. По-моему это. Я думаю, с таких идеологов больше вреда чем пользы.

1:18

О нет.

В фоне норм.

Ты практикой лучше занимайся, в не мутными задротствами. С опытом придёт понимание что к чему и куда.

Он там там по-моему вначале прикольно Objective-C программеров унижает, оно того стоит.

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

Почему не «потому, что инженер» или «потому, что рабочий»?

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

остальной комментарий

там вся сложность в том, насколько все теории и домыслы соответствуют объективной реальности. И да, искажение о справедливом мире не надо тащить на ЛОР, его нет

О, спасибо, почитаю на досуге.

без разницы на самом деле

Если «без разницы», то почему кто-то начальник, а кто-то - нет? Почему начальник именно тот, кто начальник? Что за самоопределение, самозванство?

искажение о справедливом мире

«Начальник» - это тоже «искажение о справедливом мире» «начальников».

А теории хороши тем, что показывают на чем основаны эти «искажения о справедливом мире».

Подскажите пожалуйста, какие вообще бывают способы для борьбы со сложностью разрабатываемой системы?

Ты не поверишь, способов «борьбы со сложностью» не существует.

Сложность задачи «в целом» не возможно уменьшить. Ты лишь можешь перераспределять её между компонентами системы.

Главная задача PM, PO, бизнес-аналитиков, архитектора, разрабов - НЕ ПЕРЕМУДРИТЬ, т.е. не внести дополнительную сложность.

Например, в приборостроении/имбеде сейчас ситуация такая: произошел перенос сложности с аппаратного на программное обеспечение, и сложность софта такая высокая, что в некоторых случаях стало проще адаптировать железо…

Это исключение из правил, и встречается оно, когда макаки пытаются делать ХХивП (дада, рыночек порешал).

Заканчивается это тем, что оперативно далается новая версия железа, а потом спокойно переписывается весь софт (ну так фигле, минимальная рабочая версия от макак есть, можно сделать по нормальному).

Т.о. нужно просто принять новую «архитектуру» в которой и новая и старая фичи будут являться частным случаем общей абстракции.

Это именно то, о чем я говорил в пункте про НЕ ПЕРЕМУДРИТЬ.

Сфига ли там частные случаи возникают?

Нужна новая функция - нарастили параллельно, НЕ ВМЕШИВАЯСЬ В РАБОТУ ОСТАЛЬНЫХ КОМПОНЕНТОВ СИСТЕМЫ.

Ну и зря.

TDD и Аджайл в этой стране (и не только) часто превращаются в tester driven development и ХХивП соотвтетсвенно, со всеми вытекающими…

https://www.youtube.com/watch?v=F2skk6RFFos

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

Нужна новая функция - нарастили параллельно

Такой вариант возможен, но нередко это приводит к копипасте. В этом правда есть свои плюсы.

НЕ ВМЕШИВАЯСЬ В РАБОТУ ОСТАЛЬНЫХ КОМПОНЕНТОВ СИСТЕМЫ

В частности вот этот плюс.

Начал напевать ещё до клика на ссылку.

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

Высокая декомпозиция, чистый код, документация. Остальное - частности, зависит от конкретной ситуации. Золотого молотка не существует. Следуй цитате: «Знание некоторых принципов легко возмещает незнание некоторых фактов.»

Просто пиши код, ищи решения проблем по мере надобности. Книги без практики всё равно не отложатся, так как не будешь понимать, где что надо применить и почему.

Всё просто. Надо всего лишь придумать метрику сложности разрабатываемой системы. Дальше применяешь всякие разные методы оптимизации в метрических пространствах. Сейчас модно применять нейронные сети для решения задач оптимизации. :)

Надо всего лишь придумать метрику сложности

Борьба со сложностью в программировании. (комментарий)

Метрики бывают разные, не только KLOC цикломатическая сложность. Выбор метрики в соответствии текущей моде тоже можно отдать нейронным сетям. :)

Митин Клитор!

Сначала берётся докер. В докер заворачиваются как можно малые части программы, к которым присобачивается веб-сервер, json-хэндлеры и кастомно прописанные роуты, ведь xml-rpc сложно. Это называется REST, а всё вместе называется зачатками архитектуры микросервисов.

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

Много библиотек - это хорошо, а много сервисов лучше, поэтому тащим в проект менеджеры очередей и NoSQL-ные базы данных(мы же хотим, чтоб было проще, поэтому SQL не нужен). Опять же, чем больше, тем лучше (в одном знакомом проекте было два менеджера очередей, а он ещё не перешёл на докер и две базы данных, правда, одна из них была sql, но в таких случаях мы берём ORM). Если не справишься, много компаний уже продают всё это как сервис: берёшь и подписываешься. Даже систему сбора логов можно купить по подписке.

Перейдём к опциям. Наша архитектура позволяет нам делать меньше опций, поэтому хардкод нужен и важен. Смело удаляй все пути к файлам (если ты хранишь в своих YAML(ты же пользуешься только им, да? Это же лучший человекочитаемый формат out there, любой другой использовать не стоит, а на новый надо переходить по мере появления) много данных, это надо делать в БД, рекомендую Redis. Да и вообще, архитектура позволяет и требует) и опции в них. Переменные окружения и аргументы не нужны, поэтому с ними не заморачиваемся, про это никогда не надо было знать.

Гуй. Тут мы берём CMS и/или Electron. Тут всё просто и понятно: для фронтенда CMS. Можно сделать вебапп на JS и закатать в приложение. Этим занимаются фронтендеры.

Вот я тебе и рассказал про простую архитектуру по минимуму, можешь приступать. Эти принципы используются как у акул IT-бизнеса, так и у мелких игроков и их популярность на высоте. Странно, что ты про них ещё не знаешь.

Из кодофич берём среднее по рынку.

Если «без разницы», то почему кто-то начальник, а кто-то - нет?

Почему если подбросить монетку в чуть меньше 50% случаев выпадает орёл, и чуть меньше 50% случаев решка? А очень-очень редко она падает на ребро. Глупый вопрос на самом деле. Кому-то повезло, кого-то протащили, у кого-то язык подвешен, кто-то имеет нужную внешку, если надо с людьми общаться много, у кого-то развит навык руководить, который весьма слабо связан с умом или иными навыками. У кого-то характер подходящий. Дофига факторов, включая случайности и образование и интеллект в них находятся довольно далеко по списку, если смотреть корреляции.

какие вообще бывают способы для борьбы со сложностью разрабатываемой системы?

Способ придуман древнеримскими программистами: «разделяй и властвуй».

P.S.

«любую сложную задачу программирования можно решить добавив очередной слой абстракций»

Но есть продолжение: «…кроме случая, когда проблема состоит в слишком большом количестве слоёв абстракций».

Ты живешь один или с другом?

Снимите уже себе номер на сутки.

Тот же франктал, я уверен, в жизни нормальный мужик.

Нет. Если человек годами занимается тем, что в интернетиках желчно поливает говном всех, с кем не согласен - это не может не иметь очень значительных отражений в девиантности психики. Другое дело, это девинтность человек может скрывать. До поры до времени, пока ему выгодно.

То же самое, кстати и с айрон баг.

Я у врача был не так давно (нет, не у психиатра, хирург). Чёрт меня дёрнул возразить на вполне безобидную его фразу.

Нормальный мужик (твоё выражение) начал мне на полном серьезе втирать про заговор масонов. И рисовать схему на бумаге. И это был не троллинг.

Анон, ты слишком сурьёзен! Я ж в шутку это написал )

для борьбы со сложностью

Метапрог уже предлагали?

А если серьёзно, то звучит по-капитански, но ответ зависит от решаемых задач. Конечный автомат напрашивается, когда ты делаешь что-то, что хорошо описывается набором состояний.

То же самое ООП возникает само собой, когда ты пишешь программу с GUI. Все популярные оконные API объектно-ориентированы, вне зависимости от того, написаны они на языке с поддержкой ООП или нет (в последнем случае код будет более тяжеловесным и менее очевидным, вот и всё). Не потому, что разработчики так замыслили, а потому, что так окна работают. «Окно - это объект в памяти, которому, возможно, соответствует область на экране».

Тот же metaprog может сколько угодно не любить ООП, но взаимодействуя с окнами, его придётся применять.

Просто поглядывай на них иногда. Если не понятно, то и хрен с ним, но рано или поздно поймёшь, мб даже пригодятся.

Вот плюсую.

Мне кстати очень интересно, почему вы все думаете, что iron_bug - девочка?

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

Ну или ты хочешь, чтобы мы в твоей половой принадлжности тоже сомневались? Это мы с удовольствием, да. :)

А инженер учится 5 лет всякой инженерной науке. А рабочий не знает всего этого, поэтому его советы непрофессиональны. Это учить врача как правильно лечить.

Таки бывает, что и фельдшер учит врача лечить, особенно если фельдшер со стажем, а врач только из вуза вышел.

И бывают рабочие очень высокой квалификации. Сейчас, кстати, очень востребованы на ряде предприятий, поскольку профтехобразование сгноили, а теперь хватились.

Лечись от элитизма, короче.

Ну, и где этот UML теперь?

Вполне себе успешно применяется при проектировании. Фанатский подход к UML себя, конечно, изжил.