Переменное именование и члены команды, которые говорят на другом языке

Измените требования к членам вашей команды - они должны адекватно понимать письменный английский.

Изменить: в ответ на комментарий Билла К., мне кажется, что Стоимость решения проблем со слабой связью не учитывается при расчетах экономии. Нет, я никогда не работал с зарубежными разработчиками, но я работаю с двумя людьми, для которых английский язык не является родным, и общение с ними иногда идет немного медленнее, хотя они оба прожили в США 20 лет.

Также , Я не ожидал, что мой ответ окажется самым полезным. Просто пытаюсь донести мысль. Если вы не наняли бы кого-то для работы в своем офисе, тогда зачем вам нанимать их для работы с другой стороны земного шара? Даже если вы проходите через агентство,

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

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

Большинство разработчиков должны хорошо разбираться в техническом английском (в конце концов, API на большинстве языков написаны на английском). Поэтому английский кажется хорошим выбором. Переменные, как правило, не имеют очень сложных имен, например xCounter, isXYZ и т. Д. И если их трудно назвать, я бы воспринял это как верный признак того, что уровень абстракции, на котором объявляется эта переменная, не соответствует правильный.

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

Что-то должно дать ☺

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

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

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

И вы всегда можете выполнить рефакторинг, если какое-то слово выглядит неверным.

I am not sure about the specific problem i.e. variable names are not descriptive, or are they using variable names aren't in English, variable naming style is inconsistent etc. Either way, you can try to establish detailed coding standards and perhaps use code audits or reviews to enforce them. For example:

• Using "temp" as the name of local variables is not allowed
• Variables must be named so that the purpose of the variable is obvious
• Always use a consistent style to name variables (e.g. Camel Case)

The key would be to publish these rules and enforce them for the entire organization.

Оператор EXECUTE просто имеет другую грамматику, чем другие операторы, такие как SELECT и SET. Например, обратите внимание на раздел синтаксиса в верхней части следующих двух страниц.

Оператор EXECUTE: http://msdn.microsoft.com/en-us/library/ms188332.aspx

Оператор SET: http://msdn.microsoft.com/en-us/library/ms189484.aspx

Синтаксис EXECUTE принимает только значение

[[@ parameter =] { значение | @variable [ВЫХОД] | [ПО УМОЛЧАНИЮ]]

В то время как синтаксис SET принимает выражение

{@ local_variable = выражение }

Значение - это просто жестко закодированная константа, но выражение будет оцениваться. Это похоже на использование varchar 'SELECT 1 + 1'. Сейчас это просто значение varchar. Однако вы можете оценить строку следующим образом:

EXEC('SELECT 1 + 1')

Я полагаю, все, что я указываю, это то, что команда EXEC не допускает выражения по определению, что вы, по-видимому, уже выяснили. Я не знаю, каковы намерения разработчиков T-SQL, когда они сделали это таким образом. Я полагаю, что грамматика просто выйдет из-под контроля, если вам разрешено создавать подзапросы внутри подзапросов в списке параметров хранимой процедуры.

Выражение T-SQL: http://msdn.microsoft.