Оver-engineering - "зачем так сложно?"

[ax_mct]

Цитата:

Сообщение от ALES

коллеги, делаем ставки на "увидим ли мы "сценарии работы от MS" или и так всем все понятно?

Не сценарии от MS нужны,а UAT (User Acceptance Testing) где UAT - канал общения с реальными пользователями в реальных компаниях для хождения по земле.

Вместо этого сейчас носятся с телеметрией из облаков как способом связи с реальным миром.
Клуб анонимных оверлейщиков

"Программистский подход" но на уровне корпорации.

P.S. Хотя может я чего не знаю и связь с реальным бизнесом таки есть.
C другой стороны если бы была эта обратная связь то не радовался бы настолько Dave Froslie возможностям телеметрии.

[macklakov]

Цитата:

Сообщение от ax_mct

P.S. Хотя может я чего не знаю и связь с реальным бизнесом таки есть.
C другой стороны если бы была эта обратная связь то не радовался бы настолько Dave Froslie возможностям телеметрии.

Ну, у тебя восприятие несколько искажено обидой на то, что тебе испортили бизнес. Я твою обиду разделяю. Однако что с этим поделаешь?
Связь с бизнесом у них, судя по всему, таки есть. И стратегия есть не самая худшая. Просто из-за неопытности они не знают на какую информацию можно полагаться, а на какую нет. У них же произошло слияние нескольких продуктов. И на американском рынке доминировала отнюдь не AX, а GP. Получается что партия людей с опытом в более отсталых системах довольно влиятельна. И они пытаются переделывать как им привычнее. Я сам лично слышал нытье на тему:"ну почему в AX не получается делать как GP?" Да и потом, бытует мнение что NAV таки более приятная система чем AX и с их точки зрения доминирование AX это варварство. И как между ними рассудить?
Но, судя по ряду признаков и решениям находящимся в разработке, вместо того чтобы разбираться какая систем лучше, а какая хуже, делается попытка брость всю эту охапку чемоданов с оторванными ручками. Вместо этого делается альтернативная, изначально облачная платформа для модулей, стыкующихся друг с другом. Именно эко-система, а не продукт. Если получится, будет интересно. Рынок сильно поменяется. Но есть надежда что при этом он еще и сильно разрастется, а значит и для нас место найдется
Но вот у AX в этой схеме нет будущего. Поэтому над ней дозволяется издеваться как кому в голову взбредет. CRM это любимое и понятное, родное. CRM очень хорошо в новую модель ложится. А AX это что-то странное, непонятное, что-то такое где партнеры могут диктовать условия. А партнеры зачастую заинтересованы в том, чтобы в продукте было побольше заморочек, тогда у них есть монополия на экспертизу. Поэтому AX раздражает. Ее не жалко. Пусть ребята играются в арихтекторов, руку набивают.

[macklakov]

хотя, кого я обманываю? Если даже флагманский продукт, основа основ, Windows, которой уже 30 лет, к пользователю повернута самым неприглядным местом. Вот только что пытался пароль поменять. Она мне говорит что пароль несоответствует критериям. А что за критерии не говорит. Более того, критериям, он, как выясняется, соответствовал, это что-то в AD перклинило, когда мне пытались к Office365 доступ дать. Нет, админы криворукие, конечно, но это не операционка, а гребаный стыд. Unit tests, автоматизированное тестирование... А в Excel, банальном Excel, глючит буффер обмена!
При этом сайт какого нибудь стартапа, запиленный на коленке студентом, детально объясняет что он от меня хочет. Уже лет 10-15 как. А великая и могучая винда не соизволит опуститься до такой банальности. Эта контора это филиал ада на земле, ставящая своей целью причинить пользователям, клиентам, специалистам и даже своим сотрудникам, максимальные страдания. Ни с чем не сравнимый experience.
Если хватает смелости уйти в PHP, беги! Беги и не оглядывайся. Здесь ад.

[belugin]

Цитата:

Сообщение от mazzy

Тут у меня такое соображение. По мотивам выступления Макса Белугина.

Может разница в восприятии сложности диктуется namespace'ами?

Кошелек Миллера - чтобы чем-то комфортно оперировать надо иметь это в количестве 7+-2.

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

PHP код:

PS E:\RainMain\Source\AppIL\Metadata\ApplicationSuite> ls -Recurse -Include *.xml |  measure

Count    : 78843 


Это количество объектов в ApplicationSuite чтобы их равномерно разбить на кусочки по 8 надо

[Math]::Log(78843, 8)

5.42223168398599 уровня. НАД уже существующими объектами приложения.

Но существующие объекты тоже достаточно жирные. Если посчитать строчки кода, то:

PS E:\RainMain\Source\AppIL\Metadata\ApplicationSuite> ls -Recurse -Include *.xml | %{ (gc $_.FullName).Length }|  measure -sum | % sum
24284376

PS E:\RainMain\Source\AppIL\Metadata\ApplicationSuite> [Math]::Log(24284376, 8)
8.17784169341017

Цитата:

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

Это называется Single Responsibility Principle

Цитата:

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

В традиционной аксапте можно использовать префиксы для того, чтобы отделять модули. В 2012 появились модели, в 7 появились модули.

То есть у нас есть объекты приложения, модели, модули, причем отличить внутренне от внешнего можно только на уровне объектов приложения (да и то не всех). У модулей есть ключевое слово internal, но оно не работало для нас, например год назад полностью - не поддерживалось в VS и не было InternalsVisibleTo (что надо для юниттестов).

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

То есть нужно ~9 уровней а есть пять, причем, последние два воявились в 2012 и 7 и внутренности нельзя спрятать выше уровня класса.

На уровне модуля хотя бы контроллируются зависимости и их нецикличность.

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

[mazzy]

Цитата:

Сообщение от belugin

Кошелек Миллера - чтобы чем-то комфортно оперировать надо иметь это в количестве 7+-2.

угу-угу. и я в эту сторону говорю.

Цитата:

Сообщение от belugin

Это количество объектов в ApplicationSuite чтобы их равномерно разбить на кусочки по 8 надо

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

как только появляется слово "все" - жди логической ошибки.

Цитата:

Сообщение от belugin

Если посчитать строчки кода, то:

жжошь!

Цитата:

Сообщение от belugin

Это называется Single Responsibility Principle

спасибо )
SOLID - не священная книга.
Эти принципы имеют свои области применения и имеют случаи, когда их не рекомендуется применять.

Кроме того есть паттерн Фасад https://en.wikipedia.org/wiki/Facade_pattern
и много других.

собственно вопрос этой темы: почему один принцип, не слишком свойственный старой аксапте, упорно применяется в последних версиях.

Цитата:

Сообщение от belugin

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

и суффиксы. и соглашения по наименованию объектов.
и вообще много чего было придумано.

Цитата:

Сообщение от belugin

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

Да.
Потому что позиционировалась как "единая система", "единая база", "целостные и всегда актуальные данные".

Цитата:

Сообщение от belugin

То есть нужно ~9 уровней а есть...

Кому нужно, Макс?
Кому? И зачем?
Какие свойства возникнут в системе после того, как эти уровни появятся, а какие свойства пропадут?

Цитата:

Сообщение от belugin

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

Наверное...

[belugin]

Цитата:

Сообщение от mazzy

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

как только появляется слово "все" - жди логической ошибки.

Где я говорил, что кто-то просил разбивать из все. Разумеется никто не читает классы сразу. Я просто привел некоторые цифры про несоразмерность сложности продукта и возможностей, которые дает платформа для его понимания.

Цитата:

жжошь!

Можно развернуто.
У тебя есть какая-то другая метрика для оценки коричества информации в коде?

Цитата:

спасибо )
SOLID - не священная книга.
Эти принципы имеют свои области применения и имеют случаи, когда их не рекомендуется применять.

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

Цитата:

и суффиксы. и соглашения по наименованию объектов.
и вообще много чего было придумано.

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

Цитата:

Потому что позиционировалась как "единая система", "единая база", "целостные и всегда актуальные данные".

При чем тут это?

Цитата:

Кому нужно, Макс?
Кому? И зачем?
Какие свойства возникнут в системе после того, как эти уровни появятся, а какие свойства пропадут?

См рассуждения выше.

[mazzy]

Цитата:

Сообщение от belugin

Где я говорил, что кто-то просил разбивать из все. Разумеется никто не читает классы сразу. Я просто привел некоторые цифры про несоразмерность сложности продукта и возможностей, которые дает платформа для его понимания.

хм... логично.

Цитата:

Сообщение от belugin

Можно развернуто.
У тебя есть какая-то другая метрика для оценки коричества информации в коде?

о... вот ты озадачил. не думал в этом направлении
а зачем такая метрика?

Цитата:

Сообщение от belugin

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

а... ты об этом.
знаю-знаю. но специально стараюсь не использовать терминологию в ВОПРОСАХ.
выбор терминологии отвечающим позволяет многое узнать о его ходе мысли.

вот я спросил про "ездач", а ты ответил одним из принципов в SOLID.
а почему именно SOLID? почему не другие шаблоны и паттерны?

почему спрашиваю? а потому что основным инструментом SOLID является рефакторинг кода. SOLID - это шаблон agile разработки.

но:
1. майерософт выпущенный в релизе Аксапты код не рефакторит по соображениям совместимости. )))
2. с точки зрения не-МС-программистов, набор классов в Аксапте является библиотекой. agile не очень подходит для разработки библиотек )))

==================
и вообще, если человек задает вопросы - это не значит что он не знает ответа.
это значит, что он хочет узнать мнение другого человека.
)

Цитата:

Сообщение от belugin

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

т.е. отсутствие инструментария...
и в самом деле, причем тут это?

[macklakov]

Цитата:

Сообщение от belugin

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

Ну по этому вопросу, как раз, разночтений нет. Не встречал еще человека который считает что сваливать все объекты в одну кучу AOT, да еще и в одно пространство имен, это хорошее решение. Это как раз особенность AX по которой мало кто скучать будет.

[belugin]

Цитата:

Сообщение от mazzy

о... вот ты озадачил. не думал в этом направлении
а зачем такая метрика?

Чтобы оценить потребное количество уровеней кусочков по 8 - см рассуждения выше.

Цитата:

а... ты об этом.
знаю-знаю. но специально стараюсь не использовать терминологию в ВОПРОСАХ.
выбор терминологии отвечающим позволяет многое узнать о его ходе мысли.

вот я спросил про "ездач", а ты ответил одним из принципов в SOLID.
а почему именно SOLID? почему не другие шаблоны и паттерны?

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

Цитата:

почему спрашиваю? а потому что основным инструментом SOLID является рефакторинг кода. SOLID - это шаблон agile разработки.

Мне вот кажется, что это принципы хорошего дизайна.

Цитата:

но:
1. майерософт выпущенный в релизе Аксапты код не рефакторит по соображениям совместимости. )))

Никто не запрещает рефакторить при сохранении публичных интерфейсов. Так как internal не работает, то публичные интерфейсы есть только на уровне классов (то есть нельзя выделить из существующего класса приватный класс, например).

Цитата:

2. с точки зрения не-МС-программистов, набор классов в Аксапте является библиотекой. agile не очень подходит для разработки библиотек )))

Можно про последнее - откуда источник сведений? Библиотека это такой же продукт как и все - если есть требования для категории пользователей "программист", то почему нельзя применять для нее тот же agile?

Цитата:

т.е. отсутствие инструментария...
и в самом деле, причем тут это?

Ты же сам начал про неймспейсы. Неймспейсы поддерживаются инструментарием

[mazzy]

Цитата:

Сообщение от belugin

Чтобы оценить потребное количество уровеней кусочков по 8 - см рассуждения выше.

ясно.

Цитата:

Сообщение от belugin

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

именно.
именно поэтому я сознательно не употреблял термин в вопросе.

Цитата:

Сообщение от belugin

Мне вот кажется, что это принципы хорошего дизайна.

нет, конечно.
во-первых, это только ООП.
во-вторых, это часть agile. И еще вопрос - насколько agile применим в данном случае.

"...которые означали пять основных принципов объектно-ориентированного программирования"
"...Это часть общей стратегии гибкой и адаптивной разработки"
https://ru.wikipedia.org/wiki/SOLID_...BD%D0%B8%D0%B5)

english:
"for five basic principles of object-oriented programming and design"
"It is part of an overall strategy of agile and Adaptive Software Development"
https://en.wikipedia.org/wiki/SOLID_...riented_design)

Цитата:

Сообщение от belugin

Никто не запрещает рефакторить при сохранении публичных интерфейсов.

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

и?
так что же в аксапте можно рефакторить?
в этой ветке обсуждалось семейство FormLetter - его можно?
в этой ветке обсуждался runBase - его можно?

Цитата:

Сообщение от belugin

Можно про последнее - откуда источник сведений? Библиотека это такой же продукт как и все - если есть требования для категории пользователей "программист", то почему нельзя применять для нее тот же agile?

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

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

итак, ты считаешь, что agile подходит и для библиотек.
именно поэтому МС одновременно и закрывает код аксапты, и пропагандирует гибкую разработку.

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

или ссылку, где это обсуждается?

[belugin]

Цитата:

Сообщение от mazzy

во-первых, это только ООП.
так что же в аксапте можно рефакторить?
в этой ветке обсуждалось семейство FormLetter - его можно?
в этой ветке обсуждался runBase - его можно?

Все можно, но не по всякому. Жесткие правила - в выпущенной на рынок версии нельзя делать несовместимые изменения (это проверяется скриптами).

Но если просто гигантские изменения будут, то это то же не приветствуется - требует обоснования (внутри версии).

Цитата:

итак, ты считаешь, что agile подходит и для библиотек.

Да

Цитата:

именно поэтому МС одновременно и закрывает код аксапты,

Не поэтому, я думаю, чтобы легче было обновлять.

Цитата:

и пропагандирует гибкую разработку.

можешь чуть подробнее рассказать, как применять методики гибкого программирования тем, у кого нет доступа к коду? есть ли особенности?

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

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

Цитата:

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

Мне кажется, это скорее к другой теме - про оверлееринг.

[ax_mct]

Цитата:

Сообщение от macklakov

Ну, у тебя восприятие несколько искажено обидой на то, что тебе испортили бизнес.

Цитата:

Сообщение от belugin

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

Проект Green, как обьединение купленных ERP в одну на базе .NET, мной воспринимался как создание компонентов-кирпичиков из которых программисты могут очень эффективно строить бизнес-приложения чтобы удовлетворять потребности бизнеса.

Разница в восприятии не в условиях,а в результатах труда. Мой результат труда - удовлетворить потребности бизнеса клиента. Не код сам по себе, а результат его выполнения. Абстракции и улучшение - для меня это термины бизнес-процессов, не кода. Мне все равно какой код, хоть 2000 строк. Я прикладной программист.

Код АX - это прикладной код. Системному программированию там делать нечего.
Есть kernel, вот и улучшайте сборщик мусора.

Оverengineering возможно потому что салон автомобиля перепутали с двигателем.

[dech]

Цитата:

Сообщение от ax_mct

Разница в восприятии не в условиях,а в результатах труда. Мой результат труда - удовлетворить потребности бизнеса клиента. Не код сам по себе, а результат его выполнения. Абстракции и улучшение - для меня это термины бизнес-процессов, не кода. Мне все равно какой код, хоть 2000 строк. Я прикладной программист.

Вы уж простите за такие слова, но говнокод любой из нас легко напишет (Для меня 2000 строк - уже говнокод). Все мы прикладные программисты. Но изменять функционал и добавлять новый все-таки с умом надо. Требовать хороших удобных инструментов любой может. А вот создавать иерархии наследования, выделять интерфейсы, оптимизировать запросы к БД, ускорять работу форм и отчетов не всякому под силу. Многие не задумываясь дублируют метод, или того хуже класс, набитый под завязку этим самым г*. Меняют 2 строчки и довольны.

Для меня мало закончить задачу. Я всегда стараюсь сделать рефакторинг кода в тех классах, которые правлю. Если предстоит скопировать логику класса под какие-то свои цели, я смотрю как можно обобщить её, чтобы не было тупого дублирования. Возникает иерархия классов, происходит выделение общих методов в родительский класс. Дальше эту структуру становится намного легче использовать, добавляя туда полезный код. Естественно, я не делаю такого со стандартом, больше всего ошибок и проблем возникает с кодом компаний, внедряющих собственные решения. Если делается под заказ, то вся работа происходит в сжатые сроки, тут и автотесты писать некогда и рефакторинг проводить времени нет. Скорость без качества. Все конечно довольны, но радость недолго длится. Некоторые ошибки вылезают только лет через 5-7.

Пример: Решили сделать загрузку данных батчем и раскидать в журналы по разным компаниям. Делали через changeCompany и runAs. А потом клиент удивляется, куда пропадает часть данных? Смотрим, вроде нормально, правильно... закоммитили транзакцию, блок смены компании закрыли. Только дальше в этом же методе идёт (внимание) удаление связанных данных, которое происходит уже в текущей компании. После этого я нахожу еще кучу классов, которые делают то же самое. Продублировали без зазрения совести. И никто не удосужился протестировать. Скопипастили и всё, мы - молодцы!

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

P.S. ax_mct, я заранее извиняюсь, т.к. не знаю насколько вы хороший и компетентный разработчик. Но ваш подход в целом мне не нравится.

[belugin]

Цитата:

Сообщение от ax_mct

Оverengineering возможно потому что салон автомобиля перепутали с двигателем.

Код-это не салон и не двигатель, это чертежи и документы по которым компилятор и установщик строит салон и двигатель.

Соответственно примерно по таким же законам надо работать.

Какой документ лучше, вот такой?

Цитата:

• У лисы длинный хвост.
• У бобра длинный хвост.
• Кенгуру имеет длинный хвост.
• Такой же хвост и у собаки.

Или вот такой:

Цитата:

У этих животных хвосты длинные

• Лиса
• Бобер
• Кенгуру
• Cобака.

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

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

Если нас волнует только кенгуру нам проще найти поиском ее и уточнить какой хвост у него.

Могут быть промежуточные варианты - например нас волнуют все, кроме кенгуру.

Так же и фреймворки - например SysOperation эквивалентен разделу в начале документа, где написано:
- бывают операции
- у операций бывают параметры
- если не сказано обратного, то надо :
- загрузить параметры из SYsLastValue
- спросить параметры согласно типам
- сохранить их в SysLastValue
- выполнить операцию

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

Если хочется, особенного, можно описать это или атрибутами или кодом в UI Builder.

Описанные параметры и операцию можно использовать из других частей документа без дополнительных описаний.

RunBase эквивалентен фразе в начале документа:
"Есть операции, которые могут показывать диалог и запускаться. Как связаны "показать диалог" и "запуститься" я не знаю, так же операция может сохранить состояние и восстановить ее, как именно - лично дело каждой операции"

То есть надо каждый раз повторять:
метод main, диалог (создания и получения), сохранение и восстановление и работу с версиями (все же аккуратно поддерживают восстановление из старых версий в unpack, да?). Я вот конкретно иногда забывал добавить строчку в getFromDialog или копировал но не правил и от этого были ошибки.

P.S. Это тут было?
https://www.youtube.com/watch?v=GRr4xeMn1uU

[ax_mct]

Dech, мне тяжело написать 2000 строк даже если я очень захочу.
Речь о существующем коде.
И об отношении к коду.
Для меня 2000 строк это не говнокод, а просто код.
Не хуже и не лучше чем если бы был разбит на части.

Да, тот же settleNow() примерно такой длины, но я не уверен что от деления этой логики на множество методов, или не дай бой иерархии классов, станет легче. Скорее всего будет шило на мыло.

Проблема то именно в фанатичном использовании ООП вообще и не свойственного для Аксапты ООП в частности.
Вот это нетерпимость к "неправильному" коду и есть одна из причин over-engineering.
Если код делает то что от него требуется, включая возможность его поддержки и расширения, то он не может быть неправильным. При условии конечно соблюдения Best Practices для АХ, но никак не "общепринятого программирования".

Уважай культуру места где находишься вот и все. Если 2000 строк в данной культуре - ОК, и более того работает и работает, то не трогай. Не считай себя более одаренным чем те программисты которые подняли этот продукт.
Уважай то что работает какое бы грязное оно не было. Рабочее оно как раз всегда грязное.

[Bobkov]

Цитата:

Сообщение от belugin

Какой документ лучше, вот такой?
Или вот такой:
Однозначного ответа нет.

Из моего скромного опыта, ответ зависит от того, как пойдут требования для изменений.

Если требования для изменений пойдут построчно (наиболее реалистичный вариант, IMHO), то удобнее будет документ с независимыми строками. Если же требования для изменений будут относиться ко всем строкам сразу (маловероятный вариант, IMHO), то удобнее окажется документ "У этих животных хвосты длинные".

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

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

IMHO, конечно

[ax_mct]

Цитата:

Сообщение от dech

...
изменять функционал и добавлять новый все-таки с умом надо. Требовать хороших удобных инструментов любой может. А вот создавать иерархии наследования, выделять интерфейсы, оптимизировать запросы к БД, ускорять работу форм и отчетов не всякому под силу. Многие не задумываясь дублируют метод, или того хуже класс, набитый под завязку этим самым г*. Меняют 2 строчки и довольны.

Для меня мало закончить задачу. Я всегда стараюсь сделать рефакторинг кода в тех классах, которые правлю. Если предстоит скопировать логику класса под какие-то свои цели, я смотрю как можно обобщить её, чтобы не было тупого дублирования. Возникает иерархия классов, происходит выделение общих методов в родительский класс. Дальше эту структуру становится намного легче использовать, добавляя туда полезный код. Естественно, я не делаю такого со стандартом
...
Пример: Решили сделать загрузку данных батчем и раскидать в журналы по разным компаниям. Делали через changeCompany и runAs. А потом клиент удивляется, куда пропадает часть данных? Смотрим, вроде нормально, правильно... закоммитили транзакцию, блок смены компании закрыли. Только дальше в этом же методе идёт (внимание) удаление связанных данных, которое происходит уже в текущей компании. После этого я нахожу еще кучу классов, которые делают то же самое. Продублировали без зазрения совести. И никто не удосужился протестировать. Скопипастили и всё, мы - молодцы!
...

Только счас вчитался, как то мозг сразу не осознал.
Коллега, вы крайне опасный романтик программирования.

Убеждение что дублирование это всегда плохо и надо создавать иерархии наследования, выделять интерфейсы, выделять общие методы в родительский класс и прочее в том (не SYS) коде к которому вы прикасаетесь - это тот самый студенческий максимализм.

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

Из-за страха/неприятия перед дублированием кода создавать иерархии наследования, выделять интерфейсы, выделять общие методы в родительский класс -
это как ни парадоксально звучит и есть overengineering.

Использовать подобные средства надо тогда когда говорит здравый смысл, а не просто потому что повтор кода. У нас приложение не группа закрытых DLL, а открытый текст.

И как правильно подметил Bobkov, повтор кода - может быть необходим для обеспечения независимости кода. Всегда есть аспекты тестирования, деплоймента, одновременной работы, сырость требований и прочее помимо чистого искуства. Ремесленные аспекты.

"если менять то только в одном месте" - это постулат компьютерной науки не имеющий ничего общего с реальной инженерией.
Неестественные абстракции, то есть те которые не отражают реальные вещи, - намного хуже чем повтор кода.

[macklakov]

Цитата:

Сообщение от ax_mct

тот же settleNow() примерно такой длины

settleNow() сам по себе результат "программизма". Объединить accounts receivable и account payable в одну и иерархию, мог только человек который ни дня не провел в этих отделах, зато много в коде ковырялся и увидел в этих процессах некоторую корреляцию. Но это реально 2 совершенно разных отдела! И работают они по совершенно разным бизнесс-процессам. Поэтому вся эта CustVend иерархия создает больше проблем, чем пользы.
Т.е. "программизма" хватает и в "старой доброй" axapta. И от него надо было избавляться. Это учетная система, она должна отражать реальность, а не продвигать идеализм в массы.

[macklakov]

Цитата:

Сообщение от dech

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

Сделать наследование таблиц еще сложнее. Требуется и талант и образование и опыт большой. А вот сделать интеграцию с банком конкретным, особых талантов и знаний не надо. Надо просто упереться и сделать. При этом интеграция со всеми существующими банками "из коробки" рынку нужна, а вот наследование таблиц под большим вопросам. Но почему-то вместо интеграции у нас наследование таблиц.
Ах, да! О чем это я! Нам же дали замечательную универсальную интеграцию с банками! Недоделанный SSIS. Тоже непростая техническая задачка, я вам скажу. Типа от нормального банка мы получим файл, для которого квалифицированный девелопер легко подправит XSLT и мы получим желанную интеграцию. Только вот бизнес, заразы такие, когда выбирают банк, почему-то не спрашивают, какому стандарту следуют их файлы, они смотрят на выбор и стоимость финансовых инструментов. И бизнес приходит в некоторую оторопь, когда оказывается что в каком нибудь копеешном бухгалтерском пакете все эти банки уже есть. А вот в AX партнер либо продает дополнительный пакет интеграции, нормально поддерживать который у них нет ресурсов, либо лихорадочно ищет человека, который знает и X++ и XSLT и еще в состоянии разобраться с дикими форматами банковских файлов.

[trud]

Цитата:

Сообщение от belugin

Так же и фреймворки - например SysOperation эквивалентен разделу в начале документа, где написано:
- бывают операции
- у операций бывают параметры
- если не сказано обратного, то надо :
- загрузить параметры из SYsLastValue
- спросить параметры согласно типам
- сохранить их в SysLastValue
- выполнить операцию

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

Если хочется, особенного, можно описать это или атрибутами или кодом в UI Builder.

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