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

Почему если подбросить монетку в чуть меньше 50% случаев выпадает орёл, и чуть меньше 50% случаев решка?

У тебя неправильная монетка. Я вот когда сам подбрасывал советские 5 копеек, почти всегда ловил гербом вверх.

Глупый вопрос на самом деле.

Теория вероятности - это тоже «искажение о справедливом мире». Но в этой теории описано то, на чем основаны эти «искажения», и к чему приводят эти «искажения».

После начинаешь подстраиваться под «искажения» теории - не сам ловишь подброшенную монетку, а пусть свободно падает на землю.

И «справедливый мир» «искажается».

И, вообще, не будет же гордый и свободный человек сгибать спину ради 5 копеек. «Характер подходящий». :)

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

В случае копипасты таки да, - надо провести рефакторинг к следующему релизу.

А как это скажется на иерархиях сущностей - отдельный вопрос.

Если ты фанат ООП, - вероятно, будет выделен очередной «базовый класс», и в очередной раз будет проблема хрупкости базового класса…

Способа только два - опыт и мозг. Только они позволяют со временем понимать, что сложное - это не каша, а просто множество компонентов сложенных с друг с другом и образующих единое целое. Соответственно приходит понимание, что независимые сильно друг от друга вещи нужно развиваться отдельно и делать максимально простыми внутри. Помогает также чтение исходников других людей, это как раз таки опыт, тут ты понимаешь что главное это разбивать код на части и чтобы части были максимально понятными. Как ты это делаешь вопрос десятый. Хочешь ООП в рамках одной гиганской программы на Java - пожалуйста. Хочешь разбить ПО на множество мелких программ - пожалуйста. Как угодно вообще.

Из всего перечисленного ни один пунктов толком не влияет на понятность сложного ПО. Даже ООП не даёт само по себе ничего. Почитай ка код современных проектов на C++ или Java, да ты там не то что без пол литры, а без 10 литров не разберёшься, требуется много времени чтобы войти в проект средних размеров. Собственно ни ООП ни метапрограммирование не запрещает разработчику наплодить настолько запутанную иерархию, раскидать код так по файлам и так назвать все сущности, что буд-то читаешь код инопланетянина. Плюс есть любовь ньюфагов называть сущности, которым миллион лет новыми словами конечно добавляет прелести.

объем кода в erlang достаточно компактен

И, вообще, не будет же гордый и свободный человек сгибать спину ради 5 копеек. «Характер подходящий». :)

Ещё как будет. Кушать то хочется.

Ещё как будет. Кушать то хочется.

Голодный гнет спину не за 5 копеек, а за еду.

У тебя «монетаризм» головного мозга.

«Монетаризм» - это «искажение о справедливом мире». Ничем не лучше «теории вероятности», точнее, намного хуже.

спрашивала

Зачем ты продолжаешь говорить о себе в женском роде?

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

Не обязательно. Вот GUI есть, а ООП нет:

[code] module Main(main) where – A simple counter

import Fudgets

main :: Dialogue main = fudlogue (shellF «Counter» counterF)

counterF = intDispF >==< absF countSP >==< incButtonF

incButtonF :: F Click Click incButtonF = buttonF «Increment»

countSP :: SP Click Int countSP = putSP startstate $ mapAccumlSP inc startstate where inc n Click = (n+1,n+1)

startstate = 0 [/code]

или вот даже C++ [code] ImGui::Text(«Hello, world %d», 123); if (ImGui::Button(«Save»)) MySaveFunction(); ImGui::InputText(«string», buf, IM_ARRAYSIZE(buf)); ImGui::SliderFloat(«float», &f, 0.0f, 1.0f); [/code]

Что случилось с тегом [code]? Как теперь цитировать код?

То же самое ООП возникает само собой, когда ты пишешь программу с GUI.

Не обязательно. Вот GUI есть, а ООП нет:

module Main(main) where – A simple counter

import Fudgets

main :: Dialogue main = fudlogue (shellF "Counter" counterF)

counterF = intDispF >==< absF countSP >==< incButtonF

incButtonF :: F Click Click incButtonF = buttonF "Increment"

countSP :: SP Click Int countSP = putSP startstate $ mapAccumlSP inc startstate 
  where inc n Click = (n+1,n+1)

startstate = 0 

или вот даже C++

ImGui::Text("Hello, world %d", 123);
if (ImGui::Button("Save")) MySaveFunction(); 
  ImGui::InputText("string", buf, IM_ARRAYSIZE(buf));
ImGui::SliderFloat("float", &f, 0.0f, 1.0f);

Революция же. Таперича специальным декретом закреплена мода на маркдаун.

if (ImGui::Button(«Save»)) MySaveFunction(); ImGui::InputText(«string», buf, IM_ARRAYSIZE(buf)); ImGui::SliderFloat(«float», &f, 0.0f, 1.0f); ```

И как тут что-то сложнее предложенного сделать?

Самый лучший способ защиты - KISS -

http://lurkmore.to/KISS

А вообще-то, с точки зрения психоанализа, надо подождать очередного видео (части 3) от Вероники Степановой по поводу сложности программных систем, разрабатываемых программистами-«а.....ками»(TM).

части 3 У девочки явно какой-то зуд на эту тему, не находишь?

Маркдауны отвратные, так бы всех и убил. Требую латех-революцию!

Маркдауны отвратные

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

латех-революцию

Латекс - это гламурно бдсмно.

Тебе ведь больше 30? Тогда с точки зрения женщины ты выглядишь очень подозрительно.

Использование шаблонного стереотипа с целью применения грубой оценки.
Такую толстую попытку потроллить ещё поискать надо.

Порою, для преодоления сложности, необходимо сделать еще сложнее, например компилятор …

И как тут что-то сложнее предложенного сделать?

Ну вот такая картинка: https://raw.githubusercontent.com/wiki/ocornut/imgui/web/v167/v167-misc.png

получается из такого исходника: https://github.com/ocornut/imgui/blob/master/imgui_demo.cpp всего 4800 строк с комментариями. Можешь попробовать сделать аналог на ООП и посмотреть сколько строк получится.

Самый лучший способ защиты - KISS -

И в пару к нему YAGNI.

Не борьба, а управление

Окна и прочие виджеты можно представлять просто как структуры (по-сишному struct).

Окна и прочие виджеты можно представлять просто как структуры (по-сишному struct).

И от этого они не перестанут быть объектами. Объект – это не ключевое слово class, это набор данных, обладающих поведением.

Каким поведением обладает строка?

Каким поведением обладает строка?

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

Это не строка умеет, а набор фунций получающих строку в качестве аргумента? Я почему то думала что объект с поведением это в котором есть operator(), но никак не набор данных.

Это не строка умеет, а набор фунций получающих строку в качестве аргумента?

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

Почитай Макконнелла Совершенный код.

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

Надо развивать визуальное программирование. Из готового - LabVIEW, из разрабатываемого - Метапрог.

Так строка это же объект, не? У нее свои методы, если не хватает возьми и перегрузи.

Объект – это не ключевое слово class, это набор данных, обладающих поведением.

Всякий раз новая, доморощенная структура данных со своим особенным, ни на что не похожим поведением. А все потому, что кто-то дедушку Перлиса в детстве не слушался:

It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures.

Посмотри язык программирования Форт (Forth). Это очень простой ЯП и целая философия программирования. Собственно как ЯП он мало где применяется, но философию стоит изучить и по возможности использовать на любом другом ЯП.

Как я это понимаю:

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

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

Ну и очевидное: давать читаемые имена, поддерживать единое форматирование кода, стараться делать код максимально понятным без использования комментариев. Но это, я думаю, все должны соблюдать по умолчанию…

И самое главное - это помнить, что мозг человека не способен удерживать в фокусе более 7 объектов, поэтому нельзя доводить подпрограммы/классы/модули до состояния огромных монстров. Лучше несколько маленьких подпрограмм, решающих конкретные понятные задачи, чем одна большая, которая решает непонятно что.

отвечаю по порядку

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

Никаких. Если тебе НУЖНА сложная система зачем тебе бороться?

Может ты хотел спросить как бороться со сложным кодом который порождается так или иначе во многих проектах?

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

Я предлагаю подумать из-за чего так происходит?

1. Недостаток времени - лишь бы быстрее выполнялись задачи
2. Недостаток контроля качества (денег?)
3. Постоянно изменяются/добавляются требования/задачи

Что из этого следует?

Что у тебя ВСЕГДА будет говнокод, вопрос лишь в его масштабах.

Исходя из вышеперечисленных пунктов ты можешь:

1. Давать больше времени на разработку
2. Не жалеть бабла на доработку/ревью/контроль качества, и что там еще делают чтобы код был идеальным (хотя тут у каждого свои критерии идеальности кода)
3. Разработать сразу документацию вместе с требованиям, acceptance criteria, и всякими остальными штуками. Чем больше и чем детальнее тем лучше. И больше эти доки не трогать во время разработки.

кстати я так и не понял почему она так их называет. Есть где-то ссылка на это?

Надо развивать визуальное программирование. Из готового - LabVIEW, из разрабатываемого - Метапрог.

развивай

а мне вот надо делать работу вот прям щас, есть что-то юзабельное?

Пока что LabVIEW. Прототип Метапрога рабочий, но пользоваться пока тяжеловато (лаги, баги).

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

Мозги разработчика.

Как съесть слона? По частям. Это все, главный и единственный принцип.

Остальное это жалкие попытки систематизировать и затолкать все богатство инженерных подходов в прокрустово ложе «единственно правильной концепции» (тм). Можно ли построить дом топором? Можно. Но лично я предпочту более широкий выбор инструментов. Красиво-взмахнул-топором-дрочерство на конечном результате как сказывается? Да хреново сказывается, очевидно. Но если мы уходим от стройки и обращаем свой взор на программирование, то внезапно обнаруживаем немалое количество адептов идеального взмаха топора. Оценки ставятся как в фигурном катании - владение коньком, артистизм, передача образа, етц. То, что шуруп вкручен херово уже никого не волнует. Зато как красиво к стене подошел! Как шурик держал!

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

• в борьбе со сложностью полезна формализация:
  • абстрагирование
    • https://en.wikipedia.org/wiki/Dependency_inversion_principle
  • модели, моделирование

Тебя просили юзабельное, а не про твои девиации рассказать. Лабвью не пригоден для общего назначения. Метапрог дефективен по дизайну.

Скучно человеку в подохшем треде, он решил остальные засрать рекламой своего поделия. Но… срач по этой теме в последнее время очень плохо разгорается. Потому что все лулзы уже извлечены :)

А что ТЫ сделал для того чтобы Метапрог стал юзабельным?

А что ТЫ сделал для того чтобы Метапрог стал юзабельным?

Денег не дам. Иди в переходи клянчи.

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

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

Нужен новый клован.

Проектированием архитектуры программисты не занимаются, это делают архитекторы.

Вот дочитал до этой «мудрой» фразы и понял, что не понимаю откуда эти ваши архитекторы появляются. Рептилоиды их «штоле» высиживают на планете «Нубиру»…

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

По сути темы могу сказать только одно: Много практики с которой иногда приходит нужный опыт.

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

У меня было очень мало опытных подсказчиков - в большинстве случаев я оказывался таковым.