Началось все с
Деструкторы — плохо, используйте явное освобождение ресурсов
Конструкторы — плохо, используйте фабрики, прячьте конструкторы в private
Множественное наследование — плохо
Наследование — всегда плохо, используйте агрегацию и интерфейсы
Интерфейсы со множеством вызовов — плохо, используйте интерфейсы с одним
* сюрприз, почти такие интерфейсы в Си с самого начала, при определении любой функции она приводится к указателю с типизированными параметрами прямо из коробки, только к этому "интерфейсу" еще this в качестве параметра надо добавить — вот уже почти современное ООП. Но инкапсуляция будет нарушена.
А инкапсуляция тоже не всегда хорошо. Когда тесты на какой то участок кода пишутся, нужно состояние окружения подменять на входе, а на выходе тестировать что оно изменилось в нужное. Т.е. и состояние тестируемого объекта и состояния объектов с которыми он взаимодействуют нужно устанавливать независимо от штатных методов объектов — жесткое нарушение инкапсуляции, и потом лезть во внутрь объекта за состоянием — тоже жестко нарушая инкапсуляцию. Состояние это вообщем-то все поля объекта.
Инкапсуляция — плохо для ТДД
* то что состояние this в Си-шных реализациях ООП легко отделимо от методов это то что надо для тестов
PS.
Итого, если код в более менее хорошей архитектуре, покрыт тестами, компилируется быстро и быстро работает — это по-прежнему код на СИ.
Когда ваш компилятор подвиснет в очередной раз на пару минут, задумайтесь над этим
"Будет никак" — это значит, что вы надеятесь, что с этой темой (которая по ссылке) ничего не будет. Если вы надеятесь, что с вашей темой будет по-другому, чем с темой по ссылке, это пишется "будет не как". Через "е" и раздельно.
Что до самой темы по ссылке, то она, на мой взгляд, недостаточно раскрыта.
C>Итого, если код в более менее хорошей архитектуре, покрыт тестами, компилируется быстро и быстро работает — это по-прежнему код на СИ. C>Когда ваш компилятор подвиснет в очередной раз на пару минут, задумайтесь над этим
По-разному бывает. Бывает даже так, что код нифига не покрыт тестами, а все равно, работает, собака.
У вас топик для потрындеть Философии ПО, как мне кажется.
Сферический ООП в вакууме никакого прикладного применения не имеет (статьи и конференции за полезный выхлоп не считаем), т.е. в этом разделе точно оффтопик.
Если уточнить вопрос до конкретного языка / фреймворка, то внезапно окажется, что в каждом конкретном случае все актуальные грабли уже давно известны и обойдены.
Начните с конкретных примеров, или голосуйте за снести в философию — присоединюсь.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Current, Вы писали:
C>>Надеюсь, будет никак с этой темой: C>>http://rsdn.ru/forum/trash/6091539.1
Pzz>"Будет никак" — это значит, что вы надеятесь, что с этой темой (которая по ссылке) ничего не будет. Если вы надеятесь, что с вашей темой будет по-другому, чем с темой по ссылке, это пишется "будет не как". Через "е" и раздельно.
а как же устойчивые "никак с этим не связан" и "никак не похоже на"
S>У вас топик для потрындеть Философии ПО, как мне кажется.
S>Сферический ООП в вакууме никакого прикладного применения не имеет (статьи и конференции за полезный выхлоп не считаем), т.е. в этом разделе точно оффтопик.
А также сферический DDD, TDD, BDD и другие модные слова? Не согласен.
Все таки в них обсуждаются общие принципы построения кода, по крайней мере для императивных языков. А это и есть архитектура.
S>Если уточнить вопрос до конкретного языка / фреймворка, то внезапно окажется, что в каждом конкретном случае все актуальные грабли уже давно известны и обойдены.
Тогда тема будет перенесена в обсуждение этого фреймворка и его граблей.
Здравствуйте, Current, Вы писали:
>>Сферический ООП в вакууме никакого прикладного применения не имеет (статьи и конференции за полезный выхлоп не считаем), т.е. в этом разделе точно оффтопик. C>А также сферический DDD, TDD, BDD и другие модные слова? Не согласен.
Ну, это ваши проблемы.
DDD хорош в своей теоретической части, которая про анализ требований и построение биз-архитектуры. Вторую половину — про натягивание кода на паттерны — всерьёз воспринимать невозможно.
TDD/BDD без соответствующей инструментальной обвязки вообще годятся только для буллшит-бинго. Но это снова оффтоп.
C>Все таки в них обсуждаются общие принципы построения кода, по крайней мере для императивных языков. А это и есть архитектура.
1. Нет никаких общих принципов в прикладной разработке. Точнее они есть, но пользы от них — только чтоб свою терминологию для каждого языка не изобретать.
2. Общие принципы и архитектура ПО — ортогональные понятия.
Блин, да даже банальный if в отдельных языках вынуждает городить костыли, что уж про более сложные вещи говорить?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Current, Вы писали:
>>>Сферический ООП в вакууме никакого прикладного применения не имеет (статьи и конференции за полезный выхлоп не считаем), т.е. в этом разделе точно оффтопик. C>>А также сферический DDD, TDD, BDD и другие модные слова? Не согласен. S>Ну, это ваши проблемы.
Ваши.
S>DDD хорош в своей теоретической части, которая про анализ требований и построение биз-архитектуры. Вторую половину — про натягивание кода на паттерны — всерьёз воспринимать невозможно. S>TDD/BDD без соответствующей инструментальной обвязки вообще годятся только для буллшит-бинго. Но это снова оффтоп.
C>>Все таки в них обсуждаются общие принципы построения кода, по крайней мере для императивных языков. А это и есть архитектура. S>1. Нет никаких общих принципов в прикладной разработке. Точнее они есть, но пользы от них — только чтоб свою терминологию для каждого языка не изобретать.
Может вам нечего тогда делать в форуме Архитектура ПО?
Здравствуйте, Current, Вы писали:
C>Деструкторы — плохо
деструкторы это и хорошо и плохо
C>Конструкторы — плохо
конструкторы это и хорошо и плохо
C>Множественное наследование — плохо
множественное наследование это и хорошо и плохо
C>Наследование — всегда плохо
наследование и хорошо и плохо
C>Интерфейсы со множеством вызовов — плохо
интерфейсы со множеством вызовов это и хорошо и плохо
разработка ПО это инженерия, т.е. поиск технического компромисса между противоричивыми требованиями/инструментами/решениями в определённом контексте. Так как каждый проект в той или иной степени уникален, то универсального "это хорошо" а "вот это плохо", существующего для всех типов проектов нет и быть не может. Единственное что может быть общим — это наличие здравого смысла и обоснованность принятия решений.
Здравствуйте, Current, Вы писали:
C>Надеюсь, будет никак с этой темой:
У тебя не критика ООП, у тебя критика конкретного способа его готовить.
Я, кстати, с таким способом приготовления на практике не встречался, так что подозреваю, что это синтетический конструкт чисто для дискуссии.
Здравствуйте, Current, Вы писали:
S>>1. Нет никаких общих принципов в прикладной разработке. Точнее они есть, но пользы от них — только чтоб свою терминологию для каждого языка не изобретать. C>Может вам нечего тогда делать в форуме Архитектура ПО?
Мягко говоря, странный вывод
S>>>1. Нет никаких общих принципов в прикладной разработке. Точнее они есть, но пользы от них — только чтоб свою терминологию для каждого языка не изобретать. C>>Может вам нечего тогда делать в форуме Архитектура ПО? 0>Мягко говоря, странный вывод
Ну да, он даже завсегдатый. И широкая публика тут того же мнения.
Читали "страна слепых"? Вот про форум Архитектура ПО у меня сейчас тоже мнение.
Архитектура ПО к языку это как более высокий уровень сетевой модели над более низким.
Низкий может чего-то неподдержать, но большинстиво языков поддерживает большинство архитектур.
Программы переписываются с java <-> c++ <-> c <-> perl <-> php <-> и т.д. без смены архитектуры
Не касательно вопроса зачем, просто сам факт программы можно переписывать на другой язык сохраняя не только функциональность, но и внутреннюю структуру.
Это примерно как IP все равно, будет ли внизу Ethernet, PPP или IEEE 802.11n.
Не настолько гладко, но все равно намного ближе к правде, чем та демагогия про нет "пользы от общих принципов" которую тут развели.
A>разработка ПО это инженерия, т.е. поиск технического компромисса между противоричивыми требованиями/инструментами/решениями в определённом контексте. Так как каждый проект в той или иной степени уникален, то универсального "это хорошо" а "вот это плохо", существующего для всех типов проектов нет и быть не может. Единственное что может быть общим — это наличие здравого смысла и обоснованность принятия решений.
У разрабочика цель довольно конкретная — отразить логику в коде. Если контекст требований про который ты говоришь задается прикладной областью, то я не очень понимаю где дилема — если делать сервер кафе мороженного то множественное наследование хорошо, а в gui булочной публичные конструкторы это здорово?
Если контекст в тех.окружении то, да бывает, но и там на 10 исключений 100500 общих принципов.
Здравствуйте, Current, Вы писали:
C>Здравствуйте, Pzz, Вы писали:
Pzz>>Здравствуйте, Current, Вы писали:
C>>>Надеюсь, будет никак с этой темой: C>>>http://rsdn.ru/forum/trash/6091539.1
Pzz>>"Будет никак" — это значит, что вы надеятесь, что с этой темой (которая по ссылке) ничего не будет. Если вы надеятесь, что с вашей темой будет по-другому, чем с темой по ссылке, это пишется "будет не как". Через "е" и раздельно.
C>а как же устойчивые "никак с этим не связан" и "никак не похоже на"
C>если "не", то "не так как с этой темой"
Здесь само предложение некорректно составлено. Должно быть примерно так: Надеюсь, будет не так, как с темой (ссылка на тему).
Здравствуйте, Current, Вы писали:
C>Не настолько гладко, но все равно намного ближе к правде, чем та демагогия про нет "пользы от общих принципов" которую тут развели. C>Не видишь пользы? сиди в другом форуме
Я вижу пользу от процесса разработки и реализации архитектуры для некоторых проектов, но не вижу, как твои рассуждения об "общих принципах" с этим связаны, и как они могут быть полезны. И в этом я вижу большую проблему у многих архитекторов, с которыми мне приходилось иметь дело — они очень много рассуждали о принципах, а результатом их работы становился пшик.
0>Я вижу пользу от процесса разработки и реализации архитектуры для некоторых проектов, но не вижу, как твои рассуждения об "общих принципах" с этим связаны, и как они могут быть полезны.
Мои рассуждения в начале топика. По существу мне никто не ответил, поэтому тема безвозвратно скатилась в трепло о жизни.
0>И в этом я вижу большую проблему у многих архитекторов, с которыми мне приходилось иметь дело — они очень много рассуждали о принципах, а результатом их работы становился пшик.
Программисты без архитектора делают код в архитектуре "из г. и палок", которую они на словах ругают,
но если быть честными, ей несказанно рады — вначале подпирают новыми палками, потом чтобы палки не падали, обмазывают хот фиксами
и так по кругу, деньги идут, программисты довольны, а когда им нанимают архитектора,
занимаются саботажем разной степени наглости, пока архитектора не уволят за то, что он "демотивировал" команду
мне это напоминает детский стишок
"ох и трудная это работа из болота тащить бегемота"
на первый взгляд трудно, потому что бегемот тяжелый и болото вязкое
но главная проблема в том, что бегемот живет в болоте, ему там нравится, его там дом родной,
и вылазить он категорически не хочет, а когда восьмитонная свинья не хочет ..., а когда их целый отдел ...
даже если какой-то герой их и вытащит, при первой же возможности сбегут в "г. и палки" обратно
Здравствуйте, Current, Вы писали:
C>Мои рассуждения в начале топика. По существу мне никто не ответил, поэтому тема безвозвратно скатилась в трепло о жизни.
Ты опоздал с подобной темой. Объектная истерия уже прошла, такие топики уже не вызывают большого отклика у аудитории.
C>Программисты без архитектора делают код в архитектуре "из г. и палок", которую они на словах ругают,
К сожалению, с архитектором они тоже часто делают говно. Разница только в том, что в этом случае говно ажурное.
То есть формально всё на месте — модули, интерфейсы, микросервисы всякие, а счастья — нет
C>но если быть честными, ей несказанно рады — вначале подпирают новыми палками, потом чтобы палки не падали, обмазывают хот фиксами C>и так по кругу, деньги идут, программисты довольны, а когда им нанимают архитектора, C>занимаются саботажем разной степени наглости, пока архитектора не уволят за то, что он "демотивировал" команду
Ты о каких-то конкретных программистах говоришь?
C>>Мои рассуждения в начале топика. По существу мне никто не ответил, поэтому тема безвозвратно скатилась в трепло о жизни. 0>Ты опоздал с подобной темой. Объектная истерия уже прошла, такие топики уже не вызывают большого отклика у аудитории.
Ну инкапсуляцию методов и данных, на которую был наезд, используют и хвалят 99.9%
C>>но если быть честными, ей несказанно рады — вначале подпирают новыми палками, потом чтобы палки не падали, обмазывают хот фиксами C>>и так по кругу, деньги идут, программисты довольны, а когда им нанимают архитектора, C>>занимаются саботажем разной степени наглости, пока архитектора не уволят за то, что он "демотивировал" команду 0>Ты о каких-то конкретных программистах говоришь?
Хуже, это сейчас тренд у менеджеров — "не берите в команду архитектора, он может демотивировать ребят".
Что еще хуже, этот совет практичен. Менеджеров "г. и палки" как правило тоже устраивают.
Здравствуйте, Current, Вы писали:
C>Что еще хуже, этот совет практичен. Менеджеров "г. и палки" как правило тоже устраивают.
Нужно понимать, что прямой корреляции между качеством архитектуры и прибыльностью проекта нет.
Более того, часто бывает так, что пока архитектор парит в эмпиреях ака "тут одного рефакторинга на пару человеколет", беспринципный внедренец быстренько втыкает очередную палку, обмазывает очередным г., и разблокирует сделку на $300k.
Я такого навидался. Когда софт проектируется не с нуля, и внезапно появляются задачи типа "а вот давайте добавим в магазин валидацию телефонного номера покупателя на предмет отсутствия задолженности по счетам", то архитектурно-правильные решения типа "оооо, ну давайте добавим ещё один тип плагинов в нашу систему автоматизации бизнеса, реализуем плагин по проверке номера, выставим интерфейсы для магазина, и допилим магазин, чтобы он пользовался этими интерфейсами" тупо вылетают за пределы окупаемости. А решение "давайте вкрячим вызов javascript-залипухи в кастомизацию шаблона отображения странички чекаута" опытный ниндзя может прикрутить прямо на глазах изумлённого заказчика. Это, конечно, потом больно бьёт в майнтенансе, но деньги заказчик платит сейчас, а маинтенанс будет когда-то потом.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Более того, часто бывает так, что пока архитектор парит в эмпиреях ака "тут одного рефакторинга на пару человеколет", беспринципный внедренец быстренько втыкает очередную палку, обмазывает очередным г., и разблокирует сделку на $300k. S>Я такого навидался.
Вот-вот. И архитектора будут вынуждать поддерживать это способ проектирования.
И если согласится, программисты первыми заголосят "с этим архитектором делаем г., только ажурное. Зачем нам архитектор?".
А поскольку менеджеры легко перекладывает ответственность за свои решения, со временем его уволят за демотивацию команды.
За архитектуру редко увольняют, менеджеры в ней не понимают.
В итоге, как опытный сисадмин, архитектор работает с людьми, а не с компьютерами.
По моему опыту, архитектор может работать долго, если
— он bus-фактор номер один, т.е. только он понимает как оно в целом работает, а все остальные только по кускам. и любые попытки передать знание дипломатично пресекаются
— архитектор скорее хороший менедежер — имеет подход к каждому бегемотику, и хороший скил продаж "г. и палок", который они делают
и то и другое не слишком хорошо для бизнеса, но менеджеров устраивает гораздо больше 2-ой вариант
поэтому "не берите на работу архитектора", крайне практичный совет, как это ни печально
не менее печально то, что все зло в программистах-бегемотиках
Здравствуйте, Current, Вы писали:
C>Ну инкапсуляцию методов и данных, на которую был наезд, используют и хвалят 99.9%
Дело не в этом. Просто раньше это было священной коровой и любая критика этих принципов вызывала у публики нездоровую реакцию.
Сейчас уже не так. Используют, конечно, но без религиозного фанатизма.
C>Хуже, это сейчас тренд у менеджеров — "не берите в команду архитектора, он может демотивировать ребят". C>Что еще хуже, этот совет практичен. Менеджеров "г. и палки" как правило тоже устраивают.
Ты про каких-то конкретных менеджеров говоришь?
Озвучь имена, места работы, не стесняйся.
C>>Ну инкапсуляцию методов и данных, на которую был наезд, используют и хвалят 99.9% 0>Дело не в этом. Просто раньше это было священной коровой и любая критика этих принципов вызывала у публики нездоровую реакцию. 0>Сейчас уже не так. Используют, конечно, но без религиозного фанатизма.
А это здоровая реакция?
C>>Хуже, это сейчас тренд у менеджеров — "не берите в команду архитектора, он может демотивировать ребят". C>>Что еще хуже, этот совет практичен. Менеджеров "г. и палки" как правило тоже устраивают. 0>Ты про каких-то конкретных менеджеров говоришь? 0>Озвучь имена, места работы, не стесняйся.
Здравствуйте, Current, Вы писали:
0>>Сейчас уже не так. Используют, конечно, но без религиозного фанатизма. C>А это здоровая реакция?
Что именно?
0>>Озвучь имена, места работы, не стесняйся. C>нет, спасибо. C>various anonymous managers
Ну а varius other managers так не думают
На таком высоком уровне абстракции продуктивного обсуждения не получится.
Здравствуйте, pestis, Вы писали:
0>>Ты про каких-то конкретных менеджеров говоришь? 0>>Озвучь имена, места работы, не стесняйся. P>Незачем даже далеко ходить, тот же Синклерв соседнем посте не против. Имя, должность и место работы у него в профиле
В каком сообщении он говорит, что вредно брать в команду архитекторов?
0>Ну а varius other managers так не думают 0>На таком высоком уровне абстракции продуктивного обсуждения не получится.
ну и хорошо, на всякий случай уточню, что "без архитектора" не в смысле вообще без руководства
есть тикеты, стэндапы, рука-руку моющий код-ревью друг друга, каждый фигачит тикеты в меру своего восприятия
нет "звезды" что видит архитектуру кода так, и так ее должны видеть все
бизнес интересуют доставка фич и рейтинги отказов
в коде "г. и палки"
в таком режиме комманда может работать долго и стабильно
видел как команды с архитектором переходили к этом варианту
успешных переходов от этого варианта к архитектурному не видел
Здравствуйте, Current, Вы писали:
C>В итоге, как опытный сисадмин, архитектор работает с людьми, а не с компьютерами.
Это всегда так было, есть и будет.
Работа архитектора — строить систему в условиях ограничений. И основной скилл — уметь ограничения выявлять. Чаще всего ограничения не в технологиях, а в сроках, бюджетах, людях и их потребностях, и далёких от технологий вещах. Поэтому архитектор всегда больше работает с людьми. Если это нормальный архитектор.
C>По моему опыту, архитектор может работать долго, если C>- он bus-фактор номер один, т.е. только он понимает как оно в целом работает, а все остальные только по кускам. и любые попытки передать знание дипломатично пресекаются C>- архитектор скорее хороший менедежер — имеет подход к каждому бегемотику, и хороший скил продаж "г. и палок", который они делают C>и то и другое не слишком хорошо для бизнеса, но менеджеров устраивает гораздо больше 2-ой вариант
А чем второй вариант плох для бизнеса?
В советское время был институт ГИПов, на каждом крупном проекте был свой Главный Инженер. Он как раз работал по второй модели и это считалось правильным.
C>поэтому "не берите на работу архитектора", крайне практичный совет, как это ни печально
Я бы сказал, что не надо брать архитектора-теоретика.
C>не менее печально то, что все зло в программистах-бегемотиках
Программисты разные бывают. В изобретательство превышает лень и получается overarchitecture, у других лень оказывается сильнее и получается код из говна и палок.
Держать баланс могут не все. А когда целый коллектив, то это отдельная сложная нелинейная работа. А если добавить нетехнические ограничения — вот и работа для архитектора.
G>Работа архитектора — строить систему в условиях ограничений. И основной скилл — уметь ограничения выявлять. Чаще всего ограничения не в технологиях, а в сроках, бюджетах, людях и их потребностях, и далёких от технологий вещах. Поэтому архитектор всегда больше работает с людьми. Если это нормальный архитектор.
В розовой теории это должен делать бизнес-аналитик, а архитектор спец. именно по компьютерам. На практике, это даже почти так и есть — утверждения бюджета, сроков и бизнес требований делается большей частью менеджментом хотя и в диалоге с архитектором.
Но архитектору все равно достанется работа "с людьми" в том смысле что они — ленятся, врут, завидуют, интригуют, своевольничают и т.д. И под это надо строить всю работу.
G>Это всегда так было, есть и будет.
Да, но учился он на компьютерщика.
C>>- он bus-фактор номер один, т.е. только он понимает как оно в целом работает, а все остальные только по кускам. и любые попытки передать знание дипломатично пресекаются C>>- архитектор скорее хороший менеджер — имеет подход к каждому бегемотику, и хороший скил продаж "г. и палок", который они делают C>>и то и другое не слишком хорошо для бизнеса, но менеджеров устраивает гораздо больше 2-ой вариант G>А чем второй вариант плох для бизнеса?
Я извиняюсь, здесь для бизнеса в смысле "общечеловеческой пользы". Которая не всегда коррелирует с интересами владельцев, которые не всегда коррелируют с интересами менеджмента.
В розовой теории "общечеловеческой пользы", архитектор видит на 2 шага вперед, и разжевывает свои знания всем, добиваясь их реализации. Интриговать ему не нужно, потому что окружающие его люди понимают его ценность для коллектива, и без зависти и бунта, трудолюбиво и честно исполняют его предписания.
С точки зрения карьеры идеальный архитектор это звезда, который тоже видит технологии на 2 шага дальше всех, и который заражает и программистов и менеджеров своим энтузиазмом т.е. оба пункта из предыдущего сообщения — 1) только он знает как это работает в целом, 2) ладит с программистами и успешно продает их "г. и палки" менеджменту. Не в идеале достаточно второго.
G>Программисты разные бывают. В изобретательство превышает лень и получается overarchitecture, у других лень оказывается сильнее и получается код из говна и палок. G>Держать баланс могут не все. А когда целый коллектив, то это отдельная сложная нелинейная работа. А если добавить нетехнические ограничения — вот и работа для архитектора.
Да, причем нетехническая часть полностью преобладает. Так что если архитектор забьет на техническую, проблем в горизонте проекта будет минимум.
Работа по технической части это большей частью дело внутренней честности и амбиций перехода на следующий проект.
Причем все это будет скорее мешать в нетехнической части текущего проекта.
G>>Работа архитектора — строить систему в условиях ограничений. И основной скилл — уметь ограничения выявлять. Чаще всего ограничения не в технологиях, а в сроках, бюджетах, людях и их потребностях, и далёких от технологий вещах. Поэтому архитектор всегда больше работает с людьми. Если это нормальный архитектор.
C>В розовой теории это должен делать бизнес-аналитик, а архитектор спец. именно по компьютерам. На практике, это даже почти так и есть — утверждения бюджета, сроков и бизнес требований делается большей частью менеджментом хотя и в диалоге с архитектором.
Бизнес-аналитик не знает технических ограничений и не является экспертом в построении систем.
"Спец по компьютерам" не знает бизнес-ограничений, поэтому скорее спроектирует розового единорога, чем реальную систему.
Не знаю такой теории, которая говорит нам, что не нужно иметь технического лидера в проекте. Из банальной логики вытекает, что надо, и инженерная практика подсказывает то же самое последние 50 лет.
C>Но архитектору все равно достанется работа "с людьми" в том смысле что они — ленятся, врут, завидуют, интригуют, своевольничают и т.д. И под это надо строить всю работу. G>>Это всегда так было, есть и будет. C>Да, но учился он на компьютерщика.
Поэтому нормальный архитектор — редкость. Зачастую "архитектором" называют самого крутого техспеца, который решений никаких не принимает.
C>>>- он bus-фактор номер один, т.е. только он понимает как оно в целом работает, а все остальные только по кускам. и любые попытки передать знание дипломатично пресекаются C>>>- архитектор скорее хороший менеджер — имеет подход к каждому бегемотику, и хороший скил продаж "г. и палок", который они делают C>>>и то и другое не слишком хорошо для бизнеса, но менеджеров устраивает гораздо больше 2-ой вариант G>>А чем второй вариант плох для бизнеса?
C>Я извиняюсь, здесь для бизнеса в смысле "общечеловеческой пользы". Которая не всегда коррелирует с интересами владельцев, которые не всегда коррелируют с интересами менеджмента.
А чем он плох для "общечеловеческой пользы"?
C>В розовой теории "общечеловеческой пользы", архитектор видит на 2 шага вперед, и разжевывает свои знания всем, добиваясь их реализации. Интриговать ему не нужно, потому что окружающие его люди понимают его ценность для коллектива, и без зависти и бунта, трудолюбиво и честно исполняют его предписания.
То есть второй вариант плох, потому что люди несовершенны? Тогда любой вариант плох.
G>>Программисты разные бывают. В изобретательство превышает лень и получается overarchitecture, у других лень оказывается сильнее и получается код из говна и палок. G>>Держать баланс могут не все. А когда целый коллектив, то это отдельная сложная нелинейная работа. А если добавить нетехнические ограничения — вот и работа для архитектора. C>Да, причем нетехническая часть полностью преобладает. Так что если архитектор забьет на техническую, проблем в горизонте проекта будет минимум.
Если считать технической частью написание кода, то у архитектора она должна быть сведена к минимуму. Не к нулю только для того, чтобы навык не терять.
Здравствуйте, Current, Вы писали:
C>есть тикеты, стэндапы, рука-руку моющий код-ревью друг друга, каждый фигачит тикеты в меру своего восприятия C>нет "звезды" что видит архитектуру кода так, и так ее должны видеть все C>бизнес интересуют доставка фич и рейтинги отказов C>в коде "г. и палки" C>в таком режиме комманда может работать долго и стабильно
Я из чисто идеалистических побуждений, конечно, негодую, но если бизнес доволен результатами проекта, то, может быть, оно и ничего?
G>Бизнес-аналитик не знает технических ограничений и не является экспертом в построении систем. G>"Спец по компьютерам" не знает бизнес-ограничений, поэтому скорее спроектирует розового единорога, чем реальную систему.
да есть такой диалог, но там точность один-два порядка
причем, и уточнение ТЗ, и деление задач и оценки дней можно перекладывать на коллектив — точность не сильно пострадает
G>Не знаю такой теории, которая говорит нам, что не нужно иметь технического лидера в проекте. Из банальной логики вытекает, что надо, и инженерная практика подсказывает то же самое последние 50 лет.
инженерная практика 50 лет и больше — как я ее прочитал, говорит о том что архитектор/главный инженер должен быть примерно второй человек в технологической компании, причем первый это где-то главный акционер
быдло-менедждменнту такие жертвы власти не особо нужны, поэтому у них будет позиция как-бы архитектора с сильно ограниченными правами, который соотвественно закономерно будет слит коллективом. С развитием наглости менеджмента, можно вообще от этой позиции потенциального правдоруба трабл-мейкера отказаться, что и происходит
C>>>>- архитектор скорее хороший менеджер — имеет подход к каждому бегемотику, и хороший скил продаж "г. и палок", который они делают
G>А чем он плох для "общечеловеческой пользы"?
Код который работает отвратно, но успешно втюхан. И стадо бегемотов дружно подпевающее, что лучше кода в этих условиях написать было невозможно.
G>То есть второй вариант плох, потому что люди несовершенны? Тогда любой вариант плох.
Тем что, архитектор по должности должен нести заботу за тех. реализацию, а в этом варианте не берет ее на себя — нафиг нужно, а предпочитает втюхать "г. и палки" под аплодисменты команды.
G>>Не знаю такой теории, которая говорит нам, что не нужно иметь технического лидера в проекте. Из банальной логики вытекает, что надо, и инженерная практика подсказывает то же самое последние 50 лет. C>инженерная практика 50 лет и больше — как я ее прочитал, говорит о том что архитектор/главный инженер должен быть примерно второй человек в технологической компании, причем первый это где-то главный акционер
Кому должен? ГИПы в союзе вообще имели низкие административные должности, но это работало.
C>быдло-менедждменнту такие жертвы власти не особо нужны, поэтому у них будет позиция как-бы архитектора с сильно ограниченными правами, который соотвественно закономерно будет слит коллективом. С развитием наглости менеджмента, можно вообще от этой позиции потенциального правдоруба трабл-мейкера отказаться, что и происходит
В таких случаях проблема не в архитектуре, а в амбициях. В архитектуре скорее всего все в порядке, но амбиции писателя не удовлетворены.
C>>>>>- архитектор скорее хороший менеджер — имеет подход к каждому бегемотику, и хороший скил продаж "г. и палок", который они делают G>>А чем он плох для "общечеловеческой пользы"? C>Код который работает отвратно, но успешно втюхан. И стадо бегемотов дружно подпевающее, что лучше кода в этих условиях написать было невозможно.
И? Чем это плохо?
G>>То есть второй вариант плох, потому что люди несовершенны? Тогда любой вариант плох. C>Тем что, архитектор по должности должен нести заботу за тех. реализацию, а в этом варианте не берет ее на себя — нафиг нужно, а предпочитает втюхать "г. и палки" под аплодисменты команды.
Во-первых архитектор и будет формально нести ответственность. Хотя формальная ответственность ничего не означает, но по факту спрашивать будут с архитектора.
Во-вторых мы еще не выяснили в чем это плохо. Если код решает проблемы, то этого уже достаточно, а если еще и попадает в бизнес-ограничения, то это вообще идеальный код. Если архитектор смог продавать эти ограничения и обозначить проблемы, то он сделал все хорошо. Нет?
В-третьих если команда лучше не может, то это объективное ограничение. В таком случае надо его учитывать при проектировании, что нормальный архитектор и сделает (см во-вторых).
А если команда может, то нормальный архитектор запинает всех кого надо, ибо все равно спрашивать будут с архитектора (см во-первых).
G>Кому должен? ГИПы в союзе вообще имели низкие административные должности, но это работало.
Про ГИПы не знаю. Но вот Дмитрий Федорович Устинов был примерно 2-ой человек в СССР что касалось ВПК и связанных с ним отраслей. Причем 2-ой после главы государства.
из интернета, вторая ссылка по ГИП
Объясните мне пожалуйста, кто такой главный инженер проекта?...
— Это козел отпущения, которому платят бабки и мерещится решетка.
G>А если команда может, то нормальный архитектор запинает всех кого надо, ибо все равно спрашивать будут с архитектора (см во-первых).
Чем он их запинает?
У него нет полномочий. Архитектор может уволить программистов без консультаций? А менеджера проекта?
Здравствуйте, Current, Вы писали:
G>>Кому должен? ГИПы в союзе вообще имели низкие административные должности, но это работало.
C>Про ГИПы не знаю. Но вот Дмитрий Федорович Устинов был примерно 2-ой человек в СССР что касалось ВПК и связанных с ним отраслей. Причем 2-ой после главы государства.
C>из интернета, вторая ссылка по ГИП C>Объясните мне пожалуйста, кто такой главный инженер проекта?... C>- Это козел отпущения, которому платят бабки и мерещится решетка.
Да, есть такая фигня, что в союзе ГИПы несли очень большую ответственность.
G>>А если команда может, то нормальный архитектор запинает всех кого надо, ибо все равно спрашивать будут с архитектора (см во-первых). C>Чем он их запинает? C>У него нет полномочий. Архитектор может уволить программистов без консультаций? А менеджера проекта?
А вот тут интересный вопрос.
Инженеры обычно очень внутренне мотивированные люди. Им не нужна морковка, чтобы эффективно работать. Но их постоянно надо корректировать, чтобы они делали что нужно.
И вот корректировка — по сути убеждение каждого сотрудника, и этим нужно заниматься постоянно.
Если же просто не хотят работать, то сливать менеджеру, пусть разбирается.
Здравствуйте, Current, Вы писали:
C>...
C>Началось все с C>Деструкторы — плохо, используйте явное освобождение ресурсов C>Конструкторы — плохо, используйте фабрики, прячьте конструкторы в private C>Множественное наследование — плохо C>Наследование — всегда плохо, используйте агрегацию и интерфейсы C>Интерфейсы со множеством вызовов — плохо, используйте интерфейсы с одним
C>...
Началось все с того, что Алан Кей ничего не говорил про деструкторы, конструкторы, наследование (тем более про множественное) и интерфейсы.
Основным в его идее были "сообщения". Даже не объект. Эти сообщения можно группировать (похоже на инкапсуляцию и интерфейсы). Как-то навернуть на эти сообщения мат.теорию, вроде всяких алгебр. Чем то напоминает теорию категорий с его стрелками.
И как всегда псевдо-парадигма-архитекторы взяли самое незначительное в идее и развили до того что сейчас есть.
Здравствуйте, Current, Вы писали:
C>... — плохо ... C>... — плохо ... C>... — плохо ...
"Хорошо" и "плохо" — это слова-маркеры оценочных суждений, к которым, как известно, понятие "истинность" неприменимо.
Впрочем, это не столь важно. Важно, что такая на первый взгляд стройная и естественная технология, как ООП, почему-то иногда бывает полезна, а иногда даёт такую "побочку", что хоть вешайся.
Мне кажется, косяк в самой основе. В глубинном принципе, который для ООП можно сформулировать примерно так: "Если реальный мир состоит из объектов, то если и наши программы будут состоять из объектов, то моделировать ими реальный мир будет надёжнее, естественнее и результативнее".
В таком (и всех подобных ему) рассуждении есть сразу два косяка:
1. Реальный мир ни из каких объектов не состоит. Он, гад такой, вообще хрен знает из чего сам по себе состоит. Мировая теоретико-физическая мысль корчится в конвульсиях, пытаясь представить себе реальность в виде струн, стремящихся минимизировать покрываемую ими по десятимерному пространству-времени площадь, но всё глубже и глубже запутывается в измышлятине и поправочных коэффициентах. О каком стопудово объективном существовании таких вещей, как камни, деревья, люди и т.п. можно говорить в таких непотребных обстоятельствах? Любое разбиение реального мира на объекты (любое!!!) — результат волюнтаризма субъекта и особенностей тех обстоятельств, в которые в данный конкретный момент его, субъекта, занесло. Чуть изменились обстоятельства, и всё, капец. У нас уже на том же материале уже другие объекты. Будем в тысяче первый раз перетряхивать объектную модель нашей ООПшной проги. Или лепить очередную систему костылей, которая нам позволит классом "Собака" описывать не только собак и кошек (это было костылём в прошлый раз), но и аквариумных рыбок.
2. "Моделирование" — зачётная тема, но её ценность слегка (на самом деле не слегка, а очень сильно) преувеличена. Можно всю жизнь протрудиться программером и накодить гигабайты кода, но ни разу не написать ничего, что можно было бы назвать моделью чего-то. Веб-сервер не моделирует выдачу веб-страниц клиентам, а выдаёт их. Браузер не моделирует прорисовку страниц, а прорисовывает их. Даже позорный сумматор не моделирует суммирование, а делает его. И кошка не моделирует охоту на мышку. Автомобиль не моделирует перевозку пассажиров и грузов. И мы сами пишем комменты в кывт, а не моделируем это самое написание. Моделирование — узкая нишевая задача, почти совсем не встречающаяся в реальной промышленной практике. Ну и какого хрена мы должны решающим преимуществом инструмента считать его способность решать те задачи, решение которых нам заведомо не нужно? (В скобках замечу, что даже для моделирования ООП подходит не для всякого, а только для имитации взаимодействия небольших количеств дискретных сущностей)
Как-то так получается, что реально вкусными и повсеместно полезными у нас оказываются чисто служебные классы. Такие, как String, Array, HashTable и т.п. А все многочисленные ООА и ООД оказываются весьма опасным с точки зрения проектных рисков ментальным мусором.
Здравствуйте, Miroff, Вы писали:
M>Еще один прозрел. Все умные люди давно перелезли с C++ на связку C + python/java/ruby/whatever.
А самые продвинутые пошли дальше, и используют ассемблер + ОК, гугл.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Voblin, Вы писали:
V>2. "Моделирование" — зачётная тема, но её ценность слегка (на самом деле не слегка, а очень сильно) преувеличена. Можно всю жизнь протрудиться программером и накодить гигабайты кода, но ни разу не написать ничего, что можно было бы назвать моделью чего-то. Веб-сервер не моделирует выдачу веб-страниц клиентам, а выдаёт их. Браузер не моделирует прорисовку страниц, а прорисовывает их. Даже позорный сумматор не моделирует суммирование, а делает его. И кошка не моделирует охоту на мышку. Автомобиль не моделирует перевозку пассажиров и грузов. И мы сами пишем комменты в кывт, а не моделируем это самое написание. Моделирование — узкая нишевая задача, почти совсем не встречающаяся в реальной промышленной практике. Ну и какого хрена мы должны решающим преимуществом инструмента считать его способность решать те задачи, решение которых нам заведомо не нужно? (В скобках замечу, что даже для моделирования ООП подходит не для всякого, а только для имитации взаимодействия небольших количеств дискретных сущностей)
Как я уже неоднократно говорил, всё это "моделирование" существует исключительно в хреновых учебниках ООП.
В реальном программировании, где применяется реальное ООП, моделирование совсем другое.
Например, когда мы пишем программу, которая рисует геометрические фигуры, то мы в качестве основной сущности выделяем "рисователя", а вовсе не "фигуру". Потому что у фигуры поведения нет, а у "рисователя" — есть.
Это как раз и есть то, что вы называете "не моделировать, а делать".
Я это называю "модель решения, а не задачи". То есть если нам ставят задачу "напишите программу по расчёту параметров запуска баллистической ракеты", то даже при выборе ООП для реализации у нас не будет классов вроде Missile, Target, и интерфейсов типа ILauncheable.
Очень хорошо про это написано у Липперта в его серии про RPG: несмотря на наличие в игре таких сущностей, как Wizard, Warrior, Staff, Sword, и прочего, моделировать их поведение при помощи ООП лишено смысла. То есть одноимённых классов — не будет. Зато будет иерархия классов-наследников GameRule, которые описывают все вот эти ограничения типа "сила вампира снижается на 98% днём" или "Wizard не может использовать колюще-режущее оружие".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S> [...] несмотря на наличие в игре таких сущностей, как Wizard, Warrior, Staff, Sword, и прочего, моделировать их поведение при помощи ООП лишено смысла. [...] Зато будет иерархия классов-наследников GameRule, [...]
Вооот. Это уже здравая мысль. Моделировать не предметную область, а структуру задач, которые нужно выполнить программе.
Ещё выкинуть иерархию классов-наследников GameRule (не факт, что правила вписываются в иерархическую структуру), и заменить её композицией объектов, реализующих нужные аспекты правил игры. Потом рассмотреть возможность замены объектов с мутабельным состоянием на функции, преобразующие неизменяемые данные (сильно упрощается распараллеливание). И получится нормальное ООП (или уже не ООП?).
Здравствуйте, red75, Вы писали:
R>Ещё выкинуть иерархию классов-наследников GameRule (не факт, что правила вписываются в иерархическую структуру), и заменить её композицией объектов, реализующих нужные аспекты правил игры. Потом рассмотреть возможность замены объектов с мутабельным состоянием на функции, преобразующие неизменяемые данные (сильно упрощается распараллеливание). И получится нормальное ООП (или уже не ООП?).
Ну, вообще говоря да — правила обычно штука статическая. Т.е. у них есть поведение, но нет никакого "состояния", поэтому ООП для их моделирования не шибко подойдёт.
Если вдруг будет состояние — то вполне сработает объектная иерархия. Наследоваться от правила придётся редко, чаще будет применяться композиция. Тем не менее, это вполне себе нормальное ООП — ничуть не хуже иерархий наследования в 10 уровней глубиной.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Как я уже неоднократно говорил, всё это "моделирование" существует исключительно в хреновых учебниках ООП.
К сожалению, не только в хреновых учебниках, но и в реальной повсеместной практике проектирования больших систем. Например, в автоматизации бизнеса.
Если в предметной области присутствуют такие сущности, как "поставщики", "покупатели", "товары", "сотрудники", "объекты основных средств" и т.п., то если при создании системы используются ОО-технологии, то к бабке не ходи, в системе они будут отражены классами. Выстроенными в иерархию. А как? И чем точнее объектная модель системы будет соответствовать реальному бизнес-ландшафту, тем, считается, оно и лучше. Неизменно получается ужас. А переключить понимание системы с "моделирующего" и "отражательного" подхода на что-нибудь менее чреватое риском провала проекта — ох, как не просто.
И иерархии... Ну, это отдельный предмет моей горячей "любви". Если вкратце, то всё это деревостроение основывается на том, что у нас, человеков, есть два прекрасных взаимодополняющих друг друга инструмента познания действительности: анализ и синтез. Они же дедукция и индукция. Они же декомпозиция и обобщение. Поскольку мы по природе своей профессионалы этого дела (есть подозрение, что это как раз базовые операции, выполняемые одиночными нейронами), каждая одиночная декомпозиция и каждое одиночное обобщение обычно бывают фантастически успешными. То есть сразу дают ощутимую практическую пользу. Окрылённые успехом, мы пытаемся достичь большего, продолжая в том же духе. То есть дальше декомпозировать успешно декомпозированное или дальше обобщать обобщённое. Но тут нас неизменно поджидает жёсткий облом. Получается дерьмо. Причина в том, что на следующем уровне мы не можем применить тот же декомпозирующий критерий (в другом варианте — обобщающий принцип), что и на предыдущем шаге. Критерий (принцип) уже себя полностью исчерпал на предыдущем шаге, и повторно не может быть применён. Приходится для продолжения процесса использовать что-то другое. В итоге получается так, что результат уже двух шагов становится смешением двух различных принципов, притом второй оказывается волюнтаристски "подчинён" первому. На вопрос "почему не наоборот?" приходится закатывать глаза, шумно выдыхать и произносить какую-нибудь бессмыслицу типа "мне кажется, так правильнее".
А если количество уровней больше двух... ну, ты понимаешь
Чисто поржать вот путь к одному элементу одного общероссийского классификатора:
.ПРОДУКЦИЯ СЕЛЬСКОГО, ЛЕСНОГО И РЫБНОГО ХОЗЯЙСТВА
..Продукция и услуги сельского хозяйства и охоты
...Культуры однолетние
....Культуры зерновые (кроме риса), зернобобовые, семена масличных культур
.....Пшеница
......Пшеница твердая
.......Пшеница озимая твердая
........Зерно озимой твердой пшеницы
Выглядит логично ровно до тех пор, пока не возник вопрос "А что там у нас по зерну? По всякому?". Вот тут-то и оказывается, что зёрна ржи лежат и близко не рядом с зёрнами пшеницы. А булочка "7 злаков" — это вообще какой-то классификационный трындец
Я не знаю ни одной иерархии, которая была бы естественной. Даже дерево (обычное деревянное дерево) и то не совсем древовидно. О том, что дерево по-настоящему древовидно, может говорить только тот, кто ни разу не видел корней дерева.
Здравствуйте, Voblin, Вы писали: V>Выглядит логично ровно до тех пор, пока не возник вопрос "А что там у нас по зерну? По всякому?".
Создаётся интерфейс IGrain, всё подходящее зерно его наследует, и всё нормально становится.
