Следует ли избегать определенных программных конструкций (и других) ради обслуживания?

Question

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

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

Однако я не уверен, будет ли программист по обслуживанию знать каждую конструкцию, так как многие из нас не пришли из ac # background, и я не уверен, что он так же увлечен программированием, как я, или просто относился к нему как обычная дневная работа. Итак, мои вопросы:

• Следует ли избегать определенных программных конструкций для улучшения сопровождения?

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

• Является ли обязанностью программиста по техническому обслуживанию полностью выучить язык?

Answer 1

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

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

Answer 2

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

Избегайте определенных конструкций, таких как делегаты и лямбда-выражениявыражения не должны быть подходящим способом, если их правильно и разумно использовать, языковые функции, подобные этим, могут значительно снизить сложность вашего кода и сделать их более краткими и выразительными.В конце концов, в этом красота LINQ, не так ли?; -)

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

Answer 3

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

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

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

Answer 4

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

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

Мое эмпирическое правило - используйте «основной язык» настолько, насколько это возможно для человека, и, когда вы отойдете от этого, тщательно документируйте свой подход. Избегайте использования синтаксического сахара, чтобы сделать ваш код короче, если это не действительно стандартная идиома (например, свойства в C #). Читаемость должна превосходить скорость печати каждый раз.

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