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

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

• Вклады?

• Инвестиции?

• Продуманный подход?

• Когда стоит покупать акции?

• Когда стоит продавать акции?

• Когда стоит ходить на работу?а

Я просто запутался, и хочу кушать. Экономику почему-то изучают в ВУЗах, а я хочу просто книгу, где бы мне рассказали, как добыть много денег, вот и все.

Блин, естественно ты запутался. ЛОР тебе не поможет, это несколько семестровых курсов минимум. Если бы был простой и универсальный рецепт борьбы со сложностью, ты бы уже давно знал.

Тебе нужна книга «Лучший метод построения простой архитектуры программы»

На русском Гугл не нашел. Есть название на английском?

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

Вклады?

Никаких вкладов.

Инвестиции?

Да. В акции предприятий.

Продуманный подход?

Value или GARP

Когда стоит покупать акции?

Когда внутренняя стоимость бизнеса выше текущей рыночной цены.

Когда стоит продавать акции?

Когда экономические характеристики бизнеса изменились в худшую сторону.

Когда стоит ходить на работу?

На работу - никогда.

Это уже не модно, тут нужны микросервисы - вот он золотой молоток.

Шаблоны проектирования?

Это фигня. Я про них уже спрашивала и мне тут все разъяснили.

но я не нашёл пока книги, где бы мне рассказали

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

Универсального подхода нет, всегда нужно работать от задачи. Вся вышеперечисленная чепуха не истина, смотри на простые принципы — Unix way и 17 правил Реймонда, KISS, worse is better, закон Парето — вот это всё, они не решают за тебя как программировать, они учат не воротить сложной херни там, где она не требуется.

Нет ты сама всё решила, а тут оправдание своей лени и непониманию искала.

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

Ты не про то думаешь. Делать нужно максимально просто, чтобы работало сейчас. Про потом будешь думать, когда оно настанет.

Курсы в одно ухо влетают, в другое вылетают. Нужно несколько десятков тысяч строк кода написать и пару-тройку разнонаправленных проектов, в каком-нибудь говнолегаси разобраться и что-то поддерживать, да так чтобы концепции на 180° разворачивались. Вот тогда опыт будет, будет и понимание.

Это фигня. Я про них уже спрашивала и мне тут все разъяснили.

Не фигня, просто это не то на что надо фапать. =)

Это фигня

Ах, этот сладкий, не замутнённый опытом максимализм.

Я просто спросила «зачем нужны паттерны»? А вас разнесло на несколько страниц. Весь этот бред я не читала естественно, но в голове отложилось «не нужно».

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

только выделением +1 абстракции.

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

ООП да, хорошо, самое важное там инкапсуляция (для меня), но всё равно ей ненадо злоупотреблять, если уж делаешь библиотеку, то постарайся например методы делать protected вместо private, и классы не делать final.

Шаблоны проектирования? да, только для энтерпрайз приложений, те которые описаны у фаулера, от банды четырёх - это как бороться с с++

Декларативный подход? без разницы

Когда стоит применять конечные автоматы? в 99% не стоит, забудь об этом, когда понадобиться сам вспомнишь

Когда стоит применять метапрограммирование? 3 случая - кодогенерация, оптимизации, дсл (в порядке возрастания сложности) если что-то из этого нужно то применяй, например в динамических языках как ruby/js всегда можно что-то легко нагенерить, сложно заоптимизировать, и легко построить дсл. в скале же легко сделать всё.

Когда стоит применят композицию?

когда имеешь дело с функциями, композиция там и применима, функции должны хорошо покрываться юнит-тестами => не зависеть от окружающего мира (бд\нетворк)

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

я бы конечно скинул какой-нибудь код, но не думаю что смогу найти где-нибудь на гитхабе как что делать.

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

Думать в любом случае нужно, бездумное применение методов ни к чему хорошему не приведёт. Но если есть кто-то, кто может поделился своим опытом, то почему бы не приобщиться? Человек существо ограниченное, всё голове невозможно удержать, но если ты себе составишь список «Метод -> в каких случаях его стоит применять» то это может сильно облегчить жизнь.

Нужно несколько десятков тысяч строк кода написать

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

только выделением +1 абстракции.

Декомпозиция на составные части.

«Способ управления сложными системами известен с античных времен — divide et impera (разделяй и властвуй)». При проектировании сложной системы программного обеспечения необходимо разделять ее на все меньшие и меньшие части, каждую из которых можно уточнять независимо друг от друга. В этом случае мы не выйдем за пределы реальных возможностей человеческого мозга: для понимания любого уровня системы нам необходимо оперировать немногими ее частях (а не всеми). Действительно, как заметил Парнас (Parnas), разумная декомпозиция позволяет справиться со сложностью проектирования программного обеспечения путем деления пространства состояний системы

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

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

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

Как мило. Расскажи это Грейс Хоппер, Кернигану и Риччи, Линусу расскажи, пуська.

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

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

Ну это-то ясен пень.

Пример приведи, где такие программы нужно написать.

Да чего там компании, милаха про FOSS каким-то чудом никогда не слышала.

Продолжая аналогию: и все это очень полезно для того, кому нечего жрать.

А что придумали эти люди? Просто еще одну операционную систему. И до них уже это писали и многие решения уже были найдены до них. Что принципиально нового придумал Линус, если юникс придумали до него?

О да. «Нам эти микросервисы нужны для масштабирования на миллионы машин, а у вас вся контора - 15 человек» - знакомый из гугла.

Nick: mag1ck Избранные теги: machine learning, нейронные сети

Как это примечательно. И что лежит в основе машинного обучения и нейронных сетей? Не борьба ли со сложностью? Может сам сперва поделишься с нами и с собой тоже этими методами?

универсального рецепта нет

TOGAF? Не слышал?

Ты просто не знаешь про них и нечего тут строить гуру.

Я таки за бан, кек. Этот поциент неизлечим.

Где угодно.

В любой небольшой компании, а тем более стартапе у тебя будет кучка программистов, где будут выделяться лиды (и хорошо если есть ПМы), кто поопытней, кто менее, и никаких архитекторов, максимум будет бородач или шаристый CTO с которым можно советоваться. Всё решается на совещаниях коллективным разумом в норме, в худшем каждый пилит вменённую в ответственность систему сам по себе молча где-то в уголке. И ты удивишься, но нормальный архитектор тоже никогда самодурствовать не станет, он будет обсуждать задачи с непосредственными исполнителями или их руководителями.

А вообще, каждый синьёр обязан в архитектуру уметь, ему нянька не нужна. «Разраьбтчик» не зря так называется, слово-то говорящее. Кодерки — это джуны на джаве на галерах и те, кто говнину на пхп под заказ однотипную клепают, а в любых других случаях без мозгов никак.

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

TOGAF - высокоуровневый подход к проектированию. TOGAF разрабатывается с 1995 группой The Open Group на основе фреймворка Министерства обороны США TAFIM.

Не слышал? Совсем не глупости. В отличие от тебя я получаю высшее образование по этой области.

Просто еще одну операционную систему

Найс. «Ещё одну» систему, «ещё один» язык, «ещё один» свод принципов. Столпы на которых всё современное ПО стоит, а значит и весь мир.

многие решения уже были найдены до них

Их ещё понимать нужно и уметь использовать.

Что принципиально нового придумал Линус

Ничего в сущности, но ты не способна даже представить, и скорее всего никогда не будешь способна, чего стоит это «ничего нового».

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

Откуда ты знаешь на что я способна? Вместо аргументов одни сопли без доказательств.

А баран 10 лет лет работает программистов и даже не слышал что такое высокоуровневый подход к проектированию.

геральт - это такая смесь из iron_bug и царя.

Я слышу только бестолковый лепет младенца без капли практики и наблюдаю ничем не подкреплённую веру в то, что ты какие-то истины уже постигла, а ещё очевиднейшую неконситеность мышления. Такая бестолковость — это натура, может быть ты это и перерастёшь, но что-то я сомневаюсь.

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

Я много всякой лабуды слышал и с улыбкой проигнорировал.

Большинство ситуаций попадают под обобщение методов. Не надо велосипедить самому, просто берёшь и применяешь ценный опыт других программистов.

Чо это? Там заскоки на академичность и элитарность, у меня их нет. К тому оба толкают за абсотную истину.

Странное сравнение.

Для этого фреймворки есть и прочие готовые решения, даже голову включать не нужно. Но ты же немного о другом спрашиваешь, нет?

бестолковый лепет младенца без капли практики

TOGAF используют 40 из 50 крупнейших транснациональных компаний и 300 из 500 самых крупных компаний США.

Что это если не практика?

Ну элитарность есть. Ты даже сам про себя шутил на этот счёт.

( На самом деле, я просто не в духе. Какие-то свиньи за ночь засрали двор, где я живу. Я бы им сам очень доходчиво объяснил что они не правы, да где их найти теперь. )

Это не твоя практика.

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

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

И интегралы не моя практика, я их изучаю и использую.

И это вообще не про программирование как таковое, чтобы ты понимала.