Для кого Best Practice?

[axm2017]

Цитата:

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

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

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

[trud]

Цитата:

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

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

Чем тогда это будет отличаться от оверлеинга(да еще и с кучей ограничений)? Т.е. изначальная идея-то в том чтобы не меняли стандартное приложение

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

Так зачем тогда мурыжить в тренингах по разработке, что не пишем код на формах. Очередная промывка мозгов?

Тренинги писались для более ранних версий, чем D365, а там это правило было актуально.
Вообще, на все это можно посмотреть с другой стороны. Когда-то раньше наверняка существовало правило, по которому в SELECT-ах нужно было указывать индекс (INDEX HINT), по которому нужно осуществлять выборку. Потому что не было СУБД, а была просто БД (типа DBF-ок) и программист сам должен был указывать индекс, по которому осуществлять выборку.
Тоже самое можно сказать про транзакции и технологии, их заменяющие (таблицы *Delta, поле createdTransactionId и т.д.)
Сейчас уже никто не задумывается над тем, какой индекс возьмет БД (лишь бы он был). Также все знают, что ttsbegin / ttscommit заведомо решат все задачи транзакций.

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

[sukhanchik]

Цитата:

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

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

Вообще говоря, LADA сделала большой качественный скачок. И не любят ее... в основном там, где либо оборачивается много денег (Москва и область), либо там, где иномарки сильно дешевле (Дальний Восток), либо там, где нужны машины другого класса (Камчатка и регионы со сложной проходимостью). Но, к примеру, Ниву и классику в деревнях очень сильно уважают за их дешевизну и легкую починку.
Кстати и в продажах по России LADA помнится уверенно лидирует среди других марок машин...

[MikeR]

Итого резюмирую что получается:
1) Писать код с транзакциями в контролах формы - это не бага, возможно фича. херачь свои вволю.
2) Паттерны в сторону. Поменялось мировоззрение. Уточню в аксапте поменялось мировоззрение.
3) Бест Практис писался для предыдущих версий, его можно не учитывать.

PS. Французские менеджеры все таки добились за десятилетия управления заводом качества 100%, Вообще да, если в год улучшать качество процентов на 40, то даже агрегируя можно получить значение и выше 100. Пересаживаемся.)
Ну и в конце концов хватит уже рвать волосы.

[axm2017]

Пункты 2 и 3 а соответственно и 1 некорректны.

Не рекомендуют править уже существующий и работающий код без причин.

Паттерны и прочее при создании нового кода никто не отметает.

[sukhanchik]

Цитата:

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

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

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

Цитата:

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

2) Паттерны в сторону. Поменялось мировоззрение. Уточню в аксапте поменялось мировоззрение.

Скорее поменялись паттерны. Правда новые паттерны не афишировались, но можно поизучать существующий код, чтобы понять, в каком "стиле" теперь система ожидает написания кода

Цитата:

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

3) Бест Практис писался для предыдущих версий, его можно не учитывать.

Думаю, что правила (проверки) Best Pratice, которые встроены в систему - актуализируются в каждом новом выпуске системы. И им можно следовать. Да, по-хорошему нужно выпустить и донести до широкого круга разработчиков обновленный Best Practice. Но видимо в MS не считают это приоритетной задачей. И в чем-то я даже с ними соглашусь.
В общем - главное руководствоваться здравым смыслом и исходить из того, что в любой момент собственный код может перестать работать, поэтому надо либо максимально использовать стандартный код, либо максимально чего-то писать совсем в стороне.

[MikeR]

Цитата:

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

Скорее поменялись паттерны. Правда новые паттерны не афишировались, но можно поизучать существующий код, чтобы понять, в каком "стиле" теперь система ожидает написания кода.

Вот с этого все и началось: ИЗУЧЕНИЕ, статусные вещи, вроде: CustTable, CustTrans, SalesTable and others. Но по ним невозможно ПРАВИЛЬНО научится, так как они сделаны в угоду совместимости и рефакторится не будут.

Цитата:

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

...актуализируются в каждом новом выпуске системы. И им можно следовать...
.

Получается, что не актуализируются.

[MikeR]

Цитата:

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

Паттерны и прочее при создании нового кода никто не отметает.

Стоит отметить, что массовые транзакции появились в форме SalesTable c 2012 версии, тогда это было реальное нарушение. В 2009 версии там была всего одна транзакция. Нет под рукой вирт машины, но по-моему в 3 версии там все было более менее в этом плане.
По истории получается, что ухудшения массово стали попадать в систему с 2012 версии. А в 365 на них не нашлось ресурсов и просто забили.
Как-то так.

[AlexSD]

Цитата:

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

Вот с этого все и началось: ИЗУЧЕНИЕ, статусные вещи, вроде: CustTable, CustTrans, SalesTable and others

Почему вы какой-то старый хлам, от которого никак не могут избавиться, называете статусными вещами?
Нынче GER - статусная вещь. Смотрите туда.

[sukhanchik]

Цитата:

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

Вот с этого все и началось: ИЗУЧЕНИЕ, статусные вещи, вроде: CustTable, CustTrans, SalesTable and others. Но по ним невозможно ПРАВИЛЬНО научится, так как они сделаны в угоду совместимости и рефакторится не будут.

Я думаю, что будут. Просто логично с т.з. изменений блок, отвечающий за продажи рефакторить в последнюю очередь. Ведь еще ж продать надо очередную версию системы, а блок с продажами в системе - это святое.
В конце концов ничего же не остановило от рефакторинга SalesFormLetter еще в 2012.
А учиться... Начиная с 2012 правильнее учиться не по SalesTable, а по PurchTable.

По поводу встроенных проверок Best Practice - они точно меняются, просто наверное они не ловят наличие транзакций на контролах или еще какие-то вещи, от которых у людей, работавших с 3.0 - волосы встают дыбом

[MikeR]

Цитата:

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

...они не ловят наличие транзакций на контролах или еще какие-то вещи, от которых у людей, работавших с 3.0 - волосы встают дыбом

Именно так.

По поводу хлама, мне казалось, что надо продать что-то "ненужное", а потом думать как это в ГК разносить и отчеты строить.

[axm2017]

Цитата:

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

.. А в 365 на них не нашлось ресурсов и просто забили.
Как-то так.

Как стажёр, на которого традиционно падают не самые весёлые задачи, занимался /занимаюсь помимо ger иногда и портированием функционала с 12 в 365. Кстати авто портирование в явном виде не нашёл даже путем опроса коллег из мс.

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

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

[MikeR]

Цитата:

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

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

Не понимаю, почему не отфакторили после решение с учетом всего?
Или как в старое доброе советское время - ВАЛ по ПЛАНУ?

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

[MikeR]

Ладно уже понял, в этом топике не хватает комсорга, который закроет эту ветку с криком:
Ну все, хватит уже истерить! Работаем!

[axm2017]

Цитата:

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

Не понимаю, почему не отфакторили после решение с учетом всего?.
:

Вам шашечки или ехать?

Рефакторинг серьезный подразумевает понимание функционала, логики авторов и прочее. По трудоёмкость в таком случае этот процесс легко может перебить собственно первоначальную разработку + породить баги так как автотесты, активно партнёры типа нас, стали использовать лишь с 365 версии.

И появляется вопрос: а оно надо? Клиент требует решение завтра, а вы, если ударитесь в дебри рефакторинга существующего решения выдадите его через год.

[AlexSD]

Цитата:

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

Не понимаю, почему не отфакторили после решение с учетом всего?

Ну, это наверно уже классика: https://habr.com/ru/post/219651/

[MikeR]

Цитата:

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

...
И появляется вопрос: а оно надо? Клиент требует решение завтра, а вы, если ударитесь в дебри рефакторинга существующего решения выдадите его через год.

Ждем комсорга...

PS После Наделлы поставят француза, который будет рапортавать об улучшении качества продукта на 40 % в год.

[mazzy]

Цитата:

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

Кстати авто портирование в явном виде не нашёл даже путем опроса коллег из мс.

Когда ax7 только появилась, то для портирования был сделан специальный внутренний tool.
Весь существующий на тот момент функционал, включая формы и отчеты были сконвертированы автоматически.

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

Поэтому с какого-то момента, формы и отчеты, которые появлялись сначала в ax2012, переносились в ax7 только руками.

Для ax7 был разработаны паттерны на форме. "Странные" паттерны, которые были портированы тулом обозвали кастомными. С какого-то момента кастомные паттерны совсем перестали проходить CodeReview внутри.

Эпопея с паттернами и отсутствие тула по конвертированию попортила столько крови разработчикам внутри, что на бестПрактис уже никто не обращал внимания. Хотя изначально пытались конечно

[mazzy]

Цитата:

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

Ждем комсорга...

Зачем?!