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

[fed]

Похоже что я один честно ответил: "Нет, я не использую Best Practice Check и не знаком с рекомендациями." Нет, я конечно читал когда-то Best Practice (во времена версии 2.1) и даже перекомпилял время от времени приложение с включенными проверками.(В разных версиях). Из всего этого вынес ощущение, что 80% best practice - это best practice разработки сферического коня в вакууме. Ну вот нахрена мне пользоваться глючными метками, если внедрение идет на одном клиенте с одноязычным персоналом ? Нахрена мне строить индекс по сочетанию полей в каждом where, если я знаю что это параметрическая таблица из 10 записей, которая влезает в одну страницу, почти никогда не обновляется и по которой я уже построил разумный кластерный индекс ?

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

[Maxim Gorbunov]

Цитата:

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

Похоже что я один честно ответил: "Нет, я не использую Best Practice Check и не знаком с рекомендациями." Нет, я конечно читал когда-то Best Practice (во времена версии 2.1) и даже перекомпилял время от времени приложение с включенными проверками.(В разных версиях). Из всего этого вынес ощущение, что 80% best practice - это best practice разработки сферического коня в вакууме.

Денис, спасибо, отличный ответ. В целом, я согласен, что многие Best Practices часто не имеют смысла для конкретного клиента/приложения. С другой стороны, этого нельзя сказать про все Best Practices целиком. Меня, например, очень сильно напрягает, когда приходится разбираться в коде, который писали без учёта naming conventions и форматирования (а такое, к сожалению, встречается всё чаще и чаще). Я думаю, ты согласишься, что если код написан, скажем так, красиво, то его гораздо легче понять, и его можно гораздо быстрее дополнить или исправить.

В любом случае, я думаю, ты важную тему затрагиваешь - сейчас Best Practices в Developer Help представляются просто как список ничем не обусловленных рекомендаций. Я ни разу не видел обсуждения Best Practices и их обоснования (ну, за исключением бумажки, под названием Trustworthy Computing, к которой тоже много вопросов). В такой ситуации, в общем-то, не удивительно, что они так часто игнорируются.

Ну и пару слов по поводу твоих примеров "ненужных" рекомендаций.

Цитата:

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

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

А я наоборот всегда стараюсь использовать метки. "Глючность" их, обычно, побороть не так сложно. А взамен я получаю возможность переиспользовать код на другом клиенте, который может говорить на другом языке. Плюс, оставляю возможность перевода интерфейса на местный язык - всё-таки, нужно учитывать, что английский для моих пользователей не родной (я предполагаю, что и для твоих тоже ). Кроме того, мне просто легче читать код, который не перегружен текстовыми константами.

Цитата:

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

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

А вот такой рекомендации я что-то не нашёл. Может это что-то из старого? По-моему, действительно не разумно для каждого where добавлять свой индекс.

Цитата:

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

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

Заставил задуматься - может быть нам действительно стоит обсудить, кто какие Best Practices проверяет, а какие игнорирует? Заодно разберёмся, почему такие рекомендации возникли изначально. Так сказать, на пользу будущим поколениям программистов AX

[lev]

помню в свое время, с помощью проверки BP нарыл в системе (в классах, таблицах, формах) очень много объявленных, но не используемых переменных. Казалось бы мелочь, но память то под них выделяется при выполнении... Получается какое то "не целевое использование средств" .

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

С другой стороны, считаю все таки полезно иногда вручную запускать эту проверку BP.
Вдруг в BP, что то добавили важное, и к этому действительно стоит прислушаться (хотя конечно за последние 5-6 лет ничего такого не встретилось ).

[fed]

Цитата:

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

А вот такой рекомендации я что-то не нашёл. Может это что-то из старого? По-моему, действительно не разумно для каждого where добавлять свой индекс.

Ну последний раз я BP CHeck гонял на 4ке и оно мне там навыдавало пару варнингов (если я ничего не путаю), по поводу того что есть select myTable where myField==constant и по этому myField индекс отсутствует. Хотя, возможно, я что-то путаю.

А в то что метки могут не глючить - не верю. Они были глючными в версии 2.1 и они продолжают глючить в версии 2009 RU7. Вот недавно на двуязычном внедрении, коллеги накатили импорт проекта с метками, а после этого у них сервера стали выдавать сооющение "Ошибка чтения при смешении бла бла байт в файле таком-то". Пришлось индексы приложения и метод грознуть и сервера рестартовать в середине рабочего дня.

[Maxim Gorbunov]

Цитата:

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

Ну последний раз я BP CHeck гонял на 4ке и оно мне там навыдавало пару варнингов (если я ничего не путаю), по поводу того что есть select myTable where myField==constant и по этому myField индекс отсутствует. Хотя, возможно, я что-то путаю.

Проверил из любопытства на AX2009. Сделал вот такой вот класс:

class TestClass1 
{
}

public static void main(Args args)
{
    CustTable custTable;
    
    select firstonly custTable
        where custTable.SalesGroup == '10';
}

Best Practice Check промолчал. Хотя я тоже смутно припоминаю такие рекомендации, которые ещё сопровождались словами про то, что запрос непременно приведёт к table scan. Наверное, действительно раньше это внутри AX проверялось, а теперь отдали на откуп DB Tuning Advisor в SQL Server.

Цитата:

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

А в то что метки могут не глючить - не верю. Они были глючными в версии 2.1 и они продолжают глючить в версии 2009 RU7. Вот недавно на двуязычном внедрении, коллеги накатили импорт проекта с метками, а после этого у них сервера стали выдавать сооющение "Ошибка чтения при смешении бла бла байт в файле таком-то". Пришлось индексы приложения и метод грознуть и сервера рестартовать в середине рабочего дня.

.Ужас У меня, конечно, тоже бывали такие ошибки, но я что-то не помню, чтобы это было связано с метками. Ошибка чтения бывала в AOD-файлах, в AOI - это, да. В ALD, ALC или ALI - не видел. Вообще-то, у меня и мысли не возникало, что это может как-то быть связано с метками.

Самый неприятный "глюк" меточных файлов на моей практике - импорт проектов с метками в среду, в которой работает несколько АОСов. Новые метки при этом появляются только у клиентов, подключенных к тому АОСу, в который проект импортировался. Решается проблема импортом меток (только меток!) на каждый АОС по отдельности. Неприятно, конечно, но не смертельно.

[fed]

Цитата:

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

.Ужас У меня, конечно, тоже бывали такие ошибки, но я что-то не помню, чтобы это было связано с метками. Ошибка чтения бывала в AOD-файлах, в AOI - это, да. В ALD, ALC или ALI - не видел. Вообще-то, у меня и мысли не возникало, что это может как-то быть связано с метками.

Самый неприятный "глюк" меточных файлов на моей практике - импорт проектов с метками в среду, в которой работает несколько АОСов. Новые метки при этом появляются только у клиентов, подключенных к тому АОСу, в который проект импортировался. Решается проблема импортом меток (только меток!) на каждый АОСы по отдельности. Неприятно, конечно, но не смертельно.

Ну эти сообщения стабильно выдавались при попытке поиска некоторых меток в wizard и при попытке некоторые метки вывести на экран. Вероятно - все-таки предположение что проблема в метках - оно достаточно правдоподобное. И да - на этом проекте приходится метки на каждый сервер импортировать отдельно. Что в общем тоже работы добавляет слегка...