АСУ ТП в облаке — быстрая разработка проектов

[Владимир Ситников]

20% то зачем? Закоментировать нужно строку с вызовом функции.
Скажу, что если то, что нужно удалить идет не подряд, а как попало, то это будет не весело.

Вообще говоря, практика PVS-Studio показывает, что в copy&paste коде крайне много ошибок. В их анализаторе много правил именно по copy&paste направлению, и они много чего находят.

В каждой первой программе находится вот такая ошибка:
xc=xa+xb;
yc=ya+yb;
zc=ya+yb;

Если это портянка на 1000 копипастов, то я боюсь представить сколько там ошибок.
Цикл реально звучит более правдоподобным и поддерживаемым решением.

[Миних В.А.]

"что за нахи" всё равно будут: http://commadot.com/wtf-per-minute/

Да, качество кода измеряется количеством "чезанахов" в минуту))

Можно всё-таки увидеть какой-нибудь пример?
"Была задача такая-то", "обычно решается так-то", "предлагается решать так-то", "экономия на разработке -- 10 дней", "экономия на поддержке -- 20 дней", "затраты на доп обучение -- 15 дней", "затраты на программиста -- 25 дней"

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

На самом деле данный пост показал, что нет единой концепции в рядах разработчиков АСУ ТП.
Я благодарен всем, кто не пожалел своего времени и принял участие в дискуссии.
Для меня это ценная информация.

Вот классика жанра на тему автоматизации: https://www.youtube.com/watch?v=5Qn9...outu.be&t=4170

Я повеселился!!!

[qs212]

Вообще говоря, практика PVS-Studio показывает, что в copy&paste коде крайне много ошибок. В их анализаторе много правил именно по copy&paste направлению, и они много чего находят.

В каждой первой программе находится вот такая ошибка:
xc=xa+xb;
yc=ya+yb;
zc=ya+yb;

Если это портянка на 1000 копипастов, то я боюсь представить сколько там ошибок.
Цикл реально звучит более правдоподобным и поддерживаемым решением.

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

Ну и вообще, АСУТП от объекта автоматизации зависит. Например вся пищевка - дискретное производство. То есть "большой" объект, состоящий из кучи несложных функций в количестве дофига. В отличие от к примеру энергетики, где "сложные" объекты, состоящие из кучи связанных процессов. И редко что то переделывается.
А в пищевке часто запуск нового продукта сопровождается переделками технологической схемы, с добавлением/убиранием объектов, функций, блокировок. На крупных заводах этот процесс идет непрерывно, поэтому важна большая гибкость и простота перепрограммирования.

[Миних В.А.]

Цикл реально звучит более правдоподобным и поддерживаемым решением.

Или автоматизация копипаста))
Насколько я знаю, ребята, которые работают в эксплуатации (не разработчики, а именно эксплуатация), очень не любят разбираться со всякими замутами вроде циклов/косвенной адресации/и всякой магии. Особенно когда у тебя многомиллионная линия встала и плюшки на конвейерах сохнут. Им надо быстро найти по поиску нужную переменную и быстро ее "зафорсить". И времени вычислять циклы и вставлять кейсы у них нету. Поэтому банальная релейная логика им очень нравится, она очень хорошо ложиться на их понимание релейных схем. Хорошо, если у них есть грамотный спец, который сможет раскурить эту магию. А чаще всего есть дядя Ваня КИПовец, которого научили как открыть Simatic Manager и найти нужную строчку и нажать нужную кнопку чтобы все поехало. Потому что над ним стоит начальник цеха с топором и грозит лишением премии, если плюшки засохнут. Вот такая стрессовая ситуация))) Извините, сам начинал с КИП 20 лет назад и насмотрелся всякого (например на специалистов, которые измеряют напряжение лампочкой, и говорят что у них батарейка села в стрелочном вольтметре и нечем замерить напряжение).

[capzap]

20% то зачем? Закоментировать нужно строку с вызовом функции.
Скажу, что если то, что нужно удалить идет не подряд, а как попало, то это будет не весело.

Вас ни кто за язык не тянул, Вы сами обозначили цифру 20 и даже пускай закомментить требуется только вызов функции наладчику требуется влюбом случае пробежаться по всему коду ставя комменты только в нужных местах,что ещё больше его напряжет, повторяю в цикле я бы в одном из кейсов определил номера с которыми ни чего делать не надо,а по дефолту все что предписано, у меня как у НАЛАДЧИКА займёт меньше времени,чем комменты поставлять. Теперь что касается разработчика,такой ситуации вообще допускать нельзя, подобным занятием должна заниматься скала, не требуется использование объекта, отключить его в визуализации

[Владимир Ситников]

а зацените тестирование по этой ссылке https://m.habrahabr.ru/post/260767/ здесь билдера выигрывает

Там не тестирование, а порнография полнейшая.
Без http://openjdk.java.net/projects/code-tools/jmh/ тест на производительность вообще невозможно написать.

Комментарии к статье смотрели?
Вот тут Лёша по-русски рассказывает почему нельзя просто так брать и использовать System.currentTimeMillis: https://www.youtube.com/watch?v=8pMf...=youtu.be&t=20
И второй доклад тоже есть в комментариях.

[qs212]

Вас ни кто за язык не тянул, Вы сами обозначили цифру 20 и даже пускай закомментить требуется только вызов функции наладчику требуется влюбом случае пробежаться по всему коду ставя комменты только в нужных местах,что ещё больше его напряжет, повторяю в цикле я бы в одном из кейсов определил номера с которыми ни чего делать не надо,а по дефолту все что предписано, у меня как у НАЛАДЧИКА займёт меньше времени,чем комменты поставлять.

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

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

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

[capzap]

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


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

так Вы вообще имеете опыт работы с заказчиком по внедрению автгмктизации? Это значит заказчик оплатил стоимость N-ого количества клапанов, оплатил монтаж оборудования, соответственно оплатил проектные работы и тут появляется программист, который говорит ну тут 20% клапанов вообще не нужны, их смело можно выкидывать из программы, знаете за что Вас повесят на ближайшей березе? Особенно когда курс евро под сотню

[qs212]

так Вы вообще имеете опыт работы с заказчиком по внедрению автгмктизации? Это значит заказчик оплатил стоимость N-ого количества клапанов, оплатил монтаж оборудования, соответственно оплатил проектные работы и тут появляется программист, который говорит ну тут 20% клапанов вообще не нужны, их смело можно выкидывать из программы, знаете за что Вас повесят на ближайшей березе? Особенно когда курс евро под сотню

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

[Владимир Ситников]

а не какой то там Лёша

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

Этот "какой-то там Лёша" напрямую занимается производительностью сложения строк в Oracle JVM: http://openjdk.java.net/jeps/280
И не просто "что-то там мутит", а результаты его работы напрямую включаются в состав java машины.

И что? К кому мы больше прислушиваемся? К непонятному автору на habr'е, у которого всего три статьи и "про строки" это первая из них?
Или к Лёше, который активно вносит правки в OpenJDK, выступает на конференциях, и пишет статьи?

В Google хотя бы попробуйте: https://www.google.ru/search?q=alexey+shipilev

Хоть по одной ссылке ходили, которую я приводил? (я понимаю, что просмотреть те несколько часов видео адова туча времени, но я специально указывал на нужные моменты)

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

А мне, например, режет слух, когда "capzap" или "Валенок" вместо имени.
Конечно, capzap это менее ругательное имя, чем "Валенок", но, блин, чтобы упомянуть второе, и оно не звучало ругательно, нужно очень постараться.

По существу:

http://shipilev.livejournal.com/ : Привет, меня зовут Алексей Шипилёв. В отношении меня можно использовать имена Лёша, Алексей, Лёха, или в крайнем случае, Шипилёв.

Т.е. "Лёша" это первое из обращений, которые Шипилёв сам рекомендует. И рекомендует для всех, а не только для тех, кто "пиво пил".

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

Не обижайтесь, но так происходит у всех, кто начинает заниматься производительностью.
Я вот не верю, что под профилировщиком вы имели ввиду perf или Solaris Studio Performance Analyzer.

Всё остальное в данном контексте не может дать нужную точность.
Нужная точность в конкретном случае -- ассемблерный код и раскладка по времени на каждую инструкцию.
Т.е. нужно посмотреть в какой машинный код в конечном итоге компилируется builder, в какой buffer и т.п.

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

Нет. "значит" у вас неверное.

"так нелья делать" не из-за того, что результат не в мою пользу получился. Нельзя делать из-за того, что инструменты для измерения и анализа там неверные.
Попробую привести аналогию: нужно измерить длину провода, но рулетки нет. Зато есть лист А4. Прикладываем его и считаем количество. 297мм же. Можно измерить? Какие проблемы? Зачем брать рулетку? Всем же известно, что 297мм. Умножаем на количество листов и вот она, наша длина провода.

Повторюсь: вы (и автор упомянутой статьи на habr'е) далеко не первые, кто использует неподходящие инструменты для измерения производительности.
Даже эссе есть на эту тему: http://shipilev.net/blog/2015/voltmeter/

Алексей Шипилёв: Порядочное количество диалогов о производительности и её измерении звучит так. Приходит ко мне какой-нибудь Василий и спрашивает:

Вася: Как померить напряжение в розетке?
Я: Возьми вольтметр и измерь.
Вася: Но я не умею в вольтметр, смотри, у меня есть лампочка
Я: Лампочкой напряжение не узнать, возьми вольтметр.
Вася: Ну как же!...

Если вы докажете, что эффект есть, то я без проблем соглашусь. Если вы готовы тратить своё время, я готов помочь в анализе результатов и показать где именно у вас косяк. Но вообще-то, пункт №1 это замена currentTimeMillis на http://openjdk.java.net/projects/code-tools/jmh/
currentTimeMillis==лампочка
code-tools/jmh==вольтметр

Заметьте: я ни разу не говорил, что "нужно всегда использовать buffer". Не говорил и про "нужно всегда использовать builder".
Я говорил лишь про то, что замена buffer на builder (или наоборот) никак не скажется на общей производительности программы.

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

И, да, я не привожу своих замеров не из-за того, что "не умею измерять" или "лень тратить время". На тему buffer vs builder уже есть более авторитетный замер. Я могу повторить его, но какой смысл смотреть на производные, если можно посмотреть на оригинал?