Опрос: Используете ли вы Best Practice Check при разработке?

[trud]

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

[fed]

Цитата:

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

Тут добавлю по нововведениям.
AX2012 проверяет сколько полей используется из курсора и если используется 1 поле предлагает заменить select tableBuffer на select FieldList from tableBuffer
А это по моему как раз совсем и не BestPractice

Такая оптимизация имеет смысл только при наличии покрывающего индекса, ну или если у тебя таблица очень большое количество полей имеет (Но в этом случае, правильнее соптимизировать за пределы организации самого разработчика этой таблицы).
Затаскивание этого в best practice - заведомый идиотизм...
P.S. - Да - и конечно же указание списка полей в select - это хороший шанс на тяжеловылавливаемые ошибки, из за того что алгоритм поменяли, а дополнительные поля в список забыли добавить... Полностью согласен с предыдущим оратором.

[Maxim Gorbunov]

Цитата:

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

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

Так, подождите. Декларируется ведь, что эта проверка только для локальных селектов. То есть, в случае, если курсор куда-то передаётся, то проверка не выполняется.

К сожалению, нет сейчас AX 2012 рабочей под рукой. Не могу проверить.

Цитата:

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

Такая оптимизация имеет смысл только при наличии покрывающего индекса, ну или если у тебя таблица очень большое количество полей имеет (Но в этом случае, правильнее соптимизировать за пределы организации самого разработчика этой таблицы).
Затаскивание этого в best practice - заведомый идиотизм...

Ох, твои бы слова, да... Мне бы, честно говоря, тоже хотелось бы заглянуть в глаза, например, разработчикам модуля HRM

Но заметь, наличие такой рекомендации как минимум должно заставить разработчиков задуматься о структуре данных - нет?

[S.Kuskov]

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

[CDR]

Регулярно пользуюсь проверкой BP.

Очень удобно, т.к. автоматом подсказываются всякие важные мелочи, которые можешь и пропустить, сконцентрировавшись на сути модификации (например, AllowEdit = false для полей первичного ключа в таблице).

Очень удобно, когда переносишь модификацию из одной версии в другую версию. Также подсказывается большая часть важных мелочей новой версии. Помниться при переносе новой таблицы из тройки в девятку с полями InventDimId и Dimension BP check отругалась и в итоге подсказала сделать связь аналитик для сайта. Или для relation, прописанного на таблице выругалась на разную длину полей в двух таблицах.

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

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

[trud]

Цитата:

Сообщение от Maxim Gorbunov

Так, подождите. Декларируется ведь, что эта проверка только для локальных селектов. То есть, в случае, если курсор куда-то передаётся, то проверка не выполняется.

Нет не выполняется конечно же, проверять тут нечего.
Только проблема в том, что на момент написания кода могло и не передаваться. и разработчика принуждают писать select fieldlist.

А потом кто-то этот код дописывает

В целом по 2009 довольно несложно следовать BestPractice, в 2012 я потратил около 3 часов на приведение 30 часовой несложной модификации к 0 ошибкам проверок.
Т.е. опрос все же зависит от версии.

[Maxim Gorbunov]

Цитата:

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

Нет не выполняется конечно же, проверять тут нечего.
Только проблема в том, что на момент написания кода могло и не передаваться. и разработчика принуждают писать select fieldlist.

А потом кто-то этот код дописывает

Ну, в таком случае Best Practice можно переписать так: выделяйте выборку данных и их обработку в разные методы сразу в первой же версии кода

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

Цитата:

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

В целом по 2009 довольно несложно следовать BestPractice, в 2012 я потратил около 3 часов на приведение 30 часовой несложной модификации к 0 ошибкам проверок.
Т.е. опрос все же зависит от версии.

Не совсем понял. Вы предлагаете дополнить опрос вариантом вроде "Использовал в 2009, но перестал в 2012?"

[S.Kuskov]

Цитата:

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

Разработчика принуждают писать select fieldlist.

А потом кто-то этот код дописывает

А для тех кто дописывает нужно ещё одну проверку сделать. Мол вы используете поле, которое отсутствует в списке полей select.

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

[fed]

Я пожалуй некий набор постулатов выскажу:
1. Следование BP, в общем случае, позволяет несколько улучшить качество решения.
2. Следование BP не гарантирует повышения качества решения, но гарантирует дополнительные трудозатраты и косты.
3. Бездумное следование BP (без понимания того, чем то или иное правило было порождено) скорее приведет к ухудшению качества решения, чем к его повышению.
4. При наличии инженерного и программистского опыта и головы на плечах, вполне можно писать неплохие решения и без следования BP.

[Vadik]

Денис, в случае наличия головы на плечах и ведения разработки в одиночку практически любая используемая технология или методика - сплошные дополнительные косты. В случае командной работы над большим проектом прогон BP check по завершению разработки - это быстрый и дешевый способ убедиться в том, что по крайней мере в простых, но важных вещах (как то - кэширование на таблицах, метки, Mandatory и AllowEdit на полях из PK и т.д.) мы не накосячили. Раздражают какие-то определенные проверки - отключи, но это не повод не пользоваться ими совсем

[CDR]

Если честно, то получилась какая-то ерунда, а не набор постулатов...
Вместо "BP" можно подставить любое подходящее по смыслу слово ("Оформление кода", "Простановка проектных комментариев", "Рефакторинг", "ООП") и наблюдать за отсутствием смысловой нагрузки в постулатах.

[Oz]

Цитата:

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

Если честно, то получилась какая-то ерунда, а не набор постулатов...
Вместо "BP" можно подставить любое подходящее по смыслу слово ("Оформление кода", "Простановка проектных комментариев", "Рефакторинг", "ООП") и наблюдать за отсутствием смысловой нагрузки в постулатах.

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

[S.Kuskov]

Цитата:

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

4. При наличии инженерного и программистского опыта и головы на плечах, вполне можно писать неплохие решения и без следования BP.

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

Незнание закона не особождает от ответственности

[klimova_m]

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

[Vadik]

Цитата:

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

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

Только если сами признаются

[sukhanchik]

Ой больная тема Ответил, что не использую, но знаком, хотя в душе полностью согласен с fed, что BP читал только для 3.0, а дальше уже не читал .
Я пользуюсь BP только в очень сложных случаях, когда очень сложный и непрозрачный алгоритм и надо выверить код. В этом случае BP может подсказать какие-то косяки типа забыл return вставить или есть неиспользуемая переменная.
А еще BP полезен при проверке кода у новичков, когда их надо наставить на путь истинный .

[niksen]

Цитата:

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

Только если сами признаются

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

[lvan]

а почему в диаграмме шкала нелинейная?