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

[Maxim Gorbunov]

Случайно на форуме наткнулся на великолепную статью в блоге: kamalblogs: Towards Dynamics Ax Product Certification – Best Practices (Part I)

В целом, ничего слишком интересного в статье, конечно, нет, но предыстория её появления показательна. Некая группа разработчиков, сотрудников компании-партнёра Microsoft, озаботилась сертификацией своего решения для AX и с удивлением обнаружила, что полное соответствие Best Practices является одним из критериев.

У статьи счастливый конец - после месяца борьбы с компилятором и собственным кодом, разработчики осознали, что проверка на соответствие Best Practices не прихоть Microsoft, а действительно полезное занятие, повышающее надёжность кода. Побочным результатом стало налаживание более или менее осмысленной процедуры разработки с контролем версий и автоматическими сборками.

За программистов-партнёров можно только порадоваться, но сколько разработчиков не сталкиваются с необходимостью сертификации своих решений? Видят ли они пользу в проверке Best Practices в своём коде? Пользуются ли ею? Особенно интересно, как отвечают на эти вопросы начинающие AX-разработчики.

Господа, пожалуйста, удовлетворите моё любопытство. Ответьте на опрос

Спасибо всем поучаствовавшим.

[fed]

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

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

[ice]

Ну вопрос не в том, следуют ли разработчики best practice и следят за обновлениями, а в том пользуются ли они для самоконтроля этой кнопкой

[S.Kuskov]

fed, вы всё-таки лукавите Одно дело знать рекомендации, и понимая причины этих рекомендаций отступать от них. А другое дело игнорировать общепринятые правила, руководствуясь собственными предпочтениями или привычками.

[fed]

А я их не знаю. Я их читал году в 2002 и наверное процентов на 70 уже забыл. А то что для версий 3,4 и 2009 было - я точно не читал. Если я каких-то ошибок в программировании, например, SQL или взаимодействия между AOS и клиентом не делаю, так это не потому что я best practice читал, а просто потому что мой опыт или мое понимание того как SQL или AOS работают, говорят мне что такой то подход будет чреват такими-то граблями...
Кроме того, я видел лавки (ну например в германии), где строго контроллировали соответствие бест-практис и при этом делали чудовищные ошибки в дизайне и в коде...

[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

[niksen]

читал, стараюсь следовать 5% если не ещё меньше

[lev]

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

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

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

[pitersky]

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

[fed]

Цитата:

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

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

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

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

[Wamr]

Пока идет разработка БП отключен, так как тормозит при каждой компиляции.
Перед переносом на тест включаю.

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

[fed]

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

[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 и при попытке некоторые метки вывести на экран. Вероятно - все-таки предположение что проблема в метках - оно достаточно правдоподобное. И да - на этом проекте приходится метки на каждый сервер импортировать отдельно. Что в общем тоже работы добавляет слегка...

[Maxim Gorbunov]

Цитата:

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

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

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

Допустим, у нас в методе объявлена табличная переменная типа PBATable. Следуя сложившейся традиции, назовём её так же, как и таблицу, то есть pbaTable. Проблема в том, что рядом в коде могут использоваться и динамические методы объекта pbaTable, и статические методы таблицы PBATable, и даже методы, объявленные на Map'е PBAItemLine. Конечно, всегда можно разобраться, какой именно метод используется в данный момент, немного заглянув вперёд в код, но это занимает время, ведь так?

А имена переменных вроде pBATable - это как раз от непонимания сути Best Practices, которую в Developer Help разъяснять не стали.

Цитата:

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

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

Эх, как бы эту культуру ещё привить

[fed]

Цитата:

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

А имена переменных вроде pBATable - это как раз от непонимания сути Best Practices, которую в Developer Help разъяснять не стали.

Ну такие забавные имена я как раз в стандарте видел.

[Maxim Gorbunov]

Цитата:

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

Ну такие забавные имена я как раз в стандарте видел.

Не спорю. Но модуль модулю рознь. В частности, Product Builder - это такая адская ахинея, что им можно реально пугать по ночам Сам Microsoft, кстати, признался в своём бессилии и отказался от попыток привести это буйство фантазии кодеров в сколько-нибудь удобоваримый вид - Product Builder больше не развивается, а из следующих версий вообще будет исключён (см. http://www.microsoft.com/download/en...s.aspx?id=7225).

[Link]

Цитата:

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

Некая группа разработчиков, сотрудников компании-партнёра Microsoft, озаботилась сертификацией своего решения для AX и с удивлением обнаружила, что полное соответствие Best Practices является одним из критериев.

Ага, это только в теории. Наши партнеры, как раз продали свой модуль МС, в 2009 версии он устанавливается отдельно, а в 2012 уже часть системы. Так вот не знаю как в 2012, но в 2009 их код это нечто. Я с ним и так часто сталкивался, а когда апгрейдил, то насмотрелся. "Бестпрактис? Не, не слышали." - это про них )

[trud]

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

[Maxim Gorbunov]

Цитата:

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

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

Почему нет? Особенно, если учитывать, что это рекомендация только для локальных select'ов.