Этого треда уже нет.
Это копия, сохраненная 1 июня 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 1 июня 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
777 Кб, 1030x1200Какие книги по проектированию стоит почитать?
Какие инструменты и методики хорошо работают?
UML - годнота?
Как не скатиться в ООП-головного мозга?
До какого уровня конкретики стоит доводить проект на бумаге: буквально до набросков реализации или остановиться на описании объектов и их взаимодействия, а остальное уже доводить до ума в процессе имплементации?
Какие инструменты и методики хорошо работают?
UML - годнота?
Как не скатиться в ООП-головного мозга?
До какого уровня конкретики стоит доводить проект на бумаге: буквально до набросков реализации или остановиться на описании объектов и их взаимодействия, а остальное уже доводить до ума в процессе имплементации?
>>602051 (OP)
Банда четырех
Компилятор и текстовый редактор хорошо работают. Методики -- зависит от предметной области, наверное
Безусловно
Не писать на ООП-языках
Степанов сказал, что реально никто не начинает с классов и объектов, все начинают с алгоритмов. Я доверяю Степанову, он умный мужик, STL придумал как-никак.
Банда четырех
Компилятор и текстовый редактор хорошо работают. Методики -- зависит от предметной области, наверное
Безусловно
Не писать на ООП-языках
Степанов сказал, что реально никто не начинает с классов и объектов, все начинают с алгоритмов. Я доверяю Степанову, он умный мужик, STL придумал как-никак.
>>602051 (OP)
Я всё ещё верю, что существуют люди, которые реально сидят и рисуют диаграммки и пишут алгоритмы на "АЛГ НАЧ КОН" перед тем, как запустить IDE. Верю, но никогда их не видел.
Я всё ещё верю, что существуют люди, которые реально сидят и рисуют диаграммки и пишут алгоритмы на "АЛГ НАЧ КОН" перед тем, как запустить IDE. Верю, но никогда их не видел.
>>602099
Ну с алгоритмами ты малость перебрал, но вот рисовать диаграммы взаимодействия - вроде как обычная практика.
Ну с алгоритмами ты малость перебрал, но вот рисовать диаграммы взаимодействия - вроде как обычная практика.
>>602113
Да, рисуют, но прям задрачивают их единицы.
Да, рисуют, но прям задрачивают их единицы.
>>602051 (OP)
Книги Head first - говно, не читай.
Книги Head first - говно, не читай.
>>602166
А какой хороший курс есть по uml?
(Если мимо будет проходить аноноархитект, то порекомендуй и по bpmn)
А какой хороший курс есть по uml?
(Если мимо будет проходить аноноархитект, то порекомендуй и по bpmn)
>>602051 (OP)
Только если ты быстро и грамотно на нем пишешь, для грамотных людей которые могут это быстро понять и дать фидбек, ну или для документации.
Сколько бумагу не марай, все никогда не всех нюансов не предвидишь
>UML - годнота?
Только если ты быстро и грамотно на нем пишешь, для грамотных людей которые могут это быстро понять и дать фидбек, ну или для документации.
>До какого уровня конкретики стоит доводить проект на бумаге
Сколько бумагу не марай, все никогда не всех нюансов не предвидишь
А про ООП все так бугуртят же в основном от того, что решения получаемые им плохо ложатся на современную вычислительную архитектуру? Верно ведь?
>>602189
Нет, не поэтому.
Нет, не поэтому.
>>602183
Лично я читал только выше упомянутую "Банда четырех", и методичку курса по ООП, после этого все вопросы по поводу ООП отпали.
>>602189
главные минусы проседании быстродействие за счет сложной организации программной системы, если меру знать и не городить огороды из патернов, можно элегантно составлять решение задач, не теряя в производительности и сохраняя все плюсы ооп - естественность, понятность, надежность, легкое сопровождение и расширение программы.
Лично я читал только выше упомянутую "Банда четырех", и методичку курса по ООП, после этого все вопросы по поводу ООП отпали.
>>602189
главные минусы проседании быстродействие за счет сложной организации программной системы, если меру знать и не городить огороды из патернов, можно элегантно составлять решение задач, не теряя в производительности и сохраняя все плюсы ооп - естественность, понятность, надежность, легкое сопровождение и расширение программы.
>>602198
Под сложностью программной системы можно много чего понимать, и далеко не всё будет ухудшать быстродействие
Под сложностью программной системы можно много чего понимать, и далеко не всё будет ухудшать быстродействие
>>602189
Бугуртят и взамен предлагают такую хуиту, что сложно поверить, что они правда так считают.
Нормально там всё ложится.
Бугуртят и взамен предлагают такую хуиту, что сложно поверить, что они правда так считают.
> плохо ложатся на современную вычислительную архитектуру
Нормально там всё ложится.
>>602051 (OP)
Бесполезно читать про это.
Бесполезно читать про это.
А есть вообще какие-то альтернативы объектному подходу в проектировании? Декомпозиция задачи, выделение сущностей с их областями ответственности, иерархическая структура - это ведь используется независимо от того, на функциональном или императивном языке ты пишешь. Это просто естественные способы моделирования сложных систем.
>>603048
Нет, нету никакой альтернативы. Попытки что-то писать на процедурных или функциональных языках всегда приводят к изобретению "объектного подхода".
This.
Нет, нету никакой альтернативы. Попытки что-то писать на процедурных или функциональных языках всегда приводят к изобретению "объектного подхода".
> Это просто естественные способы моделирования сложных систем.
This.
>>602051 (OP)
Ебать наконец-то появился этот тред. Я искренне не понимаю, почему его ещё не было или нет в закрепе. Подписываюсь на тред. Сам пытаюсь вкатиться в архитектуру.
Работаю в небольшом ит отделе небольшое компании над внутренним CRM проектом. Благо подобие архитектуры дал веб фреймворк с которым мы работаем, но в целом архитектуры нет и код в основном пишется там где видится. Постоянные правки связанные с изменением бизнес логики приводят к перепахиванию значительной части не очень большого, но относительно сложного проекта.
Все осложняется тем, что у нас нет ни senior'ов, ни архитекторов, и просто напросто некому подсказать как и что делать.
Вот сейчас сам пытаюсь понемногу вкатиться в ООП и паттерны и нащупать хоть какую-то почву под ногами.
Причём решаемые задачи нашей системы самые классические:
- расчёт зп
- выставление счетов
- работа с товарами
- склад
И если бы у нас работал хоть сколько-нибудь опытный архитектор, то сложность и объём переработок кода сократилась бы в разы.
Ебать наконец-то появился этот тред. Я искренне не понимаю, почему его ещё не было или нет в закрепе. Подписываюсь на тред. Сам пытаюсь вкатиться в архитектуру.
Работаю в небольшом ит отделе небольшое компании над внутренним CRM проектом. Благо подобие архитектуры дал веб фреймворк с которым мы работаем, но в целом архитектуры нет и код в основном пишется там где видится. Постоянные правки связанные с изменением бизнес логики приводят к перепахиванию значительной части не очень большого, но относительно сложного проекта.
Все осложняется тем, что у нас нет ни senior'ов, ни архитекторов, и просто напросто некому подсказать как и что делать.
Вот сейчас сам пытаюсь понемногу вкатиться в ООП и паттерны и нащупать хоть какую-то почву под ногами.
Причём решаемые задачи нашей системы самые классические:
- расчёт зп
- выставление счетов
- работа с товарами
- склад
И если бы у нас работал хоть сколько-нибудь опытный архитектор, то сложность и объём переработок кода сократилась бы в разы.
>>603083
На данный момент читаю книгу для даунов или детей, или детей даунов или детей-даунов на refactoring guru.
На данный момент читаю книгу для даунов или детей, или детей даунов или детей-даунов на refactoring guru.
>>603048
А что это такое? Если это "называть структуры данных так же, как объекты реального мира", то ООП -- это велосипед, ибо так делали еще в Си.
Кстати, аргумент в пользу ООП "ну реальный мир то из объектов состоит а не из функций)))00)" на мой взгляд дурацкий, ибо ООП это не только объекты, но еще и сообщения между ними. В связи с чем у меня возникает вопрос: что нужно курить, чтобы камни начали обмениваться сообщениями с деревьями, ручьи с облаками и т.д.? В ФП объекты -- это типы, и никаких загадочных сообщений нет, есть морфизмы-стрелки -- это функции (выражения). И примеры преобразований одних объектов в другие в реальном мире есть, например, из льда можно сделать пар, достаточно сильно разогрев его, из муки, яиц, соды и других ингредиентов можно сделать пирог и т.д.
Поэтому ООП-бляди зря себе присваивают т.н. "объектный подход", этим все и так пользуются без ООП.
>объектному подходу
А что это такое? Если это "называть структуры данных так же, как объекты реального мира", то ООП -- это велосипед, ибо так делали еще в Си.
Кстати, аргумент в пользу ООП "ну реальный мир то из объектов состоит а не из функций)))00)" на мой взгляд дурацкий, ибо ООП это не только объекты, но еще и сообщения между ними. В связи с чем у меня возникает вопрос: что нужно курить, чтобы камни начали обмениваться сообщениями с деревьями, ручьи с облаками и т.д.? В ФП объекты -- это типы, и никаких загадочных сообщений нет, есть морфизмы-стрелки -- это функции (выражения). И примеры преобразований одних объектов в другие в реальном мире есть, например, из льда можно сделать пар, достаточно сильно разогрев его, из муки, яиц, соды и других ингредиентов можно сделать пирог и т.д.
Поэтому ООП-бляди зря себе присваивают т.н. "объектный подход", этим все и так пользуются без ООП.
>>603121
Зато в ООП это получается наиболее естественно, чем в трудно совместимых с реальным миром идеях об иммутабельности.
Зато в ООП это получается наиболее естественно, чем в трудно совместимых с реальным миром идеях об иммутабельности.
>>603121
Не структуры данных, а объекты
Не реального мира, а предметной области
Поподробней можно?
Не сообщения, а связь
У тебя не может быть типа данных Window, следовательно это не объекты, следовательно твои "объекты" - это примитивные типы данных, если же у тебя полноценные структуры и классы, то это уже не ФП
>называть структуры данных так же, как объекты реального мира
Не структуры данных, а объекты
Не реального мира, а предметной области
>так делали еще в Си
Поподробней можно?
>ООП это не только объекты, но еще и сообщения между ними
Не сообщения, а связь
> В ФП объекты -- это типы
У тебя не может быть типа данных Window, следовательно это не объекты, следовательно твои "объекты" - это примитивные типы данных, если же у тебя полноценные структуры и классы, то это уже не ФП
>>603138
В ООП-языке у тебя класс, в которых поля и методы, обращающиеся к полям.
В сишке у тебя структура с несколькими полями и функции, принимающие первым аргументом эту структуру.
мимо
>> так делали еще в Си
> Поподробней можно?
В ООП-языке у тебя класс, в которых поля и методы, обращающиеся к полям.
В сишке у тебя структура с несколькими полями и функции, принимающие первым аргументом эту структуру.
мимо
>>603138
А связь это что тогда? Очередная неведомая хуйня из мира такого очень похожего на реальный ООП?
>Не сообщения, а связь
А связь это что тогда? Очередная неведомая хуйня из мира такого очень похожего на реальный ООП?
>>603148
Нет, связь между объектами это, например, один объект управляет другим
Нет, связь между объектами это, например, один объект управляет другим
>>603149
Нет.
Нет.
ООП - срань.
У нас есть определенное состояние и его мутации. Функциональщина больше подходит для моделирования окружающего мира.
Кстати, было исследование, где в пиндосии ставили эксперименты над студентами. Они куда быстрее врубались в фп, чем другая группа в ООП.
У нас есть определенное состояние и его мутации. Функциональщина больше подходит для моделирования окружающего мира.
Кстати, было исследование, где в пиндосии ставили эксперименты над студентами. Они куда быстрее врубались в фп, чем другая группа в ООП.
>>603415
Вместо того, чтобы просто изменить объект, создаётся его полная копия, но немного изменённая. При этом старая никуда не девается. Так похоже на реальный мир, да.
Потому что математика головного мозга. Они такие: "как x = x = 1, если x не равно x + 1"
> Функциональщина больше подходит для моделирования окружающего мира.
Вместо того, чтобы просто изменить объект, создаётся его полная копия, но немного изменённая. При этом старая никуда не девается. Так похоже на реальный мир, да.
> Они куда быстрее врубались в фп, чем другая группа в ООП.
Потому что математика головного мозга. Они такие: "как x = x = 1, если x не равно x + 1"
>>602051 (OP)
О, запахло старыми добрыми ООП-тредами, как же я траллил тогда, эх, молодость.
ОП, книги нужно читать самые разные, даже сраного Буча, но они ничего не дадут из коробки. Надо пробовать, пытаться, переосмысливать, возвращаться, перечитывать и так 20 лет.
Один из самых надежных признаков дилетанта (или тролля) - вопли на тему превосходства/голимости ООП/ФП, или, как разновидность, развешивание ярлыков "это не ФП"/"это не ООП". Можно и на ассемблере писать ООП, или на C, как подметил >>603141-кун. Да, сахара не будет, а таблицы виртуальных методов для полиморфизма придется писать врукопашную - но можно. Прошаренный проектировщик вмегда помнит о главной цели: нам надо управлять рождением и/или развитием конкретной сложной системы, и только успех в решении данной задачи является критерием успеха подхода. ООП очень много дал инженерам в этом смысле, и что немаловажно - отрицательного, что сильно повлияло на вектор развития современных языков.
О, запахло старыми добрыми ООП-тредами, как же я траллил тогда, эх, молодость.
ОП, книги нужно читать самые разные, даже сраного Буча, но они ничего не дадут из коробки. Надо пробовать, пытаться, переосмысливать, возвращаться, перечитывать и так 20 лет.
Один из самых надежных признаков дилетанта (или тролля) - вопли на тему превосходства/голимости ООП/ФП, или, как разновидность, развешивание ярлыков "это не ФП"/"это не ООП". Можно и на ассемблере писать ООП, или на C, как подметил >>603141-кун. Да, сахара не будет, а таблицы виртуальных методов для полиморфизма придется писать врукопашную - но можно. Прошаренный проектировщик вмегда помнит о главной цели: нам надо управлять рождением и/или развитием конкретной сложной системы, и только успех в решении данной задачи является критерием успеха подхода. ООП очень много дал инженерам в этом смысле, и что немаловажно - отрицательного, что сильно повлияло на вектор развития современных языков.
>>603445
Принадлежность к парадигме определяет то, какими инструментами ты будешь пользоваться при решении определенной проблемы, минимизируя при этом количество кода. В Си можно наверняка сделать и объекты, и монады, и композицию (вообще не факт, но предположим), и потом через них решить задачу, но ты все равно их будешь делать за счет императивных средств вроде прямого управления памятью и т.д. И наоборот, в ФП можно писать императивный код, но прямое обращение к памяти и т.д. ты будешь делать используя средства ФП. В первом случае было бы быстрее (читай -- экономнее в плане количества строк кода) сразу работать с тем, что есть в Си, а во втором случае сразу работать с тем, что дает ФП.
>>603443
Как что-то плохое. Новука та же описывает мир через математические модели. Те новуки, которые не описывают, являются хуитой вроде психоанализа, марксизма и астрологии.
Принадлежность к парадигме определяет то, какими инструментами ты будешь пользоваться при решении определенной проблемы, минимизируя при этом количество кода. В Си можно наверняка сделать и объекты, и монады, и композицию (вообще не факт, но предположим), и потом через них решить задачу, но ты все равно их будешь делать за счет императивных средств вроде прямого управления памятью и т.д. И наоборот, в ФП можно писать императивный код, но прямое обращение к памяти и т.д. ты будешь делать используя средства ФП. В первом случае было бы быстрее (читай -- экономнее в плане количества строк кода) сразу работать с тем, что есть в Си, а во втором случае сразу работать с тем, что дает ФП.
>>603443
>Потому что математика головного мозга.
Как что-то плохое. Новука та же описывает мир через математические модели. Те новуки, которые не описывают, являются хуитой вроде психоанализа, марксизма и астрологии.
>>603452
Это не совсем так, в некоторых областях биологии широко применяется математика.
Физика тоже не всегда была точной наукой, часть её разделов изначально были описательными.
мимо
Это не совсем так, в некоторых областях биологии широко применяется математика.
Физика тоже не всегда была точной наукой, часть её разделов изначально были описательными.
мимо
>>603460
100001001.
100001001.
>>603445
Виталик Л. прав.
ООП скорее про принцип проектирования, который можно реализовать на чём угодно. В принципе можно сказать, что если у тебя потребность писать в ООП стиле даже не на ООП языках с соответствующим оверхедом, то ООП явно оправдан.
Просто эту концепцию, как и массу других, иногда пытаются приткнуть просто, чтобы была, не понимая, какие проблемы ты решаешь, откуда там сложности берутся и как с ними бороться.
ООП из названия видно, что ориентировано на объекты. Вот когда ты в программе имеешь дело с какими-то сложными объектами, со сложным внутренним состоянием, с большим количеством функций, к ним применимых (завязанных на состояние), особенно когда разнородные, но схожие объекты есть, то ООП подход по отношению к ним оправдан.
Но когда религиозники начинают "всё есть объект" и рожают ООП на пустом месте, то там пиздец начинается. Они не решают проблемы проектирования, а создают их.
Виталик Л. прав.
ООП скорее про принцип проектирования, который можно реализовать на чём угодно. В принципе можно сказать, что если у тебя потребность писать в ООП стиле даже не на ООП языках с соответствующим оверхедом, то ООП явно оправдан.
Просто эту концепцию, как и массу других, иногда пытаются приткнуть просто, чтобы была, не понимая, какие проблемы ты решаешь, откуда там сложности берутся и как с ними бороться.
ООП из названия видно, что ориентировано на объекты. Вот когда ты в программе имеешь дело с какими-то сложными объектами, со сложным внутренним состоянием, с большим количеством функций, к ним применимых (завязанных на состояние), особенно когда разнородные, но схожие объекты есть, то ООП подход по отношению к ним оправдан.
Но когда религиозники начинают "всё есть объект" и рожают ООП на пустом месте, то там пиздец начинается. Они не решают проблемы проектирования, а создают их.
>>603141
Что такое объект и методы.
У тебя есть объект, то есть структура данных, какая-то область памяти, где хранятся переменные и указатели, ссылка на описание класса объекта, таблицу виртуальных функций и т.п., тут специфика каждого языка. Метод объекта - это самая обычная функция, куда одним из аргументов передаётся указатель на объект. Эта функция просто берёт указатель на объекта, получает переменные оттуда и что-то с ними делает.
Например в питоне этот указатель даже явно в методах указывается, первый параметр, принято его self называть. Чаще принято неявно его передавать, и в функции этот указатель называется обычно this.
Как было в сишечке. Самый яркий пример - функции для работы с файлами. Там два типа функций было. Более показательный f-вариант
FILE *f = fopen(name, attr);
c = fgetc(f) // прочитать следующий символ из открытого файла
В сущности FILE - это какой-то сложный объект. И во все функции ты первым параметром передаёшь указатель на этот объект.
И так можно реализовывать любые объекты.
Можно и самому наследование поддержать, и виртуальные функции, и другое.
По сути: современные языки мультипарадигмовые, сюда идёт развитие. Они не пытаются выжать максимум из одной парадигмы, а больше базу берут от каждой, которой ты можешь пользоваться. Как в конкретном случае удобнее, так и пользуешься.
Питон, JS - они и немного ООП, но немного, и немного ФП.
Общий тренд сейчас - асинхронные инструменты, их запиливают во все языки, async/await. Полезно знать, но это тоже не панацея даже для асинхронных задач. Просто один из принципов проектирования соответствующего сервисного кода.
Что такое объект и методы.
У тебя есть объект, то есть структура данных, какая-то область памяти, где хранятся переменные и указатели, ссылка на описание класса объекта, таблицу виртуальных функций и т.п., тут специфика каждого языка. Метод объекта - это самая обычная функция, куда одним из аргументов передаётся указатель на объект. Эта функция просто берёт указатель на объекта, получает переменные оттуда и что-то с ними делает.
Например в питоне этот указатель даже явно в методах указывается, первый параметр, принято его self называть. Чаще принято неявно его передавать, и в функции этот указатель называется обычно this.
Как было в сишечке. Самый яркий пример - функции для работы с файлами. Там два типа функций было. Более показательный f-вариант
FILE *f = fopen(name, attr);
c = fgetc(f) // прочитать следующий символ из открытого файла
В сущности FILE - это какой-то сложный объект. И во все функции ты первым параметром передаёшь указатель на этот объект.
И так можно реализовывать любые объекты.
Можно и самому наследование поддержать, и виртуальные функции, и другое.
По сути: современные языки мультипарадигмовые, сюда идёт развитие. Они не пытаются выжать максимум из одной парадигмы, а больше базу берут от каждой, которой ты можешь пользоваться. Как в конкретном случае удобнее, так и пользуешься.
Питон, JS - они и немного ООП, но немного, и немного ФП.
Общий тренд сейчас - асинхронные инструменты, их запиливают во все языки, async/await. Полезно знать, но это тоже не панацея даже для асинхронных задач. Просто один из принципов проектирования соответствующего сервисного кода.
Ещё соплей, чуть из серии ООП vs ФП.
Суть ООП - есть объект, некая сущность. Настоящий объект это то, что нельзя скопировать, к нему можно только применить методы. Вот как Window, или структура файла, сокета или чего ещё. Скопировать объект - это целая песня, он же может содержать ссылки на другие объекты, как эксклюзивно, как и шареные между другими объектами. В общем случае скопировать объект невозможно. Вот как в реальном мире, где состояние квантовой частицы скопировать невозможно.
ФП опирается больше на математические идеи, где всё есть какое-то выражение, можно всегда скопировать, сохранить и т.п.
Невозможно применить ФП к настоящим объектам, у них просто недетерминированное состояние. ФП не может быть заменой ООП в реально жизни примерно никогда. Вот из-за этих свойств объекта. Но на самом деле это проблема объектов, а не их сильная сторона. Было бы куда проще, если бы объекты было легко клонировать, сохранять и восстанавливать, пересылать по себе. И вот реально надо проектировать так, чтобы максимально уходить от этого "квантового" свойства объектов, это реально убирает массу проблем и открывает массу возможностей. Но возможно далеко не всегда, а когда возможно, не всегда разумно.
Суть ООП - есть объект, некая сущность. Настоящий объект это то, что нельзя скопировать, к нему можно только применить методы. Вот как Window, или структура файла, сокета или чего ещё. Скопировать объект - это целая песня, он же может содержать ссылки на другие объекты, как эксклюзивно, как и шареные между другими объектами. В общем случае скопировать объект невозможно. Вот как в реальном мире, где состояние квантовой частицы скопировать невозможно.
ФП опирается больше на математические идеи, где всё есть какое-то выражение, можно всегда скопировать, сохранить и т.п.
Невозможно применить ФП к настоящим объектам, у них просто недетерминированное состояние. ФП не может быть заменой ООП в реально жизни примерно никогда. Вот из-за этих свойств объекта. Но на самом деле это проблема объектов, а не их сильная сторона. Было бы куда проще, если бы объекты было легко клонировать, сохранять и восстанавливать, пересылать по себе. И вот реально надо проектировать так, чтобы максимально уходить от этого "квантового" свойства объектов, это реально убирает массу проблем и открывает массу возможностей. Но возможно далеко не всегда, а когда возможно, не всегда разумно.
>>602051 (OP)
В ООП языках для говноедов, никакой особой идеи нет, это просто надстройка над процедурным программированием, код - это утверждения МЕНЯЮЩИЕ глобальное состояние программы. В языках для людей код - это выражения. Выражения соответствуют математическим объектами и ОБОЗНАЧАЮТ их величины.
В ООП языках для говноедов, никакой особой идеи нет, это просто надстройка над процедурным программированием, код - это утверждения МЕНЯЮЩИЕ глобальное состояние программы. В языках для людей код - это выражения. Выражения соответствуют математическим объектами и ОБОЗНАЧАЮТ их величины.
>>603788
Содомит
Содомит
56 Кб, 732x566>>603880
Харкнул в ебло этому пролетарию.
Харкнул в ебло этому пролетарию.
>>603501
Я не он (хотя и работал с одним Виталиком Л. в Авито пару лет назад).
>>603501
Люто двачую, особенно этот пиздец проявляется при работе с большими объемами данных (вроде текстовых редакторов) и сложными абстрактными структурами (вроде конечных автоматов в компиляторах). Важно уметь увидеть, где подход на пользу, а где во вред, а не совать его везде. Тут еще проблема в том, чаще всего ООП действительно хорош в прикладных задачах уровня крудошлепства; это порождает ложное убеждение, что он хорош всегда и везде.
>Виталик Л. прав.
Я не он (хотя и работал с одним Виталиком Л. в Авито пару лет назад).
>>603501
>религиозники начинают "всё есть объект" и рожают ООП на пустом месте, то там пиздец начинается
Люто двачую, особенно этот пиздец проявляется при работе с большими объемами данных (вроде текстовых редакторов) и сложными абстрактными структурами (вроде конечных автоматов в компиляторах). Важно уметь увидеть, где подход на пользу, а где во вред, а не совать его везде. Тут еще проблема в том, чаще всего ООП действительно хорош в прикладных задачах уровня крудошлепства; это порождает ложное убеждение, что он хорош всегда и везде.
>>602051 (OP)
1. Твой пик по шаблонам
2. Patterns of Enterprise Application Architecture
3. Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems
1. Твой пик по шаблонам
2. Patterns of Enterprise Application Architecture
3. Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems
>>603141
Методы в ООП под капотом работают аналогично сишным функциям, принимающим указатели на структуру. Всегда сркытно первым аргументом идет ссылка на сам объект. В яве так, по-моему.
Методы в ООП под капотом работают аналогично сишным функциям, принимающим указатели на структуру. Всегда сркытно первым аргументом идет ссылка на сам объект. В яве так, по-моему.
>>603445
По подробнее можно? Я только знаю про DOD когда ООП тормозило кеш на убогом соснольно-соснульном железе:
https://www.youtube.com/watch?v=rX0ItVEVjHc
>ООП очень много дал инженерам в этом смысле, и что немаловажно - отрицательного, что сильно повлияло на вектор развития современных языков.
По подробнее можно? Я только знаю про DOD когда ООП тормозило кеш на убогом соснольно-соснульном железе:
https://www.youtube.com/watch?v=rX0ItVEVjHc
>>607512
Fragile base class как фундаментальный неустранимый недостаток, к примеру. В итоге современные best practices избегают длинных цепочек наследования, а в некоторых языках наследование реализации вообще недопустимо.
Fragile base class как фундаментальный неустранимый недостаток, к примеру. В итоге современные best practices избегают длинных цепочек наследования, а в некоторых языках наследование реализации вообще недопустимо.
>>607512
ООП не может "тормозить кэш", это может делать компилятор, не умеющий в оптимизацию.
>ООП тормозило
ООП не может "тормозить кэш", это может делать компилятор, не умеющий в оптимизацию.
>>609533
Может.
Особенно заметно в плюсах, развесистый ооп вызывает регулярные кэш мисы.
Остальные языки слишком тормозные, что бы это сильно влияло.
Может.
Особенно заметно в плюсах, развесистый ооп вызывает регулярные кэш мисы.
Остальные языки слишком тормозные, что бы это сильно влияло.
>>602099
А нахуя их рисовать? Я могу начать за месяц думать над решением задачи, не приступая к написанию кода. Могу долго думать, как это лучше написать. Когда структура более-менее прозрачна, сажусь писать.
А нахуя их рисовать? Я могу начать за месяц думать над решением задачи, не приступая к написанию кода. Могу долго думать, как это лучше написать. Когда структура более-менее прозрачна, сажусь писать.
>>603095
Как называется книжка?
Как называется книжка?
>>604686
Спасибо, почитаю
Спасибо, почитаю
>>609591
Это делает не ооп, а конпелятор крестов. ООП - это просто способ записывать программу, а как ее выполнять - вопрос совершенно другой. Тот же раст на этапе конпеляции вытворяет такое, что крестам и не снилось.
>развесистый ооп вызывает регулярные кэш мисы
Это делает не ооп, а конпелятор крестов. ООП - это просто способ записывать программу, а как ее выполнять - вопрос совершенно другой. Тот же раст на этапе конпеляции вытворяет такое, что крестам и не снилось.
А накидайте курсов бесплатных/которые есть на торрентах по архитектуре.
Там чистая, микросервисы, cqrs es
Что-нибудь где эту херь на практике показывают. От статей пухнет голова как от непонятной теории.
Там чистая, микросервисы, cqrs es
Что-нибудь где эту херь на практике показывают. От статей пухнет голова как от непонятной теории.
Бамп
>>602183
хорошая книга, стоит читать.
хорошая книга, стоит читать.
>>603121
Поэтому от двача нужно отказаться, ну, или заходить раз в месяц, два, после такого текста.
Чел, ООП это альтернатива реальному миру, она не говорит о том, что ООП сделали для объектов реального мира.
удаляюсь с вашего позволения.
Поэтому от двача нужно отказаться, ну, или заходить раз в месяц, два, после такого текста.
Чел, ООП это альтернатива реальному миру, она не говорит о том, что ООП сделали для объектов реального мира.
>Objects sometimes correspond to things found in the real world
удаляюсь с вашего позволения.
>>603121
Ничего курить не нужно, потому что именно так обстоят дела в реальном мире. Звёзды на небе это энергия излучённая в момент Х, которую ты своими рецепторами уловишь и обработаешь к момент Y, причём те картинки что ты увидишь далеко не то что было на самом деле, да и никакого объекта к этому моменту может и не быть, т.е. объект звезда существует только внутри сообщения в твоём мейлбоксе и его свойства сужены до уровня, который твой интерфейс способен обрабатывать.
>В связи с чем у меня возникает вопрос: что нужно курить, чтобы камни начали обмениваться сообщениями с деревьями, ручьи с облаками и т.д.?
Ничего курить не нужно, потому что именно так обстоят дела в реальном мире. Звёзды на небе это энергия излучённая в момент Х, которую ты своими рецепторами уловишь и обработаешь к момент Y, причём те картинки что ты увидишь далеко не то что было на самом деле, да и никакого объекта к этому моменту может и не быть, т.е. объект звезда существует только внутри сообщения в твоём мейлбоксе и его свойства сужены до уровня, который твой интерфейс способен обрабатывать.
С ОО-даунами бесполезно спорить и что-то им доказывать.
ООП не дает строгого определения объекта, это открывает огромные возможности для маневрирования. Приводишь в пример очередной костыль-паттерн и в ответ слышишь: КО-КО-КО ЭТО НЕ НАСТОЯЩИЙ ООП. НАСТОЯЩИЙ ООП ЭТО [очередной набор баззвордов вперемешку без какого-либо смысла].
Очень похоже на ситуацию с верунами, которые по разному интерпретируют писания троллей и даунов из прошлых веков.
ООП не дает строгого определения объекта, это открывает огромные возможности для маневрирования. Приводишь в пример очередной костыль-паттерн и в ответ слышишь: КО-КО-КО ЭТО НЕ НАСТОЯЩИЙ ООП. НАСТОЯЩИЙ ООП ЭТО [очередной набор баззвордов вперемешку без какого-либо смысла].
Очень похоже на ситуацию с верунами, которые по разному интерпретируют писания троллей и даунов из прошлых веков.
>>650234
Абстрактный объект на то и абстрактный, что о нём известен только некий набор свойств. Собственно, математика изучением объектов, о которых почти ничего не известно.
Абстрактный объект на то и абстрактный, что о нём известен только некий набор свойств. Собственно, математика изучением объектов, о которых почти ничего не известно.
test
О, как раз хотел спросить про книгу с ОП-пика. Оно еще актуально, или устаревшее говно мамонта?
>>655672
Паттерны не устаревают.
Сама корзинка говно по сравнению с бандой четырех, но почему бы и нет.
Паттерны не устаревают.
Сама корзинка говно по сравнению с бандой четырех, но почему бы и нет.
>>602051 (OP)
Точно не из той серии, что на оппике, где на обложке всякие босоногие долбаебы с отвратительной формой стопы (даже мне, фут-фетишисту, блевать хочется).
Я пытался читать Хавьера Design Patterns .NET. НИАСИЛИЛ, каюсь
Если ты не Senior Solution Arcitect, то тебе это не нужно. А то забьешь себе голову всякой хуйней и будешь потом оборачивать функцию сложения двух чисел в декоратор, который создается фабрикой через прокси, которая в свою очередь создается билдером а над всем этим Abstract Factory ебнуть, сам не зная зачем, но не зря ж книжку читал
Если твой проект будет иметь 100 000+ сущностей, которые будут распределены по 1000 БД, а бизнес логика такая, что даже будучи распределенной поровну в головы целой армии китайцев не поместится, то да. В остальных случаях практически бесполезна.
Ты так говоришь, как будто это что-то плохое
Обычно это делается так:
1. Тебе объясняют на пальцах то, чего от тебя хотят
2. Тебе все предельно понятно и ты идешь кодить
3. Начинаешь кодить и чет уже не так все понятно
4. Идешь уточнять, тебе уже не так уверенно отвечают на твои вопросы
5. Ты идешь и рисуешь на бумаге схему, как ты понял, что от тебя хотят и несешь показывать со словами "ЭТО ВЫ БЛЯТЬ ХОТИТЕ?"
6. Тебе говорят "НЕТ, БЛЯТЬ НЕ ЭТО!"
7. Ты говоришь "ТАК НАРИСУЙ БЛЯТЬ КАК НАДО!"
8. Тебе рисуют, вроде все понятно, идешь кодить
9. Возвращаешься на шаг 3
> Какие книги по проектированию стоит почитать?
Точно не из той серии, что на оппике, где на обложке всякие босоногие долбаебы с отвратительной формой стопы (даже мне, фут-фетишисту, блевать хочется).
Я пытался читать Хавьера Design Patterns .NET. НИАСИЛИЛ, каюсь
> Какие инструменты и методики хорошо работают?
Если ты не Senior Solution Arcitect, то тебе это не нужно. А то забьешь себе голову всякой хуйней и будешь потом оборачивать функцию сложения двух чисел в декоратор, который создается фабрикой через прокси, которая в свою очередь создается билдером а над всем этим Abstract Factory ебнуть, сам не зная зачем, но не зря ж книжку читал
> UML - годнота?
Если твой проект будет иметь 100 000+ сущностей, которые будут распределены по 1000 БД, а бизнес логика такая, что даже будучи распределенной поровну в головы целой армии китайцев не поместится, то да. В остальных случаях практически бесполезна.
> Как не скатиться в ООП-головного мозга?
Ты так говоришь, как будто это что-то плохое
> До какого уровня конкретики стоит доводить проект на бумаге: буквально до набросков реализации или остановиться на описании объектов и их взаимодействия, а остальное уже доводить до ума в процессе имплементации?
Обычно это делается так:
1. Тебе объясняют на пальцах то, чего от тебя хотят
2. Тебе все предельно понятно и ты идешь кодить
3. Начинаешь кодить и чет уже не так все понятно
4. Идешь уточнять, тебе уже не так уверенно отвечают на твои вопросы
5. Ты идешь и рисуешь на бумаге схему, как ты понял, что от тебя хотят и несешь показывать со словами "ЭТО ВЫ БЛЯТЬ ХОТИТЕ?"
6. Тебе говорят "НЕТ, БЛЯТЬ НЕ ЭТО!"
7. Ты говоришь "ТАК НАРИСУЙ БЛЯТЬ КАК НАДО!"
8. Тебе рисуют, вроде все понятно, идешь кодить
9. Возвращаешься на шаг 3
>>602051 (OP)
Точно не из той серии, что на оппике, где на обложке всякие босоногие долбаебы с отвратительной формой стопы (даже мне, фут-фетишисту, блевать хочется).
Я пытался читать Хавьера Design Patterns .NET. НИАСИЛИЛ, каюсь
Если ты не Senior Solution Arcitect, то тебе это не нужно. А то забьешь себе голову всякой хуйней и будешь потом оборачивать функцию сложения двух чисел в декоратор, который создается фабрикой через прокси, которая в свою очередь создается билдером а над всем этим Abstract Factory ебнуть, сам не зная зачем, но не зря ж книжку читал
Если твой проект будет иметь 100 000+ сущностей, которые будут распределены по 1000 БД, а бизнес логика такая, что даже будучи распределенной поровну в головы целой армии китайцев не поместится, то да. В остальных случаях практически бесполезна.
Ты так говоришь, как будто это что-то плохое
Обычно это делается так:
1. Тебе объясняют на пальцах то, чего от тебя хотят
2. Тебе все предельно понятно и ты идешь кодить
3. Начинаешь кодить и чет уже не так все понятно
4. Идешь уточнять, тебе уже не так уверенно отвечают на твои вопросы
5. Ты идешь и рисуешь на бумаге схему, как ты понял, что от тебя хотят и несешь показывать со словами "ЭТО ВЫ БЛЯТЬ ХОТИТЕ?"
6. Тебе говорят "НЕТ, БЛЯТЬ НЕ ЭТО!"
7. Ты говоришь "ТАК НАРИСУЙ БЛЯТЬ КАК НАДО!"
8. Тебе рисуют, вроде все понятно, идешь кодить
9. Возвращаешься на шаг 3
> Какие книги по проектированию стоит почитать?
Точно не из той серии, что на оппике, где на обложке всякие босоногие долбаебы с отвратительной формой стопы (даже мне, фут-фетишисту, блевать хочется).
Я пытался читать Хавьера Design Patterns .NET. НИАСИЛИЛ, каюсь
> Какие инструменты и методики хорошо работают?
Если ты не Senior Solution Arcitect, то тебе это не нужно. А то забьешь себе голову всякой хуйней и будешь потом оборачивать функцию сложения двух чисел в декоратор, который создается фабрикой через прокси, которая в свою очередь создается билдером а над всем этим Abstract Factory ебнуть, сам не зная зачем, но не зря ж книжку читал
> UML - годнота?
Если твой проект будет иметь 100 000+ сущностей, которые будут распределены по 1000 БД, а бизнес логика такая, что даже будучи распределенной поровну в головы целой армии китайцев не поместится, то да. В остальных случаях практически бесполезна.
> Как не скатиться в ООП-головного мозга?
Ты так говоришь, как будто это что-то плохое
> До какого уровня конкретики стоит доводить проект на бумаге: буквально до набросков реализации или остановиться на описании объектов и их взаимодействия, а остальное уже доводить до ума в процессе имплементации?
Обычно это делается так:
1. Тебе объясняют на пальцах то, чего от тебя хотят
2. Тебе все предельно понятно и ты идешь кодить
3. Начинаешь кодить и чет уже не так все понятно
4. Идешь уточнять, тебе уже не так уверенно отвечают на твои вопросы
5. Ты идешь и рисуешь на бумаге схему, как ты понял, что от тебя хотят и несешь показывать со словами "ЭТО ВЫ БЛЯТЬ ХОТИТЕ?"
6. Тебе говорят "НЕТ, БЛЯТЬ НЕ ЭТО!"
7. Ты говоришь "ТАК НАРИСУЙ БЛЯТЬ КАК НАДО!"
8. Тебе рисуют, вроде все понятно, идешь кодить
9. Возвращаешься на шаг 3
>>602125
Двачую. Пробовал читать их книгу по C# - чуть не блеванул.
Двачую. Пробовал читать их книгу по C# - чуть не блеванул.
>>602125
Конкретно эту рецензировал и рекомендовал Эрих Гамма и какой то второй из банды. Она считается проще и понятнее оригинала. К тому же примеры - на джаве. Опять же надо понимать что хэд фест - это учебник для нубов, а не справочник. Поэтому воды много. В начале первая страница об этом.
>>602051 (OP)
Книги Боба Мартина и Мартина Фаулера наверни.
>>не читай.
Конкретно эту рецензировал и рекомендовал Эрих Гамма и какой то второй из банды. Она считается проще и понятнее оригинала. К тому же примеры - на джаве. Опять же надо понимать что хэд фест - это учебник для нубов, а не справочник. Поэтому воды много. В начале первая страница об этом.
>>602051 (OP)
>>Какие книги по проектированию стоит почитать?
Книги Боба Мартина и Мартина Фаулера наверни.
>>675173
Мошенники, которые зарабатывают тем, что пишут свои мутные книжки и выступают на конференциях где рассказывают о своих бредовых идеях. Удивительно, что кто-то ведется на таких говорящих голов, которые никогда и нигде не работали программистами.
>Боба Мартина и Мартина Фаулера
Мошенники, которые зарабатывают тем, что пишут свои мутные книжки и выступают на конференциях где рассказывают о своих бредовых идеях. Удивительно, что кто-то ведется на таких говорящих голов, которые никогда и нигде не работали программистами.
>>602099
В моей шараге есть такие преподаватели
В моей шараге есть такие преподаватели
>>675176
Кто-то еще ходит учиться в вузик к людям, которые никогда не работали программистами.
Кто-то еще ходит учиться в вузик к людям, которые никогда не работали программистами.
>>676055
Не может - он ведь тоже никогда не работал программистом.
>или ты что-то конкретное сказать можешь?
Не может - он ведь тоже никогда не работал программистом.
>>683866
Размести объяву о найме джуна без опыта, скидывай как тестовое. у вас же там и так полно программистов за миску борща
Размести объяву о найме джуна без опыта, скидывай как тестовое. у вас же там и так полно программистов за миску борща
>>603451
Вообще-то марксизм описывает, если мы про марксистскую экономику говорим. С предсказательной силой там беда, но это общая проблема всех экономических и социологических теорий, а математика на месте.
>Те новуки, которые не описывают, являются хуитой вроде психоанализа, марксизма и астрологии
Вообще-то марксизм описывает, если мы про марксистскую экономику говорим. С предсказательной силой там беда, но это общая проблема всех экономических и социологических теорий, а математика на месте.
Давайте пертрем за Event Storming. Кто умеет/практикует?
1) На каком этапе надо учить и пробовать применять паттерны, сразу после общих концепций ооп?
2) Как развивать ООП-мышление? Мне сказали, что я все равно пишу структурным подходом, несмотря на использование классов.
2) Как развивать ООП-мышление? Мне сказали, что я все равно пишу структурным подходом, несмотря на использование классов.
>>602060
толсто
толсто
34 Кб, 1166x229>>602051 (OP)
Как бы вы спроектировали элегантно?
Есть класс УниверсальныйРисовательТаблиц (УРТ), который пишет наименование объекта и в столбцах его свойства (разных типов). Есть класс Товар, у него свойства: вес, состав, дата изготовления, срок годности, адрес производителя. УРТ может нарисовать каталог таких товаров. Но в магазине хранится другая структура {Товар, цена, количество} , и УРТ должен нарисовать и список таких записей тоже, причем уже не все свойства Товара надо отобразить, а напимер так: наименование, дата изготовления, вес, цена, количество.
Я думал сделать интерфейс, который передается УРТ, из него УРТ может получить массив названий свойств (строк). И еще сделать в интерфейсе метод GetValue(int tovarId, string propertyName), а в реализации этого метода if (propertyName == "состав") { ... }. Но они же разных типов могут быть. Что делать?
Как бы вы спроектировали элегантно?
Есть класс УниверсальныйРисовательТаблиц (УРТ), который пишет наименование объекта и в столбцах его свойства (разных типов). Есть класс Товар, у него свойства: вес, состав, дата изготовления, срок годности, адрес производителя. УРТ может нарисовать каталог таких товаров. Но в магазине хранится другая структура {Товар, цена, количество} , и УРТ должен нарисовать и список таких записей тоже, причем уже не все свойства Товара надо отобразить, а напимер так: наименование, дата изготовления, вес, цена, количество.
Я думал сделать интерфейс, который передается УРТ, из него УРТ может получить массив названий свойств (строк). И еще сделать в интерфейсе метод GetValue(int tovarId, string propertyName), а в реализации этого метода if (propertyName == "состав") { ... }. Но они же разных типов могут быть. Что делать?
>>843448
Ну и что что разных типов, у тебя будет отдельная реализация этого интерфейса для товара и никогда её не будет использовать для других типов.
Нормальная у тебя идея - Урт может получать (с помощью сеттера) ноль и более интерфейсов "отдаватель списка интересующих полей", поставленных в соответствие с типом, к которому такой отдаватель надо получать.
Это конечно если не хочется вручную выдирать из товара нужные поля и пихать в урт , я бы сделал вручную
Ну и что что разных типов, у тебя будет отдельная реализация этого интерфейса для товара и никогда её не будет использовать для других типов.
Нормальная у тебя идея - Урт может получать (с помощью сеттера) ноль и более интерфейсов "отдаватель списка интересующих полей", поставленных в соответствие с типом, к которому такой отдаватель надо получать.
Это конечно если не хочется вручную выдирать из товара нужные поля и пихать в урт , я бы сделал вручную
>>843448
View Model
View Model
Есть некая игра на прямоугольной доске. В клетках стоят фигуры разных типов. Если начинать с самой простой реализации, то доска - двумерный массив, а фигуры - целые константы const int A = 0, B = 1... или enum { A, B, C ... }. Тут уже возникает мысль, что фигуры должны уметь себя рисовать, значит надо сделать их классами с методом Draw(), но пока не до этого, будем отделять логику игры, от ее отображения. Далее выясняется, что некоторые фигуры могут быть Левыми и Правыми. Продолжая вариант с перечислениями получаем enum { A, B, CLeft, CRight, DLeft, DRight... }. Тут конечно проблема, если я хочу функцию, меняющую ориентацию фигуры, придется ифами перебирать все типы. Я тут 3 варианта вижу, и все они не очень.
1) Иерархия классов Фигура->СимметричнаяФигура. Надо будет проверять, является ли фигура симметричной. Если является, то кастовать ее к этому типу и отражать. И если у меня нет множественного наследования, я не смогу подобным образом добавить другие свойства.
2) Интерфейсы. Опять надо проверять тип и кастовать. Также для всех Симметричных типов придется накопипастить одинаковую реализацию. Я не знаю как тут не копипастить.
3) Универсальный класс фигуры, в котором есть все свойства всех фигур и методы проверки, реализовано это свойство или нет.
Что лучше, другие варианты?
1) Иерархия классов Фигура->СимметричнаяФигура. Надо будет проверять, является ли фигура симметричной. Если является, то кастовать ее к этому типу и отражать. И если у меня нет множественного наследования, я не смогу подобным образом добавить другие свойства.
2) Интерфейсы. Опять надо проверять тип и кастовать. Также для всех Симметричных типов придется накопипастить одинаковую реализацию. Я не знаю как тут не копипастить.
3) Универсальный класс фигуры, в котором есть все свойства всех фигур и методы проверки, реализовано это свойство или нет.
Что лучше, другие варианты?
>>852694
по-байтоебски в енаме отвести бит на флаг - симметрична ли фигура или нет, и менять флаг через xor.
по-байтоебски в енаме отвести бит на флаг - симметрична ли фигура или нет, и менять флаг через xor.
>>609958
Ты наверное архитектуры больше чем Хелоуворда не продумывал.
А вот пришлось как-то писать с нуля кросплатформенное приложение, читающее сенсоры с разных мат.плат. везде свои стандарты, где-то подключено к чипсету напрямую, где-то к SIO, да и везде свои SIO и чипсеты, где-то данные идут по 8бит, где-то по 16, короче, в линуксе одни методы доступа к аппаратуре, в винде другие, короче, заёб полный с этой стандартизацией, чтобы потом не росло как больное дерево.
Надо сначала продумывать и детально и где-то записывать. Чтоб потом следовали четко документации, а не так: "слушай я тут хуйню придумал, давай её заимплементим, потом доделаем и будем её тоже поддерживать", вот именно на этой стадии проект "размазывается" и начинается возня в болоте.
Ты наверное архитектуры больше чем Хелоуворда не продумывал.
А вот пришлось как-то писать с нуля кросплатформенное приложение, читающее сенсоры с разных мат.плат. везде свои стандарты, где-то подключено к чипсету напрямую, где-то к SIO, да и везде свои SIO и чипсеты, где-то данные идут по 8бит, где-то по 16, короче, в линуксе одни методы доступа к аппаратуре, в винде другие, короче, заёб полный с этой стандартизацией, чтобы потом не росло как больное дерево.
Надо сначала продумывать и детально и где-то записывать. Чтоб потом следовали четко документации, а не так: "слушай я тут хуйню придумал, давай её заимплементим, потом доделаем и будем её тоже поддерживать", вот именно на этой стадии проект "размазывается" и начинается возня в болоте.
О, тред живой, охуенно. Читаю сейчас книгу с оп-пика в бумаге.
А также купил на рефакторинг.гуру за полторашку весь камтент, копейки же.
А также купил на рефакторинг.гуру за полторашку весь камтент, копейки же.
13 Кб, 336x189>>988720
Архитекторов нет, это сверхлюди, которые были до нас. Это великие умы на которых держится Вселенная. Мы только приходим\уходим, чиним\добавляем баги на фундамент залеженный богами.
Архитекторов нет, это сверхлюди, которые были до нас. Это великие умы на которых держится Вселенная. Мы только приходим\уходим, чиним\добавляем баги на фундамент залеженный богами.
>>994311
Слышал что-то про ленивые вычисления, питушок? Все факториалы объявлены вычисленными наперёд.
Слышал что-то про ленивые вычисления, питушок? Все факториалы объявлены вычисленными наперёд.
>>609958
значит ничего сложного не писал
значит ничего сложного не писал
>>653252
сейчас есть техлиды, входящие в отделы архитектуры, сам такой
Задачи отдела архитектуры - разбивка и оценка проекта на этапе pre sale, архитектура и выбор основного стека, запуск проекта, передача постоянному техлиду, поддержка техлида на время существования проекта. Как правило дают пол процета-процент доли прибыли проекта.
сейчас есть техлиды, входящие в отделы архитектуры, сам такой
Задачи отдела архитектуры - разбивка и оценка проекта на этапе pre sale, архитектура и выбор основного стека, запуск проекта, передача постоянному техлиду, поддержка техлида на время существования проекта. Как правило дают пол процета-процент доли прибыли проекта.
198 Кб, 2094x1390>>602051 (OP)
>>656154
из UML самая полезная - sequence diagram, разбираешься ли ты в существующей системе или встраиваешь что-то новое
"изучать UML" тебе нахуй не всралось, идешь да рисуешь её на примере. В пикрелейтед OAuth, глянул на диаграму, сразу понятно что к чему.
Диаграму классов рисуют гораздо реже, в основном если заказчик в документации требует.
>>656154
из UML самая полезная - sequence diagram, разбираешься ли ты в существующей системе или встраиваешь что-то новое
"изучать UML" тебе нахуй не всралось, идешь да рисуешь её на примере. В пикрелейтед OAuth, глянул на диаграму, сразу понятно что к чему.
Диаграму классов рисуют гораздо реже, в основном если заказчик в документации требует.
Тред утонул или удален.
Это копия, сохраненная 1 июня 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 1 июня 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.