LINUX.ORG.RU

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

 , , ,


4

2

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

  • ООП?
  • Шаблоны проектирования?
  • Декларативный подход?
  • Когда стоит применять конечные автоматы?
  • Когда стоит применять метапрограммирование?
  • Когда стоит применят композицию?
  • и т.д.

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

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

  • Вклады?

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

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

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

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

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

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

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

t184256 ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от t184256

Вклады?

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

Инвестиции?

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

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

Value или GARP

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

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

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

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

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

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

FilosofeM ★★ ()
Последнее исправление: FilosofeM (всего исправлений: 1)

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

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

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

WitcherGeralt ★★ ()

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от t184256

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

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

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

Liz812 ()

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от WitcherGeralt

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

mag1ck ()
Ответ на: комментарий от WitcherGeralt

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

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

Liz812 ()
Ответ на: комментарий от anonymous

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

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

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

mag1ck ()
Ответ на: комментарий от Liz812

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

WitcherGeralt ★★ ()
Ответ на: комментарий от Liz812

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

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

mag1ck ()
Ответ на: комментарий от Liz812

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

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

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

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

Liz812 ()

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

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

anonymous ()
Ответ на: комментарий от Liz812

Где угодно.

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

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

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 1)
Ответ на: комментарий от WitcherGeralt

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

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

Liz812 ()
Ответ на: комментарий от Liz812

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

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

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

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

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

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

WitcherGeralt ★★ ()
Ответ на: комментарий от Liz812

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

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

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

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

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

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

Liz812 ()
Ответ на: комментарий от WitcherGeralt

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

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

anonymous ()
Ответ на: комментарий от no-such-file

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

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

mag1ck ()